Introduction

In the last post about communication we discussed what it took to build up the ESP tool chain as well as the STM32 Toolchain. We loaded the esp-link interface on to the esp and a simple serial communication program onto the STM32 and had the two micro-controllers communicate. It was amazing but for the Sunleaf team sending data between micro-controllers just wasn't enough. We are building a next generation internet of things device. This means it has to work with a cloud system. This also means we need to be able to do basic REST commands. If you need to know more about REST commands I added a link here.

The esp-link supports micro-controller REST Commands but only though a Serial Line Internet Protocol SLIP interface. This was a surprise. Initially we were planning on using simple AT commands to 'GET' and 'POST' data. But there are a few issues with this. The basic serial communication protocol is error prone. Even with some nice libraries that do error checking we still experienced a few errors in the communication. It is also slower. We really though the right way to build this up is to add a SLIP interface to the STM32 so we can communicate with the esp-link and the rest of the internet reliably and quickly. In this log we first discuss what SLIP is. Then we'll cover the port we are using for the STM and give a working example.

SLIP: What is it, really?

When I first realized that I needed a SLIP interface I was hopeful. The STM32F446RE is a fairly common chip. There had to be someone working on an open source version that I could use. I couldn't find one. There are a lot of closed source versions available, if you have between $10K-$30K to drop on a license... But if that's you then you probably aren't reading this now. This definitely isn't us. So we decided we needed to build our own. To do this we needed to learn a little more about SLIP, why it exists and why is it used?

The SLIP protocol consists of commands with binary arguments sent from the attached the STM32 to the esp8266. The ESP8266 then performs the command and responds back. The responses back use a callback address in the attached STM-Client code. For example the command sent by the STM32 contains a callback address and the response from the esp8266 starts with that callback address. This enables asynchronous communication where esp-link can notify the STM32 when requests complete or when other actions happen, such as wifi connectivity status changes or RSSI Values...

However, there is no true internet standard for Serial Line IP. There is a good deal of work done on this still. It is intended to work as a point-to-point serial connection for TCP/IP connections.

SLIP is commonly used on dedicated serial links but has been replaced on many CPUs with PPP. For embedded systems like the STM32F+ESP8266 system it works well. It is also nice because I don't have to post my SSID and wifi password wit this configuration. This is because SLIP allows mixes of hosts and routes to communicate with one another (host-host, host-router and router- router are all common SLIP network configurations).

Basically it is a simple two layer protocol providing basic IP framing. Here is a diagram of how the protocol is supposed to work:

Here is a summary of SLIP:

• Breaks an IP datagram into bytes.
• Send the END character (value “192”) after the first and last byte of the datagram;
• If any byte to be sent in the datagram is “192”, replace it with “219 220”.
• If any byte to be sent is “219”, replace it with “219 221”

Kinda nifty? Well, not really. It is very old but for an embedded system to post reliable REST requests it is top-notch. Next we talk about how it is implemented in the STM32F446RE Board.

SLIP for the STM32: STM-Client Overview

As we discussed we've loaded a sun leaf version of the esp-link software onto the ESP. Here is where the source is kept: https://github.com/jeelabs/esp-link. Now, versions of esp-link use the SLIP protocol over the serial link to support simple outbound HTTP REST requests and an MQTT client. There are examples of these libraries for REST and MQTT libraries as well as demo sketches in the el-client repository. These only work on Arduino boards and I think a few NXP boards. If you want to use a real micro-controller you'll have to port some of this to C. Which is what I did...so I guess you don't have to any more...

The homepage for the mbed repository: https://developer.mbed.org/users/ShaneKirkbride/code/STM-Client/

Again keeping in mind that is is largely ported from the EL-Client repository here are some highlights about how this port works. First there are two serial objects that the client requires: Serial and DebugSerial. This is extreamly helpful because you are essentially blind to what is going on inside the STM32 once the program kicks off unless you use the debugSerial object. In the El-Client repo there is no true main.cpp for the rest example. This is because the program is intended for the Arduino. So the first thing we did was make our own. It was a very similiar example. The main difference is that the STM32 (or maybe the mbed API...) dosen't support asynchronous communication. There are a lot of stream objects in the Arduino code that don't port correctly to C.

This is fairly easy to overcome by Arduino the serial objects in main and changing the stream* datatype classes to serial* datatypes. This was really the biggest catch. Once I figured this out the only other trick was to reset the ESP8266. A lot of research went into figuring out how to do this correctly. I almost ported a LWIP library but found the STM-Client to work better.

Here is a screen shot of the system sending a 'get' request to www.timeapi.org.

I used putty...but you can use any serial output. This text is all through the serial debug port.

There is also a 'post' example that is commented out in the code for posttestserver.com. This also works but I'm working on this to get it talking to vivaplanet right now so it has limited functionality.

There are a few more firmware goals we are going to address in the next two months. The first will be posting to a cloud based server: vivaplanet. Posting to something like an Azure cloud service is non-trival for a platform but I'm confident it can be done. The second is OTA programming the STM32. This is also non-trival and may require a hardware change to the rev 2 board. Lastly, I need to get the Kalman filter engine working. If we're lucky we'll get to all of these topics before October. We also need a rev 2 board and a rugged mechanical housing but that will also be coming soon to a log entry near you.