FreeCalypso > hg > freecalypso-ui-dev
annotate README @ 10:ad0d9f7c06e9 default tip
README: update for the present situation
| author | Mychaela Falconia <falcon@freecalypso.org> |
|---|---|
| date | Sun, 29 Dec 2019 23:01:26 +0000 |
| parents | 6c35c9f2ecab |
| children |
| rev | line source |
|---|---|
| 6 | 1 This repository contains a couple of hack-utilities that have been developed as |
| 2 attempts at displaying TI's 176x220 pixel demo/prototype phone UI on an external | |
| 3 development host in the absence of a suitable Calypso target device with an LCD | |
| 4 of the needed large size. Two approaches have been tried, separated in time by | |
| 5 about 2.5 y: | |
| 6 | |
| 7 2015-09 approach | |
| 8 ================ | |
| 9 | |
| 10 A year before FreeCalypso Magnetite, when all we had was the TCS211 semi-src | |
| 11 from Sotovik with its original all-Windows build system, with all of the blobs | |
| 12 intact and no apparent hope of deblobbing, plus our first attempt at bottom-up | |
| 13 GSM fw with completely broken L1, we had built two hacked-up versions of TI's | |
| 14 TCS211 fw with TI's 176x220 pixel UI enabled: one running on the GTA02 modem, | |
| 15 the other running on the Pirelli DP-L10. Both were hacked up to emit raster | |
| 16 blits of the big 176x220 pix, 16 bits per pixel color UI on the RVTMUX serial | |
| 17 channel, running at Calypso's maximum baud rate of 812500 bps. These hacks | |
| 18 have not been touched since 2015-09, but they can still be found in the | |
| 19 historical leo2moko-debug and tcs211-pirelli Hg repositories on Bitbucket. | |
| 20 | |
| 21 A host utility named fc-lcdemu had been written to display these LCD blits | |
| 22 emitted by those hacked-up firmwares. It receives these blits via a pipe from | |
| 23 rvinterf and displays them in an X11 window; it thus naturally requires libX11 | |
| 24 to compile and an X11 display to run. X11 programming is a black art which | |
| 25 this author (Mychaela Falconia) once knew but now largely forgot, hence | |
| 26 fc-lcdemu was based on the HECterm project (an xterm-like terminal application | |
| 27 for X11) by the same author, but from a much earlier life phase. | |
| 28 | |
| 29 If you wish to resurrect and play with one of these external LCD output hacks | |
| 30 from 2015-09, you will need to invoke rvinterf with special arguments to tell | |
| 31 it to launch fc-lcdemu and to pass the LCD blits to it; the synopsis is as | |
| 32 follows: | |
| 33 | |
| 34 rvinterf -B812500 -X fc-lcdemu /dev/ttyXXX | |
| 35 | |
| 36 The -B812500 argument is needed to tell rvinterf to use this high baud rate, | |
| 37 and the -X option tells rvinterf to invoke the following named program (can be | |
| 38 a more complex shell command) with popen(3) and then feed it LCD blits received | |
|
9
6c35c9f2ecab
README: update for the fc-host-tools-r8 release
Mychaela Falconia <falcon@freecalypso.org>
parents:
8
diff
changeset
|
39 from the target. If you use the new version of rvinterf in fc-host-tools-r8 or |
|
6c35c9f2ecab
README: update for the fc-host-tools-r8 release
Mychaela Falconia <falcon@freecalypso.org>
parents:
8
diff
changeset
|
40 later, the old -v option is no longer needed and no longer accepted. |
| 6 | 41 |
| 42 This 2015-09 approach was putting a huge load on the RiViera Trace mechanism, | |
| 43 hacks were required in the firmware to massively super-size the memory space | |
| 44 allotted to RVT and to run the RVTMUX serial channel at 812500 baud, and even | |
| 45 with the supersized memory allocation and the maximum serial baud rate there | |
| 46 were still some 'Lost Message' traces. The hacks on the firmware side which | |
| 47 implement this 2015-09 approach have NOT been included in our current Magnetite | |
| 48 firmware. | |
| 49 | |
| 50 2018-03 approach | |
| 51 ================ | |
| 52 | |
| 53 Rivisiting the phone UI subproject of FreeCalypso in 2018, I got another idea | |
| 54 for how to get the LCD framebuffer bits out of a Calypso device: instead of | |
| 55 having the firmware push them out to the trace buffer every time r2d_refresh() | |
| 56 is called, have the fw do nothing, and have the external host read the | |
| 57 framebuffer memory out at its own pace via ETM memory read commands. The new | |
| 58 fc-lcdpoll utility implements this approach; in order to avoid having to reopen | |
| 59 the X11 can of worms, I made fc-lcdpoll output the blits in the form which the | |
| 60 already-existing fc-lcdemu code from 2015 takes as input, so you run a pipeline | |
| 61 like this: | |
| 62 | |
| 63 fc-lcdpoll framebuffer_base_addr | fc-lcdemu | |
| 64 | |
| 65 fc-lcdpoll connects to rvinterf as a regular client, thus you would typically | |
| 66 have rvinterf running already when you run the above pipeline in another window. | |
| 67 fc-lcdpoll needs to know the address of the in-RAM framebuffer maintained by | |
| 68 the R2D firmware component, and this address needs to be given on the command | |
| 69 line. You can find it by grepping the linker-generated map file (fwimage.map | |
| 70 or ramimage.map as appropriate) for the _r2d_lcd_memory_words symbol. | |
| 71 | |
| 72 This new approach works with current FC Magnetite firmware, and has been tested | |
| 73 in a few different ways: | |
| 74 | |
| 75 * We have a real TI-made D-Sample board and we can run our Magnetite firmware | |
|
10
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
76 on it, but lacking the real tpudrv10.c driver code for Clara RF, we are |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
77 running with a disassembly-based reconstruction attempt which is unfortunately |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
78 still broken and non-functional. The D-Sample board thus has no GSM radio |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
79 functionality when running our fw, and the firmware can only do what any |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
80 regular phone would do in an area with zero coverage: limited to stepping |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
81 through menus and examining SIM phonebook entries and stored messages. The |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
82 physical LCD output works, but is often garbled due to what appears to be a |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
83 hardware problem. Running fc-lcdpoll|fc-lcdemu against this setup results in |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
84 the virtual LCD mirroring the physical one, albeit with seconds of lag, and |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
85 the virtual LCD shows what the physical one *should* display if it weren't |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
86 garbled. |
| 6 | 87 |
| 88 * One can run a UI-enabled Magnetite build on our FCDEV3B modem board and use | |
| 89 the fc-lcdpoll|fc-lcdemu pipe to display what the fw puts in the framebuffer. | |
| 90 Unlike the D-Sample, our FCDEV3B has perfectly working GSM radio, thus this | |
| 91 setup allows us to see the behaviour of the UI firmware with a working radio | |
| 92 and thus a working GSM network connection underneath. By calling the number | |
| 93 of the SIM inserted into this setup, one can see the incoming call screen | |
| 94 followed by the missed call indication. Because there is no physical keypad | |
| 95 on the FCDEV3B, it appears at first that the show stops here with no way to | |
| 96 feed keypresses to the firmware, but TI's firmware does have a mechanism for | |
| 97 sending simulated keystrokes via RVTMUX encoded in GPF system primitives, and | |
| 98 we have recently figured out how to use it. Our fc-shell utility now offers | |
| 99 the new key command for sending such simulated keypresses to the target, and | |
| 100 by combining this key entry mechanism with the present fc-lcdpoll|fc-lcdemu | |
| 101 display viewing mechanism, we've been able to exercise the UI a little | |
|
10
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
102 further. |
| 6 | 103 |
|
10
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
104 * One can also use a Pirelli DP-L10 phone instead of FCDEV3B. The long-time |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
105 bug that caused GSM radio functionality to break if it was brought up without |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
106 getting some deep sleep first was fixed in 2019-03, and all GSM radio |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
107 functionality now works just as well on this Pirelli target as it does on our |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
108 native FCDEV3B. The native 128x128 pixel LCD on this phone remains dark and |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
109 unused for now because it is too small to display TI's 176x220 pixel UI, but |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
110 the present fc-lcdpoll|fc-lcdemu mechanism works just as well on the Pirelli |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
111 as it does on FCDEV3B. However, the Pirelli phone has a physical keypad that |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
112 has the same repertoire of buttons as D-Sample, and our fw knows and supports |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
113 Pirelli's keypad wiring. Thus if you run a UI-enabled Magnetite build on the |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
114 Pirelli, you can use the phone's native keypad to drive this UI, but you have |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
115 to use the fc-lcdpoll|fc-lcdemu mechanism to see the display output. |
| 6 | 116 |
|
8
0efa0f4081a0
README: added blurb about hex dumps in rvinterf output impairing usability
Mychaela Falconia <falcon@freecalypso.org>
parents:
7
diff
changeset
|
117 One currently outstanding defect with this fc-lcdpoll mechanism is that rvinterf |
|
0efa0f4081a0
README: added blurb about hex dumps in rvinterf output impairing usability
Mychaela Falconia <falcon@freecalypso.org>
parents:
7
diff
changeset
|
118 currently prints all ETM packets as full hex dumps, and the flood of all that |
|
0efa0f4081a0
README: added blurb about hex dumps in rvinterf output impairing usability
Mychaela Falconia <falcon@freecalypso.org>
parents:
7
diff
changeset
|
119 hex in the rvinterf window makes that window unusable for its original intended |
|
0efa0f4081a0
README: added blurb about hex dumps in rvinterf output impairing usability
Mychaela Falconia <falcon@freecalypso.org>
parents:
7
diff
changeset
|
120 purpose of seeing other debug output from the fw. This voluminous rvinterf |
|
0efa0f4081a0
README: added blurb about hex dumps in rvinterf output impairing usability
Mychaela Falconia <falcon@freecalypso.org>
parents:
7
diff
changeset
|
121 output also slows down the rate at which the LCD framebuffer is polled. One |
|
0efa0f4081a0
README: added blurb about hex dumps in rvinterf output impairing usability
Mychaela Falconia <falcon@freecalypso.org>
parents:
7
diff
changeset
|
122 can run rvinterf with the -n option to suppress its output, but then all other |
|
10
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
123 debug trace output will be lost too. Back in 2018-03 I was thinking about |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
124 fixing rvinterf at some point to make its output less voluminous by default, |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
125 keeping the human-readable traces, but omitting the rarely-useful hex dumps |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
126 from the default output - but now I am thinking of different approaches as |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
127 outlined below. |
|
8
0efa0f4081a0
README: added blurb about hex dumps in rvinterf output impairing usability
Mychaela Falconia <falcon@freecalypso.org>
parents:
7
diff
changeset
|
128 |
| 6 | 129 Baud rate considerations |
| 130 ======================== | |
| 131 | |
| 132 The ETM memory read approach implemented in fc-lcdpoll is a lock-step, one read | |
| 133 transaction at a time mechanism, not a continuous unstoppable stream of data | |
| 134 like the original 2015-09 approach - therefore, it does not impose any load on | |
| 135 the firmware's trace buffers, and it can work with RVTMUX running at any baud | |
| 136 rate, even plain 115200. However, the slower the RVTMUX serial channel runs, | |
| 137 the slower will the virtual LCD update, hence running the serial line at 812500 | |
| 138 baud is still preferable. To change the RVTMUX serial baud rate from 115200 bps | |
|
7
d584d7b50f10
README: simplified way of setting TR_BAUD_CONFIG to TR_BAUD_812500
Mychaela Falconia <falcon@freecalypso.org>
parents:
6
diff
changeset
|
139 to 812500 bps in your Magnetite firmware build, simply add a |
|
d584d7b50f10
README: simplified way of setting TR_BAUD_CONFIG to TR_BAUD_812500
Mychaela Falconia <falcon@freecalypso.org>
parents:
6
diff
changeset
|
140 TR_BAUD_CONFIG=TR_BAUD_812500 argument to your ./configure.sh line, |
|
d584d7b50f10
README: simplified way of setting TR_BAUD_CONFIG to TR_BAUD_812500
Mychaela Falconia <falcon@freecalypso.org>
parents:
6
diff
changeset
|
141 and remember to pass the -B812500 option to rvinterf when talking to such |
|
d584d7b50f10
README: simplified way of setting TR_BAUD_CONFIG to TR_BAUD_812500
Mychaela Falconia <falcon@freecalypso.org>
parents:
6
diff
changeset
|
142 trace-speed-increased firmware. |
|
10
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
143 |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
144 New thoughts as of 2019-12 |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
145 ========================== |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
146 |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
147 While the fc-lcdpoll approach implemented in 2018-03 is much cleaner and much |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
148 more workable than the original 2015-09 approach, the update rate of the virtual |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
149 LCD is painfully slow, which is why no actual UI development work has been done |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
150 yet via this approach. It needs to be remembered that a 176x220 pixel |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
151 framebuffer image with 16 bits per pixel weighs 77440 bytes, while the |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
152 theoretical maximum throughput of a Calypso UART at the maximum 812500 baud rate |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
153 is 81250 bytes per second - thus even under ideal conditions it will still take |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
154 almost a full second to push out a single frame update. The original 2015-09 |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
155 approach tried to get close to this theoretical maximum update rate by having |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
156 the firmware stream out framebuffer updates continuously, but embedding this |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
157 stream within RVTMUX resulted in overwhelming the trace mechanism beyond what |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
158 it was meant to handle. |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
159 |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
160 The newer 2018-03 approach avoids overstressing the trace mechanism, but the new |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
161 drawback is that the update rate of the virtual LCD got even slower: it now |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
162 takes about 4 s to update the virtual LCD window by reading out the firmware's |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
163 framebuffer via ETM, thus any UI features (animations, temporary message |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
164 pop-ups) that last less than 4 s become lost. This unacceptable lag in visible |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
165 display updates is the main reason why I did not pursue further UI development |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
166 work back in 2018 using this mechanism. |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
167 |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
168 If we were to continue down the virtual LCD route as opposed to looking for a |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
169 new Calypso platform with a suitable hardware LCD, one possible approach would |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
170 be to make use of two fully accessible UARTs on our FCDEV3B as opposed to just |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
171 one UART accessible on our previous OM GTA02 and Pirelli DP-L10 platforms. One |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
172 idea would be to keep the IrDA UART for RVTMUX and keep it free from virtual LCD |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
173 blit traffic, remove the ASCII AT command channel from the MODEM UART (not |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
174 needed for basic handset UI work) and repurpose the MODEM UART for a new ad hoc |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
175 interface that would carry just virtual LCD blits and nothing else. It would be |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
176 similar to going back to the original 2015-09 approach, but using a dedicated |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
177 UART and thus not loading the RiViera Trace mechanism at all. |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
178 |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
179 However, as of right now (final days of 2019) I (Mother Mychaela) am not looking |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
180 at any more virtual LCD approaches because as explained above, even under ideal |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
181 conditions we would still have a lag of almost a full second per frame update - |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
182 and no real LCD on any real phone or proper development board is that slow. |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
183 |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
184 Instead my view is that the proper solution is to acquire or create a UI |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
185 development platform whose LCD subsystem would be no worse than D-Sample. The |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
186 exact arrangement implemented on the DS board is unknown because we have no |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
187 schematics or any other hw docs, but the R2D driver in TI's firmware implements |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
188 both LCD module configuration writes and actual pixel output by writing 16-bit |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
189 words into certain magic addresses in the nCS3 address space, meaning that a |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
190 16-bit parallel microprocessor bus write interface is implemented in some |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
191 manner. The 128x128 pixel LCD (also 16-bit color) on the Pirelli DP-L10 is |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
192 similarly memory-mapped, with both commands and pixel data written as 16-bit |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
193 words into magic addresses on another chip select (nCS4 in Pirelli's case) - |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
194 although they have the additional complication of going through that SPCA552E |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
195 camera chip which we would much rather not have. |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
196 |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
197 Smaller LCDs on lower-end phones are attached serially, using either uWire or |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
198 I2C, but note that the largest serial LCD we have ever seen on a real-life |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
199 Calypso phone is the 96x64 pixel 16-bit color LCD on the C139. Pirelli's |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
200 128x128 pixel LCD is already 2.6 times larger in terms of bits per frame, and |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
201 it is parallel memory-mapped, not serially interfaced any more. TI's 176x220 |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
202 pixel LCD on the D-Sample (also 16-bit color) is another 2.3 times larger than |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
203 Pirelli's 128x128, and it is also parallel memory-mapped. I desire a 176x220 |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
204 pixel LCD for UI development so I can see TI's original UI in its full glory, |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
205 and I feel that interfacing it to the Calypso in any other way than 16-bit |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
206 parallel memory-mapped would be substandard: the update rate would be slower |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
207 than it was on the original D-Sample, and the user experience with the UI would |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
208 no longer be the same as what TI's original developers experienced when they |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
209 implemented this UI. |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
210 |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
211 The current situation as of the last days of 2019 is that we are looking to put |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
212 together our own FC Luna UI development platform with a memory-mapped parallel- |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
213 interfaced 176x220 pixel LCD using a certain historical development board as our |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
214 starting point. Our current hope is to be able to work on this project in the |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
215 first half of 2020 once the starting-point hw arrives at the Mother's shop in |
|
ad0d9f7c06e9
README: update for the present situation
Mychaela Falconia <falcon@freecalypso.org>
parents:
9
diff
changeset
|
216 California. |