LCD evaluation and other preparations for FC handset

[Mychaela Falconia]

So I am progressing with the evaluation of candidate LCD modules for
our FreeCalypso Libre Dumbphone handset.  So far I have received
sample LCD module pieces from two different Chinese manufacturers,
let's call them Vendor A and Vendor B, 5 sample pieces from each.
There is also a third manufacturer (Vendor C) - according to my last
communication with them, they will hopefully be sending me their
sample pieces some time this coming week.

Vendor A is basically a no-go - to put it simply, they lied to me
about the technical specs of their LCD.  They sent me one datasheet
originally, and when the sample pieces were already on their way to
me, they sent me a different datasheet.  The original datasheet said
that the controller's IM0 configuration pin is brought out, allowing
the LCD to be used with either an 8-bit or a 16-bit interface, but
then it turned out that the pieces they actually sent me do not have
this config pin brought out and are fixed-wired for 16-bit mode instead.
My current FT2232D method can only drive an 8-bit interface; in order
to test a 16-bit-only LCD I would have to design and build some other
(significantly more complicated) test setup, and there is no way I can
justify embarking on such a project.

But the other vendor's LCDs are much better - their product actually
matches the datasheet on the basis of which I ordered the samples -
and I have already made good progress with them.  This vendor sent me
not only the LCDs themselves, but also a breakout board that converts
the LCD's FPC interface to 2.54 mm header pins, or rather holes in the
PCB into which said pins can be soldered - I had to do the soldering
myself.  I soldered in the pins for contacts 1 through 37 (yes, a lot
of soldering, and I had to do it all myself by hand, as I was too
anxious and couldn't wait however long it would take to get pro
assistance), soldered resistors for the backlight LEDs into the
following 3 holes, and then made a whole rat's nest of jumper wires
(25 or so) to connect the LCD interface pins to an FT2232D breakout
board (the same FT2232D board as we use for FCDEV3B UARTs, but with
the EEPROM programmed differently), plus the power supplies: 3.3V for
all of the logic, but using raw 5V from USB with series resistors for
the backlight LEDs.

With the just-described rat's nest fully assembled, the backlight
lights up very nicely as soon as USB power is plugged in.  The
brightness looks quite decent with only about 48 mA flowing through
the LEDs in total, about 16 mA through each LED: the resistors I put
in series with the LEDs are 110 ohm each, the supply is 5 V, so
assuming 3.2 V LED drop, each LED should have about 16 mA flowing
through it - a very reasonable power budget for an LCD backlight.  And
of course in the actual handset we'll use Calypso PWL to dim this
backlight, so the display brightness (and thus its power draw) will be
a user setting.

I then used my libftdi-based lcdtest program (can be found in the
just-published freecalypso-hwlab repository) to put the FT2232D chip
into MCU host bus emulation mode and communicate with the ST7775R
controller inside the LCD module.  I successfully read this controller's
ID register through this interface, proving it working, and I also got
the LCD to turn on (although not yet known if it's in the right
configuration or not) through some register writes.  Thus we know that
my FT2232D hack works, and so does my rat's nest of jumper wires and
soldering hacks.

For the next step I need to get the correct set of ST7775R register
settings specific to this LCD module; I have already emailed the
vendor and am now awaiting their response.  It'll probably be Monday
China time.  Some (most? all? not sure) of these settings can probably
be figured out experimentally, but I am not going to give my business
to a vendor who won't provide their officially recommended register
settings.

And then there is the third vendor from whom I have yet to receive the
ordered sample pieces.  They have been very consistent in their
communication, never claimed one thing and then retracted it, thus
when I do receive their LCDs, they will need to be tested and
evaluated too.  They will also need to provide their own register
settings, and I will probably need to make a little PCB of my own to
connect their LCD to another FT2232D breakout board - as I understood
it, they don't have a breakout board like the other vendor.  But I
still wish to evaluate both of these two currently-viable candidate
LCDs - the selection of LCD for our handset needs to be as informed as
possible with respect to the available choices.

So that's the progress on the LCD search and evaluation front.  Once
we have our LCD selection nailed down, before I start on the actual
HSMBP (handset motherboard prototype) design, we will also need to
design and build a custom FT2232D adapter board which I am calling the
FreeCalypso UART+JTAG adapter.  With the FCDEV3B we are able to get
away with using COTS FT2232x breakout boards, but the handset will
have a different serial port arrangement similar to the Pirelli.  The
serial channel on the handset's built-in USB port will be suitable and
sufficient for end user usage (AT commands in normal operation, also
suitable for reflashing with fc-loadtool), but deep development and
low-level hardware bring-up will require the other serial channel
which will be brought out on an FPC/FFC connector, similar to
Openmoko's debug board arrangement and Pirelli's unpopulated debug
connector footprint.  And for me it makes the most sense in such
situations to build the needed debug adapter or test fixture first,
ahead of the main product hw - the hardware eng equivalent of test-
driven development in the sw world.

And we still need to fix and close the sleep mode bug.  I have a high
confidence in my current hypothesis that FDP driving the flash chip's
reset line is the culprit, but it looks like we won't be able to test
it empirically until we build our next board, be it FCDEV3Bv2 or the
first version of the HSMBP.  I was hoping to test my hypothesis
through a surgical experiment on a current FCDEV3B board, but now it
looks like that idea won't work: we can disconnect the reset line from
FDP by cutting a trace, but then it will float (not connected to
anything), which is bad.  I was hoping to be able to pull the flash
reset input up by connecting it to an adjacent pulled-up ball by way
of a solder bridge, but I was told that there is no way to make that
solder bridge stay in place as the memory IC BGA is soldered back on.
Right now I am trying to get a hold of the gentleman who polished the
Altium PCB layout for our current FCDEV3B boards (after the Iranians
left us with a slightly unfinished job) and see if he would be
interested in taking on a small job to make my desired changes for
FCDEV3Bv2 - I'll post an update when I know more.

Hasta la Victoria, Siempre,
Mychaela aka The Mother