Subject:
|
Re: USB Tower Performance [was leJOS/BricxCC news]
|
Newsgroups:
|
lugnet.robotics.rcx
|
Date:
|
Sun, 7 Sep 2003 04:55:11 GMT
|
Viewed:
|
3711 times
|
| |
| |
In lugnet.robotics.rcx, Dick Swan wrote:
> Parity bits may be John's problem with quad speed USB tower
> downloader.
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 it is.
> 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;
I will fiddle around with my code a bit to see if I can do something similar
(without completely overhauling it).
> "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 was running into problems with GetVersion when I lowered the first USB timeout
parameter (read first char) below 100ms. All the values on BricxCC's diagnostic
dialog were coming back fine except for the version number.
> 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.
If it is relatively simple maybe you could just post it here for anyone
interested to use.
John Hansen
|
|
Message is in Reply To:
| | Re: USB Tower Performance [was leJOS/BricxCC news]
|
| 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. (...) (21 years ago, 6-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
|
|
|
|