diff FC-handset-spec @ 59:3ead88660a4e

FC-handset-spec: started Venus board description
author Mychaela Falconia <falcon@freecalypso.org>
date Sun, 13 Jun 2021 04:10:21 +0000
parents e6a1d1699ebb
children f0d9a2cf15d2
line wrap: on
line diff
--- 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.