Subject:
|
RE: NRLink reading RCX response w/ RobotC
|
Newsgroups:
|
lugnet.robotics.nxt
|
Date:
|
Thu, 2 Aug 2007 19:40:32 GMT
|
Reply-To:
|
<DICKSWAN@SBCGLOBAL.NETihatespam>
|
Viewed:
|
22598 times
|
| |
|
|
> Only the third message describes "Test I2C Messaging". It's very
> specific to the message thread and in it you also state that you
> have written on the subject before. I couldn't find any other
> messages with info about the "Test I2C" function. If there is a
> general explanation of this function I would very much like to learn
> - it seems to be a very useful tool,
I couldn't find it either, but its out there somewhere.
> Without instructions it requires a bit of intuition.
Agreed. It started as a internal debugging tool and was left visible
for the small handful of power users who write their own I2C device
drivers.
> An important item missing was the fact that "Menu Level->Expert"
> must be enabled to make the test panel entry appear in the menus - a
> wild guess I made after hunting through the menus over and over. It
> took me a loooooong time to figure this out. I can now open "I2C
> Test".
Agreed. I went back and updated the forum posting to make this
clearer.
> So, I am able to see the data coming from the RCX using "02 42"
> (found that in "NXT Hitechnic Accelerometer.c" - thanks). The
> response is 9 bytes long. Where do I find the definition of this
> response - the RCX sent message is only 1 byte long. Is this all
> from the NRLink device or is some of the data added by RobotC?
The best way to understand the format of RCX IR messages is to
download the RCX SDK from the LEGO web site and read the documentation
in it. Here's a few pointers on the basics.
Every message is prefixed by optional header bytes which begin with
00, FF, or 55. There can be an unlimited number of header bytes.
Normally there are 3 and they are 55, FF, 00 but if a byte is dropped,
etc you can get a different quantity. Or you can customize the RCX
firmware -- it's a simple byte-value parameter -- to set the number of
prefix bytes.
So message should begin with the first non-zero prefix byte.
Your IR message reception software should clear out any existing
garbage bytes before sending a message that generates a response.
Your IR message reception software should time the interval between
message characters. If more than 30-msec elapses between characters
then it should reset its state to looking for beginning of message.
The 30-msec duration is the default value. It can be customized to a
shorter (or longer) value.
Each message character is sent twice. Once as the character value and
a second time as the inverse value. This ensures that there is an even
balance of ones and zeroes transmitted which is needed by the AGC
(Auto Gain Control) circuitry.
For most messages, the length of the message can be determined by the
3 LSB of the opcode. This is documented in the LEGO SDK. However, this
rule is not always followed if you're using some of the new extended
opcodes in the ROBOTC RCX firmware.
Each message is followed by a checksum byte (and its inverse).
Say for instance you sent a "keep alive" message. This is a single
byte message with opcode x10. The bytes transmitted would "normally be
"55 FF 00 10 EF 10 EF"; the first "10 EF" is the opcode and its
reverse. The second "10 EF" is the checksum. Note that the RCX doesn't
care about the header bytes so you could equally send "10 EF 10 EF"
with the same results.
The reply message received by NRLINK for above would be "55 FF 00 EF
10 EF 10". The first byte of the reply is the inverset of the opcode.
So first "EF 10" indicates the reply opcode and second "EF 10" is the
checksum.
You'll need to read the the SDK to understand why if you send two
consecutive "keep alive" messages the first is sent as "55 FF 00 10 EF
10 EF" and the second as "55 FF 00 18 E7 18 E7". Bit 3 is toggled.
Once you understand the basic formatting of I2C messages, then you'll
have to read the documentation that came with the NRLink (or other I2C
sensor) to figure out which registers to read and how to interpret
them.
As I recall the NRLink has two important registers: one contains a
count register of how many bytes have been received and the second is
an array containing the received bytes. You should probably have a
loop that is continuously reading (with a wait statement in the loop
so that it doesn't hog all the CPU cycles) the 'count' register and
when this is non-zero read the indicated number of bytes and pass them
to the message reception software routine.
> Example:
> RCX sends 0x46 and NXT reads C2 55 FF 00 F7 08 46 B9 3D
> 7th byte looks like the data to be read.
>
> RCX send 0x95 and NXT reads C2 55 FF 00 F7 08 95 6A 8C
> Again, 7th byte looks like the data - but the trailing two bytes are
> different also.
It looks like the RCX is transmitting the following to the NRLink:
C2 Garbage from previous message
55 FF 00 Message header
F7 08 the "Set message" opcode and its inverse
46 B9 The parameter '46' and its inverse
3D The first byte of checksum. Second inverse byte 'C2' was
not read and becomes garbage for the next transaction.
I think this is what you intended since I presume you meant by "RCX
sends x46" that you meant send message '46' over the IR link.
If you happen to be using the ROBOTC RCX firmware you'll find that one
of the nifty RCX feature extensions is that it allows messages to
contain up to 5 bytes of data. In the LEGO supplied firmware, you can
only send a single byte message.
|
|
Message has 1 Reply:
 | | Re: NRLink reading RCX response w/ RobotC
|
| (...) I downloaded the SDK from (URL) but can't find any reference to the message format. Perhaps this is the wrong SDK? I've looked in all the doc .pdf files and skimmed everything else. I sure am having a hard time locating things. (...) So what (...) (18 years ago, 3-Aug-07, to lugnet.robotics.nxt)
|
Message is in Reply To:
| | Re: NRLink reading RCX response w/ RobotC
|
| (...) Searching for "robotc i2c" returns 3 message in the forums: "Interfacing with Lego Sensors" "Help with US sensor!!" "RobotC I2C Help" Only the third message describes "Test I2C Messaging". It's very specific to the message thread and in it you (...) (18 years ago, 2-Aug-07, to lugnet.robotics.nxt)
|
8 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
|
|
|
|
