5 bits | 3 bits | n bytes | 3 bits | n bytes | 3 bits |
---|---|---|---|---|---|
command | param-size (bytes) | param-data | param-size | param-data | end-sequence |
This is complete frame that needs to be transmitted to the embedded device.
This is the command that needs to be sent to the device.
Allows the user to specify how bits are allocated to the first parameter. This is specified in Bytes (max limit is 8 Bytes).
In the cases of strings, this would just be broken into a bunch of 8 Byte chunks.
The actual data that needs to be transmitted over the protocol.
000
is the end sequence. The reason this is 3 bits is because the this can be interchangeable with the param-size
portion.
Eg.
5 bits | 3 bits |
---|---|
command | 000 |
About the commands, do you have some bandwidth limitation? It would be easier to work with if we didn't have to split bytes and fiddle with bits to extract the values of interest, and likewise when we are forming a command, it would be easier if we could just send our variables out on the wire without having to do bitwise operations.
It is very strange that the 'word length' is changing from 3 to 8 bits for the transmission of each param length and param data, respectively. Embedded serial hardware is generally designed to work with 8 bit words, and I've never seen anything that will let you do three. This means that this protocol would have to be 'bit banged' by a microcontroller, and that's not helpful.
I recommend you revise your packing so that every field is 8 bits (or some multiple thereof): command, param length, and so on.