Keil Logo Arm Logo

How can I create a user defined protocol for communication over UART?

Next Thread | Thread List | Previous Thread Start a Thread | Settings

Details Message
Author
Pete Almassi
Posted
11-Jul-2017 12:20 GMT
Toolset
ARM
New! How can I create a user defined protocol for communication over UART?

I need to use STX, ETX, Length, Data, Checksum , CMD(Command) bytes in my protocol structure. Data and Length will be variable fields where length refers to length of data. I am new to Embedded c and just need an idea, where i can start as I am confused that, what kind of data(structure of data) user should sent over uart to initiate communication with micro controller. The protocol structure I am trying to develop is as follows:

STX|CMD|LENGTH|DATA|CHECKSUM|ETX.

Thanks in advance.

Author
Zaphod Beeblebrox
Posted
11-Jul-2017 14:12 GMT
Toolset
ARM
New! RE: How can I create a user defined protocol for communication over UART?

This is a topic that is frequently underestimated. There are so many bad protocols (especially in terms of resilience and efficiency).

I'll start you off with what I think is one of the most fundamental questions to consider:

You would potentially use the ASCII control characters STX and ETX to represent 'Start Of Transmission' and 'End Of Transmission' respectively. Would you allow the characters 0x02 and 0x03 to appear within the remainder of your message (such as within CMD, Length, Data, Checksum)?

If you don't, then synchronisation within your receive routine is considerably easier, since you can treat any received STX as a start of a message and restart message accumulation accordingly. Then keep accumulating until you receive an ETX (or detect an error). You can consider having something like an escape sequence to allow the bytes 0x02 and 0x03 to appear within your data lying between the message delimiters.

You can, of course have a protocol that use the message delimiters and also permit any data within the block.

I've seen (and had to use) many badly designed protocols. Some done by self-proclaimed communication experts. They are, in my opinion, an indication of an amateur design. It's often obvious how fudges and kludges are added to both protocol and communication routines to work around flaws introduced at the start.

If you can, look around for examples of existing protocols and see what you can learn from them.

Author
John Linq
Posted
12-Jul-2017 06:24 GMT
Toolset
ARM
New! RE: How can I create a user defined protocol for communication over UART?

http://www.keil.com/forum/14431/questions-about-half-duplex-rs485-network/

Author
Andrew Neil
Posted
12-Jul-2017 08:11 GMT
Toolset
None
New! What's the question?

I'm a bit unclear what is the actual question here:

* Is it how to design a protocol?

* Is it how to implement a protocol from a given design?

The former would be entirely independent of the hardware & programming language.

The latter seems to be suggested by giving the frame structure:
STX|CMD|LENGTH|DATA|CHECKSUM|ETX.

Or perhaps it's a bit of both - and the OP is confusing himself with implementation details before the design is complete ... ?

Author
Zaphod Beeblebrox
Posted
12-Jul-2017 08:37 GMT
Toolset
None
New! I'm a bit unclear what is the actual question here:

When it comes to serial protocols (such as used over RS-485), it is extremely wise to seriously consider implementation when creating the design. Hence my comment regarding kludges and fudges.

Most importantly for many serial implementations is consideration of error detection and recovery. That consideration is frequently not present when protocols are first conceived.

Author
Pete Almassi
Posted
12-Jul-2017 17:12 GMT
Toolset
ARM
New! RE: Trying to create a generic program to control various peripherals of a micro-controller.

What am I trying to create here is a very generic program that will work on virtually every PC, provided it uses a serial interface(UART) to communicate with uC. So I am trying to implement this protocol for sending responses(result of uC operations) and receiving commands(what peripheral should uC operate on). The command can be very simple like PWM 100 where PWM is the peripheral needs to be used and 100 is the value provided to Match Registers(for example). Now I am confused regarding the implementation of frame structure as how the frame needs to struct for a specific operation. Like who(user or uC) would send the start and stop bit. How we can keep the data and LOD fields variable. What kind of command should a user send to uC. And how can i minimize the size of frame by performing on bits(binary) rather than bytes. I just needed a brief idea as what exactly these protocols are used for and how they actually work or how frames are formed and send to uC for desired operation.
Thanks in advance. And sorry for the long post.

Author
Andrew Neil
Posted
12-Jul-2017 23:27 GMT
Toolset
None
New! a generic protocol to control various peripherals of a micro-controller.


https://github.com/firmata/protocol

Author
Andrew Neil
Posted
13-Jul-2017 10:18 GMT
Toolset
None
New! RE: a generic protocol to control various peripherals of a micro-controller.

You could base it on the widely-used AT Command protocol

http://www.itu.int/rec/T-REC-V.250/en

eg,

AT*PWM=100

AT Commands are a bit cumbersome for machine use, but are great if you also want human users to be able to use the interface; eg, at a terminal...

Author
helping uart
Posted
13-Jul-2017 10:10 GMT
Toolset
ARM
New! RE: Trying to create a generic program to control various peripherals of a micro-controller.

The serial communication between a PC and a peripheral microcontroller is a case.

The simplest, might be the serial 1byte send command without response expected.
If a response is required it could return an ACK/NACK to the comamand or data.

The modbus protocol (ASCII/RTU) over serial lines is very well documented
and used for many years in vast applications.

The classic IP network has already given solutions to brief communications
with simple protocols like ICMP and UDP.

a. IP+ICMP echo
Serial medium + SLIP + IP header(20bytes) + ICMP header(8bytes) + N data bytes
This ICMP implementation requires 20+8=28bytes for header and N data bytes
@9600 for 4 data bytes the time needed is about 32ms
@9600 for 32 data bytes the time needed is about 60ms
@115200 for 4 data bytes the time needed is about 2.8ms
@115200 for 32 data bytes the time needed is about 5.2ms

b. IP+UDP echo
Serial medium + SLIP + IP header(20bytes) + UDP header(8bytes) + N data bytes
same speed ...

The overhead to accept/buffer/process IP+ICMP/UDP header is typical and not an issue.
Even the cheksum in many cases is optional or can be implemented with simple math.

Instead of an Ethernet network adapter you can use the classic serial port
either physical as COM1 or virtual by USB to Serial adapters.
The slip driver is available (or can be implemented) at Embedded microcontoller side
and is available on PC side like Win/XP and almost in all Unix/Linux OS,
but is missing on win7/8/10.

Using the IP set the device/service can be expanded to the Internet of Things era.

...

Author
Westonsupermare Pier
Posted
13-Jul-2017 12:41 GMT
Toolset
ARM
New! RE: Trying to create a generic program to control various peripherals of a micro-controller.

Review chapters on how Asynchronous Serial works, levels, start bits, stop bits, parity, data bits etc. Some books/datasheets from the 1970's or 80's might be illuminating.

Review chapters of data representations, structures, binary numeric forms, etc. Pretty foundational stuff. If you don't grasp this stuff building protocols is going to be a bit difficult.

Discuss with professor/tutor, or review any number of texts on computer architectures, micro-controller design, etc.

Next Thread | Thread List | Previous Thread Start a Thread | Settings

Keil logo

Arm logo
Important information

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies.

Change Settings

Privacy Policy Update

ARM’s Privacy Policy has been updated. By continuing to use our site, you consent to ARM’s Privacy Policy. Please review our Privacy Policy to learn more about our collection, use and transfers
of your data.