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 _______________________________________________ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community
