Re: Increasing available program memory
 

Yes, you'll need to have a full-duplex serial port driver (like mine) running on each of the processors. Then you'll need to design a state machine that parses the messages as they come in. Here's an example of a very simple packet:

Byte 1: 'P' ; First synchronization byte. I use my younger son's first initial
Byte 2: 'B' ; Second synchronization byte. I use my oldest son's first initial
Byte 3: Command byte ; i.e., 01 = start motor #n, 02 = stop motor #n...
Byte 4: Data needed for command; e.g., motor number
Byte 5: Eight-bit checksum; Least significant eight bits of the summation of bytes 1-4. This is used to make sure the packet isn't corrupted.

-Kevin

Re: Increasing available program memory
 

When you write the example code on how to send packetized data between the FRC-RC and EDU-RC can you include an example of how to create a packet such as the one outlined in your last reply (Or any type of packet for that matter)?

Thanks again,

Re: Increasing available program memory
 

Yes, I intend to.

-Kevin

Re: Increasing available program memory
 

Thank you so much. Have you written (Or know of) any documentation (Or tutorials) on how to use the serial ports on the RC or transmitting and parsing packet data?

Thank you very much,

Re: Increasing available program memory
 

Hey Kevin,

Any news on how its going with the example interface code between the EDU-RC and the FRC-RC?

Thanks,

Re: Increasing available program memory
 

Dan,

Reading over your posts in this thread, it looks like you have never programmed a serial link before... It is not really so hard.

A simple Google search will yield thousands of hits. The issue is digging through them until you find a simple example...

Start by reading the sections "Typical Protocols" and "Serial Client & Server Example Programs" at this link. Personally, I prefer the full or "complete" packet with a checksum after the ETX for data integrity.

Now look at the specification and code for the CMU2cam we used this year. You will see that it is a very simple protocol. For example SV 1 200r is a command from one CPU to another to move servo #1 to position 200. Also, you have the default code which implements 1/2 of the protocol definition.

Just as the CMU definition is specific to the requirements of the camera, your definition will be specific to your requirements. The biggest job that you have to do is to sit down and write the interface definition. After that, the coding is cake...

You do not need to wait for Mr. Watson to do this for you. And as always, you can post here if you have more questions.

Regards,

Mike

Re: Increasing available program memory
 

I'm working on something that I'll be releasing in the future. In the meantime, have a look at the attached code that I wrote for IFI's breaker panel. The code parses the incoming telemetry and updates global variables with the state of individual breakers. I should point out that there is a weakness in IFI's telemetry packet in that they don't include somthing like a checksum at the end of the packet, which could be used to validate the data within the packet. The attached code makes the assumption that once the two synchronization bytes are received, the next four data bytes are valid. A better solution (left to the student :) ) would be to update the system variables after the data has been received *and* the next two bytes are validated as synchronization bytes.

-Kevin