Subject:
|
Re: NQC RCXLib bug & wish
|
Newsgroups:
|
lugnet.robotics.rcx.nqc
|
Date:
|
Tue, 22 Feb 2000 01:48:39 GMT
|
Viewed:
|
2243 times
|
| |
|
|
In article <FqArz5.1LL@lugnet.com>, "Vlad Dumitrescu"
<vladdu@NOSPAM.hotmail.com> wrote:
> Hi! (especially Dave)
>
> While trying to get a working communication channel between the PC and
> the RCX
> with the original firmware, I discovered a bug in RCXLib: in RCX_Link,
> BuildTxData, the 3rd bit in the command code is toggled when sending the
> same
> command several times in a row. This is fine, but the problem is that
> the kRCX_Message command (0xF7) does not need that! The correction is
> simple:
>
> if ((byte==fTxLastCommand) && (fTxLastCommand != kRCX_Message)) byte ^=8;
I didn't realize that kRCX_Message packets wouldn't survive toggling the
duplicate reduction bit. I'll fix this in the source. Actually, I
think rather than hard-coding the decision with kRCX_Message, I'll make
it dependent on whether retries are being used. In theory, whenever
your using retries you want duplicate reduction on. When retries are
off, duplicate reduction will also be off.
> Another note. There is no easy way to get replies from the RCX, in form
> of
> messages. The simplest is to allow reading the whole buffer read from the
> serial port - but access to fRxLength is needed! (either public or
> protected)
This has been a long-standing issue, but its not without complications:
1) When to read the serial port. Currently, everything is done with
synchronous I/O. I really don't want to try to support async I/O in a
platform independent manner. The upshot of this is that there will
probably be a 'poll' method on RCX_Link that will drain the Rx buffer
looking for a message packet.
2) The tower will sleep after several seconds, thus some other
mechanisms is required to keep it alive. If you're sending messages
rather often then it isn't a problem, however in the general case there
would need to be some way of doing this. However, anything you send at
the tower will obliterate any recieved data at that time.
3) How to deliver messages to the client. Assuming the polling model,
it would be ok to return the message (if any) as the result of the poll
call. However, it would also be nice to process messages that were
received between commands. This makes me lean towards a virtual method
to handle received messages - clients could the implement their own
message handling. However, not everyone would feel like implementing an
RCX_Link subclass. Perhaps some special Message Handler abstract class
that you register with RCX_Link instead.
Dave
--
reply to: dbaum at enteract dot com
|
|
Message is in Reply To:
 | | NQC RCXLib bug & wish
|
| Hi! (especially Dave) While trying to get a working communication channel between the PC and the RCX with the original firmware, I discovered a bug in RCXLib: in RCX_Link, BuildTxData, the 3rd bit in the command code is toggled when sending the same (...) (25 years ago, 21-Feb-00, to lugnet.robotics.rcx.nqc)
|
2 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
