Category Archives: ESP-12F

A Flashing ESP Chips Surprise

Well, you could have blown me away.  Tonight was making a little relay controller for the hot tub using a WEMOS board and relay board. I carefully soldered them together and plugged them into a USB connection on my PC, as I’ve done thousands of times.

Also as I’ve done thousands of times I flashed the board with my ESP8266 standard software which I have down to a single button-press in Eclipse.

Continue reading A Flashing ESP Chips Surprise


ESP8266 Home Control Update

As the blog entry on using my home control code ROMS for ESP8266 is filling up and of course as much of the information is now dating I thought I’d do a new blog to bring everyone up to speed and move the conversation to this blog entry. The good news is  - the code is now running under SDK 2.1.0 – i.e. bang up to date at the time of writing.

Home Control 2017

Firstly – yes, everything works – but the procedure for flashing ESP-12 etc has changed ever so slightly. I have updated the binary files to run on Espressif SDK 2.1.0 and updated the RBOOT code I use for OTA (over-the-air updating) to the latest version.

Continue reading ESP8266 Home Control Update


ESP8266 Lessons Learned

ESP-01The Trip: As regular readers may know, early in 2016 I worked in Spain on a contract with some great guys to analyse information from ESP8266 chips. Without going into any commercial detail, this is what I brought back from that trip as well as other lessons learned since then.

The scenario: The tests were done on a series of ESP-01 WIFI micro-controllers  in a rural environment, initially with a bank of 40 ESP-01 boards. These were powered by a single 20 amps 3v3 power supply. Yes, a switched supply. The boards were mounted on Vero-board and power applied. No linear regulator to smooth out the crap ( I would normally run 5v switched and a linear 3v3 regulator on-board for each device), lossy tracks on Veroboard, signals interfering with each other..  except it DOES get worse - read on.

The Place: The location we conducted our tests was off-grid, relying on solar power and a generator - and the weather most of the time was cloudy - that meant at regular intervals the remote generator kicked in and when it did a couple or so mains cycles were lost as the set-up there uses a combined inverter/charger. The result of that was that at regular intervals, the router reset.

boardsAside from actual power cuts you don't get much worse than this.  At first when we switched on the boards - which are running a modified version of my home control software which is in turn based on TUANPMs MQTT code with a boatload of stuff added and a lot of tweaking over time, only some of the boards would report back. A quick check of the router revealed that by default it only allocated enough room for 32 connections on DHCP. That was quickly doubled and lo and behold, all the boards logged in by MQTT to the PC (running Node-Red and MQTT and firing off data to a database).

Useful outcomes: Well, any thoughts I may have had concerning reliability completely vaporised this last 2 weeks as day after day our little bunch of 40 boards (not even all from the same supplier as some were blue, some were not) just sat there constantly delivering information. This was soon increased to  a wopping 120 boards without issues.

So if you're just starting up with ESP chips - bear the above in mind before jumping to conclusions about board reliability. The boards used in the test, running as I speak, were the early 512K versions, today I always use ESP-12 boards in my own projects as they have eight times the amount of FLASH which means OTA, big programs (up to 1MB of C code (that's a lot)) and in the case of the "F" version arguably better antennae.

I sometimes hear of people complaining that once programmed, some ESP boards go into a loop at power up - and I've recently had this happen to me TWICE. In each case I had extra bits and pieces attached and was running the board off the FTDI - again in each case, putting proper 5v onto the boards immediately resolved the "problem". FTDIs vary a lot in their output and voltage.  While it is tempting to use them to power the ESP (or indeed the micro-usb connector in some cases, straight off your PCs USB - the time will come when this causes trouble and now you know the answer.


Weather 2 Board and ESP8266

tmpE044NOT the cheapest board on the planet, I was handed a couple of these little boards by a friend this weekend.. the weather-2 board.

The board uses 2 i2c chips – the BME280 which as you may know is a miraculous little chip offering temperature, humidity and pressure readings all in one chip. I already support that in my ESP8266 code. Nothing new there and the chip works as expected when plugged in using this module.

What this board brings to the party is a chip I was previously unaware of – the si1132 – which in one chip offers readings of visible light level, UV level and IR levels.

The original library for this used floats and I’ve reduced that down to integers – looking at the variations I doubt I’ve affected accuracy at all – and these now come in the form of I2c commands in my ESP8266 code..




Assuming the board is attached (or a board containing that chip that works at the same I2c address) – you can grab readings from this chip no problem.

I could envisage one of these outside – in a cover that protects it from the direct light and direct heat of the sun, offering all 6 readings – handy for lots of things.  Or maybe you just want an alarm when you’ve had too much sunbathing – I’ll leave it to others to figure out best uses.

Makes a useful addition to the home control project. Source of the ESP8266 code available as are ROMS.


16 Channels of PWM for ESP8266

PCA9685This morning a little board turned up for me – the advert said “Smart Electronics” – but the board says Adafruit 16-channel 12-bit PWM board. At £1.38 each these represent EXCELLENT value – especially as the Adafruit originals are much more expensive. Nicely made with gold connections and all the connectors provided.

Actually when I bought these I was unaware of the Adafruit product – I didn’t see the likeness until I went looking for code to modify for my own use.

(the Adafruit board is blue, the one I have is dark purple) - In essence a very nice little  board which takes in 5v and I2C (in this case software I2C on the ESP8266) and gives out up to 16 channels of 12-bit PWM at up to 1,600hz without external clocks etc.

So right now I’ve added only basic control – a single command that has two uses – one to set up the board, the second to control individual channels. I’ve added this to the ESP8266 home control.

The command works like this – two examples – one for setup, one to control output 0 (ie bit 0 as you can control multiple bits at once) – and assuming device 0x40 (decimal 64)



where 0 is OFF and 4095 would be full on.

Here's another example - set all 16 outputs to 100


PWM ControlI checked out the Adafruit code for Arduino and made a very simplified version – I’m not sure I fully understand the two parameters (ON and OFF – the last two) because setting the first to 0 seems to give the full range using the last parameter only – maybe someone who’s already used this might enlighten us. Anyway, it works, reliably and it’s available. I’ve updated the source and the ROMS.

To test, I wired from the ESP ground, GPIO4 and 5 (already connected to an I2c device with pullups) and Vcc. I also connected +5v (that goes to the 5v rail on the board) and then I connected a LED to the +5v rail and PWM output 0.  really very simple. I guess what I need is some kind of timer-based control to allow slow ramping up and down of brilliance – which would mean you could arrange at least 16 channels of lighting from the ESP8266. Mind you – you can do that with serial RGB LEDS but they’re quite expensive compared to other lighting.

In the photo above I connected 8 outputs to +V and a bar-led – I bought these for testing just like this – as you can see I’ve put values from 2000 to 4060 in there and there’s a nice variation of brilliance on all of them. The speed this is working (1,600hz) in the background (all done by the chip) – waggling the display does not produce any kind of strobing effect). As for levels – at the very dimmest levels with a bright LED you can just tell the steps – but WAY, WAY better than simple 8-bit PWM.

All works – if anyone wants to take the software further who’s already been there, happy to incorporate any working additions.

Follow the Adafruit link to get their Arduino code – here (minus the ESP master library) is what’s left once I get what I wanted…

This is all in the home control software – just reproduced here so you can see what’s involved, maybe point out any improvements etc.

uint8_t PWMAddr=0x40;
#define PCA9685_MODE1 0x0
#define PCA9685_PRESCALE 0xFE

#define LED0_ON_L 0x6
#define LED0_ON_H 0x7
#define LED0_OFF_L 0x8
#define LED0_OFF_H 0x9

#define ALLLED_ON_L 0xFA
#define ALLLED_ON_H 0xFB
#define ALLLED_OFF_L 0xFC
#define ALLLED_OFF_H 0xFD

void IFA pwmWrite(unsigned char addr,unsigned char d)
i2c_master_writeByte(PWMAddr << 1);
if (!i2c_master_checkAck())
i2c_master_stop();                   // End I2C communication
iprintf(RESPONSE, "Bad PCA9685 I2C\r\n");
i2c_master_stop();                   // End I2C communication

uint8_t IFA pwmRead(uint8_t addr)
uint8_t a;
i2c_master_writeByte(PWMAddr << 1);
if (!i2c_master_checkAck())
i2c_master_stop();                   // End I2C communication
i2c_master_stop();     i2c_master_start();
i2c_master_writeByte((PWMAddr << 1)|1);
if (!i2c_master_checkAck())
a = i2c_master_readByte();
return a;

int IFA ifloor(float x) {
int xi = (int)x;
return x < xi ? xi - 1 : xi;

void IFA pwmFrequency(uint8_t chipAddr, float freq)
pwmWrite(PCA9685_MODE1,0); // saves a reset function
freq *= 0.9;  // Correct for overshoot in the frequency setting
float prescaleval = 25000000;
prescaleval /= 4096;
prescaleval /= freq;
prescaleval -= 1;
uint8_t prescale = ifloor(prescaleval + 0.5);
uint8_t oldmode = pwmRead(PCA9685_MODE1);
uint8_t newmode = (oldmode&0x7F) | 0x10; // sleep
pwmWrite(PCA9685_MODE1, newmode); // go to sleep
pwmWrite(PCA9685_PRESCALE, prescale); // set the prescaler
pwmWrite(PCA9685_MODE1, oldmode);
pwmWrite(PCA9685_MODE1, oldmode | 0xa1);  //  This sets the MODE1 register to turn on auto increment.

void IFA pwmSet(uint8_t chipAddr,uint8_t num, uint16_t on, uint16_t off)
i2c_master_writeByte(PWMAddr << 1);
if (!i2c_master_checkAck())
i2c_master_stop();                   // End I2C communication
i2c_master_stop();                   // End I2C communication

And so there it is – working 16-channels of PWM (or 32 or more) added to the home control setup so you can control these lights via MQTT or serial via a simple command.

If anyone wants to tinker – the lights all start up as ON – I’d rather they started up as OFF and I’d also like a master ON/OFF. Ok, I could do it the hard way I guess.

I could see a daughter board coming up with 16 MOSFETS on it… actually you could just use it for on-off control if you wanted  - at the price.

One of the BIG benefits for me is – the Espressif PWM is simply not that good – I use it – but for example, you cannot use that AND I2c at the same time because both the Espressif implementation and another I’ve tried both continue to mess with interrupts in the background even when on 100% or off 100%.  This neatly bypasses the issue.


ESP8266 Meets Arduino via I2C

If you’ve been reading the blog regularly you’ll know I added I2c to the ESP8266 code some time ago – that is, the ability to send an I2c message either to read or write – originally intended and still working with cheap I/O expanders – so you lose 2 wires (GPIO4 and 5) and gain another 6 or 14 for one or two I/O expander boards.

Well, I’ve updated it as of tonight.

Of course, ESP12 talking to Arduino is nothing new but given what we’ve built up here with the ESP boards and Node-Red I thought it might be useful to have the option to expand further.

What a few hours ago seems like something in the distance – well, it is done – and it works – and it has LOTS of potential. Read on.

ESP8266 and Arduino and I2c

What you see above (the FTDI is just stuck into the ESP8266 board for power) is a 1284 Aiduino boards flashing lights  - controlled by MQTT – that is, the ESP12 board on the RIGHT is taking in the MQTT and sending commands via I2c to the 1284-based board and to the little red expander in the middle (on the same 2 pins).

Hence, I’ve spent the day working on the I2c code adding the ability to send multiple byte parameters and to receive a byte (I could have made it receive multiple bytes but for simple control a byte will do).

ATMEGA1284The next step was to set up an Arduino – or in my case specifically an ATMEGA1284 chip to talk to the ESP – hence giving us the ability to control Arduino ports via Node-Red.  Now as yet another blog entry here will testify, you can of course connect (now that the node is fixed) an Arduino directly to the Raspberry Pi in charge – but puts too many physical constraints up.  I had no intention of developing Firmata on the ESP – and so a simple i2c protocol was develop and SO much more can be done.

Right now I have an ESP8266  on the bench with a 2-wire I2c connection to an I/O expander – and an Arduino-type board using the 1284. I can talk to both from the ESP (and hence from my Arduino wirelessly via MQTT) and can control the following:

  • Any pin as an output (and PWM outputs where appropriate
  • Any pin as an input (and analog inputs where appropriate)

So first things first – I used  the Atmega1284 simply as I have loads of them – both DIP40 and surface mount in our little AIDUINO boards. The 1284 has twice the RAM of a 2560 and is easy to use. However this would work equally well in a normal Arduino or in the massive 2560 boards.. the only difference being which two pins are used for i2c. The red chart above, shamelessly stolen from ManicBug’s website shows the pins (in parentheses the numbering system I use).

So in the ESP8266 (grab the latest ROMS or SOURCE) I have a simple method of communication which can be used by MQTT or serial. The format is similar to that used elsewhere in the home control system.

i2c:  device, return, param1, param2, param3, param4, param5.

Not all parameters are needed.

So – to talk to an i2c expander sitting as device 39, connected to pins 4 and 5 of the ESP board…


device 39, no return value, send out 3 (which lights up the bottom 2 LEDS.


This returns the value in the port expander.  this is covered in two previous blogs.

So what has changed is that the code can now send out multiple parameters – and optionally receive information back.


The above sends out to device 8, expecting nothing back, type 1 means set a port bit, bit 20 in this case (see red table above) – to 1.


Above – device 8, 1 means return a byte, type 4 means read analog value and port number is 30 – the instruction will return the value of the analog input.

1 is digital out, 2 is digital in, 3 is PWM out, 4 is analog in – you must use appropriate ports – not all are able to handle analog in or PWM out… and you don’t have to worry about port direction setting – this is checked before any operation and set.

There is SO much more potential here but only so many hours.  I will likely make the settings for outputs non-volatile at some point – and add in all manner of device monitoring and probably also make use of the multiple serial ports on these devices.

For now that’s not bad for a Sunday session.  If you’re seriously interested I’ll make the Arduino code available but right now it is highly volatile – but it works!!


Blowing the Home Control 2017 Code

Hackitt and BodgittThis is for the people who’ve been trying out my software (or thinking of trying it out) on the ridiculously cheap (£1.40) but very reliable, powerful and comprehensive ESP12 WIFI processor board and those who’ve gone ahead and gotten some boards we made – all referenced in earlier blogs. For the latest on how to FLASH the chips see this blog update.

Essentially the assumption here is that you have an ESP-12F-based )(or variation such as ESP-12E) board of some description and that GPIO0 is used as a programming button (held to ground to program etc) – and also as a web setup button.

Continue reading Blowing the Home Control 2017 Code


ESP12 and Memory

Anyone writing large projects with the ESP units in C (and probably in other languages without necessarily realising it) will have come across the problems of .TEXT memory. This is the RAM used to store functions.

Functions are stored in their own part of RAM called .TEXT memory and it is WAY too small. Now most of you will have made liberal use of the “ICACHE_FLASH_ATTR “ directive in your functions. This ensures that functions stay in FLASH until actually needed and this saves lots of .TEXT RAM – indeed without it, larger programs would be impossible.

Despite all of that I’ve been slowly running out, sitting at 7CFF  (you can only go up to 8000) recently and when the latest API came out – that was it – over the top – dead.

So for a while I stuck with the previous SDK and eventually got onto Espressif.

They asked me for a .DUMP file – which of course I neither had nor understood and they suggested that in the project directory I type:

xtensa-lx106-elf-objdump -x -s app_0.out > app_0.dump

WELL I was convinced this was another Linux tool that would not work in Windows – but it DID and produced the English-readable file app_0.dump which tells you where all your functions are sitting.

They suggested I add the "ICACHE_FLASH_ATTR"  to my EASYGPIO functions. Well of course as that was an existing library I’d not touched that – and sure enough – I got just enough memory back to be able to use the latest SDK!!   I was now sitting at 7B52 on the latest SDK – not good – but better… and at least I was using the latest SDK. They then suggested I use "os_memcpy, os_memset, os_strcpy" instead of "memcpy, memset, strcpy" so I systematically went through all the code and did this.

On recompiling – I now find the .TEXT RAM sitting at 79C2, the lowest it has been for AGES – another 512 bytes back just by using their functions instead of the standard ones!

I’m making no claims about reliability as I’ve not given this a thorough test – but that is for me a very worthwhile improvement in memory. Of course that means a tiny slow-down as functions have to be pulled out of FLASH to use… What speed would we have gotten out of these devices if they’d just done the RAM differently. Still – given the price of ESP devices I suppose we can’t complain.


APDS9960 Gesture Sensing with ESP8266

APDS-9960A thought for a little display project. I recently came across some code for an LCD display (160*240 - detailed in a previous blog) using the ESP12 and an LCD display. But I'm inclined to use the Nextion display (also detailed in a previous blog) because it is touch sensitive. The only problem with that is that the Nextion is somewhat more expensive and larger.

One of my pals brought this chip to my attention – the APDS9960 Digital Proximity, Ambient Light, RGB and Gesture Sensor.

It is i2c and not only reports back RGB and general light levels but also has it's own IR transmitter and logic inside to decode simple up, down, left and right gestures. So here are my thoughts - for example for a simple thermostat. Put next to the display it would offer simple up/down control of temperature as well as left/right perhaps to show a graph.

For more complex operation, one could make some kind of convoluted movement which would then trigger off a menu - with left/right selection and up/down change.

Worthy of further thought and has anyone already implemented the i2c code (Arduino ESP8266 C for example) to talk to this device?



EMW3265Erm, no, though you might think so by this headline..

Read the comments – the $5 ESP8266 – where?  $2 ESP8266 more like it – less, even -

There’s even a claim that this new single-source board (Seeed Studio) has MORE memory – well at least one variation of ESP12 has 4Mbytes – and the EMW… according to the ad, 512K.

And what about the all important Windows and Linux support libraries? Erm, no.

Another comment – Chinese documentation? Well I don’t know about you guys but I have  raft of English documentation that until recently came with the Espressif SDK and which is now maintained online.

And the last – Chinese – guess where SEEED are!

Cheap, reliable, effective, more compatible variations of ESP and more suppliers than you can shake a stick at – and we want to move for what reason?

But – if you like spending money – there’s this – even more expensive -


Automatic Router Selection for ESP8266

I wonder if anyone who has done this can help.  As most of you know, I program my ESP8266 devices in C.  I've been having some issues with weak signal recently and it would be really nice to have a list of acceptable access points and their passwords - and have the ESP, if it loses the signal, check the list (including identical SSIDs) and reconnect.

Has anyone done this already and if so would they care to share code?


ESP8266 Remote Access

Notice I titled that remote access as against remote programming – but that’s part of it.

Years ago, having gotten sick and tired of dismantling my home control Arduinos just to upgrade the code, I purchased a couple of small units from China which I’ve just thrown in the bin.   One had a USB plug on it and plugged into the PC, the other had an FTDI output on it. Both had those black 2.4Ghz antenna.

So the purpose of these units was to wirelessly replace an FTDI – or serial programmer, the idea being that instead of bringing the Arduino project back to wherever one programs the devices, you plugged the unit into the project and over the air programmed it.

At the time I was using Arduinos and those CHEAP £1.50 radio modules – the NRF24L01s, the worst radio boards in the world who’s range could be so bad you’d be lucky to get through one wall. I had high hopes for them with a great mesh network called RADIOHEAD, but ultimately their range and lack of ability to read signal strength doomed them.   However, as you can imagine they were dotted all over the house and I thought this little radio pair would solve the issue of programming them without ripping everything up.

It turns out the “radio FTDI” had the same problem – it was based on the NRF24L01.

Fast forward to September 2015. Here I am in Spain with a new setup of ESP-12 modules controlling lights, watering system and a lot more.  I’ve made some improvements to our “home control 2015” software in the ESPs and once again I find myself having to dismantle kit.

Now, I know that is it possible to program over the air – a few guys have tackled this successfully and indeed much of the code is built into the Espressif SDK. Right now my friend Aidan is working on adding this to our code but there are two issues, he’s not had luck up to now and secondly as our code comes to something like 300k you’re never going to be able to add this to the ESP-01 modules (we use ESP-01 sometimes, ESP-12 other times…)  as you need as much spare storage as you have code for OTA programming!

It was with that in mind that last night I dragged out the old FTDI boards to see if I could save myself the effort of dismantling the Pergola lighting system to update it.  Suffice it to say that I managed to get a few bytes programmed before that all came to an end despite several attempts. With around 25 WIFI units of one description or another dotted around the place, the old wireless FDTI (same frequency range) simply could not handle more than a few feet.


I figured it would not hurt to look around and see if someone has alternative wireless solutions – lots of time has passed since I bought that kit.

And so it was that I stumbled upon this. – as it happens it is quite new – essentially what we are looking at is a single unit (yes, that had me going for a while) which will hook into the WIFI system and act like an FTDI – given that you can fire the serial out of your PC over TCP to a port – port 23.   I grabbed the code (the stable 1.04 version) and very excitedly blew it into an ESP-01 unit I had lying around.

Really, nicely done web interface (with remnants of Martin Hanzarov’s code in there) and a really good write-up – indeed there may be enough info in there to help us implement our own FOTO (over the air) updates to our code.

But this has far wider implications – a virtual serial link would also let you monitor the serial line of a remote unit for debugging info – and our units do indeed put out lots of serial debugging info. It would also let you remote program and monitor un-wirelessly enabled Arduino projects.

So the first problem was – I had this unit sitting as on my network and I needed to blast info into port 23 to have it come out as 115K serial.  I have ECLIPSE sitting on the PC running my projects and there’s a line in the MAKE file that says “COM6”.  I have absolutely NO idea how to turn that into a TCP statement if indeed it can be done (FEEL FREE TO START TYPING IF YOU KNOW HOW).

So I turned to a 30 day trial of a PC program that promised to provide a “virtual com port” – and that it did. Serial/IP Redirector let me create a link to port 23 and ship raw data back and forth to COM22 (which doesn’t exist on my PC)- LO AND BEHOLD I set it running, put PUTTY on the PC talking to COM22 and with a real FTDI attached to the little ESP-01 board on real COM6 I set that running on a terminal –at 115K. Utterly flawless raw serial communications – rock solid.

I was getting excited by now. I took my ESP-01 board and cross-connected the serial to an ESP-12 test board. I held GPIO0 to ground and turned the power on, putting the ESP12 into programming mode.

I punched COM22 into the ECLIPSE project and hit the FLASH button on the project. Lights flashed on both units. With a scope attached  to the serial in on the ESP-12 I could see clean 115k data going into my project and… nowt, zilch, nothing.

I was up until the early hours ensuring the baud rate was ok and that my level conversion wasn’t getting in the way – you see all my projects use a resistive divider on the serial input of ESP boards so the whole lot will work just fine with 5v logic on the FTDI and elsewhere.  I wondered if hooking two of these units together with serial cross connected might prove too much but the scope says no – it says I’ve a perfectly reasonable serial signal going into the ESP-12 – but it’s not having it – no responding output whatsoever. Eclipse tries sending out data over and over and eventually gives up just as if there’s nothing connected.

So near and yet so far.

I got up this morning and the unit was still rock-solidly connected to the WIFI and typing a few characters provided perfect results at the other end – but I cannot program ESP units – yet.

Very exciting, yet very frustrating.

Perhaps coffee and a new start to the day will help. BUT I had to bring this to you as the article is really good, the software seems to WORK and there’s a super-bumper version with it’s own OTA updating in the works for larger targets like an ESP-12 (more FLASH) than the ESP-01.

I’m sure this is going to be a winner – just need to get it to work. After all, the ability to add remote programming to any FTDI-enabled project for what, a couple of quid.. well, you just can’t ignore it.

Meanwhile if anyone reading this firstly knows how to set COMX on Eclipse (on Windows) to TCP – do let me know – and if you really think you know what I’m doing wrong here and want to jump in before I figure it out – by all means – you have the keyboard…