freecalypso-docs: FC-handset-spec comparison

comparison FC-handset-spec @ 54:138021ca5eae

FC-handset-spec: starting firmware scope description

author	Mychaela Falconia <falcon@freecalypso.org>
date	Sat, 12 Jun 2021 05:32:38 +0000
parents	016f8cf2418c
children	df6c61d0e817

comparison

equal deleted inserted replaced

-:016f8cf2418c
+:138021ca5eae
 operation and readability interacts with the backlight:
 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
+LCDs are called transflective: primarily reflective, but can also operate in
-on the backlight if you need to operate the phone in darkness, such as
+transmissive mode when the optional backlight is turned on.  With these B&W
-outdoors at night or inside with all lights off.  The firmware in such phones
+displays, you only need to turn on the backlight if you need to operate the
-is typically designed to leave the actual display functional and updated at
+phone in darkness, such as outdoors at night or inside with all lights off.
-all times, with only the backlight subject to on/off control.
+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
 readable without the backlight at all - backlight required for readability
 (BLRR) is another way to describe such LCDs.  Because the display is not
 hence we are changing the wiring so that -Prts will trigger RPWON rather than
 PWON.  The same boot effect can still be achieved with -Pdtr triggering
 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.

FreeCalypso > hg > freecalypso-docs

comparison FC-handset-spec @ 54:138021ca5eae