FreeCalypso handset project update

[Mychaela Falconia]

Hello FreeCalypso community,

It is time for me to post another update on what I am currently doing
in the project.  My primary goal remains the same: right now I use a
Pirelli DP-L10 (running its original proprietary fw) as my personal
everyday phone, and I seek to replace it with my own phone, meaning
one in which all key hardware design decisions are made by me,
optimized for running FreeCalypso handset firmware.

I've been doing FC handset fw development work (FC Tourmaline source
repository) on my current Luna platform; this platform consists of an
LCD board (an LCD module mounted on a simple carrier board I concocted
last year) and a 5x5 keypad board, connected with ribbon cables to a
Caramel-type Calypso motherboard, originally iWOW DSK and now our own
FC Caramel2.  This platform works well for most handset fw development
tasks, but it still has a few significant limitations:

1) The physical arrangement with a bunch of separate boards connected
with ribbon cables is an utter mess.

2) The TR-800 aka Tango module that forms the core of both iWOW DSK
and FC Caramel2 motherboards brings out most Calypso+Iota chipset
signals (many more than the competition), but not all.  Here are the
issues that result from some of the more obscure chipset signals not
being brought out on TR-800:

2a) Calypso buzzer output BU/PWT is not brought out.  TI's TCS211
version of their demo/prototype/PoC phone handset UI code was developed
on TI's D-Sample platform, that platform does have a classic cellphone
buzzer (apparently magnetic, not piezo like I previously thought)
implemented right on the DS motherboard itself, and TI's TCS211 version
(as opposed to other non-Calypso chipset versions) of their proto-UI
makes ringing sounds (on incoming calls and SMS) via the Calypso
buzzer, not via any other mechanism.  When we run on a platform like
Luna where this Calypso-driven buzzer is missing, the noise-making
code in the fw does nothing (it still makes the Calypso chip put out
the ringing tone waveform on the BU output, but that output then goes
nowhere), hence we can't tell if it is working correctly or not.

2b) My end goal is to build my long-desired FC Libre Dumbphone handset
replacing Pirelli DP-L10, hence our handset will need to implement 3
audio routing modes: default earpiece and mic (classic hold-up-to-ear
operation), hands-free loudspeaker mode, and a wired headset jack.
The default earpiece and mic will be connected to Iota chip signals
that are dedicated for these standard functions, the hands-free
loudspeaker will be driven with the same amplifier chip as proven good
on FCDEV3B, connected to Iota AUX output, and the wired headset jack
will be implemented using Iota signals dedicated for this purpose, the
3 signals beginning with HS.  But this 3rd audio channel is not brought
out on TR-800 - the two headset jacks on iWOW DSK and Caramel2 boards
are the main and AUX audio channels instead.

Based on these considerations, I am now thinking about building a new
development board, a successor to our current Luna arrangement, a new
board tentatively named FC Venus.  This proposed FC Venus board will
have the following improvements over Luna:

* It will be a single monolithic board specifically intended for
handset fw development, as opposed to a "generic" module evaluation
board like Caramel/C2, meaning that the LCD and the keypad matrix will
be right on the main board itself.  There will be no support for
non-handset configurations like MCSI on FC Venus - use FCDEV3B or C2
for those other configurations instead.  Calypso MCSI pins are
repurposed as GPIOs in the handset configuration, and I am using these
GPIOs for LCD and later keypad backlight control.

* The board will be built in the expensive way, with the Calypso core
chipset implemented directly on the Venus board itself just like on
FCDEV3B, not the cheap way where the Calypso part is encapsulated in a
premade module like TR-800.  Yes, the higher cost will be unfortunate,
but this board will serve as a practice run for the actual handset
motherboard which will also need to be built in the direct-chipset
way, and using raw chips directly instead of going through TR-800 will
allow us to connect the Calypso buzzer and the 3rd audio channel which
are otherwise inaccessible.

* When it comes to the Calypso+Iota+RF chipset to be laid out directly
on the Venus board, instead of continuing to copy Openmoko's triband
layout, I will go for TI's original Leonardo quadband layout, which
was fully recovered last year (after being sorely missing for most of
FC project herstory) by reverse-engineering iWOW's PCB - the insides
of TR-800 are nothing but a mass-produced version of TI's original
Leonardo core.

* There will be a magnetic buzzer implemented directly on the Venus
board itself, just like on the original D-Sample, controlled by Calypso
BU/PWT output.  With this added hw feature, both the original TCS211 fw
and our current Tourmaline successor will finally run in their full
glory.

* All 3 audio paths that are envisioned for the real FC handset will
be implemented on the Venus board.  There will be two TRRS jacks in
the same pinout as on Caramel2 (originally iWOW's pinout), one carrying
the main audio channel like on current C2 (to be replaced with the
real earpiece and mic on the actual handset), the other being the
"true" headset jack connected to the headset audio channel.  There
will also be a 2-pin header for connecting a loudspeaker just like on
FCDEV3B, driven with the same proven-good amplifier circuit as on
FCDEV3B.  My intent for the actual FC handset is to produce ringtone
melodies using the hands-free loudspeaker and the Melody E1 feature of
Calypso DSP, i.e., unlike FC Venus development board, the final
handset won't have a buzzer.  But with FC Venus featuring both the
buzzer and the loudspeaker audio channel, it will be the perfect
platform for making the firmware transition from the former to the
latter.

* FC Venus will of course feature a 176x220 pixel color LCD just like
FC Luna, but I am hoping that the actual LCD module will be the final
one, suitable for the actual FC handset.  The HaoRan LCD module used
in our current Luna setup has good picture quality and the right kind
of electrical interface, but it is not suitable for the handset because
of mechanical issues.  The other Startek LCD which I evaluated back in
2018 also exhibited good picture quality, but it suffers from similar
mechanical mounting problems, and the 3 backlight LEDs inside that
module share a common cathode, instead of the more typical common
anode configuration.  With my original backlight driver circuit design
using a resistor in series with each LED, it didn't matter whether we
put these resistors on the anode side or the cathode side - but I have
recently discovered a special white LED driver chip (MAX1916) that
will make a much better solution, and this chip requires separate
cathode connections for the 3 LEDs.  HaoRan's backlight LED wiring is
compatible with MAX1916, but Startek's is not.  But I have also
recently discovered yet another LCD manufacturer who makes a module
that appears to be perfect for our needs based on the specs, and I am
in the process of ordering samples from this new LCD vendor.

* The LCD backlight LED driver circuit will be implemented using the
just-mentioned MAX1916 chip.  All of our candidate 176x220 pixel LCDs
have the same principal quality as Pirelli's LCD: backlight is required
for readability, and when the backlight is turned off, we are going to
turn off the TFT panel as well (via LCD controller register settings)
to save power, thus we end up having not just backlight on/off control,
but more properly display on/off control as a whole.  In Tourmaline I
have already reworked the firmware design to work with BLRR (backlight
required for readability) displays, with appropriate logic such that
if you press any button while the display is off, the keypress that
turns on the display is "swallowed", not executing its otherwise
regular function - this is the part which Pirelli got right in their
fw, whereas Motorola got it badly wrong in theirs, severely hampering
usability of their phones.

* I am copying Pirelli's approach where the display brightness
(backlight intensity) can be switched between bright and dim.  In
Pirelli's design which I am copying, when you are playing with phone
menus or composing SMS etc, but are not in an active call, the display
switches between full brightness and totally off - it goes fully off
on timeout, and when you press a button to wake it up, it switches on
at full brightness, together with the keypad backlight.  But when you
are in a call, when the timer expires (and it's a shorter timer, 10 s
instead of 30 s), the display goes dim instead of fully off, and in
this dimmed (but still readable) state keypresses are NOT swallowed.
I have already replicated this logic in Tourmaline fw, but right now
we have no hw for switching display backlight intensity.  FC Venus
will have the same hw circuits for switching display backlight
intensity as I intend to have on the final FC handset.  My original
idea of using Calypso LT/PWL output to vary backlight intensity via
PWM won't work with the new MAX1916 approach, but we don't need 64 or
256 different backlight levels, we only need two (full brightness and
dim mode for calls), and I came up with a GPIO-controlled switched
resistor approach that will not only work with MAX1916, but will
actually behave better than PWM under low battery conditions.

* FC Venus will have Calypso JTAG brought out just like FCDEV3B.  In
all of my years working on FreeCalypso I found very little need for
JTAG, but because Venus will be a development board intended to take
the place of D-Sample, and because the board will be built in the
direct-chipset manner with all signals accessible, it won't be right
to omit JTAG.

Right now this FC Venus board project is in the planning phase.  One
of the most critical components is the LCD module, and rather than
stay with the same LCD as is used in our current Luna platform, I am
engaging with a new LCD vendor whose module looks very promising.  In
fact, when it comes to the HaoRan LCD module used in our current Luna
setups (of which only two have been made, I have one and our dear Das
Signal has the other), I don't have any more of these modules, and
these LCDs are not the kind of part which one can simply order online
- they are only available via direct engagement with the manufacturer,
and while I was able to get a few sample pieces back in 2018, there is
no guarantee that they are still available in small quantities - they
may well ask for some big MOQ this time.  With the new LCD vendor that
I found, I am taking a different approach: I am in the process of
buying sample pieces from them which they already agreed to sell to me,
and if these sample pieces turn out to be good in my testing, then I
will immediately place a larger order to satisfy anticipated lifetime
need for the actual handset project, as opposed to waiting years in
between.

Once I receive the sample LCD pieces from the new vendor (I just sent
them the payment via bank wire xfer - they don't take Paypal, yikes),
I will need to build a simple test board for the new LCD.  It will be
an LCD test board that connects to Caramel/C2 just like our current
HaoRan LCD board, but with the new LCD module on it, and also replacing
my 2020-hack backlight driver circuit (the one with 3.5 V LDO and very
low-value resistors) with the newly discovered MAX1916 - fortunately
the on/off control from Calypso side remains the same.  This LCD test
board will also need to include a pack of DIP switches selecting
different SET resistors for MAX1916, in order to empirically determine
the right LED currents for the two desired backlight intensity levels
(full brightness and in-call dimming), and a small series resistor in
the LCD controller power supply path for current measurement, to see
if we are programming its sleep modes correctly.  If the new LCD works
exactly as I desire, then I will buy a larger quantity of these LCD
modules, we will officially adopt this LCD for our FC handset and for
FC Venus, and we won't have to revisit these LCD woes any more.

This new LCD module I'm looking forward to testing, it has an FPC tail
that needs to be soldered directly to the application board (or more
specifically, to corresponding pads in the properly designed footprint
for this LCD), as opposed to using an FPC connector.  The connectorized
approach at first glance certainly *appears* to be friendlier to low-
volume tinkering applications like ours, but all current LCD modules
are thin overall and have flat backs (as opposed to older modules with
taller sides, leaving an indentation space in the back, like Pirelli's
LCD module), thus if the system designer wishes to tuck the FPC tail
underneath the module in the final assembly, then there is no vertical
space for the FPC connector.  OTOH, LCD modules with solder-type FPC
tails seem to be designed for the arrangement where the tail is folded
under the module, and I am going to find out experimentally on the LCD
test board.

So this is where we are now - I expect to have another update in a
month or so, once I get the new LCDs and build the test board for them.

Hasta la Victoria, Siempre,
Mychaela aka The Mother