Subject:
|
Re: USB Tower Performance [was leJOS/BricxCC news]
|
Newsgroups:
|
lugnet.robotics.rcx
|
Date:
|
Sat, 6 Sep 2003 09:37:51 GMT
|
Reply-To:
|
Dick Swan <dickswa@sbcglobalAVOIDSPAM.net>
|
Viewed:
|
3588 times
|
| |
|
|
In a recent post, John Hansen raised some questions about USB Tower
[1] quad speed downloading and [2] varioustimeouts and difficulty with
certain optocdes. Here's a bit of an explanation. Lots of technical
detail for those that are interested. Others can stop reading now.
Parity bits may be John's problem with quad speed USB tower
downloader. My quad speed bootloader includes parity bits. I think
other implementations may have them disabled to squeeze out a little
more performance. I recall looking at the original source (from Kekoa?
or perhaps Baum?) a long time ago and saw parity was disabled for
serial Tower. The USB Tower has no provision (that I can see) to
disable parity bit transmission. I can provide a quad speed "boot
loader" that supports parity bits to anyone who sends me an e-mail.
Regarding "StartFirmwareDownload" and "UnlockFirmware" opcodes not
working except with larger timeouts. The "memory management" opcodes
do incur some significant delay. These opcodes include other firmware
and program download opcodes: delete tasks and subroutines, allocate
datalog, etc. For example, the "unlock" firmware scans for the "do you
knock if I byte" string; the "startFirmwareDownload" does a fill all
RAM with zero operation. In my software, I allow an optional variable
delay between message transmission and reply message reception which I
have tuned to the type or value of the opcode that is being sent;
there's only a handful that have any significant kind of delay If you
use only a single delay "timer" then you have to accommodate the worst
case which is in the 60+ range; and then add another 30-60 msec for
delay in the USB polling and the PC in general.
Below is a message reply time "histogram" that I captured on a
firmware download. The captured times are from the end of the last
byte of the download message to the start of the first reply message
byte. It covers sequence of both the fast loader "bootstrap" and then
the actual firmware itself. There's also several messages that were
captured after downloading as part of the initialization sequence.
[NOTE: the table visually formats fine with a mono-spaced font
(courier) and with removal of the newsreader inserted wordwrapping].
My tracking software captures the three longest and short response
delays for each opcode as well as the average delay and its std
deviation.
The ROM initiated opcodes all seem to have about a 10 msec response
delay. Once the RAM firmware is loaded the delay decreases to under 1
msec. I don't know why the ROM is so slow; I've found and fixed one
bug in ROM/RAM interrupt handlers that insert an extra character
transmission time before the reply but that only accounts for 2.3 of
the 10 msec.
"GetVersion" is an interesting opcode. Three were used. Two from RAM
based software with delay under 1 msec and one when the ROM was
operating with a 10 msec delay. I use GetVersion to determine whether
system is running from RAM or ROM software since different results are
returned for the two cases.
"TransferData" is also interesting. Most download program code
messages have about a 10 msec reply delay but two message show up with
a delay in 40 msec range. Coincidently, there were two "downloads".
The processing for the last "TransferData" message in a download
performs a checksum on 0x8000 - 0xCC00 and compares it against the
value sent with "start download" before it replies to the message. I'm
guessing it takes about 30 msec to do this.
..................Message Response Time.................
...................Opcode XmtSz RcvSz Total Failed Passed
......Minimums...... Avg ......Maximums...... Std Dev
Assign(0x05) 6 1| 11 11| 0.5
0.5 0.5 0.6 0.7 0.8 0.8 0.11
GetVersion 6 9| 3 3| 0.3
0.5 10.3 3.7 0.3 0.5 10.3 5.67
transmitterRange 2 1| 2 1 1|
0.6
TransferData 6 2| 84 84| 7.6
7.7 7.7 10.5 12.5 41.3 41.5 5.01
StartFWDL 6 2| 2 2| 37.9
38.9 38.4 37.9 38.9 0.71
UnlockFW 6 26| 2 2| 59.4
61.7 60.5 59.4 61.7 1.63
setPowerDownDelay 2 1| 1 1|
0.5
I think there's another bug in the Lego message handling firmware
related to a race condition between the TEI (message transmission
completed) and the RXI (received character) interrupts. Upon receipt
of TEI, the firmware switches from 'transmit message' mode to 'receive
message'. Now every RCX transmitted byte is also received as an echo
on the I/R receiver. Received characters are ignored byt the RCX
during message processing. I think it is possible that the RXI for the
last transmit message byte may occasionally occur after the TEI. The
message handler then treats it as the opcode byte of a new received
message and then interprets what the PC program thinks is a new
message as data bytes to that opcode. The solution is to delay
transmission of the next message by >30 msec because RCX firmware will
time out after 30 msec and reset itself back to "wait for preamble and
opcode" mode. When my downloader has a zero delay between messages it
invariably fails close to the middle of the download; with a 32 msec
delay, it "never" fails. I believe the same problem also exists in the
Lego RAM firmware as well although I haven't tested it. The fix is
only a few lines of code and I can provide to anyone who writes their
own RAM firmware.
To better understand the previous paragraph it helps to know how the
firmware message reception state machine work. When waiting for start
of a message it simply ignores all preamble bytes (0x55, 0xFF, 0x00)
that can occur in any order and treats the first non-preamble byte as
the beginning of the message. It uses a 30 msec inter-character
"watchdog" timer to reset itself back to the "wait for
opcode/preamble" stage. It doesn't matter how many preamble bytes (0
to unlimited) are sent in a message.
|
|
Message has 1 Reply:
 | | Re: USB Tower Performance [was leJOS/BricxCC news]
|
| (...) Doh! I forgot about Odd parity and the USB tower. I will see about fixing that little problem. Is your quad speed boot loader source significantly different from Kekoa's fastdl.s (with the parity disabling code removed)? I'd like to see it if (...) (21 years ago, 7-Sep-03, to lugnet.robotics.rcx)
|
2 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
