Category Archives: ESP-12E

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 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.0 – i.e. bang up to date at the time of writing.

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.0 and updated the RBOOT code I use for OTA (over-the-air updating) to the latest version.

To backtrack a little

For anyone new in here – some background - I’ve written software for the ESP8266 which has been in operation for some time and is under constant development. It allows the ESP8266 to control things like simple lights, serial LEDs, PWM LEDs and read sensors etc, talking via WIFI and MQTT to whatever central system you have – for example a Raspberry Pi with Node-Red. I’ve written a node to allow endless units to log in and to provide central communications for them. The software is rock solid and runs 24-7.

I use Windows to develop the software using the Cherts unofficial development environment. This provides an IDE using Eclipse for running and compiling C code. It is not necessary to use any of this if you simply FLASH the ROMS which are available – but of course if you do use the IDE you can customise code for your own use.  The projects Home Control 2016  and Nextion WiFi Touch Display both use the same software and are the end result of many years developing home control. Personally I access much of this equipment using Apps like Blynk and more recently Imperihome (see also this article, this and this).  Tools I use in Node-Red include my own BigTimer node.  All of these options were chosen after much deliberation.

So what have I learned and what has changed?

All has been going well until recently when the Espressif SDK for ESP8266 was updated, firstly to 1.54 then very quickly followed by 2.0 and all of a sudden I and other started to have issues starting up ESP8266 boards. This is now resolved incidentally.

Firstly one of my problems was lack of serial output on power-on. Some serial (115Kb) status messages I have on power up, just point-blank refused to show. I figured the code might be starting at the wrong place. But no, a quick port flick at power-up proved that everything was working – but no serial out.

After much debugging, I discovered that there would be no serial output until this function:


had been called. Prior to SDK 1.54 this was NOT the case. Simple enough - I put this at the start of my code – I’ve just checked and web updating works just fine - but merely moving this function to the start solved all the serial output issues.

Incidentally much is made of the “garbage” that comes out of the ESP8266 on power up – it is just that Espressif chose to use 78,600 baud instead of a more popular one. If user software is set to this speed rather than, say, 11500 (which is what I use) then things look very different – diagnostic on power up followed by user code – all very seamless. Problem is – not that many serial terminals support 78k.. but I digress.

The second problem was a tendency for the unit to run away with itself, firing out garbage as if the ESP-12 was broken. It would SEEM that post-SDK-1.53 or thereabouts – it is NECESSARY on initial run, to flash location starting 0x3fc000 (end of the 4th page in a 4MB Flash chip) with the default file esp_init_data_default.bin which is found in the Espressif development kit.  If this has already been blown (previous installation) then it is not necessary to redo that, but with a CLEAN FLASH, failure to flash this area results in the continuous rubbish on output. Again this did not seem to be the case before SDK 1.53/4 – I have NEVER flashed that location in the past. Once blown it is not necessary to blow this again for OTA. Still – now we know.

I’ve just had a Skype chat with Espressif engineers to try to dig deeper. They have confirmed the small file at the end is essential (I probably didn’t notice it before as I’d generally be using boards already programmed) – the serial issue we’re still trying to understand – but it all works.

System Data

There are 2 relevant files here. A file called blank.bin sits at 0x3fe000 (top of the third MB in a 4MB Flash i.e. ESP-12) and contains default system parameters produced in the SDK.  NOT setting this initially seems to have no effect on my code.

A file called esp_init_data_default.bin sits at 3fc000 and contains default system parameters stored in the SDK. This is a 1K file. This HAS to be blown when first setting up a chip.

What to do

There is a binary file called esp_init_data_default.bin which I have added to the server at – this is in addition to rboot.bin and romx.bin

In the Espressif setup there is a file called ESPTOOL – there are exe versions and .py versions of this floating around (see below). This is what I use to flash the ESP8266 chips – there are others – you may use them – but I can’t VOUCH for them!

In Windows this works for me – you will have to check for yourself.

To completely wipe an ESP12 – including all data and setup etc and assuming COM3 in this case (not necessary but if it makes you feel better)…

esptool.exe  -p COM3 -b 115200 erase_flash

To initially flash the code from scratch… assuming you have the 3 files mentioned above…

esptool.exe -p $(COM3) -b 115200 write_flash -fs 32m -ff 80m -fm qio 0x00000 rboot.bin 0x02000 romx.bin   0x3FC000 esp_init_data_default.bin 

Obviously you can change port, speed and file locations. I usually double up on that baud rate but this one is safe.

If you insist on trying this with an ESP-01 (no way will OTA work) – that 3FC000 address becomes just 0xFC000 as they only have 1MB of Flash unless you upgrade them (discussed in another blog in here – done – easy).

As an alternative, I’ve tried NODEMCU FIRMARE PROGRAMMER and that seems to work…



And so there it is – the source is updated on the web and requires SDK 2.0 or better to run. The ROMS are updated and the new file is up there.

Bear in mind there is some data here NOT being erased (see full erase command higher up) – in my case at 0x79000 – or around half way up the first megabyte – this is USER data – stored passwords etc. it was put here for compatibility with ESP-01 but I’m about to move this way up to 0xf800 leaving the best part of a MB for code – plenty of room.

And why?

Why worry about updates indeed? Well, one good reason – is that recently, updates to the SDK have used LESS precious RAM – the kind that programs (not data) run in – so with 2.0 there is more margin for expansion – which means more features and more room for more features! It is fine having 1MB to put code in but that is generally NOT the limiting factor with the ESP8266. The code ultimately has to run in RAM and there’s a slight bottleneck there – the gains of later SDK updates help a lot.

Update 31/07/2016

Having now  added i2c and parallel LCD displays to the board, I set a parallel LCD running from MQTT and updating all 4 lines of the display, once a second from Node-Red. While this was running (it’s been running all afternoon – I thought I’d try a test)… I set my serial terminal program fire out lots of on-off commands in a row – which is WAY over the top…

I set up 30 on/off commands for GPIO0 – to run at 80ms each – as you can see clean as a whistle.  I dropped that to 50ms per instruction and the board rebooted – I’m guessing that is a buffer overflow – but then – that simply is not going to happen in real life or anything like it.

I figured I’d go for broke - with 390 (I got sick of cut and paste) commands sent at 80ms it lasts almost to the end then rebooted – again a sure sign of the buffer being in trouble either overflow or wrap – backing that off to 100ms gave zero errors so not a wrap issues – Very happy with this – typically the boards get no more than a few instructions a seconds – often MUCH less. For the sake of it I think this coming week I may just take a look at this – firstly to see if at such speed, my terminal is screwing up – and if not – I’ll see if I can narrow that down but it is utterly academic

serial tester

A complete and utter aside

I don’t use the Arduino setup but as I was thinking about user data, I just checked the Arduino EEPROM library SOURCE for ESP8266 and the Arduino environment does NOT use the 3-sector trick employed in the SDK. When you update the EEPROM (which is actually FLASH on the ESP8266), the sector is wiped (even if you have user data smaller than 4k, a 4k sector is still used) and then updated from RAM – not ideal.  I have suggested to the designer that it might be a good idea to change this. Right now he’s busy working on ESP32 code.

So there it is – all working – hopefully I’ll soon get some clarification on the routine I mention above that I had to move. Time to start adding new features!!!


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 2016 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.

Let me explain the difference between programming and setup. GPIO0 is set up permanently by Espressif as the pin to hold LOW before and during power-up to put the board into programming mode to replace the firmware (which may or may not exist on purchase… could be that AT-Command firmware, LUA or something else). Web setup is just something my software does – it’s not the only software to do so. It may use GPIO2 or GPIO0 AFTER power-up to put the unit into a mode where it acts as an access point, allowing setup for, for example SSID and password.

All other I/O pins are available for one use or another including GPIO16 – take note of other blogs describing wiring and power unless you’re using something like a node-mcu board which just plugs into USB. The software works with my Node-Red software – again described in the home control blog – what’s new here is that OTA now works and you don’t need a development environment to program up the code which  I developed with lots of help from others, using the unofficial Development Kit in Windows. The software will react to MQTT commands and also commands coming into the serial line at 115k baud (serial commands are the same as MQTT payloads - no topic required). - home controlI worked with Richard Burton to get RBOOT working on our code– it is his software which allows for OTA (remote updating) when developing, in my case, in C on the ESP8266.

With OTA working (including from an external location) I thought I might try taking the ROMS and blowing a chip from them rather than from the editing system – that way others can benefit.


Well, I went to get the NODEMCU flasher which was always good – so after a couple of blind alleys – I got to this link..

As you can see, with the flasher, the RBOOT rom loads at 0x00000 and our current code runs at 0x02000. Unlike me, make sure BOTH ROMs are ticked on the left.. as the first one is so short it shows little or no sign of activity. I found I could flash at 46800 baud, you may or may not wish to play safe at 115k baud.  You may also note there is an additional file needed above – in SDK 2.0 and above, on first installation this is needed. See THIS blog entry for up to date information.

So – you blow the software onto the ESP8266 board (here is the link to the NodeMCU – no guarantees as it isn’t mine), now what?

A reminder – what will my software do?

  • Turn outputs on and off with optional timeouts
  • Read inputs
  • Handle RGB Serial LEDs (up to 300 of them assuming you have enough 5v power)
  • Handle PWM 12v LEDs (assuming you have a 12v source and driver hardware such as Mosfets)
  • Act as a LED clock (and a nice one too) with 60 serial LEDs.
  • a TON of other things including handling DS18B20, DHT11, DHT22, talking to Nextion displays (see the Serial Nextion blog) and WAY more – all in the Home Control blog. Add to that the power of Node-Red and you have the basis for a very good and reliable complete home control system.

But first the unit needs to be setup. After programming and then resetting or power-cycling the ESP12 (suggest hooking a LED and resistor to GPIO13 and down to ground) – the light will start flashing – within a second or so – hold GPIO0 (or GPIO2 depending on defaults in the current ROMS – see power-up messages coming out of the serial at 115k baud)  to ground for say 10 seconds and let go (DON’T press for the first 100ms of turning on – JUST after turning on or resetting will do – if you come in early (and if the current pin in use is GPIO0)  it will go into programming mode – of course if you don’t program it, no harm done – just reset and try again).

NOW you can access the board with your mobile phone WIFI as “hack-Setup” and once connected use the phone browser to go to and you get that nice setup on the right above which needs at least one router SSID and password, two if you have them available (second is a backup) – the address of an MQTT broker and username and password and that’s really all that is essential to start off.

Once everything is up and running , the LED on GPIO13 should be flashing very briefly (i.e. off most of the time) – a variation you can setup by commands uses an RGB LED to give more meaningful use (yellow power up, green working, orange working on it, red dead – throw in the bin etc).

You can now talk to the board via MQTT… or the serial port at 11500 baud (you could use my serial terminal.

If using the serial, fire {debug} at it – if using MQTT – then assuming you’ve given it the name “fred” then the same command would be – topic:  fred/toesp and the payload would be {out4;1} or {out4:0} to flick GPIO4 on or off (or if your board is mis-labelled as some are – GPIO5).   The Home Control blog entry goes into the rest of this in detail.

Note that if you DON’T set up an MQTT broker, the unit will try to connect to MQTT and eventually reset and start again. This is deliberate. You MUST setup an SSID, an MQTT broker and once running you should use the ESPLOGIN mode or similar to send the time to the unit shortly after power up then every 12 hours or so. Again this is detailed in the home control blog… it’s quite simple.

The rest is up to you.  I use this with my Node-Red software and I have a node for setting up the time and date on the boards…  it is called node-red-contrib-esplogin

Node-Red controls - Peter Scargill

That log-in node incidentally is available here.

That’s it for now… I’m quite chuffed the OTA now works. This of course is directly relevant to the Nextion WIFI Display project.

You can get the three BIN files from:

IMPORTANT NOTE: If you choose to use ROMS rather than compiling code, you will need to keep up with the BITBUCKET repository changes as these ROMS will be updated when I make changes – which I’ve just done having realised I need to support some older boards we made with a relay on GPIO0 whereas I’m now considering GPIO0 should be an input. There is also a DOC file in the Home Control blog and that is the ONLY up to date guide to the ever increasing instruction set.

Update 14/05/2016:  No longer showing passwords in the web setup page so you must put those in every time you use the setup page – otherwise you end up with blank passwords – which you might want. Added several new commands like cpu_clock so you can double the clock speed  - documented… ROM updated. DEFAULT pin for web updating is generally GPIO2 but on power up you’ll see serial messages which TELL you which pin to use. You can change this to GPIO14.

Update 24/07/2016:  See the changes in blog above, rendering some of the comments below obsolete.


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.


ESP8266 Lessons Learned

ESP-01The Trip: As regular readers will know, I’ve just returned from working on the first stages of a project in Spain to analyse information from ESP8266 chips. Without going into any commercial detail, this is what I brought back from that trip.

The scenario: The tests were done 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 Veroboard and power applied. You really don't get a lot worse than this - 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 is soon to be increased to 120 and with a power supply currently running freezing cold I am confident there won't be any issues. And all of this for far less than the price of a half pint in London.

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.

Coming up: I’m sitting in front of a set of WIFIThing kit – and I’ll shortly put together a short review of this equipment including a very nice WIFI wall socket.  Also – is there really an advantage in using USB3 memory sticks? I’m sitting in front of a couple of 32gig units and I’m about to run some tests. Check in later.


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?