ESP8266 – Setting up Sming and NetBeans

Sming is one of the alternative firmware for the ESP8266 that is built on top of an extensive library that hides some of the ESP8266 SDK complexities. There is also another alternative firmware that is directly integrated with the Arduino IDE ESP8266 Arduino that mimics much of the process and ways off building Arduino sketchs that deploy and run on the ESP8266.

I’ve tried both, and for my tastes, since I prefer Netbeans or other editor to the Arduino IDE, I’ve choose to use the Sming firmware.

Setting up the SDK and Sming
For starting to use the Sming firmware, we should download the ESP8266 SDK and Sming from Github. The pfalcon esp-open-sdk is the fastest way to set up the SDK. Just do:


$ cd /opt
$ git clone --recursive
$ cd esp-open-sdk

Make sure for running the above commands that you have the prerequisites installed for your platform.
The make command will take a while depending of your internet speed and machine speed. It can take around 20 minutes or more.

For installing Sming, the Github site instructions explain what is needed. Basically it’s:

$ cd /opt
$ git clone

To use Sming we need to set our environment variables.

$ export ESP_HOME="/opt/esp-open-sdk";
$ export SMING_HOME="/opt/Sming/Sming";

But this change is not permanent and it won’t work with Netbeans without changing the Makefiles.
So we need to change the core Makefile to add permanently the paths to the SDK and SMING homes:

Set Sming environment paths permanently:
Just got to Sming home directory /opt/Sming/Sming and edit the file Makefile:

Change the lines (uncomment them, removing the #):

## Defaults for Sming Core

## ESP_HOME sets the path where ESP tools and SDK are located.
## Windows:
# ESP_HOME = c:/Espressif

## MacOS / Linux:
ESP_HOME = /opt/esp-open-sdk

## SMING_HOME sets the path where Sming framework is located.
## Windows:
# SMING_HOME = c:/tools/sming/Sming 

# MacOS / Linux
SMING_HOME = /opt/Sming/Sming

## COM port parameter is required to flash firmware correctly.
## Windows: 

# MacOS / Linux:
# COM_PORT = /dev/tty.usbserial

# Com port speed
COM_SPEED = 115200

For each project demo that we are going to compile, at the root of the project we need to change/uncomment at the file the same variables to define the same values. Otherwise Netbeans will complain that the SMING_HOME and ESP_HOME Variables are not defined. We can use the Netbeans itself to edit that file.

One final change is needed regarding the that is used by Sming to flash the ESP8266 chips. The tool is made to run with Python 2 and on my Arch Machine I have both Python 3 and Python 2, being Python 3 the default. Due to this, the esptool might fail to run with the following error:

# Generating image...
  File "/opt/esp-open-sdk/esptool/", line 135
    print 'Connecting...'
SyntaxError: Missing parentheses in call to 'print'
/opt/Sming/Sming/ recipe for target 'out/build/app.out' failed
make: *** [out/build/app.out] Error 1

So we need to edit the file and change the header to use Python2:

#!/usr/bin/env python2

Also the tool assumes that the ESP8266 is connected and available at the serial port ttyUSB0.

We can now go to one of the examples directory and compile one of the examples. Since I’m using my own developer board that uses serial RTS and DTR to enter “automagically” the ESP8266 in flash mode, I just need to do make at the root of the example directory. If needed we can flash again with the command make flash

And that’s it.
Just a word of caution, since my developer board uses the RTS and DTR lines, the Sming Make file calls the that doesn’t set the RTS and DTR lines to inactive state, and so keep the ESP8266 in reset mode. To solve this, just change the TERMINAL directory on the makefile of your platform located at Sming/Sming to something that works. EDIT: Or use CTRL-T + D and CTRL-T + R to reset the lines.

Setting Netbeans to compile with the Sming Framework
Important note/update: With the latest Netbeans 8.1 version, code completion doesn’t work. Use version 8.0.2 for now to solve the issue.

To use Netbeans, just open up Netbeans, and go to Tools->Options and select the C++ icon. If needed press the Activate button to enable C++ support.
The instructions are now very similar to those in this post Setting up Netbeans for ESP8266. Just make sure that you have the C++ plugin installed, and restart the IDE if necessary.
Then at the C++ Window Build Tools tab, just add a new Tool Collection, but this time the compiler path is /opt/esp-open-sdk/xtensa-lx106-elf, and ignore the error, but select the family as GNU. The error should be gone. Give it a name: ESP8266 Xtensa and press OK. Just set up now the path to the C compiler and C++ compiler located on the bin directory: /opt/esp-open-sdk/xtensa-lx106-elf/bin.

Netbeanx Xtensa compiler

Netbeanx Xtensa compiler

For making Netbeans Code completion work, we need to add the path to include files on the Xtensa compiler tools. Make sure that it’s the ESP8266 Xtensa compiler that is selected and add the following paths:

Include paths

Include paths

These might not be enough. It really depends on the project. Make sure that you add the include paths to both the C++ and C compiler.

I had to add the following paths at the Code Completion for the Xtensa compiler so the code completion could work without warnings on the SmingCore.h file with the latest Sming version:

  • Sming/rboot
  • Sming/rboot/appcode

Just add this directories the same way as the above screenshot.

Also at the project level properties it is necessary to add the project include directory so that the user_include.h file and others can be found.

And we are set!

Compiling Basic_Blink Project
Using Netbeans, just add a new C++ project with existing sources, and select the root directory of any of the examples, in this case, let’s choose the /opt/Sming/Basic_Blink. Just make sure that the compiler tools choosen is the ESP8266 Xtensa that we previously have defined. At start Netbeans will try to run the make command, and it might fail.
Just open on the project tree the file and remove the comment from the lines defining the ESP_HOME and SMING_HOME paths.
Also select the Makefile, right click Make target->Add target and add the word flash as a target.

That’s it, we can now make the project and select Make Target->flash to flash to the device.

Happy coding

ESP8266 – Developer board for the ESP-01 and ESP-12

Not sure what might be the expression in English to express my level of frustration, but I finally gave up on Lua and the Nodemcu firmware for the ESP8266. The combo of ESPlorer and Nodemcu with the fact that isn’t required to flash the ESP8266 to deploy and test new code is in fact a great advantage. But this comes with a price, a hefty price. Above certain levels of complexity or code size, the Nodemcu firmware just starts to reboot randomly or hangs, and this adds a high level of frustration to developing medium size program. Add one more instruction, or line, and presto. It doesn’t work anymore, and I’m starting to delete comments, spaces, empty lines, to make it work again… Why bother… I’m not alone on this one: 4 reasons for leaving nodemcu…. My opinion Nodemcu is great for simple things and fine for testing, even if there is the need to learn Lua. Anything above that, there are better alternatives now and on the horizon.

Solving the problem
The problem that Nodemcu solves is the fact that we don’t need to flash any new firmware to test new programs or code. To flash new firmware we need to pull GPIO0 to Ground and pulse reset and then use a program, like to push the new firmware to the chip. With Nodemcu we do this only once, on the initial ESP8266 configuration.
For other alternative firmwares, we need to always flash the firmware with the new code/program.
But the holds a secret, it can pulse the physical serial port lines DTR and RTS to command GPIO0 and RESET to initiate the ESP8266 in flash mode, transfer the firmware, and when it ends releases the lines and allows the ESP8266 to run the new code. All without changing any connections on the ESP8266 at the physical level. In fact with this we can have the same functionality as the Nodemcu witth other firmwares. Off course off the shelf (ebay…) chips don’t do that, but I’m aware that Nodemcu and Olimex boards do support this kind of flashing mode control through the serial port. I could just bought one of these, but after programming the ESP8266 remains attached to that support electronics (serial chip) that might not be needed anymore.
So off we go building a developer board that allows the easy flashing and programming the ESP8266 but then allows the chip, namely ESP-01 and ESP-12 to detach and be used on their final board.

The board
My idealized board and in semi state of final construction (proto board) supports the firmware flashing, powers up either from a power supply or trough mini-usb, and can program the ESP-01 or ESP-12.
My design is based on a circuit available in the site, with some modifications. Also, due to the fact the DTR and RTS lines do have a function now, it’s necessary that the serial terminal programs do control these lines correctly to see, if desired, the serial port output. The serial console of ESPlorer works just fine and it has specific buttons to control these lines. In fact by pressing the RTS line button we can reset by hardware the ESP8266…
All components of the board are sourced from available items on ebay, which means that building the board is just to solder and connect some components on a protoboard with connector headers for the ESP-01 and ESP-12. Also the board can program both types, but only one at the time…

The USB serial adapter
The USB serial adapter must be one that exposes the RTS and DTR lines, and provides the serial lines at 3.3V, the level for the ESP8266. There are CP2102 based boards available on ebay or DX, that expose all the lines and are 3.3v level.
I bought mine from Alice1101983 on ebay:
It’s data and control pins are 3.3v level, just right for the ESP8266, so no need to do any level conversion, and exposes the DTR and RTS pins. Notice the board holes on the side that have the other exposed pins:
alixpress_cp2102 (Image from Alixpress).
We need to solder a wire from the RTS pin to the ESP8266 RESET pin.

Power source
I’m not powering up the board through the USB/serial adapter. The serial port adapter does have a 3.3v power pin and also a 5v power pin. But the ESP8266 can demand high currents and the 3.3v regulator on the USB/serial adapter is almost certain not to be able to provide that current, even knowing that the USB port can provide 0.5A.
So I’m not using the power provided by the CP2102 serial adapter, and instead I’m using an MB102 bread board power supply with mini usb connector that can provide 5V and 3.3v outputs. I’ve also bought mine on alice1101983: alice_mb102
This specific board receives power through the usual DC jack, but with the mini-usb connector it also can receive power from an USB power supply (mobile charger), or, even better, an USB power bank.
One of the MB102 board outputs is set to 3.3v to power up the ESP8266 boards and any other 3.3v devices, and the other other power output is set to 5V and connected to an IIC I2C level converter allowing the use of I2C 5V level devices like the 16×02 LCD screens.
I’m using these level converter devices: ebay_i2c

The schematics that I’m using are based on this schematics:

I’ve got this from the ESP8266.RU site, the same from ESPlorer, and done some modifications.
With this schema, I can use the Arduino IDE and to program the ESP8266 without the need of explicitly enter the firmware flash mode.
Also I’m not showing in my schematics the ESP-12 connections, but they are in parallel for the RX, TX, RTS and DTR lines.

A word of caution
Since now the RTS and DTR lines do have a function, some serial programs to access the ESP8266 serial console do not work. ESPlorer terminal works fine, and it has a handy DTR and RTS toggle buttons.
I’m using my own brewed python pyserial based serial program, that correctly set the RTS and DTR lines, so that after flashing the firmware we can see the serial output if any.
Also the way that reset switch resistor is in series with the switch AFTER the reset pin, means that with the serial port adapter is connected, the reset switch doesn’t work. Without being connected to the USB port, the reset switch works fine. The resistor is there to protect the CP2102 RTS line.

Final thoughts
I’m still waiting for the female headers to connect and start programming the ESP-12 on this developing board.
But so far, every thing is good. I’ve already tested the Arduino firmware ESP8266 Arduino Firmware, Sming, and off I go for testing and Espruino, which is a Javascript interpreter for the ESP8266.

Odroid emmc speeds

I’ve found out this link that shows some speed benchmarks, on the Raspeberry PI, for some SD cards and disks: RPi SD card benchmarks.

For comparison, my data:

Odroid C1+ with 32GB emmc:

root@odroid:~# hdparm -T /dev/mmcblk0p1 
 Timing cached reads:   1494 MB in  2.00 seconds = 746.46 MB/sec

My Seagate 2TB on my DS212+, also driven by an ARM processor:

root@DiskStation:/volume1/homes/root# hdparm -T /dev/sda1

 Timing cached reads:   832 MB in  2.00 seconds = 415.24 MB/sec

The flash pen that holds the operating system on my old and faithful NSLU2:

root@nslu2:~# hdparm -T /dev/sda1

Timing buffer-cache reads:    78 MB in 0.51 seconds = 155972 kB/s

And finally my Crucial SSD disk on my desktop computer:

[root@pcortex:~]# hdparm -T /dev/sdc2

 Timing cached reads:   16804 MB in  2.00 seconds = 8408.63 MB/sec

The conclusion? Not bad for the emmc. Recommended over an SD card? I think definitely. Expensive? Well, yes…

Barometric and Temperature Sensor BMP180

Since I’m doing some experiments with my OpenWeatherMap LUA based client on the ESP8266 running the Nodemcu firmware, I’ve bought a BMP180 sensor.

The thing is that even starting with 30K of free heap on the Nodemcu firmware it is almost impossible to run all the code for querying OpenWeatherMap Json interface, driving the 16×02 LCD AND also using the bmp180 sensor for local data.

Anyway, this post isn’t about this, but to one simple thing: The bmp180 values for pressure where OK around the 1000s, but the temperature was completely bonkers… Negative values, high positive values. The issue? Simple, the SDA and SCL line where swapped…

So if using the bmp180 LUA libraries that are available and seem to work for everybody except you, and me ( :) ), check and double check the connections.

Odroid-C1+ – The low power super server

On the ARM based small computers front, running Linux or Android, there are several contenders, being the most famous one the Raspberry PI. Due to the huge community and documentation available the Raspberry Pi is the most chosen for a whole range of projects including low power servers, controllers, media players and so on.
Anyway, there are several alternatives, even cheaper, than the RPi. For example the 15$ Orange Pi looks promising on the price front, but not on the software side due to the Allwinner chip, it doesn’t look very promising without closed binary blobs. Other alternatives are the Banana Pi, Beaglebone board, Cubie board, and so on.

Anyway, since I needed something low power for running Node-Red, Sparkfun’s Phant, for logging data from the ESP8266, the RPi, was the way to go. But for the same price and with better specs, the Odroid-C1+ boosts also a very good community, supports Android, Ubuntu and even Arch Linux for ARM V7.

The advantages from the Odroid-C1+ over the RPi are:
– Same price (at least for me, 45€ for the RPi vs 44€ for the Odroid)
– Powerful 1.5 GHz quad core cpu
– Dedicated Ethernet chip not sharing the USB ports with 1GBps port.
– An emmc slot for storage allowing faster I/O than the SD cards. Sizes available between 8GB and 64Gb
– IR receiver
– Supports Ubuntu, Android, Arch Linux…

And so on.

As same as the RPi, the board by itself can’t do much, so I’ve also bought the power supply, acrylic box and a 32Gb emmc solid disk.
I was torn between the cheaper typical sd card and this emmc disk. Since the odroid supports it, why not?

As we can see, while it’s not faster than a typical SSD, it has the same performance than a spinning regular harddisk:

root@odroid:/etc/NetworkManager# hdparm -Tt /dev/mmcblk0p2

 Timing cached reads:   1440 MB in  2.00 seconds = 720.23 MB/sec
 Timing buffered disk reads: 240 MB in  3.02 seconds =  79.56 MB/sec

Anyway, while the emmc is expensive, more than the price of the Odroid for the 32GB, it feels snappy and boots quite fast.

The emmc comes with a standard 4GB partition, and we need to expand it to the full emmc capacity using the provided odroid utility, or also, the gparted utility that is shipped on the ubuntu release.

So after powering up:

– Went to my router web interface and under the DHCP server tried to find which IP the Odroid got.
– Note, if connected to a HDMI monitor and if a keyboard and mouse is also connected, we can use the Odroid utility on the LXE window manager to expand the partition size from the default 4GB.
– The odroid utility can also be used from the command line:
– With the IP I’ve got, I’ve ssh to the odroid and logon as root with odroid as password.
– Started up Gparted and increased the partition from 4GB to the 32GB emmc capacity.

root@odroid:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mmcblk0p2 29G 4.6G 23G 17% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
udev 420M 4.0K 420M 1% /dev
tmpfs 425M 8.0K 425M 1% /tmp
tmpfs 85M 2.6M 83M 4% /run
none 5.0M 0 5.0M 0% /run/lock
none 425M 8.0K 425M 1% /run/shm
none 100M 24K 100M 1% /run/user
/dev/mmcblk0p1 129M 7.2M 122M 6% /media/boot

– Updated the system: apt-get update and apt-get upgrade and it took a while to upgrade a lot of packages.

– After the upgrade I added a user: pcortex and made it to belong to the sudo group. This will be my working user, to avoid mishaps with the root user….

adduser –home /home/pcortex pcortex
passwd pcortex
adduser pcortex sudo

After the initial updating, and setting up, the remaining tasks where to install nodejs, node-red, phant and sqlite3.
Still as root:

apt-get install nodejs npm sqlite3
npm install -g node-red
npm install -g phant
npm install -g node-red-node-sqlite

For Android Notifications using the Google Cloud Messaging infrastructure:
npm install -g node-gcm (Check out: Node-Red GCM notifications

And finally making a link to let node be an alias of nodejs: ln -s /usr/bin/nodejs /usr/bin/node

Now with the user pcortex, we can start Node-Red and phant and starting doing interesting things with a low power super server :)

Edit: I’ve also changed the IP from a dynamic IP to a fixed IP. I’ve kept the hostname, odroid is cool enough :)

So I’ve edit the NetworkManager.conf file located at /etc/NetworManager, and changed the managed=false to managed=true under the section [ifupdown]. The final file is this one:



And then changed the network interface configuration to the fixed IP by editing the file interfaces located in /etc/network

# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static

Note: I’ve also installed nginx instead of Apache just to keep resource usage low, but that’s another story…

ESP8266 OpenWeatherMap simple client/display using I2C 16×2 display

Since I’m doing some experiments using I2C with the ESP8266 ESP-01 board, and also having available, from some arduino projects, a 16×2 LCD with an IIC I2C adapter, I thought to do a quick program to show the current weather conditions on my location on the 16×02 display.

The hardware

The 16×2 LCD that I have, has an I2C adapter bought on eBay based on the PCF8574 port expander. This allows to control the display only using the I2C bus, and nothing more except power. At a first stage I’ve tried to use the display at 3.3V, since the PCF8574 and the display supports it, but for the display at this voltage level the contrast is too low, which meant that I could not see nothing on the display at 3.3V.

So this means that I need to use the LCD at 5V, which the ESP01 doesn’t support. The solution for this problem is to use an I2C voltage level shifter from 5V to 3.3V and vice versa. Anyway I own a few, also bought on eBay, and connect the SCL and SDA lines through the level shifter to the SDA and SDL lines, GPI02 and GPIO0 of the ESP01 board. The LCD is powered up at 5v, while the ESP-01 is kept running at 3.3V.

Using  the LCD

For using the LCD, and specifically for the I2C PCF8574 based port expander, I’ve found a simple and effective Lua class for using the display: Nodemcu 16×2 LCD Lua driver

The only thing needed to use this code is to initialize the I2C bus and reference the class. For example:

local busid = 0  -- I2C Bus ID. Always zero
local sda= 4     -- GPIO2 pin mapping is 4
local scl= 3     -- GPIO0 pin mapping is 3


lcd = dofile("lcd1602.lua")()
lcd.put("Hello World!")

And with this code snippet, with the IIC I2C port expander based on the PCF8574, the LCD works. I’m emphasizing that the I2C adapter is based on the PCF8574 chip, because there are other I2C 16×02 adapters with other chips, that might work or not with this library. YMMV.

Getting OpenWeather data
Basically I’m using this site Lisbon, PT whether that offers a free API for requesting the current weather data on my location. The request is done to their API site, and the result is return in JSON format. On the API site we can request several types of data, and see some examples for those requests. On my code I’m requesting the current weather conditions, and for that we need to use the following link:

And the answer is something like:

{"message":"accurate","cod":"200","count":1,"list":[{"id":2267057,"name":"Lisbon","coord":{"lon":-9.13333,"lat":38.716671},"main":{"temp":18.63,"pressure":1016,"humidity":82,"temp_min":17.78,"temp_max":20},"dt":1441183037,"wind":{"speed":2.1,"deg":300,"var_beg":260,"var_end":340},"sys":{"country":"PT"},"clouds":{"all":20},"weather":[{"id":801,"main":"Clouds","description":"few clouds","icon":"02d"}]}]}

So what we have to do is to request the data, decode the JSON, fill up the Lua variables with the decoded JSON data, and show them on the LCD, simple, right?

Well, the code is quite simple, but after a while the NodeMcu heap is gone and the ESP8266 reboots, but ohh well, it shows that its is possible to be done.

The code

The code is as following:


--- Get Weather from
local json = require "cjson"  -- Json object for decoding JSON data. Is available on the firmware
local Location = "Lisbon"  -- My location.
local Metrics  = "metric"  -- I'm receiving data with the Metric system Celsius and m/s

local busid = 0  -- I2C Bus ID. Always zero
local sda= 4     -- GPIO2 pin mapping is 4
local scl= 3     -- GPIO0 pin mapping is 3

local MaxTemp = 0  -- Those are self explanatory...
local MinTemp = 0
local CurTemp = 0
local Humidity = 0
local WindSpeed = 0
local Wdesc = "No data yet!..."
local WSCalls = 0  -- I'm counting the number of calls to the API...
-- Initialize the I2C Bus for displaying data on the I2C 16x02 connected LCD.

After the initializations, we have the function that does the request, and on the callback function we decode the data. On the receiving data, humidity can never be zero, and if after the answer for the request still has that value (the initial value) I assume that the call failed. While I have no valid answer, I’m calling the API each 10s, and then only each 10 Minutes. Let’s not over call the API. It’s free after all. This control is done by timer 5.

function getWeather()
  conn=net.createConnection(net.TCP, 0)
  conn:on("receive", function(conn, payload) 
      record = json.decode(payload)
      MaxTemp = record.list[1].main.temp_max
      MinTemp = record.list[1].main.temp_min
      CurTemp = record.list[1].main.temp
      Humidity= record.list[1].main.humidity
      Wdesc = record.list[1].weather[1].main .." , "..record.list[1].weather[1].description
      WindSpeed = record.list[1].wind.speed
      --print("Data received!")
    end )
  conn:connect(80,"")  -- One of the IP's of
  conn:send("GET /data/2.5/find?q="..Location.."&units="..Metrics.."\r\nHTTP/1.1\r\nHost:\r\n"
        .."Connection: keep-alive\r\nAccept: */*\r\n\r\n")
  WSCalls = WSCalls + 1  
  if Humidity == 0 then
    tmr.alarm(5,10000, 0 , getWeather) -- The call might have failed so we keep the timer at 10s interval
    tmr.alarm(5,600000, 0 , getWeather)-- Sucess. Call the API each 10 minute interval

The following two functions will scroll the information horizontally on the LCD display. On the line zero the weather data, and on the line 1 the heap status and number of API calls. We this info we can see the heap slowly deteriorating until the module reboots after around 30/35 API calls.

function notice() 
--  print(node.heap());, "Heap: "..node.heap().."  WSCalls: "..WSCalls.."  ", 250, 1, notice) 

function noticeWeather(), "TCurr: "..CurTemp.."C Max: "..MaxTemp.."C Min: "..MinTemp.."C Desc: "..Wdesc.." Humidity: "..Humidity.."% Wind: "..WindSpeed.."m/s   " ,550, 2, noticeWeather )

Of course if we don’t have an LCD we can just print the data on the serial port.

Finally the code that starts it all:

getWeather()   -- Get the weather now.
tmr.alarm(5,10000, 0 , getWeather) -- Set's the timer for the initial API call each 10s

lcd = dofile("lcd1602.lua")()  -- Instantiates the LCD functions. 


The above code, while simple in nature heavily taxes heap…. With the NodeMcu firmware of July 2015, the initial heap after running the init.lua and connecting to WiFi is around 30K, and with the first API call drops to around 10K. From that point with each call the heap drops steadily until the module reboots due to an out of memory error.

The complete code is available here: GitHub Code .

EDIT: It is now necessary to add an API Key to the OpenWeatherMap requests. Register, it is free, and get the API key. My code in GitHub shows how to use the API key.