I created one of the most simplest to use protocols for networking Arduinos. Of course there is Modbus, but it is overkill to use with the limited resources on the Arduino. This protocol fits only on one page! Works well on the Master/Slave LIN, RS485 and 2 node RS232. Enjoy
looks interesting, you have the arduino code somewhere?
Looks interesting. Indeed, any examples for us please?
Can you do us a favour - remove these posts then repost again but this time use the CODE button to post the code. That way we don't have 87 feet of pages to scroll down. Thanks.
Without proper library implementation of this protocol. I don't think this will be very useful or adaptable to the vast majority of Arduino users. That is not to take away from the effort you have shared with us, thanks.
Lefty
If I was reading a Sensirion SHT71 sensor then I would build it into a library.
Networking Arduinos and building a library on beta code is ludicrous due to the many changes that are needed to maintain the network.
You try it sometime
For those who want to examine my beta code please drop me a PM and I will send you the "87 page" code "book".
You try it sometime
Not likely, I know my software limitations. 
Lefty
Since you're going to be mixing devices that will, in some cases, be under active development, I strongly recommend the inclusion of a "message type and version" byte in the header. The "CMD" byte doesn't exactly cover that, because the format and size of the data string can change from version to version. Although you could redefine it for the purpose.
To really make the protocol robust, there should be a length byte in the header somewhere: if the command or response message structure is changed, "down-level" devices could become confused about how big the message is supposed to be, and get out of sync.
Ran
To really make the protocol robust, there should be a length byte in the header somewhere: if the command or response message structure is changed, "down-level" devices could become confused about how big the message is supposed to be, and get out of sync.
On my LIN bus application, I used a fixed packet size and by one #define
all the receive and transmit arrays are adjusted for transmit and receive.
So all the user would have to do is to make sure the baud rate, node IDs
(are different) and data byte size are all the same - I did this for simplicity sake. "Keep It Real Simple Protocol"
To really make the protocol robust, there should be a length byte in the header somewhere: if the command or response message structure is changed, "down-level" devices could become confused about how big the message is supposed to be, and get out of sync.
Ran, that's a good suggestion. That way you could have packets that varied in data length up to the maximum size. As it stands, if your packet contains data bytes, you have to pad it up to some prearranged size so that the receiver knows where data stops and CRC starts. You also would not have to treat the packet that just contains a command as a special case.
There should be no reason that a forum user could not add to the KIRSP protocol header to include the size of the data packet. After all, KIRSP is not set in concrete but a framework in which other Aruduino users can utilitize for network communications. The Modbus spec is about 50 pages long compared to mine at one page.
Good suggestion EJ & RT.
what ever happened to i2c?
It's alive and well. As the name suggests, it was designed more for communication among integrated circuits, usually on the same circuit board. While it can be extended to the bus lengths LIN accommodates with drivers, it normally is not.
Andy: recompiling and reloading everything is fine for your particular application. Maybe even better.
But, for a more general-purpose protocol (which I thought was what you were proposing), you need flexibility and error-resistance.
A simple example: you mentioned using your protocol for environmental and security monitoring. Let's say you add a fingerprint sensor by the front door. If you stick with fixed-sized packets, every message has to be expanded to the size needed by that sensor. If you make the size dependent on the CMD code, every device has to be updated every time you add a new message type.
By making a minor tweak to the work you've already done, you can make it useful in a lot more situations, more efficient, and better able to detect and recover from errors.
Ran
There should be NO reason that a forum user could not add to the KIRSP protocol header to include the size of the data packet. After all, KIRSP is not set in concrete but as a framework in which other Aruduino users can utilitize for network communications. The Modbus spec is about 50 pages long compared to mine at one page.
Good suggestion EJ & RT.
My quote still stands (above).
Having 32 or even 64 bytes of "message packet data" in a fixed length
format should be more than sufficient considering the limited resources
of the Arduino. We are not dealing with a programmable logic controller
PLC which has much more flexible resources than the Arduino.
you need flexibility and error-resistance.
If you mean "error-resistance" as error checking then my CRC-16 algorithm is more than sufficient for this application.
If you mean "error-resistance" as user configuration setup errors than,
in my particular application ,all the different header combinations are
checked for proper "setup" and all transmission of packets are aborted
if there are any configuration errors.
As it stands, if your packet contains data bytes, you have to pad it up to some prearranged size so that the receiver knows where data stops and CRC starts
Don't get me wrong, but I thought thats why most people use "arrays"
in data packet transmission.
"(M)ost people" would use whatever structure made the most sense for the application.
If for your application it's okay to transmit 128 characters, for example, when only 16 of them are valid data, then by all means do that. I'm just commenting that many applications have variable length records and a character count in the header is a way to accommodate that without wasting processor resources.
In the end, it's your protocol.
There are two different opinions concerning whether to use a fixed packet or a variable length
packet in the transmission and reception of data between network nodes.
The variable length data format is more efficient in data transmission and resource savings (less ram).
It also adds a layer of complexity and requires more programming skills and is extremely quite complex
to troubleshoot.
Having the fixed byte packet allows the user to have a network which is deterministic. The fixed value of x bytes
will take x milliseconds long for transmission. It also reduces the complexity of the communications software
algorithm and allows for easier troubleshooting. Knowing that each fixed packet is 32 bytes long is easier to
troubleshoot than a varying packet size. It is up to the system designer to determine the fixed size of the packets.
Having 128 data bytes sent and only using 16 bytes would be not only stupid but very inefficient.
I tried to keep to my communications philosophy "Keep It Real Simple Protocol" and by having a variable packet size
I would have to change my protocol name to "Keep It Real Hard Protocol". In the end, the end user should determine
which approach to take. Cheers
There are two different opinions concerning whether to use a fixed packet or a variable length packet in the transmission and reception of data between network nodes.
There are two of many being discussed here at the moment.
The variable length data format is more efficient in data transmission and resource savings (less ram).
Since we are considering a microcontroller based system, conservation of resources is a valid concern.
It also adds a layer of complexity and requires more programming skills and is extremely quite complex to troubleshoot.
Explain how it adds a layer of complexity. It seems to me that the trade off is reading a hard coded number of bytes to receive as opposed to reading the number of bytes to receive out of a header that you have to read and parse anyway.
You have mentioned troubleshooting numerous times, please explain what this troubleshooting might consist of and how either protocol affects its complexity.
Having the fixed byte packet allows the user to have a network which is deterministic.
Both methods are deterministic. Your failure to acknowledge that leads one to wonder if your purpose was to obfuscate or that you simply don't know what the term means.
The fixed value of x bytes will take x milliseconds long for transmission.
I think you must mean f(x) milliseconds because I don't think you are suggesting we adopt a non-standard 10,000 bps rate. That also brings up the question: are you assuming your slaves can accept the characters as fast as the master can queue them or do you propose some sort of flow control?
It also reduces the complexity of the communications software algorithm and allows for easier troubleshooting.
You bring up complexity and troubleshooting again. How does this protocol affect them.
Knowing that each fixed packet is 32 bytes long is easier to troubleshoot than a varying packet size.
This implies that the designer of the diagnostic software is not clever enough to use a constant packet size for troubleshooting, if indeed that is the best thing to do. Observe that a variable data length protocol will have a constant packet size if the data length is not varied.
It is up to the system designer to determine the fixed size of the packets.
Having 128 data bytes sent and only using 16 bytes would be not only stupid but very inefficient
.
On the other hand the designer's job is made more difficult and complex by having to select a fixed packet size to accommodate all potential users while still conserving the scarce resources of the node controller.
I tried to keep to my communications philosophy "Keep It Real Simple Protocol" and by having a variable packet size I would have to change my protocol name to "Keep It Real Hard Protocol".
And yet you will discover that at some point, simple is as simple does.
In the end, the end user should determine which approach to take
.
Just out of curiosity, when the master is talking to one of the slaves, how do you keep the other slaves from reacting to a 0x55, 0x[slave address] byte sequence that might be part of the data stream?