Category Archives: ESP-12

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

Facebooktwittergoogle_pluspinterestlinkedin

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

Facebooktwittergoogle_pluspinterestlinkedin

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.

Facebooktwittergoogle_pluspinterestlinkedin

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

{si1132_uv}

{si1132_ir}

{si1132_visible}

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.

Facebooktwittergoogle_pluspinterestlinkedin

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…

{i2c:39,0,3}

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

{i2c:39}

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

https://tech.scargill.net/sunday-morning-experimenting/

https://tech.scargill.net/i2c-expansion-for-raspberry-pi/

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

{i2c:8,0,1,20,1}

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.

{i2c:8,1,4,30}

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!!

Facebooktwittergoogle_pluspinterestlinkedin

Home Control Updates

For those following the home control project including the ROMS for ESP8266, I’ve made several changes in the last few days including a new uptime command {uptime?} returning a string of the time since last reset/power-cycle. Also added that to the debug output – also fixed a couple of minor RGB issues. Source code now works with very latest SDK 1.5.4.1 from Espressif http://bbs.espressif.com/viewtopic.php?f=46&t=2376

If none of this means anything to you see:

https://tech.scargill.net/blowing-the-home-control-2016-code/

https://tech.scargill.net/home-control-2016/

https://tech.scargill.net/nextion-wifi-touch-display/

Facebooktwittergoogle_pluspinterestlinkedin

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

Facebooktwittergoogle_pluspinterestlinkedin

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.

Facebooktwittergoogle_pluspinterestlinkedin

Home Control 2017

Introduction (Latest update August 09, 2017)

HomeSick of reading about other people’s home control? Want to make your own? Got some electronics and software experience? You’re going to LOVE THIS! Rock-solid home control – low cost, DIY.

If you’ve read my early blogs you’ll know that Aidan Ruff and I have been working in home control since the late 20th century. Together, we ran an electronics R&D company for many years and one of our products was a home control system called APPCON.

Home Control 2017

Continue reading Home Control 2017

Facebooktwittergoogle_pluspinterestlinkedin

The Nextion Experiment

Nextion BoardOur latest experiment! The board you see to the right should be with us in a couple of weeks. This little number will sit on the back of a Nextion board, from the smallest to  the largest without adding any height (hopefully) and contains as you see an ESP-12 and supporting components.

The extra connectors are just to give it a more general usefulness.

Having implemented software serial on GPIO4 and GPIO5, the board will allow for sending messages via MQTT directly to the Nextion while still allowing debugging and programming of the ESP using the normal ports. 

Far better I think than strapping a Raspberry Pi onto the things. We’ve not tried to do anything too clever here so this all assumes the display is already programmed up.

My own use for this is a couple of simple wall units to show and control heating and lighting… I already have a display hooked up to a Raspberry Pi for general control but it’s a tad excessive having those plastered all over the house hence this board which we’ve had made as thin as possible.

Can’t tell you much more until we get the boards back and give them a go.

Currently ending my first week of a 2 week contract (well for now anyway) over in Spain so my ability to experiment is severely hampered as you might expect (but that is compensated for by sunshine). 

By the time I get back to the UK  I’ll have some more Sonoffs to play with (hopefully the later types with one of the LEDS attached to GPIO13 on the ESP8266) and some new ESP-related stuff to review.  My new workshop is up – just needs electricity, insulation, desks, shelves – no problem really!

Facebooktwittergoogle_pluspinterestlinkedin

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?

Facebooktwittergoogle_pluspinterestlinkedin