FreeCalypso > hg > freecalypso-ui-dev

comparison README @ 10:ad0d9f7c06e9 default tip

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
README: update for the present situation
author Mychaela Falconia <falcon@freecalypso.org>
date Sun, 29 Dec 2019 23:01:26 +0000
parents 6c35c9f2ecab
children
comparison
equal deleted inserted replaced
9:6c35c9f2ecab 10:ad0d9f7c06e9
71 71
72 This new approach works with current FC Magnetite firmware, and has been tested 72 This new approach works with current FC Magnetite firmware, and has been tested
73 in a few different ways: 73 in a few different ways:
74 74
75 * We have a real TI-made D-Sample board and we can run our Magnetite firmware 75 * We have a real TI-made D-Sample board and we can run our Magnetite firmware
76 on it, but lacking the tpudrv10 driver code for Clara RF, we are running with 76 on it, but lacking the real tpudrv10.c driver code for Clara RF, we are
77 a non-functional placeholder stub for the TPU driver. The D-Sample board thus 77 running with a disassembly-based reconstruction attempt which is unfortunately
78 has no GSM radio functionality when running our fw, and the firmware can only 78 still broken and non-functional. The D-Sample board thus has no GSM radio
79 do what any regular phone would do in an area with zero coverage: limited to 79 functionality when running our fw, and the firmware can only do what any
80 stepping through menus and examining SIM phonebook entries and stored 80 regular phone would do in an area with zero coverage: limited to stepping
81 messages. The physical LCD output works, but is often garbled due to what 81 through menus and examining SIM phonebook entries and stored messages. The
82 appears to be a hardware problem. Running fc-lcdpoll|fc-lcdemu against this 82 physical LCD output works, but is often garbled due to what appears to be a
83 setup results in the virtual LCD mirroring the physical one, albeit with some 83 hardware problem. Running fc-lcdpoll|fc-lcdemu against this setup results in
84 lag, and the virtual LCD shows what the physical one *should* display if it 84 the virtual LCD mirroring the physical one, albeit with seconds of lag, and
85 weren't garbled. 85 the virtual LCD shows what the physical one *should* display if it weren't
86 garbled.
86 87
87 * One can run a UI-enabled Magnetite build on our FCDEV3B modem board and use 88 * One can run a UI-enabled Magnetite build on our FCDEV3B modem board and use
88 the fc-lcdpoll|fc-lcdemu pipe to display what the fw puts in the framebuffer. 89 the fc-lcdpoll|fc-lcdemu pipe to display what the fw puts in the framebuffer.
89 Unlike the D-Sample, our FCDEV3B has perfectly working GSM radio, thus this 90 Unlike the D-Sample, our FCDEV3B has perfectly working GSM radio, thus this
90 setup allows us to see the behaviour of the UI firmware with a working radio 91 setup allows us to see the behaviour of the UI firmware with a working radio
96 sending simulated keystrokes via RVTMUX encoded in GPF system primitives, and 97 sending simulated keystrokes via RVTMUX encoded in GPF system primitives, and
97 we have recently figured out how to use it. Our fc-shell utility now offers 98 we have recently figured out how to use it. Our fc-shell utility now offers
98 the new key command for sending such simulated keypresses to the target, and 99 the new key command for sending such simulated keypresses to the target, and
99 by combining this key entry mechanism with the present fc-lcdpoll|fc-lcdemu 100 by combining this key entry mechanism with the present fc-lcdpoll|fc-lcdemu
100 display viewing mechanism, we've been able to exercise the UI a little 101 display viewing mechanism, we've been able to exercise the UI a little
101 further. This approach definitely shows some promise. 102 further.
102 103
103 * The Pirelli DP-L10 target has also been tried. I was hoping that it would 104 * One can also use a Pirelli DP-L10 phone instead of FCDEV3B. The long-time
104 make a good platform by virtue of having a working GSM radio (unlike the 105 bug that caused GSM radio functionality to break if it was brought up without
105 D-Sample sans tpudrv10 code) and a physical keypad that is just like the 106 getting some deep sleep first was fixed in 2019-03, and all GSM radio
106 one on the D-Sample, but no joy. When running FreeCalypso on Pirelli's alien 107 functionality now works just as well on this Pirelli target as it does on our
107 hardware, among many other issues that kill any possibility of turning this 108 native FCDEV3B. The native 128x128 pixel LCD on this phone remains dark and
108 alien hw into a libre phone, we get this one highly bizarre misbehaviour for 109 unused for now because it is too small to display TI's 176x220 pixel UI, but
109 which we have absolutely no explanation: the radio works OK *only if* the 110 the present fc-lcdpoll|fc-lcdemu mechanism works just as well on the Pirelli
110 firmware is built with deep sleep enabled in CST (i.e., enabled by default on 111 as it does on FCDEV3B. However, the Pirelli phone has a physical keypad that
111 boot), and the Calypso gets to do some deep sleeps prior to the operator 112 has the same repertoire of buttons as D-Sample, and our fw knows and supports
112 manually bringing it up with AT commands. If deep sleep is disabled, as soon 113 Pirelli's keypad wiring. Thus if you run a UI-enabled Magnetite build on the
113 as you try to bring the radio up, the Calypso DSP falls over with errors 114 Pirelli, you can use the phone's native keypad to drive this UI, but you have
114 which we naturally have no way of debugging. The most recent experiment has 115 to use the fc-lcdpoll|fc-lcdemu mechanism to see the display output.
115 revealed that this same DSP death behaviour (resulting in no working GSM
116 radio) occurs even when deep sleep is enabled if the firmware is built in the
117 MFW configuration (UI layers included) - as the UI layers command the radio
118 bring-up immediately on boot, the DSP falls over. Thus we are rudely reminded
119 once more than the Pirelli target is a dead end.
120 116
121 One currently outstanding defect with this fc-lcdpoll mechanism is that rvinterf 117 One currently outstanding defect with this fc-lcdpoll mechanism is that rvinterf
122 currently prints all ETM packets as full hex dumps, and the flood of all that 118 currently prints all ETM packets as full hex dumps, and the flood of all that
123 hex in the rvinterf window makes that window unusable for its original intended 119 hex in the rvinterf window makes that window unusable for its original intended
124 purpose of seeing other debug output from the fw. This voluminous rvinterf 120 purpose of seeing other debug output from the fw. This voluminous rvinterf
125 output also slows down the rate at which the LCD framebuffer is polled. One 121 output also slows down the rate at which the LCD framebuffer is polled. One
126 can run rvinterf with the -n option to suppress its output, but then all other 122 can run rvinterf with the -n option to suppress its output, but then all other
127 debug trace output will be lost too. I plan on fixing rvinterf at some point 123 debug trace output will be lost too. Back in 2018-03 I was thinking about
128 in the future to make its output less voluminous by default: keep the human- 124 fixing rvinterf at some point to make its output less voluminous by default,
129 readable traces, but omit the rarely-useful hex dumps from the default output. 125 keeping the human-readable traces, but omitting the rarely-useful hex dumps
126 from the default output - but now I am thinking of different approaches as
127 outlined below.
130 128
131 Baud rate considerations 129 Baud rate considerations
132 ======================== 130 ========================
133 131
134 The ETM memory read approach implemented in fc-lcdpoll is a lock-step, one read 132 The ETM memory read approach implemented in fc-lcdpoll is a lock-step, one read
140 baud is still preferable. To change the RVTMUX serial baud rate from 115200 bps 138 baud is still preferable. To change the RVTMUX serial baud rate from 115200 bps
141 to 812500 bps in your Magnetite firmware build, simply add a 139 to 812500 bps in your Magnetite firmware build, simply add a
142 TR_BAUD_CONFIG=TR_BAUD_812500 argument to your ./configure.sh line, 140 TR_BAUD_CONFIG=TR_BAUD_812500 argument to your ./configure.sh line,
143 and remember to pass the -B812500 option to rvinterf when talking to such 141 and remember to pass the -B812500 option to rvinterf when talking to such
144 trace-speed-increased firmware. 142 trace-speed-increased firmware.
143
144 New thoughts as of 2019-12
145 ==========================
146
147 While the fc-lcdpoll approach implemented in 2018-03 is much cleaner and much
148 more workable than the original 2015-09 approach, the update rate of the virtual
149 LCD is painfully slow, which is why no actual UI development work has been done
150 yet via this approach. It needs to be remembered that a 176x220 pixel
151 framebuffer image with 16 bits per pixel weighs 77440 bytes, while the
152 theoretical maximum throughput of a Calypso UART at the maximum 812500 baud rate
153 is 81250 bytes per second - thus even under ideal conditions it will still take
154 almost a full second to push out a single frame update. The original 2015-09
155 approach tried to get close to this theoretical maximum update rate by having
156 the firmware stream out framebuffer updates continuously, but embedding this
157 stream within RVTMUX resulted in overwhelming the trace mechanism beyond what
158 it was meant to handle.
159
160 The newer 2018-03 approach avoids overstressing the trace mechanism, but the new
161 drawback is that the update rate of the virtual LCD got even slower: it now
162 takes about 4 s to update the virtual LCD window by reading out the firmware's
163 framebuffer via ETM, thus any UI features (animations, temporary message
164 pop-ups) that last less than 4 s become lost. This unacceptable lag in visible
165 display updates is the main reason why I did not pursue further UI development
166 work back in 2018 using this mechanism.
167
168 If we were to continue down the virtual LCD route as opposed to looking for a
169 new Calypso platform with a suitable hardware LCD, one possible approach would
170 be to make use of two fully accessible UARTs on our FCDEV3B as opposed to just
171 one UART accessible on our previous OM GTA02 and Pirelli DP-L10 platforms. One
172 idea would be to keep the IrDA UART for RVTMUX and keep it free from virtual LCD
173 blit traffic, remove the ASCII AT command channel from the MODEM UART (not
174 needed for basic handset UI work) and repurpose the MODEM UART for a new ad hoc
175 interface that would carry just virtual LCD blits and nothing else. It would be
176 similar to going back to the original 2015-09 approach, but using a dedicated
177 UART and thus not loading the RiViera Trace mechanism at all.
178
179 However, as of right now (final days of 2019) I (Mother Mychaela) am not looking
180 at any more virtual LCD approaches because as explained above, even under ideal
181 conditions we would still have a lag of almost a full second per frame update -
182 and no real LCD on any real phone or proper development board is that slow.
183
184 Instead my view is that the proper solution is to acquire or create a UI
185 development platform whose LCD subsystem would be no worse than D-Sample. The
186 exact arrangement implemented on the DS board is unknown because we have no
187 schematics or any other hw docs, but the R2D driver in TI's firmware implements
188 both LCD module configuration writes and actual pixel output by writing 16-bit
189 words into certain magic addresses in the nCS3 address space, meaning that a
190 16-bit parallel microprocessor bus write interface is implemented in some
191 manner. The 128x128 pixel LCD (also 16-bit color) on the Pirelli DP-L10 is
192 similarly memory-mapped, with both commands and pixel data written as 16-bit
193 words into magic addresses on another chip select (nCS4 in Pirelli's case) -
194 although they have the additional complication of going through that SPCA552E
195 camera chip which we would much rather not have.
196
197 Smaller LCDs on lower-end phones are attached serially, using either uWire or
198 I2C, but note that the largest serial LCD we have ever seen on a real-life
199 Calypso phone is the 96x64 pixel 16-bit color LCD on the C139. Pirelli's
200 128x128 pixel LCD is already 2.6 times larger in terms of bits per frame, and
201 it is parallel memory-mapped, not serially interfaced any more. TI's 176x220
202 pixel LCD on the D-Sample (also 16-bit color) is another 2.3 times larger than
203 Pirelli's 128x128, and it is also parallel memory-mapped. I desire a 176x220
204 pixel LCD for UI development so I can see TI's original UI in its full glory,
205 and I feel that interfacing it to the Calypso in any other way than 16-bit
206 parallel memory-mapped would be substandard: the update rate would be slower
207 than it was on the original D-Sample, and the user experience with the UI would
208 no longer be the same as what TI's original developers experienced when they
209 implemented this UI.
210
211 The current situation as of the last days of 2019 is that we are looking to put
212 together our own FC Luna UI development platform with a memory-mapped parallel-
213 interfaced 176x220 pixel LCD using a certain historical development board as our
214 starting point. Our current hope is to be able to work on this project in the
215 first half of 2020 once the starting-point hw arrives at the Mother's shop in
216 California.