gardenergeek.com

Gardening, electronics and everything else that is fun.

Author: gardenergeek

The RTOS-SDK for ESP8266

In my previous post I described some basic options when starting developing for the ESP8266, and also described the NON-OS SDK briefly. I have choosen not to use the NON-OS SDK mainly based on three resons:

  • ESP8266 comes with built in software and API, your application don’t “own” the hardware by itself (this is the main reason)
  • Threading can be a good tool for creating simpler code.
  • I have never used FreeRTOS, it seems more challenging and fun to explore it rather than using f.i. the Arduino IDE and just hack away.

The first reason is the most important to me, let me explain the reasoning.

Lets consider an example, you want to build a remote sensor that monitor temperature and reports it back to a central server. Using a simpler plattform to build this, when you are finished your binary will consist of your application code, some library code to use sensor and RF and a “main” binary from the arduino SDK which bootstraps the application and calls your application entry points (setup() and loop()).

The flow in the application is very simple:

  1. The CPU starts into “main” from the SDK, it initializes itself and then call your setup() function.
  2. When your setup function returns, the “main” module runs again and probably sets up a timer function, which will call your loop() function.
  3. Thats all, everything else that happens in the application are handled by your application.

When building the same solution with the ESP8266 using the NON-OS SDK, the solution whould be very similar. The only difference would be that you had to setup the timer yourself.

Ok, but why would this be a problem when using the ESP8266 and not using the Arduino?

As I see it, the problem is that your application must “share” the hardware with firmware developed by ExpressIf. The ExpressIf code is closed source, so you will never know in detail what it does, the only thing that you can be sure off is that it does some very important and time critical stuff (communicating over Wifi, e.t.c.).

When reading the documentation from ExpressIf, clearly point this out (from ESP8266 SDK programming guide by ExpressIf):

Notice:

• Using non-OS SDK which is single-threaded, the CPU should not take long to execute tasks:

‣ If a task occupies the CPU too long, ESP8266 can’t feed the dog, it will cause a watchdog reset;

‣ If interrupt is disabled, CPU can only be occupied in us range and the time should not be more than 10 us; if interrupt is not disabled,  it is suggested that CPU should not be occupied more than 500 ms.

• We suggest using a timer to check periodically, if users need to call os_delay_us or function while, or function for in timer callback, please do not occupy CPU more than 10 ms.

• Using non-OS SDK, please do not call any function defined with  ICACHE_FLASH_ATTR in the interrupt handler.

• We suggest using RTOS SDK, RTOS to schedule different tasks.

In most cases it will not be a problem if guidelines from ExpressIf is taken into account, however in practical work they are not that easy to follow. For instance, you have some code that for some reason disables interrupts, how long in us does it take to execute ? Does it take less than 10us ?

I generally think it is hard to develop software according to some rules, it is much more easy to have the rules enforced by an API, and this is what you get by using the RTOS-SDK instead of the NON-OS SDK.

A really simple and stupid example (if you called someFunc from a timer it would work)

	/* using the NON-OS SDK */
	void someFunc()
	{
		/* Do some lengthy stuff */
		while(true);
	}

	void ICACHE_FLASH_ATTR user_init(void)
	{
		/* Will cause Watch dog reset */
		someFunc();
	}

Call someFunc as a RTOS task, scheduler will make sure that firmware can do what it needs.

	/* using the RTOS-SDK */
	void someFunc(void *pvParameters)
	{
		/* Do some lengthy stuff */
		while(true);
	}
	void ICACHE_FLASH_ATTR user_init(void)
	{
		/* will work just fine */
		xTaskCreate(someFunc, (const signed char *)"task", 256, NULL, 2, &t);	
	}

Using the ESP8266

Ok, now its time to start developing for the ESP8266. Basically you can use it in two ways, either as a “wifi modem” using a different MCU for application (f.i. an Arduino) or use it standalone.  My first project will be a simple humidity and temperature sensor for our cellar. The purpose is to monitor the climate in orde to make sure that no mold can grow.

The solution will look something like this:

  • DHT22 sensor (measures humidity and temperature)
  • Some central unit (probably a Raspberry PI) for data storage and monitoring
  • Network using Wifi
  • Power supplied by battery

The ESP8266 hardware would certainly meet these requirement by itself, the challenge is to have it run on battery. An Arduino based solution could poweroff the ESP8266 completely when not sending data, and this would consume much less power than using the ESP8266 by itself. My goal is to have the solution running for a year on some standard alkaline batteries.

Now when the hardware plattform is set, it is time to consider the software plattform. There are several options available:

Language: assembly, C/C++ and Lua

SDK: NON-OS SDK and RTOS SDK.

I have worked alot in C/C++ so for me deciding the language was easy. Lua is cerainly a good option as well, but it is a new language for me, and I also think that using a script language developing for embedded systems “feels” wrong. However, the CPU is quite powerful so it might work very well.

NON-OS SDK and RTOS SDK

For the difference according to Expressif, se this article

Initially I started to use the NON-OS sdk, again it felt right when developing for embedded systems to maximize control and minimize overhead. I have worked with some other MCU:s and I have always worked directly with the hardware without any OS. A big advantage when working with the ESP8266 is that if you decide to use the NON-OS SDK, you gain access to several very good and easy development environments:

The Arduino environment

As a hobbyist interested in embedded systems, it is impossible to miss the Arduino plattform. It has a large community, a great number of libraries and available open source software. It is certainly the plattform that will get you productive really fast. Nowdays, it is possible to use the arduino environment when developing for the ESP8266. I have not tried this myself, but if you have used Arduino before it seems like a good choice.

Sming

If I were to use the NON-OS SDK I would must certainly use Sming. Sming is an opensource framework which makes working with the ESP8266 really simple. If you come from an Arduino background, you will also be familiar with the API, it is very similar. The ESP8266 is a much more powerful plattform than Arduino, The Sming framework makes using the Wifi parts in ESP8266 simple, in wraps the ugly expressif API:s in clean and simple to understand API:s and makes using the “flash file system” Spiffy simple. In my opinion this is the best option.

Read more about Sming

Using the NON-OS SDK directly

It is certainly possible to use the NON-OS SDK directly. I preffer working on Windows and I am used to Visual Studio and also the Arduino environment, I had much difficulties to get it to work, I suppose if you are a Linux guy it would be much simpler. And, anyway I see no advantage of using it directly, use Sming instead!.

In my next post I will explain why I selected not to use the NON-OS SDK.

 

 

ESP8266

I guess you all have heard about the little wonder ESP8266. It is a soc that contains wifi, CPU, GPIO and much more. It is incredibly cheap, only about $2-3 on Ebay.

In my greenhouse I want to measure and control many different things, my previous plan was to use arduino and the cheap nrf24l01 radio for this. The disadvantage is that I have to have another network on our farm (we already have Wifi), and off course I also need to bridge this network onto the Internet in order to make the data accessible for central processing.

So why not use Wifi instead, and I will have all infrastructure already in place!

The ESP8266 soc is hard to use withou making your own PCB, fortunatly there are a number of modules mainly manufactured by AI-thinker. They are named ESP-XX and all have different configurations, I have bought some ESP-01 (the first module), ESP-07 (possibility to add external antenna), ESP-12E and ESP-12F.

List of all modules

The boards have onboard flash memory to store user applications, and some (or all) GPIO pins exposed.

I think a really good “starter kit” is:

A module with bread board adapter:

ESP8266 SMD Adapter Board R2

I bought one adapter with a ESP-12F already soldered on, which is really convinient and it works very well. I also bought two extra without any module on it, and it worked great to solder both ESP-07 and ESP-12E onto it.

A breadboard friendly power supply:

Breadboard-Friendly Power Supply Module 5V/3.3V

The modules are quite power hungry, first i tried to feed it by the FTDI adapter (via USB), but it didn’t work very stable. The bread board power supply is really good, with on/off swicthes and the possiblity to feed both 5v and 3.3v at the same time.

An FTDI adapter (USP to serial), make sure it supports 3.3v:

CP2102 USB-TTL UART Module V2 (Genuine IC)

 

 

© 2017 gardenergeek.com

Theme by Anders NorenUp ↑