Safe & Sound - Safety Jacket for the Tolling Industry #6: Writing your own protocol - part 2

Its been two weeks since my last blog posts and my absence has been due to good reason. I am pursuing my PhD. where lab machine time is hard to come-by. Coupled with some health issues, the last two weeks have been the most hectic ever.

In this post I continue some basics of protocol design and next week, I will move to finally document the implementation of the project itself.

What is TLV?

A quick search on google reveals that TLV stands for Type-length-value. In this protocol, we start by sending the type parameter to indicate communication type and consequently the length of the entire structure and finally the value to be communicated. This is basically what we did the last time around with the difference that we now want to simplify things. There are no address or misc bytes of data.

I have used TLV in another project here https://www.element14.com/community/groups/lighting/blog/2016/01/16/multipurpose-modular-light-bar-project-08-mqtt-communications-at-the-cc3200--javascript-paho-and-tlv-protocol where it was piggybacked on MQTT.

Where is it and why do we need it?

In our case, we will be piggybacking it on our Network Layer.

The essence of a protocol stack is that each layer has an individual function and each layer has some specific functionality. In our case, the stack looks like…

------------------------------------------------- 

|         TLV Layer/Session layer                    |

-------------------------------------------------       

|        Network Layer/Base protocol            |

-------------------------------------------------

|        Physical Layer/Serial/UART               |

-------------------------------------------------

This relates to the OSI model and theoretically not all layers are necessary. An Application layer will sit atop this stack and that is where the primary application code resides and takes decisions etc.

We require this middle layer so that if we decided to use the same application with TCP/IP sockets or even MQTT, this layer can be modified without modifying the application code. This facilitates portability and the application can be developed on Windows, tested on Linux and finally implemented on a BeagleBone Black.

The implementation will be similar to what is discussed in the previous post here (https://www.element14.com/community/community/arduino/blog/2015/01/24/dynamic-living-room-lights-the-tree-code-explained--write-a-protocol-with-interrupts)

The layer integration

The next problem faced is that of use and integration and how one layer talks to another. There are a number of ways this binding happens and here are the basics. Take the example of our Base protocol that uses Serial functionality of the platform. In order to receive and send a byte, we have a function called get_serial_buf() and put_serial_buf(). Here the functionality is encapsulated in functions and this could be fetch from a buffer, read a register or simply read a file for testing. Hence simply put the code in primitive C language was usually a pointer to a function. In some cases a programmer would use #define macros but using pointers to functions is still a better way.

Hence there will be a header file with pointer definitions and then they would be passed the address of functions that could access lower layer functionality. In the last instalment, the process of writing the payload was not mentioned and it was because of want of this explanation. Hence we can modify the old code to write to a memory location and define a function to read that space. This function can now be called in the upper layer i.e. the TLV layer. Incase the same communication needs to be done over MQTT, simply point to the function that can read the MQTT Payload.

We will go into more details IF I get feedback in the comments. In my last post, no one realised that the state diagram was actually missing and unless details are necessary, I don’t feel like adding them in the first place.

Where is the code?

Unlike the last post, I am not including the code yet. I will upload and link a video demo and explanation on Monday to conclude this series. Suffice to say that this should provide useful for beginners and people trying to understand any kind of protocol stack and the why’s behind it.

I am experimenting with BLE and the TI BLE module next along with a series on Autodesk Eagle- from start to finish.

Let me know what you think in the comments.

Happy hacking,

Cheers,

IP

Please click the safety_jacket tag for all posts in the series.