ESP8266 Lies and Deceit

tmpCE60It never ceases to amaze me when looking through Ebay, the level to which companies or individuals are prepared try to mislead the public or at best are simply unable to form sentences correctly. Some even tell outright lies.

Let’s take one of my favourite subjects, the ESP8266 boards. Way back in the past, ESP8266 life started off with the ESP-01 module, comprising an ESP8266, 512KB FLASH and most of the connections NOT brought out. Being surface mount, only the most agile could solder pins to get the extra outputs – but – we were all new to this – and what a bargain, for just a couple of pounds you could have a crippled ESP8266 and actually turn things on and off via WIFI.

Today we expect a lot more and probably the big standard in ESP8266 is the ESP-12 (and variations). There are many boards out there based on this module which offer all the available IO pins – and of course the now standard 4MB of FLASH.

Why is the FLASH important? Well, programs are stored here and effectively appear to RUN in FLASH (they don’t but that’s a different conversation).  The ESP8266 has programming access to 1MB of FLASH – which means you can store up to 1MB of program in the device (including the rather large SDK or similar library needed to run the programs. For clarify here 1MB is 1 megabyte, 1Mb is 8 times less as the small b means BITS.

As many of you know I’ve been working on code for these devices since they first came out and my “kitchen sink” code can do SO much – I won’t go into this here but you can read about it on the blog. I’m still nowhere near to running out of RAM or FLASH.

In addition to running up to 1MB of programs, you can also use another 1MB to store another version of the software. Known as OTA, a common  technique downloads a new copy of the software into a second 1MB space then the boot code selects the new 1MB segment  on boot to give us a wireless update. Next time around the new copy is written into the original 1MB and the FLASH 1MB segment used is then swapped back etc etc.

The remaining 2MB is not quite so easy to access but can be used to store data – and the Arduino-look-alike code popular with some, makes use of this with a “file system” able to access that extra FLASH. Because of this, folk get all sorts of ideas about using that extra FLASH for storing data.

With that in mind I was intrigued to see THIS LINK – now, no-one is lying here but it’s a damned good attempt at fooling the unwary.  The title says “NodeMCU V3 WIFI Module ESP8266 + 32M Extra Memory Flash USB-Serial CH340G”. I’m ashamed to say this ad is from a British-based company as well. The price is “OK” and so this seemed like a bargain. I say British – well, it is sold in Britain but the language somewhat gives the game away… “We add extra memory size to 32Mb. This better, for make big project with big library.”

So – here we see the first issue – despite the headline and careful wording this is in FACT a board with 32Mb of FLASH – that’s little b – or – 4MB just like any other modern board but they try to give the impression to the unwary that this is somehow EXTRA – no it is NOT.

Simple LUA language – well, yes, no doubt it does but that is freely available anyway.

10 GPIOs….  really?   GPIO 0,2,4,5,12,13,14,15,16. There are 4 more IO pins but as 2 of them are attached to the USB I don’t really class them as GPIO – and of the other two only one can be used and ONLY if you are using DIO programming mode – without purchasing a board I can’t tell.  Not lies but again – designed to mislead beginners. If you also recall that GPIO16 is output only – and for deep-sleep needs to be tied to reset, that leaves in my book, 8 general purpose IO pins that you can count on…  for the really uninitiated, GPIO-0 can’t be held low on power up either as it doubles up as a programming pin – so it isn’t REALLY a general purpose IO pin, which leaves 7.

Then we can look at pricing – most of these boards are made in China and if not then the underlying chip is – so don’t get carried away by the extra value of buying in Britain or the USA – you might get faster delivery and that’s about it. NodeMCU boards seem to go from around £3.50 (ESP-12 on a backboard with regulator and USB chip) to  staggering £7.45

How about this one..   now this is CHEAP – looks good – but I did find the memory claim interesting.. ESP8266 wifi chip development card with a very large memory capacity: 8MBytes (32MBit),  Struggle as I might, unless I’ve just entered a parallel universe I don’t see how 8MB == 32Mb.. erm, no – it’s a standard 4MB board. Actually I quite like the look of this one.

So -  if you’re looking for an ESP8266 board -  just be wary…. read the details VERY carefully and remember – most of what you see on these boards is just flourish – easy access to pins, regulator etc. The actual working bit of most of these boards is encapsulated in a typical ESP-12 module… at £1.60 – for the dab hand, one of these plus regulator, reset circuit and a few Rs and Cs is all you need….  so don’t go paying too much for very little extra. I generally pay around £3.50 and since sorting the DIO programming issue out am favouring the little WEMOS-type boards. Works for me…   but as I’ve stated elsewhere – if you want to do deep-sleep stuff with these boards you will want to forget ones with USB chips on them – and you might even want to look at those with guaranteed low-loss regulators.  If anyone has recommendations on that score – fire away.


11 thoughts on “ESP8266 Lies and Deceit

  1. I've been trying to find your earlier remarks regarding not using boards with USB chips when wanting to do deep sleep. That may explain a problem I'm having. My searches aren't turning anything up. Is this contained in a particular post you can point me to without too much trouble? Thanks.

    1. The only effect USB chips have on deep sleep is to use juice. Similarly with regulators though to a much lesser extent (usually). So you need a minimum system. Don't forget you also need GPIO16 attached to reset.

      1. Thanks for the reply. For anyone else happening across this topic, I found a blog post regarding operating the NodeMCU on battery power. Among other things, the author performs some invasive board surgery to disable the problematic components, but has some suggestions for how to allow the re-enabling of the USB so that the board can still be used for easy development.

    1. Hi there Michael... yes, looked at them - but as I have no use for an external antenna (some of the Pi-type boards have them and for my uses I've never seen an advantage over the internal types which work just fine) and as you can't actually use any more than 1MB for anything other than data, I've never pursued these 🙂

  2. Nice blog!

    "Why is the FLASH important? Well, programs are stored here and effectively appear to RUN in FLASH (they don’t but that’s a different conversation). "

    Does this mean if I write PIC (position independent code), compile it as such, and then write it to a known address in flash that I will not be able to effectively drop my PC (program counter) at that address and expect it to execute?

      1. Worked through much of it.

        0x10000.bin gets flashed to 0x10000 in ESP's flash.
        Via their eagle linker script they map this to a virtual address of 0x40210000.
        ESP will then execute these instructions from flash, for example my function is at position 0x5860 in the bin file. So on ESP it exists at 0x15860. When I wrote some inline asm to dump out the program counter it was a few instructions deep from 0x40215860.

        My theory is that one can write a binary blob into a particular address in flash, let's say... 0x50000 and then jump program counter to 0x40260000 and this blob should run normally.

        End result should be a small applet which can be dynamically updated and which has freed itself from the massive blob by linking statically with all the rest of the code which makes ESP run.

        One item still researching is relocatable code generation by gcc. The manual I was looking at did not mention support within the generic nor within the xtensa sections. Several other processor types have it mentioned. Maybe the doc is old or maybe it isn't supported. If the latter then the dynamic applet would need to be coded in ASM rather than C.

Leave a Reply

Your email address will not be published. Required fields are marked *