Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I would use <a href="http://en.wikipedia.org/wiki/HDLC" rel="nofollow noreferrer">HDLC</a>. I have had good luck with it in the past. I would for a point to point serial just use the <a href="http://en.wikipedia.org/wiki/High-Level_Data_Link_Control#Asynchronous_framing" rel="nofollow noreferrer">Asynchronous framing</a> and forget about all of the other control stuff as it would probably be overkill.</p> <p>In addition to using HDLC for the framing of the packet. I format my packet like the following. This is how options are passed using 802.11</p> <pre><code>U8 cmd; U8 len; u8 payload[len]; </code></pre> <p>The total size of each command packet is len +2</p> <p>You then define commands like </p> <pre><code>#define TRIGGER_SENSOR 0x01 #define SENSOR_RESPONSE 0x02 </code></pre> <p>The other advantage is that you can add new commands and if you design your parser correctly to ignore undefined commands then you will have some backwards compatibility.</p> <p>So putting it all together the packet would look like the following.</p> <pre><code> // total packet length minus flags len+4 U8 sflag; //0x7e start of packet end of packet flag from HDLC U8 cmd; //tells the other side what to do. U8 len; // payload length U8 payload[len]; // could be zero len U16 crc; U8 eflag; //end of frame flag </code></pre> <p>The system will then monitor the serial stream for the flag 0x7e and when it is there you check the length to see if it is pklen >= 4 and pklen=len+4 and that the crc is valid. Note do not rely on just crc for small packets you will get a lot of false positives also check length. If the length or crc does not match just reset the length and crc and start with decoding the new frame. If it is a match then copy the packet to a new buffer and pass it to your command processing function. Always reset length and crc when a flag is received.</p> <p>For your command processing function grab the cmd and len and then use a switch to handle each type of command. I also require that a certain events send a response so the system behaves like a remote procedure call that is event driven.</p> <p>So for example the sensor device can have a timer or respond to a command to take a reading. It then would format a packet and send it to the PC and the PC would respond that it received the packet. If not then the sensor device could resend on a timeout.</p> <p>Also when you are doing a network transfer you should design it as a network stack like the <a href="http://en.wikipedia.org/wiki/OSI_model" rel="nofollow noreferrer">OSI modle</a> as <a href="https://stackoverflow.com/users/18256/foredecker">Foredecker</a> points don't forget about the <a href="https://stackoverflow.com/questions/815758/simple-serial-point-to-point-communication-protocol/817750#817750">physical layer stuff</a>. My post with the HDLC is the <a href="http://en.wikipedia.org/wiki/OSI_model#Layer_2:_Data_Link_Layer" rel="nofollow noreferrer">data link layer</a> and the <a href="http://en.wikipedia.org/wiki/OSI_model#Layer_7:_Application_Layer" rel="nofollow noreferrer">RPC and command handling is the Application Layer</a>.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload