However the Facebook post did not attract too much attentions. I went ahead and shared the same on Twitter with hashtag #ESP8266.

It’s official! #ESP8266 I/Os are 5V tolerant. #goodtoknow pic.twitter.com/SBf9a7qOx9

— Baoshi (@ba0sh1) July 30, 2016

//platform.twitter.com/widgets.js

Apparently Twitter has much more bandwidth among ESP8266 fans. Soon I received quite a few counter claims that their ESP8266s were toasted by 5V input voltage. So who is correct? The chip designer or the end users? I think it would be interesting to find out.

On a side note, Twitter user vAir (@vAirMon) pointed to me that on Page 17 of ESP8266 Datasheet it is mentioned  “All digital IO pins are protected from over-voltage”. I looked into my document archive and found it does appear on “Version 4.3” of “ESP8266EX Datasheet”, released “Tuesday, May 12, 2015”.

But on a more recent version, Version 1.0 (?) , released “20160422”, the whole section is removed.

Though intriguing, the “old” datasheet do point out that the over protection is based on “snap back” circuit, not the traditional two diodes voltage clamp. I found some  background information of these two protection methods here. Basically snap back circuit sits only in between input and GND. There is no conductive path between input and power rail therefore it is not possible for 5V input voltage to raise the 3.3V rail.

Experiment

Assumption

The fact is that I do not have access to any die-inspection equipment. Even if I had the equipment I would not be able to tell if a silicon die was damaged from over voltage. Therefore the experiment is designed based on the assumption that I/O will only destroy the chip via excessive input or output current, which causes thermal breakdown. As the GPIOs on ESP8266 are specified to be able to source 12mA, and usually I/O pins are able to sink more current than sourcing, I conservatively assume that any input/output current larger than 12mA is able to fry the chip.

Test of over-voltage input

The experiment setup is as follows:

For the experiment I’m using my ESP8266 Breakout Board with ESP-12E. It has GPIO pins directly connected to the leads. The AMS1117 regulator on the breakout board is removed to get rid of LDO GND current. Instead, the module is powered with 3.3V from GW Instek GPD-3303S power supply. An Advantest/ADCMT 6240A DC Voltage Current Source/Monitor is used to simulate voltage input into GPIO5. I used the following Arduino sketch as testing firmware:

#include <esp8266wifi.h>
void setup()
{    
    WiFi.forceSleepBegin(); // turn off ESP8266 RF     
    delay(1); // give RF section time to shutdown
    Serial.begin(115200);
    Serial.println(F("ESP8266 in No-RF mode"));
    pinMode(5, INPUT);
    pinMode(4, OUTPUT_OPEN_DRAIN);
    digitalWrite(4, HIGH);
}

void loop()
{
    int pin5 = digitalRead(5);
    if (pin5 == HIGH)
        Serial.println(F("IN5=HIGH"));
    else
        Serial.println(F("IN5=LOW"));
    delay(500);
}

In the beginning of setup(), I purposely turned off WiFi  so that the power consumption of ESP8266 can be monitored from GW Instek supply more precisely without WiFi interference.
For this experiment, I vary ADCMT 6240A power output from 0V to 5.5V in 0.1V steps. Below is the result of GPIO5 input voltage vs. input current:

It is clear that

• When the input voltage varies from 0V – 5.5V, maximum sinking current for ESP8266 is only 3.52uA, maximum sourcing is 0.89uA
• Of all the experiment the supply current for ESP8266 stays at 16mA, GPIO input does not go into 3.3v rail.
• No any type of over current observed
• The GPIO input L-H transition is at 1.6-1.7V (not shown on the graph)
• It seems the chip internally has 1.8V and 3V domains. Some switching happens in between 1.8V to 3V where the input pin actually sources current out.

Test of over-voltage pull-up at output

Similar experiment is also done with over-voltage pull up at output pin. The setup is below:

In this experiment, GPIO4 is set to Open Drain output mode. An external pull-up resistor pulls GPIO4 output above 3.3V. The choice of pull-up resistor is 1K, smaller than usually required. Because of the pull-up resistor, the current feed into GPIO4 will never go beyond 5.5mA. However it is still interesting to find out what is the actual amount.

The result is below:

• When the pull-up voltage varies from 0V – 5.5V, maximum GPIO sinking current is only 3.72uA, maximum sourcing 0.83uA
• Of all the experiment the supply current for ESP8266 stays at 16mA
• No over current observed
• The 1.8V phenomenon can be observed too for output.

Conclusion

I believe the experiment result is conclusive. The ESP8266 I/O is 5V tolerant unless couple of uA current can destroy the chip. Except for completely wrong wiring, such as feed 5V into 3.3v rail or feed 5V into output pin (in output low state or in output high with push-pull mode), 5V on GPIO pins will not destroy ESP8266.

The post Is ESP8266 I/O really 5V tolerant? appeared first on Digital Me.

If you search MQTT and ESP8266 on the intraweb, most likely all hits can be traced back to the great work done by TuanPM. However Tuan’s code is based on Espressif’s NON-OS SDK. There has been some great debates about embedded programming with-or-without an OS. To me programming with OS vs NON-OS is like programming with C vs Assembly. I like programming in C, so I wrote a new MQTT client for Espressif’s RTOS SDK.

The source code is published at https://github.com/baoshi/ESP-RTOS-Paho

Here are some notes:

• The code is based on the Eclipse Paho project, specifically the embedded C client.
• Socket-level APIs used, the code is thread-safe.
• Many error handlings were added to the original Paho client, including time-out for most of the network functions. These are designed to work with an RTOS to support automatic error correction at various abused conditions.
• I’m compiling using the “Unofficial ESP8266 DevKit“. Other toolchain such as esp-open-sdk can be used as well (adjust pathes in Makefile).
• Skeleton code for connecting a MQTT broker is as follows:

[code]
struct Network network;
MQTTClient client = DefaultClient;
MQTTPacket_connectData data = MQTTPacket_connectData_initializer;
unsigned char mqtt_buf[100];
unsigned char mqtt_readbuf[100];

NewNetwork(&network);
ConnectNetwork(&network, MQTT_HOST, MQTT_PORT);
NewMQTTClient(&client, &network, 5000, mqtt_buf, 100, mqtt_readbuf, 100);
data.willFlag = 0;
data.MQTTVersion = 3;
data.clientID.cstring = mqtt_client_id; // you client’s unique identifier
data.username.cstring = MQTT_USER;
data.password.cstring = MQTT_PASS;
data.keepAliveInterval = 10; // interval for PING message to be sent (seconds)
data.cleansession = 0;
MQTTConnect(&client, &data);
[/code]

To subscribe to a MQTT topic, use

[code]
MQTTSubscribe(&client, "/mytopic", QOS1, topic_received);
[/code]

The parameter topic_received is a callback function handling the received message:

[code]
// Callback when receiving subscribed message
LOCAL void ICACHE_FLASH_ATTR topic_received(MessageData* md)
{
int i;
MQTTMessage* message = md->message;
dmsg_puts("Received Topic ");
for (i = 0; i t; md->topic->lenstring.len; ++i)
dmsg_putchar(md->topic->lenstring.data[i]);
dmsg_puts(", Message ");
for (i = 0; i < (int)message->payloadlen; ++i)
dmsg_putchar(((char*)message->payload)[i]);
dmsg_puts("rn");
}
[/code]

To publish a MQTT topic, use

[code]
char msg[PUB_MSG_LEN];
MQTTMessage message;
message.payload = msg;
message.payloadlen = PUB_MSG_LEN;
message.dup = 0;
message.qos = QOS1;
message.retained = 0;
MQTTPublish(&client, "topic", &message);
[/code]

The demo project included in the library shows how the MQTT related functions can be organized inside a FreeRTOS task and interact with other tasks, such as retry connection after server error, WiFi error, etc. The following diagram may be helpful to understand the code. (Imaging how this can be done using NON-OS SDK)

As Espressif had just teased us with the new ESP32 chip and RTOS is rumored to be the default SDK, I hope this piece of code will be useful.

The post ESP8266 MQTT client on RTOS appeared first on Digital Me.

Another year, another Maker Faire. Yes! for this year it is nolonger “Mini Maker Faire”, we’ve just upgraded to the full fledged “Maker Faire” event. As Singapore Maker Faire has grown 10 times compare to 3 year ago, I am not able to cover every single booth or exhibit in the event. I only write about those I’m interested in.

An Augmented Reality Sandbox is a perfect application of Kinect. Originate at UC Davis, this construction is made by the students from Temasek Secondary School.

Benjamin Low and “Art makes us” team, who made the “Synesthete’s Music Machine” last year, have came back with “Neobombe”, a simulation of   Turing machine inspired by the movie “The Imitation Game”. This setup contains 11 Arduinos driving 36 step motors. The motors spin according to the enigma decipher algorithm running at backend. Since I’m too late to write his, Ben has already published his “making-of” article here.

Leon Lim, who is the “go-to” person for DIY PCB etching in the community, bought us two day’s worth of live etching and soldering workshop. Participants have experienced PCB etching using household suppliers, drilling and soldering. The end product is a cardboard dome with colorful LED lighting, very nice!

This ball shaped robot is developed by IDA Labs. It travels on the ground and also in water. But I really do want to see a BB-8 leh. Maybe next year?

Here comes some heavy weight electronics project. Design by Adnan of 2-Watt Elements,  Chippy is an “Intel Edison powered USB hub” Intel Edison breakout board that helps developer to access Edison peripherals much much easier. Interested people please take note, Chippy is coming to market coming September.

More interesting projects from local and overseas guest are better capture using video format:

Yearly Review

As I said Maker Faire is like a new year’s day to me. The past year is an exciting year, that I am able to monetize my project. I designed an ESP8266 breakout board and start selling on Tindie since February. As of today, I sold total 332 boards across 29 countries.  And this is mainly why I have not been updating this blog too frequently, because I totally underestimated the effort went into the production and sales of these boards. My initial idea was just to sell some extra pieces from my prototype lot and recover part of the cost. But in the process it becomes so welcomed that my I can hardly fulfill orders. I’ve not able to write too much code for ESP8266 either, which is a great pity.

A “good” news is ever since Adafruit, OLIMEX and Sparkfun start to produce their versions of ESP8266 development board, my sales drops like brick wall. But this gives me more time to work on the software side and do some new projects, stay tuned

And since I’ve done so much on ESP8266, I can’t help bring a project to Maker Faire. So this is my selfie with ESP8266 clock. The clock synchronize time from NTP, gather temperature/humidity and push to a MQTT broker, and display MQTT messages from my webpage (more on this in the following posts).

A big THANKS to Mr Teo Swee Ann and Espressif Systems to make this possible.

Rant

I hesitated a bit before write this part. It will hurt someone, for sure.

ARDUINO IS NOT ELECTRONICS!

I have been talking to some makers, attending some events, and people seems to mistake Arduino as the only electronics platform.

ARDUINO IS NOT ELECTRONICS!

I have to admit Arduino helps to lower the entrance barrier, bring people onboard electronics, which is fantastic. But do not claim you understand electronics because you can follow some online tutorials and create some Arduino projects.

The same applies to Raspberry Pi, Banana Pi, Beagle Bone, etc.

I don’t know whole lot of electronics either.

I come across the Nah’s family who present this electronics learning kit in the Maker Faire. I personally give them the best project award.

This basic components block kit immediately reminds me of the Radioshark laboratory kit (clone) I started with. There is no shortcut to learning electronics. You still have to start with basic components and Ohm’s law.

For more expert advise, I highly recommend this eevBLAB episode.

/Rant over.

The post Maker Faire, Yearly Review, and Rant appeared first on Digital Me.

The modules I’m targeting are ESP-07 and ESP-12, both having identical pinout but only differ in antenna type. I choose these two because they have all the I/O available, and using same edge castellation (half vias) connectors which is easy to work with.

The modules are 16mm tall, easily occupies 4 rows (2 rows on each side) on a breadboard. Therefore my first design requirement is to minimize real estate on the breadboard. To do this I made some custom pin headers by modifying from SMT pin header.

I removed pair of pins from both ends and replace with through hole pins. This little touch strengthens the bounding between pin header and the board. If otherwise on my first version I can easily pull up all the pads when lifting the board up from breadboard. With this design, I maintain 4 rows occupation on the breadboard, that leaves another 6 rows for wiring.

The boot mode of ESP-8266 is often another source of confusion. The table below summarizes different boot modes during power on or reset:

In firmware flashing mode, user is able to update new firmware from UART0 using FLASH_DOWNLOAD_TOOLS or esptool.py.

The board is designed for ESP8266 developers so reset and flash must be made easily accessible. I designed a simple circuit that only uses one button to perform these two tasks:

During idle state, internal pull-up in the ESP8266 RESET pin turns on Q1. Q2 cut off so GPIO0 remains high due to GPIO0 internal pull-up. At the same time, C1 discharges from R2 and Q1. When user presses SW1, RESET goes low immediately. Meanwhile, Q1 turns off and 3.3V power charges C1 through R1 and R2. If user releases SW1 quickly and the voltage across C1 has not reached Q2’s threshold voltage, Q2 remains off and ESP8266 enters normal running mode. However if user holds SW1 long enough before releasing, Q2 will turn on, pull GPIO0 low. At the moment user releases SW1, RESET goes high but GPIO0 will be held low for a while due to C1 have to discharge through R2 and Q1. The choice of C1 and R2 are such that it keeps GPIO0 low long enough for ESP8266 to enter program mode.

The board also includes a 3.3V LDO (AMS-1117 3.3) and a UART header using FTDI Basic pin out. Below is my programming hardware. (Yes I’m writing OLED driver, which will be release right after).

The schematic and board are designed using KiCad BZR 5312. Windows binary is available at http://kicad.nosoftware.cz/. I have uploaded the schematic and PCB onto my GitHub page at

https://github.com/baoshi/ESP-Breakout

At the moment I’m trying to sell extra boards on Tindie. Please visit my store

Product link -> https://www.tindie.com/products/Ba0sh1/esp8266-esp-0712-full-io-breadboard-adapter/

This is my first attempt to generate some income via hobbyist project. Please support if you also want to join the ESP8266 fun!

Thanks

The post ESP8266 breadboard adapter and I’m on Tindie appeared first on Digital Me.

The application is made with ESP8266 RTOS SDK. SSD1306 based OLED panel is connected on GPIO4/5 using software emulated I2C. I rushed this out last night and the code is in a mess now.To prevent bad influence I’ll release the code after I reorganize them.

The post Happy New Year from ESP8266 appeared first on Digital Me.