ESP8266 Code Update

The code that forms a series of articles on this blog has now not been updated for some time – simply because it “just works” and has been doing so reliably for many months. However, I’ve been wanting to add bits to it and my problem was I was running dangerously low on iRAM. This would not affect the stack or reliability but would just stop me from continuously adding code.

Well, thanks to Espressif that is now history. The latest Esp8266 SDK, released just days ago, fixes a number of things on the ESP8266 – you can find the SDK here – you will need it if you wish to compile code but of course ROMS are available as usual.  The upshot for me is the return of nearly 800 bytes of iRAM which is something of a breath of fresh air.

The software has been updated to version 1.8.5, the code is available here…  and the SDK here.

And if you’re wondering what on EARTH I’m talking about… if you’ve seen “the script” – this is what it was put together for in the first place.

Blowing the home control 2016 code

Home control 2016

Extract from the manual (which is the best source of info).

Home Control


32 thoughts on “ESP8266 Code Update

  1. Quick question on the ESP8266. I purchased 5 of these @2.95 at the time, not knowing much about these things. I went to connect a bunch of stuff to it while it was mounted on breadboard, only problem, the ESP8266 is to large for the breadboard and leaves no holes on either side of it to plug wires into it. (only +/- rails)

    Any work arounds that you know of?

    Have since ordered a couple of Wemos D1 MIni’s

    1. Yeah, thats the “normal” issue with those boards.
      If you have two breadboards, you can mount them side by side.

      Other solution is, only connect pins in use to the breadbord with wires.

      I personelly only use breadboards with Dev-Boards to test hardware/software, then shrink it to a small pcb with a bare ESP12. So the finished complete devices are as small as possible and fit into a small case (mostly including a battery).

  2. Has the old problem with the ROMS re-emerged? I have made several attempts, using different ESP8266s and different uploaders and am getting the old fast flashing led and gobbledy-gook serial output. Is it just me?

    1. No – I’ve updated this article slightly incidentally as I’m now using SDK 2.1.0 – but remember the bit in here about flashing an area near the time on first use….

      I forgot all about that myself some time ago – did the full flash including that top area and now I’m reprogramming boards on a daily basis as I develop my 1306 code – without any issues.

  3. Ok, I’ve checked the manual – confirmed that GPIO2 is the default and fixed a load of typos – new manual is available with the rest of the code on BitBucket.

  4. Im a noob at most of this and have a question about flashing the esp8266’s. I am using the NodeMCU boards. Using on linux I flashed the chip with the following: -p /dev/ttyUSB0 -b 115200 write_flash -fs 32m -ff 80m -fm qio 0x00000 /home/mike/firmware/rboot.bin 0x02000 /home/mike/firmware/romx.bin 0x3FC000 /home/mike/firmware/esp_init_data_default.bin

    All 3 files were downloaded just before the attempt from Bitbucket. All seemed to go well and the LED I put on GPIO13 flashes. Before flashing the chips with the new code I could see the chip in my wifi list but after I cannot. I followed your instructions about grounding GPIO0 for 10 seconds to enable access thru wifi so I can enter the SSID, Passwords, and MQTT broker info but I can’t see it in my list of available wifi connections. Im sure I am missing some small detail but for the life of me cant seem to figure out what im missing. I have been stumped before in my pursuit of this and eventually I figure out what I did wrong so I hesitate to even ask. Is it possible its the NodeMCU boards Im using and the code aren’t compatable? Or have I flashed it incorrectly? Any help in the right direction would be appreciated.
    Thanks for all your posts by the way. They are great and I am learning new things every day.

    1. Never mind. I thought I would give it another try this morning as I was heading out to work. Low and behold, worked like a charm. Grounded out GPIO2 instead of GPIO0. Tried that early on yesterday but not after I re flashed.

      1. Oh yes, I think GPI2 is the default web programming pin (it goes back to an early board we did with a relay on GPIO0 which in itself is a throwback to using ESP-01 boards which only had 2 useful wires. Now I tend to use GPIO16 (as it is fairly useless otherwise unless you’re doing low power stuff) for relay – and one of the options in the software sets the WIFI pin to GPIO0. Make sure that GPIO13 is set to whatever LED you’re using – as it can handle both normal lEDs and serial RGB (or none if you’ve another use for GPIO13).

        I’ll make that more clear in the doc file.

  5. Thank you Peter for the implementation of the BME/BMP 280 familiy in the firmware.
    I noticed (beacuse I have one) that there are some vendors that use inverted addresses (x76 for BMP and x77 for BME) .
    Can you consider a possible expansione of the temp_type command in the future releases? kind regards

    1. Hi Andrea

      The BMP is no problem as I fire the address off to the calling routine – the BME is slightly more of a challenge as the code uses the address as a constant and it is plastered all over the place.

      In order to test this I’d need both boards here and I have a sneaking suspicion I’ve left them both in the UK. I’ll have a look but don’t count on it. On the other hand if you have the source code – you can just change the #define. It is in /driver/bme280.h

      1. Yes, I’m going to do it later on. Anyway there should be also some other issue somewhere because in any case the ic2check do not return me any device, while the bme280 is working perfectly on a wimos that i use as tester… I’ll investigate deeper on that. ty

        1. Ok. I had some trial for BME280. I have two shields and I hacked via hw the i2 address. Now one is h76 and the otherone 77h. In both the cases it does not work. I used the command i2c_check and i always have no device found. SO I was thinking if the problem was more related to I2c speed or some pullup resistor to add in the path.
          I’m actually using the 3.3v and GND and the GPIO4 and 5 (scl and sda).

    1. Yes, sorry, well I’ve been doing a lot of time travelling recently and well, you know – you lose track. Now suitably fixed.

    1. Well, I’d like to do a little more with displays – given the massive amount FLASH I have available to me. I’m currently playing with one of those little I2c 128*64 OLED displays – dirt cheap and I’m running one on a NEO – a fairly small library that does text only and does it extremely quickly. I don’t quite understand it well enough yet to be able to migrate it over but that would make a nice addition.

      1. Yes it would be great to have oleds to play with in the new spare ròom on the ESP8266S. My next thing is reprogramming my sonoff touch light switch myself. I can’t wait to put big timer on it. Thanks for making it Peter. From down under good night.

        1. BigTimer is still awol from the flows site – but DCEEJAY has promised to take a look.

            1. GOOD… but he did it for the Arduino – in C# – it can be a pain in the arse to back-convert Arduino libraries – I know – I’ve done some of them. Better in straight forward C for use with the Espressif SDK.

            2. If I recall correctly this is one of the ones I tried – and uses a LOT of the available NANO RAM – one of the things I like about the library I’m using with the Nano is that it does not try to be all things to all people – it is text only – I2s only…. and it hardly uses ANY RAM… I may try to convert it.

      2. Tried several Arduino libraries that would run on Nano and ESP8266 but I prefer the following library to control the OLED displays:

        It’s text-only and due to low memory use it runs both on my Arduino Nano and ESP8266.

        Some additional nice features:
        – using streams, so you can use something like oled.println(“hello”)
        – vertical text scrolling

            1. Yes if works well on the Nano. I may well have a go at converting the I2c version to work in my ESP code…

Comments are closed.