Subject:
|
Re: Difficulty with WRITE COMMAND over BT
|
Newsgroups:
|
lugnet.robotics.nxt
|
Date:
|
Sat, 28 Apr 2007 11:45:17 GMT
|
Viewed:
|
18947 times
|
| |
|
|
> It's hard to say what exactly might be going wrong. Here's how I write a file
> to the NXT:
>
> // write in < 64 byte chunks
> xferred := 0;
> aStream.Position := 0; // start at the beginning
> while xferred < size do
> begin
> cnt := Min(size - xferred, kNXT_MaxBytes-3);
> // fill our buffer with the right number of bytes
> for i := 0 to cnt - 1 do
> aStream.Read(buf.Data[i], 1);
> // write these bytes to the NXT
> Result := NXTWrite(handle, buf, cnt, cnt = (size - xferred));
> if not Result then Break;
> inc(xferred, cnt);
> end;
>
> The maximum number of bytes per write is 61 (64-3). Each command is sent with
> the no response flag set (0x81 rather than 0x81) except for the very last
> command (when cnt = (size - xferred)).
Thank you very much for the reply. It is still consistently puzzling.
If I write some other file - for example a text file named file.txt, I can write
and close, and see it in the list (through findfirst/findnext) successfully.
This works both if I open it with openWrite and openWriteLinear.
I tried with a binary file containing both non-ascii and controlcode bytes,
and it also downloads smooth.
When I do it with an executable file produced by NBC
(nbc -Z1 -O=hello.rxe hello.nbc) then the communication hangs
at various points - either when writing one of the chunks or
when closing the file, but it never succeeds completely.
Both sides report that the connection is still there, but NXT does not respond
anymore to any other command, until the port is closed and reopened on the PC
side.
The same executable file can be successfully downloaded using NBC
(nbc -d -b hello.rxe) over USB, and then it can be started on the NXT correctly.
I tried different NBC programs with the same result.
I give long enough delays between the individual write commands, and I am a
little curious about whether your NXTWrite function from the (wow Pascal!)
example is making any delays in order not to jam the NXT buffers? Are these
delays taking into account the 256 byte NXT page size buffer which needs
(according to docs) some extra 6ms to flush?
Sometimes the close command receives a different feedback from NXT, where status
is equal 190 (0xBE) - which the firmware sources suggest to be
ERR_RC_UNKNOWN_CMD.
However, this is not a reply to the close command (it seems to be the OPEN WRITE
command talking because the whole reply packet is: 3, 0, 2, 129, 190).
I am never sending open write command (using open linear).
This hypothesis is confirmed by the fact that if I purge input and output
buffers of the virtual serial port before sending the close command (3 0 1 132
0), this weird packet is never received back - so it must be a pending reply to
something from before.
This weird packet was received only when downloading one particular NBC program.
This behavior is consistently seen only with NBC executable files, and all other
files download fine.
One of the NBC programs I used is here:
http://www.idi.ntnu.no/~petrovic/hello.nbc and here
http://www.idi.ntnu.no/~petrovic/hello.rxe.
Thank you for your kind attention!
Pavel
|
|
Message is in Reply To:
 | | Re: Difficulty with WRITE COMMAND over BT
|
| (...) It's hard to say what exactly might be going wrong. Here's how I write a file to the NXT: // write in < 64 byte chunks xferred := 0; aStream.Position := 0; // start at the beginning while xferred < size do begin cnt := Min(size - xferred, (...) (18 years ago, 27-Apr-07, to lugnet.robotics.nxt)
|
3 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
Active threads in NXT programmable brick
|
|
|
|
|
|
