Geek Answers Handbook

Development of a protocol for serial commands and data

I need (to design?) A protocol for communication between a microprocessor data logger and a PC (or similar) via a serial connection. There will be no control lines, the only way the device / PC can know if they are connected from the data they receive. The connection can be broken and restored at any time. The serial connection is full duplex. (8n1)

The problem is which types of packages to use, handshake codes or similar. The microprocessor is extremely limited in capabilities, so the protocol should be as simple as possible. But the data logger will have a number of functions, such as scheduling logging, loading logs, setting the sampling rate, etc., which can be active at the same time.

My bloated version will look like this: for a data logger and for a PC, a fixed packet size is 16 bytes with a simple verification amount of 1 byte, possibly 0x00 bytes at the beginning / end to simplify packet recognition and one byte indicating the type of data in the packet (command / parameters / log data / real-time values, etc.). For synchronization, a unique "hello / reset" package (total zero) can be sent to the PC, which, after detection by the device, is returned to confirm synchronization.

I would appreciate any comments on this approach and welcome any other suggestions, as well as general comments.

Observations: I think I will have to fold myself, since I need it to be as light as possible. I will take pieces from the protocols suggested in the answers, as well as some others that I found ... Slip , PPP and HLDC .

+4
source share
3 answers

The microcontroller interconnect network (MIN) is designed specifically for this purpose: the tiny 8-bit microcontrollers speak with something else.

The code is licensed by MIT, as well as embedded C, as well as Python implementations:

https://github.com/min-protocol/min

+2
source

You can use Google Protocol Buffers as a data exchange format (also check the C> bindings if you use C). This is a very effective format, well suited for such tasks.

+6
source

I would not try to invent something from scratch, perhaps you could use something from the past, for example ZMODEM or one of its cousins? Most of the problems you mentioned were resolved, and there are probably a number of other cases that you did not even notice.

Details of zmodem: http://www.techfest.com/hardware/modem/zmodem.htm

And the source code c is in the public domain.

+1
source

More articles:


All Articles