FreeCalypso > hg > freecalypso-ui-dev

comparison README @ 8:0efa0f4081a0

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
README: added blurb about hex dumps in rvinterf output impairing usability
author Mychaela Falconia <falcon@freecalypso.org>
date Fri, 16 Mar 2018 04:44:26 +0000
parents d584d7b50f10
children 6c35c9f2ecab
comparison
equal deleted inserted replaced
7:d584d7b50f10 8:0efa0f4081a0
117 radio) occurs even when deep sleep is enabled if the firmware is built in the 117 radio) occurs even when deep sleep is enabled if the firmware is built in the
118 MFW configuration (UI layers included) - as the UI layers command the radio 118 MFW configuration (UI layers included) - as the UI layers command the radio
119 bring-up immediately on boot, the DSP falls over. Thus we are rudely reminded 119 bring-up immediately on boot, the DSP falls over. Thus we are rudely reminded
120 once more than the Pirelli target is a dead end. 120 once more than the Pirelli target is a dead end.
121 121
122 One currently outstanding defect with this fc-lcdpoll mechanism is that rvinterf
123 currently prints all ETM packets as full hex dumps, and the flood of all that
124 hex in the rvinterf window makes that window unusable for its original intended
125 purpose of seeing other debug output from the fw. This voluminous rvinterf
126 output also slows down the rate at which the LCD framebuffer is polled. One
127 can run rvinterf with the -n option to suppress its output, but then all other
128 debug trace output will be lost too. I plan on fixing rvinterf at some point
129 in the future to make its output less voluminous by default: keep the human-
130 readable traces, but omit the rarely-useful hex dumps from the default output.
131
122 Baud rate considerations 132 Baud rate considerations
123 ======================== 133 ========================
124 134
125 The ETM memory read approach implemented in fc-lcdpoll is a lock-step, one read 135 The ETM memory read approach implemented in fc-lcdpoll is a lock-step, one read
126 transaction at a time mechanism, not a continuous unstoppable stream of data 136 transaction at a time mechanism, not a continuous unstoppable stream of data