The code linked at the end of this post allows two cortex controllers to be connected using their UART ports. The master cortex (with VEXnet and joystick) controls the slave cortex (no VEXnet) using the example communications protocol.
I’ve posted about serial communications before in the ROBOTC programming tips thread, however, I wanted to show an example that was a little more developed with bi-directional communication between two devices.
For some of the products I work on at my day job I created a simple protocol known as the P3 protocol (when I talk about a “protocol” I’m referring to the rules that need to be followed to allow communication wiki). The name (although having another meaning) was supposed to indicate an enhanced version of an old Sony protocol known as the P2 protocol. This was used for many years in the broadcast industry as a means to control video tape recorders and other similar equipment. The official spec for that would have to be obtained from Sony but I see a summary has been posted here. The P2 protocol has some limitations and is not ideal as a general purpose communications method. The baud rate is slow (38.4k) and the maximum payload data size is only 15 bytes, however, it was an easy protocol to implement and I used custom variations of it for many years.
I decided to port a simplified version of my P3 protocol to ROBOTC on the cortex as a demo. The original plan was to have an application running on a PC controlling the cortex, I did implement that but decided I didn’t want to deal with the cross platform and driver issues involved with publicly releasing it. Plan B uses two cortex controllers connected to each other, one acts as a communications master, the other as a slave.
Serial communication in the context of this post means asynchronous serial communication. This is a means of communication where the clock (a periodic timing signal that determines the speed that data is sent) is not sent from one device to another as a discrete signal. Sometimes the clock is encoded into the data so that a receiving device can exactly recover it, however, in this case it means that as long as both sending and receiving devices know the approximate clock speed (say within 5%) the information can be retrieved from just one data signal. The alternative to asynchronous would be synchronous communication, one flavor of this is used for communications between the cortex and IMEs and is called I2C (inter integrated circuit). Lots of detail on I2C in this old post.
**Example code functionality
The demo only implements commands for motor control and status. A complete implementation would also allow access to the sensor ports and perhaps offload certain processing tasks. The Demo allows the joystick on the master cortex to control four motors on the slave cortex (all 10 are theoretically controlled but only the analog joystick channels are connected to the motors).
**Format of a data packet.
The protocol is not that different from others I have presented in the past. All communication is initiated by the master cortex, it sends a packet of information (several consecutive bytes) to the slave. The slave replies to the master with either an acknowledge (ACK), requested information or an indication that an error has occurred (NAK). Any baud rate can be used but for the example code I am running at 230.4K, pretty much the highest standard rate supported by ROBOTC.
For complete information on the protocol see the document here.
A serial transaction captured by an oscilloscope appears as follows.
Due to the nature of the ROBOTC implementation there will always be a small delay between command and reply, however, this really is not an issue and still easily allows a message to be sent every 10mS (100Hz).
**Connection between host (master) cortex and slave
Demo source code
The source for the p3 library and the demo code (both master and slave) is on github. The ROBOTC implementation limits commands to 128 bytes of data to save memory, this can be increased by modifying the header file if necessary, see the source for more details.