# HG changeset patch # User Mychaela Falconia # Date 1623557421 0 # Node ID 3ead88660a4e7e9bb6a9cef18b2dbb8783c3504f # Parent e6a1d1699ebb56a63636a2d25fd26339d0348217 FC-handset-spec: started Venus board description diff -r e6a1d1699ebb -r 3ead88660a4e FC-handset-spec --- a/FC-handset-spec Sun Jun 13 02:31:07 2021 +0000 +++ b/FC-handset-spec Sun Jun 13 04:10:21 2021 +0000 @@ -24,7 +24,7 @@ * 176x220 pixel color display (no touch) * 21-button main keypad * 3 side buttons for volume control and an auxiliary function -* hands-free loudspeaker +* hands-free loudspeaker, also to be used for ringing * vibrator * USB port that combines charging and computer interface * wired analog headset jack @@ -1237,3 +1237,114 @@ On development boards such as FC Venus, the vibrator on/off function can turn a LED on and off to provide an indication of the UI layers making a vibrating alert. + +3. Venus development board + +As of the summer of 2021, FreeCalypso handset development has reached a point +where a new development board is desired, to take the place of our current Luna +development platform. The newly planned FreeCalypso development board is +codenamed Venus, and it is envisioned as serving two goals: + +1) Many of the hardware features intended for the ultimate FC handset product + as described in Chapter 1 can be prototyped on this Venus board; + +2) The board will serve as the ideal firmware development platform, covering all + features and options that are listed in the previous chapter and defined as + being in scope for FC handset firmware. + +The following sections spell out the design specification for this Venus +development board. + +3.1. Build principle + +The board will be built in the "hard" way, with the Calypso+Iota+RF chipset +implemented directly on the Venus board itself, as opposed to using a Tango +(iWOW TR-800) module. This approach is necessary because we need some Calypso +and Iota signals that are not brought out on TR-800: + +1) We need Iota HSMICBIAS, HSMICP and HSO signals (the 3rd audio channel) in + addition to the primary and secondary audio channels, in order to prototype + section 1.7 hardware for the real handset, and in order to provide a proper + firmware development platform for section 2.3. + +2) We need Calypso BU/PWT output so we can implement an old-fashioned buzzer, + which we need in order to develop and maintain firmware per section 2.4, + supporting both buzzer and Melody E1 ringing. + +Once we have accepted that we have to bite the bullet and build our Venus board +in the "hard" way, we can also implement some other nice-to-have functions that +would have been deemed non-essential otherwise: + +* We can bring out Calypso JTAG (which is not brought out on TR-800) like we did + on FCDEV3B. In the Mother's experience there is very little actual need for + Calypso JTAG, but it would be improper to omit this interface on a development + board when bringing it out is possible. + +* With access to the internal ON_nOFF signal, we can implement a reliable + chipset-ON LED indicator, also like we did on FCDEV3B. + +* We can implement both LPG and PWL LEDs like on the original D-Sample. Neither + LED is strictly needed for the handset firmware functional scope or for + prototyping toward the final handset; at least one LED is desired for the + purpose of indicating virtual vibrator on/off state, but similarly to other + considerations, it would be improper to pass up the opportunity to implement + both LEDs. + +* Mostly unrelated to the handset project, falling instead into the realm of + general Calypso chipset knowledge recovery, I have wanted for a long time to + sniff the internal chip-to-chip VSP interface between Calypso and Iota - but + such feat cannot be accomplished on any currently existing hardware, as it's + an internal interface going from one BGA to another on PCB inner layers. If + we are building a new Calypso development board for other purposes, it would + be nifty to throw in a VSP tap header as well. + +3.2. Purpose and scope + +Aside from the logically unrelated VSP tap feature, our Venus board will be +intended for handset firmware development and handset hardware prototyping only. +It is not intended for non-handset directions of interest - for other interests +and purposes, use Caramel2 or FCDEV3B. + +Calypso MCSI will not be available on FC Venus - in handset applications MCSI +pins are switched into GPIO mode, and we'll be using these GPIOs for LCD +backlight control on both Venus and the final handset. (Our current Luna +platform is likewise.) If you need MCSI, then you are doing modem work, not +handset, so use Caramel2 or FCDEV3B. + +3.3. RF bands and PCB layout + +The Mother's intent for the Venus board is to stop copying Openmoko's triband +PCB layout and instead switch to TI's original Leonardo+ quadband layout, which +has been recovered from iWOW TR-800 via professional PCB reverse engineering. +We will need quadband RF for the final FC Libre Dumbphone handset, thus it would +be best to switch to it now, starting with Venus. + +3.4. Power supply arrangement + +FC Venus will have the same orange Weidmuller power input connector as previous +TI and FreeCalypso development boards C-Sample, D-Sample, Leonardo, FCDEV3B and +Caramel2. Ready-made VBAT needs to be provided via this connector, fed directly +to the core chipset and to VBAT-powered peripherals, no on-board power +conversion. During development, operation with an AC-mains-powered fixed 3.6 V +DC supply is generally much more convenient than a real battery. + +For development and testing of handset battery management in the firmware, and +for exercising the charging boot path in particular, Iota VCHG needs to be +brought out like it is on iWOW DSK and FC Caramel2 boards, to be connected with +a jumper wire to +5V pin on the DUART28 USB adapter whenever a "charger plugged" +condition needs to be presented to the chipset. FC Venus will feature a 2x4 pin +header with Iota BCI signals like on Caramel2: + +ICTL VCCS +PCHG VCHG +ADIN2 ADIN1 +GND GND + +The Mother's approach to development and testing of higher-level UI functions +dealing with battery management is to use the BSIM feature of our FCHG driver, +in which case the board remains powered from a fixed DC supply (no actual +battery) and only VCHG needs to be connected. However, if a need arises to +connect an actual battery and an actual Iota-controlled charging circuit, it +will be possible: the battery will need to be connected to the orange power +input connector, and the control signals for the charging circuit will need to +be connected to the 2x4 header.