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