| |
In lugnet.robotics.rcx.java, Mark Riley wrote:
[snipped]
> LeJOS, on the other hand, skips around quite a bit. There's an
> initial segment (or two) that runs from 0x8000 to ~0xB500 and
> a second high memory segment from 0xF000 to ~0xFB00. Just
> adding zeros as I did would make the download take too long, so
> I think you'll have to peek at the download code and take into
> account the memory gaps.
I have incorporated the changes made to firmdl in the leJOS distribution into my
BricxCC firmware downloader code. Now I can successfully download all the
firmwares I have access to (well, I haven't actually tried ldcc yet).
I looked at some firmware code Dick Swan sent me - and even ported it to Delphi
with the intent of using it instead of the current code - but I couldn't
successfully download leJOS using it and it failed to load pbForth (the latest
version) because of a limit on the line length of each SREC record. I'm not
sure what went wrong with leJOS exactly, as I was guessing a bit on how to read
the data from Dick's class (or my translation of his class) once I had the
firmware loaded into it. I think I guessed right, though, as I was able to
download the standard firmwares after loading them into his class.
Dick sent me some other code related to using the USB tower in fast mode when
downloading firmware which I haven't been able to get functioning in BricxCC
either.
In TowerIOHdlr.cpp there is a very interesting routine which I think may be the
key to getting fast firmware downloading working in BricxCC.
In CTowerIOHdlrUSB::setTowerBaudRate, Dick has this:
// Note: Tower drivers set carrier frequency to 76 Khz when baud rate is set to
4800.
// RCX always uses 38 Khz, so need to set it back.
Maybe, I thought, all I need to do is adjust my carrier frequency as per his
comment. It still doesn't work, unfortunately.
Then he sets the timeouts to some unknown values (they aren't defined in the
source he sent me). I'm not sure that is the problem - seems unlikely as my
timeouts (originally) were the default values of 200, 100, 200.
Finally he has this comment:
// Consistently fails if tower is not "warmed up"
getTower()->WarmUpTheTower();
That's very interesting.
WarmUpTheTower calls purgeTowerIO, it writes 55FF00 to the tower (repeated
sufficiently such that the time to transmit all the characters >=
nWarmUpTimeInMsec), it reads the response for awhile, then it calls purgeTowerIO
again.
I don't know how critical the timing is here or whether you need to send lots of
55FF00s in order to make the USB tower run in fast mode or what is exactly the
trick to get it to work. Right now I can't even download the fast firmware stub
if I set my USB tower timeouts too low (100, 0, 0). Everything else seems to
operate fine with the timeouts set that low, but not reading the response to a
Boot Mode op (0x65) or reading the response to a Begin Firmware op (0x75). With
the timeouts set to the default (200, 100, 200) the stub downloads fine but then
the attempt to transmit in fast mode fails.
As Dick has mentioned elsewhere, iirc, his code seems to handle partially fouled
up responses better than NQC/BricxCC does and that may have something to do with
why I can't get it to work.
If anyone has ideas/suggestions/code they wish to share/etc I am definitely
interested.
On a more positive note, I have a functional pbForth console built into BricxCC
now which works with either the serial tower or the USB tower (which requires
the latest version of pbForth since it now uses Odd parity). I'm still trying
to sort out XModem stuff and downloading script files (Xon/Xoff issues) but I am
very pleased with my recent progress with pbForth support.
None of this has been released yet, of course, but it is coming soon. :-)
John Hansen
http://members.aol.com/johnbinder/bricxcc.htm
|
|
Message has 1 Reply:
 | | RE: leJOS & BricxCC news
|
| John, Thanks for continuing to work on this. It's one of the things that keeps me motivated to continue supporting pbForth. Now, there has not bee much traffic there lately, and I have not done much with it becuase as far as I know, things are "just (...) (21 years ago, 5-Sep-03, to lugnet.robotics.rcx.java, lugnet.robotics.rcx, lugnet.robotics.rcx.legos, lugnet.robotics.rcx.nqc, lugnet.robotics.rcx.pbforth)
|
Message is in Reply To:
| | Re: leJOS & BricxCC news
|
| (...) works (...) and (...) as to (...) BrickOS (...) both (...) I'm no expert on leJOS, but I've experienced a similar problem with my LDCC firmware and the NQC downloader. Originally the memory sequence in my .srec file was non-contiguous (i.e. (...) (21 years ago, 29-Aug-03, to lugnet.robotics.rcx.java)
|
14 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
