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/esp-open-sdk

## COM port parameter is reqruied 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/uncoment 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 mad 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 thats 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.

Setting Netbeans to compile with the Sming Framework
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.

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…

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 NodeMCU firmware updating

My ESP-01 board has not being used for a few weeks due to other projects, and today, after updating my local nodemcu firmware repository I’ve found out that the latest build directory where the binary for the firmware was located was gone.
No problem.
We can find now the pre-compiled binaries on this link: NodeMcu Firmware Releases

There is also a cloud compiling option on this link: NodeMcu custom builds
If by any chance you are having second thoughts in providing your e-mail, use one from Fake Mails and wait for the firmware on the provided (temporary) e-mail.

Anyway, the procedure is always the same:

  • Close anything that using the serial port, for example the ESPlorer tool
  • Put the ESP8266 into firmware flashing mode by connecting the GPIO0 to ground and reset the board or power cycling.
  • Flash the firmware with ./ -p /dev/ttyUSB0 write_flash 0x000000 nodemcu_float_0.9.6-dev_20150704.bin
  • Remove the GPIO0 from GND and power cycle or reset
  • Connect to serial port and check the NodeMCU version

Update done!

Mosquitto Broker with Websockets enabled on the Synology NAS

Synology NAS are great devices, mainly due to the bundled software (CloudStation, Photo Station, to name a few), that also can run other software that is provided on non official package sources.
One of such providers is the SynoCommunity that provides a Mosquitto MQTT broker packaged for the Synology NAS. While I’ve successfully was able to cross compile the Mosquitto broker for my DS212+ NAS with websockets enabled (I do have a draft post with the steps that I’ve never published), the SynoCommunity package allows a simpler way to install and use a Mosquitto broker that has the WebSockets protocol support compiled in.

So, what is needed to be done?

Setting up:

  • 1st: Add to your Synology server the SynoCommunity package source. See the detailed instructions on the community web page.
  • 2nd: Install the Mosquitto package from the Synology package manager.
  • 3rd: Edit the file located at /usr/local/mosquitto/var/mosquitto.conf. You need to connect through ssh as root to do this.

At the end of this file add the following lines:

listener 1883
listener 9001
protocol websockets

Note that the 1883 is the standard MQTT broker port, and 9001 is the port that I’ve choose have the websockets server listening/answering.

After the change, stop and start the Mosquitto broker on the package manager action dropdown box for the Mosquitto package.

Still using ssh, and logged in as root, check now that the port 9001 is active:

root@DiskStation:/volume1/homes/root# netstat -na | grep 9001 
tcp        0      0  *               LISTEN       
tcp        0      0      ESTABLISHED

In the above case we can see that there is a websocket client connected to the broker from my workstation.


For testing we can use the HiveMQ websocket client: that allows to communicate using the websockets transport.

Despite the fact that the page is available on an external, internet based server, the websocket client will be running on YOUR web browser, on your machine in your own (internal) network, so at the connection settings for the broker, for Host I use my internal IP address:, and for the Port: I use the 9001 value.

I can now subscribe and publish to topics using the browser, and also using MQTT-SPY we can see and check the MQTT Websockets communication.

And that’s it!

ESP8266 – Updating the SDK to the latest version

So version 1.0 of the ESP8266 SDK as been released:
This means that I need to update my cross compiling tools for the ESP8266 to the latest version.
I’ve installed and configured my environment according to this post: and this post documents how I’ve updated my environment.

Updating the crosstools
This is quite easy, just go to the crosstool-NG directory and execute git pull. This will bring into your machine the latest release of the cross compiling tools.

Downloading and installing the Espressif ESP8266 SDK
At the date of this post I’ve downloaded this SDK version: This post refers to version 1.0.1_b1_15_04_02. At the bottom of this post there is a link for downloading the SDK. Just download the SDK:

On my configuration, my SDK is on the directory ESP8266_SDK at /opt/Espressif. So I just make a backup of this SDK version and expand the new one:

cd /opt/Espressif
mv ESP8266_SDK ESP8266_SDK_old
unzip ~/Downloads/
mv esp_iot_sdk_v1.0.1_b1/ ESP8266_SDK
mv License ESP8266_SDK

We need finally to install some libraries:

cd /opt/Espressif/ESP8266_SDK
wget -O lib/libc.a
wget -O lib/libhal.a
wget -O include.tgz
tar -xvzf include.tgz

And that’s it.

Compiling application and demos.
For compiling the IoT_Demo sample:

cd /opt/Espressif/ESP8266_SDK
mv example/IoT_Demo .
sed -i -e 's/xt-ar/xtensa-lx106-elf-ar/' -e 's/xt-xcc/xtensa-lx106-elf-gcc/' -e 's/xt-objcopy/xtensa-lx106-elf-objcopy/' -e 's/xt-objdump/xtensa-lx106-elf-objdump/' -e 's/xt-nm/xtensa-lx106-elf-nm/' Makefile
export PATH=/opt/Espressif/crosstool-NG/builds/xtensa-lx106-elf/bin/:$PATH

But before running make, check what version of python is the default:

python -V

If it is version 3, then the python scripts run only on python 2, and we need a workaround:

cd /opt/Espressif/ESP8266_SDK/bin
ln -s /usr/bin/python2 python
export PATH=/opt/Espressif/ESP8266_SDK/bin:/opt/Espressif/crosstool-NG/builds/xtensa-lx106-elf/bin/:$PATH

Running now the python -V command should report version 2.7.

We can now run make:

make[2]: Entering directory '/opt/Espressif/ESP8266_SDK/IoT_Demo/driver'
make[2]: Leaving directory '/opt/Espressif/ESP8266_SDK/IoT_Demo/driver'

No boot needed.
Generate eagle.flash.bin and eagle.irom0text.bin successfully in folder bin.
make[1]: Leaving directory '/opt/Espressif/ESP8266_SDK/IoT_Demo'

Success. We can now flash the IoTDemo.