Subject:
|
RCX to RCX NQC
|
Newsgroups:
|
lugnet.robotics.rcx
|
Date:
|
Thu, 15 Sep 2005 03:01:16 GMT
|
Viewed:
|
4524 times
|
| |
|
|
One last email on this topic.
There's new opcodes in the Swan firmware to support many
data bytes in a single "mailbox" message. The standard
firmware supports "mailbox" messages with a single byte
parm. I found this very restrictive in building RCX to RCX
applications.
I added five new opcodes to the firmware for expanded
messaging. The first is the "send longer mailbox" message
and it takes three word parameters. It looks at the value of
these parameters and figures out which of the four new send
opcodes to use based on how many of the parameters are
non-zero. These four opcodes send an additional 1, 2, 4 or 6
data bytes with the message "mailbox" number.
I haven't documented these new opcodes, but I'll take the
time if anyone is interested.
Last year I built a small master-slave RCX application to
demonstrate this capability. The master RCX had six motors
and six sensors. Devices 0..2 were on the master and 3..5
were on the slave. [I also extended the internal motor and
sensor "source" variables to accept 0..5 instead of 0..2].
When you referenced sensor/motor indices 3..5 then this
would cause messaging between master and slave. This was one
of the neat things about the application because it was
transparent to NQC application programs which RCX was
hosting the physical devices.
The actual "device driver" for devices 3..5 was a separate
continuously running RCX task written in NQC; it's about
1200 bytes long. This task in the master continuously polled
the slave for changes in sensor readings with a one byte
message. Slightly longer polling request messages were used
when the master had to send a command to the slave
containing motor control updates. The device driver was
event driven; I added new firmware events to flag when motor
control values were changed.
The reply message from the slave was variable length using
the new opcodes described above. The slave only replied when
sensor values had changed from what it had last reported. On
when the master requested a complete refresh.
When there were no motor or sensor the poll request and
acknowledgement was taking under 15 milliseconds. I got this
speed by eliminating the preamble bytes (remember how I said
they were optional in my last post); disabling the
complement bytes and setting the link speed to 4800 baud
(another two undocumented features of the Swan firmware).
There were three bytes sent in each direction (mailbox
opcode, mailbox value, and message checksum).
The application worked quite well and was robust. The
biggest problem I had was to remember to turn off the slave
RCX when I wanted to download application program changes to
the master RCX.
|
|
Message is in Reply To:
 | | Re: RCX to RCX NQC
|
| (...) Ahh, now I understand why it is called a "toggle bit" - I somehow misinterpreted this to mean a new command had the toggle bit set (to 1), and if the sending unit doesn't recieve a reply it should re-transmit the command with the toggle bit (...) (19 years ago, 14-Sep-05, to lugnet.robotics.rcx)
|
8 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
