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.
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.
www.keil.com/.../
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 ... ?
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.
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.
github.com/.../protocol
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.
...
You could base it on the widely-used AT Command protocol
www.itu.int/.../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...
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.