comparison 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
comparison
equal deleted inserted replaced
58:e6a1d1699ebb 59:3ead88660a4e
22 features are to be included: 22 features are to be included:
23 23
24 * 176x220 pixel color display (no touch) 24 * 176x220 pixel color display (no touch)
25 * 21-button main keypad 25 * 21-button main keypad
26 * 3 side buttons for volume control and an auxiliary function 26 * 3 side buttons for volume control and an auxiliary function
27 * hands-free loudspeaker 27 * hands-free loudspeaker, also to be used for ringing
28 * vibrator 28 * vibrator
29 * USB port that combines charging and computer interface 29 * USB port that combines charging and computer interface
30 * wired analog headset jack 30 * wired analog headset jack
31 * single SIM slot 31 * single SIM slot
32 32
1235 firmware will "vibrate" virtually. 1235 firmware will "vibrate" virtually.
1236 1236
1237 On development boards such as FC Venus, the vibrator on/off function can turn a 1237 On development boards such as FC Venus, the vibrator on/off function can turn a
1238 LED on and off to provide an indication of the UI layers making a vibrating 1238 LED on and off to provide an indication of the UI layers making a vibrating
1239 alert. 1239 alert.
1240
1241 3. Venus development board
1242
1243 As of the summer of 2021, FreeCalypso handset development has reached a point
1244 where a new development board is desired, to take the place of our current Luna
1245 development platform. The newly planned FreeCalypso development board is
1246 codenamed Venus, and it is envisioned as serving two goals:
1247
1248 1) Many of the hardware features intended for the ultimate FC handset product
1249 as described in Chapter 1 can be prototyped on this Venus board;
1250
1251 2) The board will serve as the ideal firmware development platform, covering all
1252 features and options that are listed in the previous chapter and defined as
1253 being in scope for FC handset firmware.
1254
1255 The following sections spell out the design specification for this Venus
1256 development board.
1257
1258 3.1. Build principle
1259
1260 The board will be built in the "hard" way, with the Calypso+Iota+RF chipset
1261 implemented directly on the Venus board itself, as opposed to using a Tango
1262 (iWOW TR-800) module. This approach is necessary because we need some Calypso
1263 and Iota signals that are not brought out on TR-800:
1264
1265 1) We need Iota HSMICBIAS, HSMICP and HSO signals (the 3rd audio channel) in
1266 addition to the primary and secondary audio channels, in order to prototype
1267 section 1.7 hardware for the real handset, and in order to provide a proper
1268 firmware development platform for section 2.3.
1269
1270 2) We need Calypso BU/PWT output so we can implement an old-fashioned buzzer,
1271 which we need in order to develop and maintain firmware per section 2.4,
1272 supporting both buzzer and Melody E1 ringing.
1273
1274 Once we have accepted that we have to bite the bullet and build our Venus board
1275 in the "hard" way, we can also implement some other nice-to-have functions that
1276 would have been deemed non-essential otherwise:
1277
1278 * We can bring out Calypso JTAG (which is not brought out on TR-800) like we did
1279 on FCDEV3B. In the Mother's experience there is very little actual need for
1280 Calypso JTAG, but it would be improper to omit this interface on a development
1281 board when bringing it out is possible.
1282
1283 * With access to the internal ON_nOFF signal, we can implement a reliable
1284 chipset-ON LED indicator, also like we did on FCDEV3B.
1285
1286 * We can implement both LPG and PWL LEDs like on the original D-Sample. Neither
1287 LED is strictly needed for the handset firmware functional scope or for
1288 prototyping toward the final handset; at least one LED is desired for the
1289 purpose of indicating virtual vibrator on/off state, but similarly to other
1290 considerations, it would be improper to pass up the opportunity to implement
1291 both LEDs.
1292
1293 * Mostly unrelated to the handset project, falling instead into the realm of
1294 general Calypso chipset knowledge recovery, I have wanted for a long time to
1295 sniff the internal chip-to-chip VSP interface between Calypso and Iota - but
1296 such feat cannot be accomplished on any currently existing hardware, as it's
1297 an internal interface going from one BGA to another on PCB inner layers. If
1298 we are building a new Calypso development board for other purposes, it would
1299 be nifty to throw in a VSP tap header as well.
1300
1301 3.2. Purpose and scope
1302
1303 Aside from the logically unrelated VSP tap feature, our Venus board will be
1304 intended for handset firmware development and handset hardware prototyping only.
1305 It is not intended for non-handset directions of interest - for other interests
1306 and purposes, use Caramel2 or FCDEV3B.
1307
1308 Calypso MCSI will not be available on FC Venus - in handset applications MCSI
1309 pins are switched into GPIO mode, and we'll be using these GPIOs for LCD
1310 backlight control on both Venus and the final handset. (Our current Luna
1311 platform is likewise.) If you need MCSI, then you are doing modem work, not
1312 handset, so use Caramel2 or FCDEV3B.
1313
1314 3.3. RF bands and PCB layout
1315
1316 The Mother's intent for the Venus board is to stop copying Openmoko's triband
1317 PCB layout and instead switch to TI's original Leonardo+ quadband layout, which
1318 has been recovered from iWOW TR-800 via professional PCB reverse engineering.
1319 We will need quadband RF for the final FC Libre Dumbphone handset, thus it would
1320 be best to switch to it now, starting with Venus.
1321
1322 3.4. Power supply arrangement
1323
1324 FC Venus will have the same orange Weidmuller power input connector as previous
1325 TI and FreeCalypso development boards C-Sample, D-Sample, Leonardo, FCDEV3B and
1326 Caramel2. Ready-made VBAT needs to be provided via this connector, fed directly
1327 to the core chipset and to VBAT-powered peripherals, no on-board power
1328 conversion. During development, operation with an AC-mains-powered fixed 3.6 V
1329 DC supply is generally much more convenient than a real battery.
1330
1331 For development and testing of handset battery management in the firmware, and
1332 for exercising the charging boot path in particular, Iota VCHG needs to be
1333 brought out like it is on iWOW DSK and FC Caramel2 boards, to be connected with
1334 a jumper wire to +5V pin on the DUART28 USB adapter whenever a "charger plugged"
1335 condition needs to be presented to the chipset. FC Venus will feature a 2x4 pin
1336 header with Iota BCI signals like on Caramel2:
1337
1338 ICTL VCCS
1339 PCHG VCHG
1340 ADIN2 ADIN1
1341 GND GND
1342
1343 The Mother's approach to development and testing of higher-level UI functions
1344 dealing with battery management is to use the BSIM feature of our FCHG driver,
1345 in which case the board remains powered from a fixed DC supply (no actual
1346 battery) and only VCHG needs to be connected. However, if a need arises to
1347 connect an actual battery and an actual Iota-controlled charging circuit, it
1348 will be possible: the battery will need to be connected to the orange power
1349 input connector, and the control signals for the charging circuit will need to
1350 be connected to the 2x4 header.