Using an FRC with the RCX?

[Ryan M.]

Here are a few links:

Packet description: (includes example of sending IR message)
http://graphics.stanford.edu/~kekoa/rcx/protocol.html
From this website, I think that sending:
55 ff 00 f7 08 M ~M C ~C
Where C is the checksum. Sends the messageM. One thing I'm confused on is the checksum. It doesn't seem to work the way I read it in his description. Even trying to figure the checksum using his example I didn't come up with the same thing he did. It may be I just don't understand it. If you kow, tell me how to compute it.

Some more stuff on the packets: (not as good)
http://graphics.stanford.edu/~kekoa/rcx/#Protocol

Do you need to know how to send that out, or do you already have that figured out?

--EDIT--
Here is a site with examples of using it in C++. http://www.generation5.org/content/2001/rob08.asp.
Reading that, it's a great site.

[Astronouth7303]

Originally Posted by Texan

Here are a few links:

Packet description: (includes example of sending IR message)
http://graphics.stanford.edu/~kekoa/rcx/protocol.html
From this website, I think that sending:
55 ff 00 f7 08 M ~M C ~C
Where C is the checksum. Sends the messageM. One thing I'm confused on is the checksum. It doesn't seem to work the way I read it in his description. Even trying to figure the checksum using his example I didn't come up with the same thing he did. It may be I just don't understand it. If you kow, tell me how to compute it.

Some more stuff on the packets: (not as good)
http://graphics.stanford.edu/~kekoa/rcx/#Protocol

Do you need to know how to send that out, or do you already have that figured out?

--EDIT--
Here is a site with examples of using it in C++. http://www.generation5.org/content/2001/rob08.asp.
Reading that, it's a great site.

The example from LUGNET was made for MSCOMM and VB. I just took the array and wrote the functions for the controller.

A message packet is only one additional info section.
Header (3 bytes)
OpCode (2)
Message (Info, 2)
Checksum (2)

The OpCode for Message is 0xF7. It has one argument: the message value. Every data byte is followed by it's not. So you get:
Header = 55FF00
OpCode = F708
Message = M ~M
CheckSum = (F7+M) & FF

I think we're finally getting it!

The second link is extremely helpful. And I'm glad to know about the Null-modem cable thing: The LIRT is CTE, not a CSE (it is a male, like your computer), so maybe a standard cable works!

[Ryan M.]

You said the prog port earlier, but how do we access that? Or, rather, can we get enough control to do what we want? You can send text, but I haven't studied the printf() access of the port. Maybe that port will work or maybe something else is necessary. Correct me if you know the way.

[Astronouth7303]

Originally Posted by Texan

You said the prog port earlier, but how do we access that? Or, rather, can we get enough control to do what we want? You can send text, but I haven't studied the printf() access of the port. Maybe that port will work or maybe something else is necessary. Correct me if you know the way.

Ok. The text is transmitted as bytes (I assumed ASCII, but I'm not sure). So basically, you replace the text with bytes. A string is an array of bytes terminated by a null characcter (0x00).

I looked in printf_lib.c I traced the flow of execution from printf(), and ended up at Write_Byte_To_Uart(). Which is:

/*********************************************************
* SUBROUTINE NAME: Write_Byte_To_Uart
* PURPOSE:       Writes a byte to the UART.
*     Argument       Type           IO   Description
*     --------       -----------    --   -----------
*         data       int            I    data to transmit to the UART
* RETURNS:       void
*********************************************************/

static void Write_Byte_To_Uart(int data)
{
  TXREG = data;  /* a carriage return */
  Wait4TXEmpty();
}

I simplified it to the macro:

#define SendByte(Byte) {TXREG = Byte; Wait4TXEmpty();}

(And I don't actually know how to write macros!)

You call this repeatedly to write the whole packet.

Of course, You can't recieve: the LIRT only remains active for 3 seconds after you transmit something.
Also: this whole setup is unusual, so if it doesn't work, don't worry. We just may end up buying a pair of UART DTEs and making a double box!

[Ryan M.]

Originally Posted by Astronouth7303

I simplified it to the macro:

#define SendByte(Byte) {TXREG = Byte; Wait4TXEmpty();}

(And I don't actually know how to write macros!)

You call this repeatedly to write the whole packet.

That's what I figured would work, but I wasn't sure. Don't do a lot of COMM port work.

And the macro looks fine.

[Astronouth7303]

Neither do I. I just read the file. It's aparently easy!

[Astronouth7303]

2 updates:
1. Found gray cable setup.

GRAY CABLE
 Rx Tx
 Tx Rx
DTR DTR
Gnd Gnd
RTS CTS
CTS RTS

Or am I misinterpreting?

From front:
1 2 3 4 X
 X 5 6 X

1 2 4 3 X
 X 6 5 X

X's are no connection, numbers mean it's connected to the same number.
Get the idea?


2. What's the TTL output? I was thinking of the possibility of connecting through that. The prog port is used for so much else!

[Ryan M.]

Originally Posted by Astronouth7303

2 updates:
1. Found gray cable setup.

GRAY CABLE
 Rx Tx
 Tx Rx
DTR DTR
Gnd Gnd
RTS CTS
CTS RTS

Or am I misinterpreting?

From front:
1 2 3 4 X
 X 5 6 X

1 2 4 3 X
 X 6 5 X

X's are no connection, numbers mean it's connected to the same number.
Get the idea?

Where'd you get the info? I'll see if I agree.

Originally Posted by Astronouth7303

2. What's the TTL output? I was thinking of the possibility of connecting through that. The prog port is used for so much else!

I don't know. You're much better at harware stuff than me.

[Gabriel]

I know that its probably more fun to reverse-engineer it, but have you guys thought about talking to LEGO for the specs? I know that they sponsor team 96 and I think their mindstorms engineers work with them.

[Astronouth7303]

Why? all the reverse-engineering and spec-finding has been done for us. The most reverse-engineering I've done yet is putting a continuity tester to the original gray cable! And RS-232 has been standardized to death, so it's the easiest protocal to use (at either end!).

[Astronouth7303]

The TTL port uses the same transmission format as RS-232 (low start bit, 8 data bits, high stop bit). So if you take a 3-pin cable and attach it the Tx, Rx, and Gnd pins on a DB9 female connector, you can use TTL port instead of the prog port. The macro would need to be changed slightly.

Odd, ifi_utilities.c and printf_lib.c both use 'TXREG', but ifi_picdefs.h defines 'TXREG1' and 'TXREG2'.

[Ryan M.]

Originally Posted by Astronouth7303

The TTL port uses the same transmission format as RS-232 (low start bit, 8 data bits, high stop bit). So if you take a 3-pin cable and attach it the Tx, Rx, and Gnd pins on a DB9 female connector, you can use TTL port instead of the prog port. The macro would need to be changed slightly.

Odd, ifi_utilities.c and printf_lib.c both use 'TXREG', but ifi_picdefs.h defines 'TXREG1' and 'TXREG2'.

If you think it'll work, go for it.