Best UART serial protocol for simple application?

kolyur

Hi all,

I'm working on a project where I have to communicate between a Prop and an industrial operator interface (Red Lion G307K2 to be exact). The comms will be RS-232 and I already have level shifting in place with a MAX3232. The Red Lion unit has built-in drivers for lots of protocols (mainly proprietary interfaces with other industrial devices and PLCs) and also has a scripting language where you can directly control the port. I have used these serial commands in the past on other projects and am familiar with the programming.

I'm thinking about what would be the best serial protocol to use. I'm leaning towards Modbus RTU at this point since the Red Lion has a built-in driver for it, which would put the programming burden on the Prop (as a slave). I've received some helpful advice on Modbus from JonnyMac and others, and there are a few objects in the Obex which makes me think it's certainly do-able on the Prop side. I'm wondering, however, if it would be overkill for my application. I only have a handful of bytes to transfer back and forth, and speed is not a big issue (probably will end up somewhere between 9600 and 56k baud). I should have at least several cogs available.

Can anyone suggest a simpler standardized protocol, or should I think about "rolling my own" serial driver? I've written custom serial code on both the Propeller and the Red Lion in the past, but it was always to conform to the protocol of the connected device. I'm in new territory here since I have full control of the serial port on both devices. Or should I just stick to Modbus? Just trying to figure out what basket to dump all of my eggs into.

I'm very interested in hearing others' experiences and thoughts on this topic.

Thanks,
John

Peter Jakacki

I've done Modbus before mainly over RS-485 and various other protocols but if you have control and it is point-to-point over RS-232 then keep it simple. I favor text based commands as these are the most flexible and rather than having any fixed fields use these basic rules:

- if it is a digit then convert and accumulate the value
- if it is not a digit then push that value onto a data stack and zero the digit accumulator
- Use single character commands - execute immediately - ignore unknown commands

This is basically what I do with what I call my terse command mode in Tachyon Forth which I use in industrial control apps. Here is where I tell it to turn on output 21 and then take a ping reading and return with the value.
1,21O4m
Where 1 is the value (vs 0) and comma pushes this value onto the stack while 21 will get pushed onto the stack as well when O is encountered but it executes by taking the top two values and writing the value to port 21. After this 4m simply reads the mm range from a ping sensor on port 4.

So writing a command interpreter for this is dead simple and yet the protocol is very flexible.

Duane Degn

I'd think you'd want to use whichever protocol you feel comfortable using.

Pretty much any of the serial drivers can read the bits coming in and send the outgoing data to the RS-232 chip.

Modbus RTU is kind of a pain to use but it's so common it's a good protocol to learn to use (if you don't know how already).

kolyur wrote: »

Can anyone suggest a simpler standardized protocol, or should I think about "rolling my own" serial driver?

If speed isn't an issue, ASCII based protocols can be very convenient since you can test the interface with a terminal window.

Parallax's DHB-10 uses an ASCII based protocol which could be adapted for use in other projects. The DHB-10 protocol uses the motor control portions of the Eddie robot interface.

I ported the original Eddie code to run on a Propeller Activity Board. Here's a link to this project.

One weakness of the DHB-10/Eddie protocol is it's not really a good protocol to use with a wireless connection. Any device using this protocol assumes the data last received corresponds with the last command sent. It's very possible for commands to be lost when using a wireless connection and if more than one command is issued prior to a response being received. In cases where more than one command had been issued, the meaning of the received data can be ambiguous.

Depending on the application, it can be very useful to have some why to identify the received data. The DHB-10/Eddie protocol could be modified to have it repeat the command as part of the reply. This way data received from the Propeller would be less ambiguous.

What sort of data is being sent? If you're sending floating point values, ASCII based protocols can cause rounding issues. IMO, it's generally not a good idea to send floating point values as normal, base 10, ASCII numeric characters. When sending floating point numbers with ASCII characters, I think one is better off converting the number to hexadecimal characters so all the significant bits get set as intended without the rounding errors which accompany converting between floating point numbers and characters.

kolyur

Thanks for the replies. The bulk of my data transfer will be 16-bit integers. No floating point or strings.

It seems to me that I could just create a very simple bidirectional protocol, something like this:
[identifier byte] [high date byte] [low date byte] [checksum]

The receiver would understand the purpose of the data based on the identifier byte. Each device would be sending out data as it's available, and the receiver would parse it. It wouldn't be a master/slave arrangement, although I could set up certain identifier bytes to be requests for information and the receiver would deviate from its usual transmissions to provide a response.

I don't know much about checksums but I'm sure there are some simple standards out there that I could use. My baud rate will be low and I don't expect to run into any data transmission problems. The MAX3232 is only a few inches from the Prop on the same PCB, and the wires carrying RS232 will only be 6-8 inches long.

I've seen some serial protocols that always require a response to data, even if it's just a ACK or NAK with no other data. I understand this can help with retransmitting corrupt messages, but for what I'm doing I think it would just clog up the works.

Am I oversimplifying this?

Duane Degn

Here's the checksum method I use with one of my Modbus projects. It's a 16-bit checksum but I think you could adapt it to use as an 8-bit checksum (though I'm not sure how to do this without thinking about it a bit more).

I think this checksum makes sure bytes are received in the correct order.

As noted in the code, I copied this from something Mike Green wrote here in the forum.

PUB Crc16(bufferPtr, size)

'' This method was written by Mike Green.
'' Found on Parallax forums.

   result := $FFFF
   repeat size
      result ^= byte[bufferPtr++]
      repeat 8
         result := result >> 1 ^ ($A001 & (result & 1 <> 0))

I don't think you're oversimplifying things.

Electrodude

I was involved in a project that had a Propeller talk to a Red Lion unit over Modbus. You may have already seen my Modbus master object in the obex. I made a C port of my modbus driver that has more features than the Spin version which was used to talk to the Red Lion unit, and I should really port those extra features back to the Spin version.