# HG changeset patch # User Mychaela Falconia # Date 1623475958 0 # Node ID 138021ca5eae385f56c2be6aa03f7b69be6f1797 # Parent 016f8cf2418cbd4c8ba831c04b85dce8b9a8dbcb FC-handset-spec: starting firmware scope description diff -r 016f8cf2418c -r 138021ca5eae FC-handset-spec --- a/FC-handset-spec Sat Jun 12 02:58:47 2021 +0000 +++ b/FC-handset-spec Sat Jun 12 05:32:38 2021 +0000 @@ -123,11 +123,13 @@ 1) older phones with black&white LCDs: on all phones of this type which I've ever used, the display is perfectly readable without the backlight given ordinary ambient lighting, be it natural daylight or room lighting. Such - LCDs are called reflective. With these B&W displays, you only need to turn - on the backlight if you need to operate the phone in darkness, such as - outdoors at night or inside with all lights off. The firmware in such phones - is typically designed to leave the actual display functional and updated at - all times, with only the backlight subject to on/off control. + LCDs are called transflective: primarily reflective, but can also operate in + transmissive mode when the optional backlight is turned on. With these B&W + displays, you only need to turn on the backlight if you need to operate the + phone in darkness, such as outdoors at night or inside with all lights off. + The firmware in such phones is typically designed to leave the actual display + functional and updated at all times, with only the backlight subject to + on/off control. 2) most newer phones with color displays, of which Pirelli DP-L10 is a representative case, have transmissive LCDs that are not designed to be @@ -978,3 +980,106 @@ nTESTRESET, but it is a bigger hammer (reset of RTC can be unwanted), hence -Prts will be recommended as the gentler option, leaving -Pdtr for times when recovery from runaway code is needed. + +2. FC handset firmware functional scope specification + +FreeCalypso handset firmware will always run (perhaps with subset functionality) +on more hardware targets than just our main-goal FC Libre Dumbphone handset. It +already does: our firmware currently runs on our Luna development platform, and +prior to FC it ran on TI's original D-Sample platform. A very restricted +functional subset also runs on Motorola C139 hardware. + +If we consider only the main goal of FC Libre Dumbphone handset, then our +firmware evolution can be seen as strictly linear: we start with what we got +from TI, and we morph it toward what will be needed to operate our handset, +adding functionality and peripheral support which we need for our FC handset, +but which is not present in the starting point code from TI. However, we also +have side-branch functionality: at times when the code from TI supports +something which we don't need for our own FC handset, but which may be useful +for alien hardware targets, a moral imperative can be made for keeping and at +least minimally maintaining that functionality as a kind of side-branch feature, +a permitted configuration that is not needed for our own FC handset but needed +for others. Similarly, when we add support for entirely new peripherals that +are planned for our FC handset (such as the loudspeaker), we should make the +firmware change in such a way that targets without the extra feature can still +be supported. Finally, when we are changing the firmware in ways that +significantly depart from TI's original, it may sometimes be prudent to preserve +TI's original way as a lorekeeping option. + +The following sections will spell out what we support and what we don't support +in FreeCalypso handset firmware, and how these scoping decisions relate to our +starting point from TI, to our main goal of FC Libre Dumbphone handset, and to +secondary objectives of alien target support and lorekeeping. + +2.1. Display support + +2.1.1. Support for different display sizes + +By the very nature of the problem, any phone handset UI design will always be +quite specific to a particular display size in pixels, and also to the display +type as in color or black&white. The starting point code we got from TI +supports 3 different UI configurations in terms of size and coloration: + +* 176x220 pixel, 16-bit color; +* 176x220 pixel B&W; +* 84x48 pixel B&W. + +In FreeCalypso we have made two changes to this set of possible UI +configurations: + +1) The large (176x220 pixel) B&W option has been removed. In TI's delivery this + option was nothing more than a quick&dirty hack to extend their small (84x48 + pixel) B&W UI to the large D-Sample screen, and this configuration offers + nothing useful - any real display of such large size will always be color. + +2) The small B&W configuration has been extended from 84x48 to 96x64 pixels. + Why 96x64? Because it is the size in pixels of Motorola C139 LCD, and it is + the smallest LCD size found among those alien Calypso phones whose existence + is known to us and for which we have at least minimal support. Extending + this UI configuration from 84x48 to 96x64 pixels was an easy change because + it is an increase in screen real estate (not a decrease), and it is a fairly + small increment, such that UI design choices which were sensible for an 84x48 + pixel display are still sensible for 96x64. + +The main principal difference between our approach in FreeCalypso and what a +conventional commercial phone manufacturer would have done is that we are +retaining TI's smallbw configuration and keeping it supported, as opposed to +disregarding it and working only on the bigcolor UI config for our own planned +hardware product. We keep this smallbw UI configuration around, in the extended +96x64 pixel size, for two reasons: + +1) Lorekeeping: unlike TI's 176x220 pixel B&W config that was totally + uninteresting, TI's old smallbw UI (from the days of C-Sample) is + sufficiently interesting and unique (and naturally quite different from the + bigcolor version) to be worth preserving. + +2) By keeping this configuration around (not discarding it and not allowing it + to bitrot beyond repair), we keep the door open for the possibility of a + minimally usable FreeCalypso Lite aftermarket firmware for Motorola C139. + +Both UI configurations can be built for our current Luna platform, and both of +them display on our Luna LCD. The virtual framebuffer of 96x64 pix B&W in the +smallbw config is displayed in the center of our physical 176x220 pixel color +LCD, surrounded by a pale magenta border. The same ability to run both configs +will continue on our next development board (Venus). + +2.1.2. Backlight readability paradigm + +(See theoretical background in section 1.4.3.) + +Our actively maintained FC handset firmware has been paradigmatically redesigned +to assume a display which is NOT readable without the backlight. Our logical +primitives with respect to display control are display on/off, rather than +backlight on/off, and we swallow the initial keypress that turns on the display. + +This change is a significant departure from TI's original. The LCD on TI's +D-Sample is transflective, and when the backlight is off, the display remains +readable in ambient light. It is certainly better in this regard than Motorola +C139 LCD. And if we go back further in TI's history to C-Sample and earlier, +those 84x48 pixel B&W LCDs were the traditional mostly-reflective type, +perfectly readable without the backlight. + +This area is one where we are NOT retaining TI's original way as an option in +our actively maintained firmware. The difference between the two principal +paradigms is too great, and we don't have any active-demand prospective targets +with B&W displays of the old traditional kind.