Regular readers will know that we've been having some capacity issues here at tech.scargill.net with our old provider “Unlimited Hosting” who turned out to be FAR from unlimited - and if you're reading this - we're now up and running with a new provider – Smart Hosting – not without teething problems but they’ve been REALLY helpful. Apologies if any of today's comments have been lost in the process, an unfortunate product of changing over. Hopefully now you should see a far more responsive site. I’ve already seen comments coming in so it’s all working. The next time someone promises me an "unlimited hosting" service I'm going to be a lot more critical of that claim!
Back in the dark ages when the ESP8266 was something new, I had a go at the nodeMCU software, essentially implementing the Lua language (or a subset of it) on the ESP8266. At the time I was not familiar with Lua but thanks to some of the excellent resources out there on the web, I quickly caught up.
Sadly, my expectations exceeded the ability of the implementation to match and every time I went past flashing a few lights – CRASH. I gave up in disgust. I’m not complaining as that gave me the impetus to learn the hard way how best to program these chips – which I maintain is using the C language – and in my case via the unofficial development kit which is just an excellent piece of work by Mikhail Grivorev, leading to a complete Windows environment with a ton of examples. Between that and TuanPMs excellent MQTT code as a starting point I’ve been happily programming away and even built up a working relationship with Espressif in the process. My home control project is well under way and now just waiting for some new boards – and a function that Espressif have promised to shut down PWM.
Meanwhile this morning, I can’t remember what I was reading that triggered me off, I decided to have a quick look at the node-MCU code again. I had it sitting in the development environment but figured it would be out of date and so went off to the repository to study any changes – which I duly put into the code. The GIT Makefile is useless for Windows but fortunately there was one in the environment – and as it happens, a good one. I wasn’t about to go backward so I made sure I was linking to the very latest SDK which at this time is 1.1.2 with at least one patch – all available from the Espressif forum.
I checked the settings in the Makefile, adjusted the SPI speed up to 80Mhz, set the FLASH size to 4Mb to suit the sparkly new ESP-210 that is sitting here looking for a job – and started the compile process. Within a minute and without any issues, the code was flashed. I have to say I was expecting at least one or two issues – but no.
I set up a 9600 baud terminal, in the process discovering for the first time that you can have multiple terminals at once in the Eclipse environment – handy (it would be more handy if it always reported the right location of bugs but you can’t have everything). Sure enough – a working Lua board.
I told it about my WIFI setup and sure enough it grabbed that too. The project has come a long way since the early days and now (apparently) supports json, a file system, timers, pwm, i2c, spi, 1-wire, net, mqtt, coap, gpiio, wifi, adc, uart and more. I’ll believe all of that when I see it.
I was delighted to see that both the integer and float versions are available – that’s a plus! I also noted support for the WS2812b chips – I noted that as I had to make a change to the source code and I’m delighted to note that they’ve made use of a local compiler directive that I was not even aware of to ensure accurate timing. Wish I’d seen that a month ago when I started work on my own WS2812b support.
I’m pleased to see the nodeMCU docs have come on a long way – sadly the website was running like a DOG at the time but here’s a few stats I managed to get off the board.
print(node.heap()) returned 20kbytes which is more than when I tried it – but then it used to die when the heap got down to 5K so we’ll have to wait and see how reliable that is.
3 Channels of PWM are available – at 10 bit resolution. Clearly some work to be done here as Espressif have just released a library handling more outputs than that at nearer to 14 bit resolution – and it works as I’ve been using it in my own research and projects. However – handy enough.
There are libraries for sending to displays complete with fonts – now that I’m interested in – if this will do reliably MQTT and report results to a display I have a use for this already – wall thermostats.
So, overall, a very brief test – it is possible with the right environment to get interactive and easy to use nodeMCU up and running in minutes – you don’t need special boards and the software is free. Can’t be bad – how complex a program you can make withou running out of RAM remains to be seen. Here is some more info on nodeMCU.
Well, it’s looking like a good day for discovering more ESP-based boards. This time the ESP-13. APPARENTLY what sets this one apart is 16MBytes of FLASH… My question is – when will RAM be the bottleneck (personally I think it already is) – can’t add that as it is internal. Just think of the web pages and imagery you could store in that!!!
After carefully removing from the box… I plugged it in to my PC via it’s micro-USB connector. The right noises appeared, no lights…
As it happens I had a fairly complex project on the go in front of me so I changed the port number to the device at hand and pressed the programming button on my PC..immediately a green light came on on the board along with 2 yellow communication lights.
After the usual programming time I was left with a fully programmed board – no problem with a BLUE light on!. It is nice to get something in the post that just works first time – and looks pretty.
So what’s so special about this – for one thing – it has 0.1” connectors – which is always a plus. Unlike the ESP-12 it runs on 5v. It also has 4Mbyte of FLASH (most of the other boards have 512K Flash). I just cannot imagine filling up that amount of room – but of course, with the ability to store web pages in FLASH you never know what someone might get up to!
There is a user-definable LED on-board attached to GPIO5 (that’s 4 LEDs in total up to now) and the Silabs CP2014 USB to serial device lets you program up to 921600 baud (rather handy if you wanted to use up that 4Mbyte).
As well as USB you can also power the board by either 5v or 3v3 – which is nice. Other features include pull-ups on GPIO16 and GPIO2 so you could use either for temperature sensing without adding anything. TOUT is actually the ADC – so you get that coming out along with the 2 pins for serial I/O which of course can be used for general purpose.
Armed with on-board antenna there is no facility for an external antenna but to be honest I’ve never seen the need for one – the internal ones seem to work just fine.
So – just for a bit of fun I dragged out the nodemcu-firmware in my Eclipse environment (important for Windows users because the make file that comes with the original is for Linux) – applied just about the only update that was missing (a couple of lines change for WS2812b LEDs) – set the SPI speed to 80Mhz, set the size of FLASH to 4Mbytes and pressed the FLASH button – lo and behold it compiled first time, dropped into the ESP-210 without issue and after strapping a strip of serial WS2812b LEDs to the board, entered the right LUA instruction…. and VOILA – a strip of brightly coloured WS2812b LEDs. What could be easier.
So there it is – another board to ponder! Invector Embedded Systems AB. Lots of info here. http://wiki.sweetpeas.se/index.php?title=ESP-210 including instructions for putting NodeMCU on it if that’s your thing.
Apologies to those of you trying to get to the blog yesterday. For reasons not yet known, the site came to a grinding halt and it took the service providers until this morning to bring it back online. It now appears to be working very quickly. Let's hope that was an isolated example.
Meanwhile, for those of you interested in the ESP8266, Espressif have confirmed they will shortly add a pwm.stop() function to the PWM code - marvellous.
Oh and you'll find on their forum if you've not been there in the last few days, updates for SDK 1.1.2 to fix a current-consuming bug in sleep mode!
So there’s a nice project for the mathematically inclined. My ESP boards get the time (summer time and location corrected) via MQTT where that’s worked out on a more powerful Raspberry Pi. They also get dusk and dawn times.
As it is possible on the ESP to get the time via NTP, and it is easy to add the regional offset, all that is missing is summer/winter time correction and dusk and dawn times in a stand-alone environment. I found one piece of code which looked like it might do the job but it would not compile as all the various floating point libraries such as sin/cosine etc. etc. are all missing.
Is there another way to get local, summer adjusted time and date along with lighting up and dawn times, from a server without having to do lots of maths locally. Clearly one could write something on a server somewhere in PHP to do the job – but that might be re-inventing the wheel?
Being a Sunday I was lying in bed early this morning pondering life when I was reminded that we had 2 short power cuts in a row the night before due to me overdoing the electric heaters here in our cave in Spain where we’re having a short break. The laptop of course survived no problem due to internal battery but the Raspberry Pi went stone cold dead on me.
It occurred to me as I load more and more onto this tiny computer including a MYSQL database, that such cuts could do damage to the microSD card and indeed people have said that occasionally they go bad.
It occurred to me as I was sitting starting at one of the many unused “emergency power” solutions I have for my phone lying around that one of these would make an ideal “uninterruptable power supply” for the Pi. Indeed a very trivial script attached to one of the input pins could easily monitor the incoming power and do a nice, graceful shut down in the event of power loss.
I have one of those “Juicebar” devices, half the size of the Pi that accepts USB power and/or solar charge and with maybe 200ma capability could easily keep the Pi running for half an hour or more. Aside from the obvious advantage of protecting against power loss, I have no doubt these units will also protect to some extent from power surges.
And so that’s the plan. One wasted piece of kit lying around doing nothing could now save the bacon next time we have a power cut. These devices can be had for as little as £2.99 from Ebay (minus the solar panel) so really it just makes sense.
Up market at £10, the solar chargers come with 10,000maH capacity – that’s well over a day of operation and the solar panel can actually make a small contribution to the running costs!
Update March 26,2015: Just as has been mentioned it has come to my attention that many designs of these power systems will NOT allow you to use them in this way - you'll have to test. I have 4 such supplies - two will act as uninteruptables, the other two will not charge and be used at the same time (which seems a bit daft).
Update June 24,2015: http://www.banggood.com/30000mAh-Solar-Charger-Battery-Power-Bank-For-iPhone6-Smartphone-p-919239.html - this one’s a winner – no guarantees though.
While waiting we’ve done ourselves a new board – it’s not too obvious but under that power supply / dc/dc convertor area – are three MOSFETS for PWM use and we’ve added a connector so you could stick some RGB serial LED strip straight onto a connector.
GPIO16 is on there and on this particular board we have NOT shorted GPIO16 to reset so it can be used for purposes other than for SLEEP mode! The board is designed to take ESP-12s (or ESP12-E ignoring the new leads) but at a pinch could use an ESP-01 if all you wanted was a RELAY output and a sensor. Before anyone asks – with the DC/DC convertor, the board with no lights attached uses around 100ma with 12v in. The Tiny85 is there for interest only so some of those parts on the left would normally not be used. In a couple of of weeks we should have boards and get one built up – but 95% of the layout is already tested. More details on the main Home Control 2015 page.
Updated Sunday 22/06/2015 : The thing about the ESP8266 is there is always something new to discover problems with!!
So this week –
The new PWM module appears to have issues and as we don’t have the source, we can’t fix them. Right now it will only do up to 90-95% duty cycle– and once it starts up there is no way to stop it – that is, attempts to use tight code for, say, serial LED control fail because of the interrupts going on in the background – I’ve asked for fixes and a stop routine. Started a new version of our board with 3 MOSFETS on it in anticipation of getting this working.
SNTP – the sntp routines work – you can get the time from a server – but if you add in from the SDK documentation, the bit to set the time zone first – it will then NOT get the time. A better example is needed. The default time routine gives the time not at GMT - but GMT-5 ?!!?!?! So you need to add the number of hours for where you are (*60*60). That leaves just the summer/winter correction which is a whole other ball game.
On the lookout for a maths type..
I’m about to do a blog item on PWM on the ESP8266 – the reason for that is – they’ve some new code which currently isn’t 100% or I’d be writing it up now – but suffice it to say the maximum duty cycle value is 22,700 or thereabouts. That just blows away what you can do with an Arduino.
Now, much as it would make for beautiful displays, that’s WAY too many steps – but as we know, our eyes are non-linear – so simply dividing that down to say a 256- entry lookup table would produce VERY rough stepping at low brilliance with far too smooth stepping at the top end.
I have the spreadsheet open, just need someone to jog my memory – what formula do we need to put in the cells to get 256 levels out of this?
Watchdogs on the ESP8266
Since Espressif SDK 1.01 or thereabouts, watchdog timer operation seems to have changed – delays of any length even in init() are out – or so it would seem? So I got onto Stanza Wang, the business Development Director of Espressif Systems who as always was most helpful and got a quick reply from one of the development engineers on this subject.
It turns out they’d prefer the use of these function:
void pp_soft_wdt_stop(); // close software watchdog
void pp_soft_wdt_restart(); // reset software watchdog
So for example use void pp_soft_wdt_stop(); before your delay and then use void pp_soft_wdt_restart();
Delays are not a good idea full stop if you’re using background processes such as WIFI – but you might not be!
Maximum use of FLASH
Thanks to Richard Burton, it is now possible to start programming right down at the bottom of memory – leaving LOADS of FLASH free (though iRAM continues to be a precious commodity – someone needs to do a “how to” on saving RAM. I’ve blogged on this elsewhere with a link.
Debugging and those Pesky Messages
And now…. debugging. I have had it up to here with odd strange output from the Espressif SDK. TuanPM implemented a simple macro called INFO for outputting to the serial port for debugging and general information – but there was no way to control what came out – worse, the SDK kept throwing status information out which wasn’t wanted – so we’ve written our own.
If you’re outputting info to the serial line the best way as we’ve found is to disable Espressif’s messages using
in your user_init function. This turns off all output to the serial – unfortunately that means that os_printf() no longer works – so you’re dead in the water. We wrote our own printf equivalent for the serial port and we call it iprintf().
You don’t HAVE to make it this complicated… if you want you can simply, having disabled os_printf() use ets_printf() where you want text to the serial port - but we wanted more control.
Here are a couple of definitions – bit masking – you might choose to make your own.
This is in our DEBUG.H file
extern int enable_debug_messages; // Needed by debug.h
#define DEBUG 1
#define INFO 2
#define RESPONSE 4
#endif /* USER_DEBUG_H_ */
So somewhere in the init, set a variable (see above) to the level of debugging you want….
int enable_debug_messages = INFO | RESPONSE;
And here is the function to use that…
char buf; // resulting string limited to 127 chars inc arguments – change if you like
va_start (args, fmt);
ets_vsnprintf(buf, sizeof(buf), fmt, args);
if (debug_type & enable_debug_messages) uart0_tx_buffer(buf,os_strlen(buf));
So basically you have a function you can call with a debug level..
iprintf(INFO,”Starting up the program”);
You can pass parameters to it just as you would with printf….
iprintf(RESPONSE,”The answer is %d”,answer);
Depending on the level of debugging you want you could expand on this greatly. Someday we’ll convince Espressif to optionally turn off that start-up 78k rubbish and we’ll have totally clean output – for now this is a great start.
A shame you often have to hunt around for this stuff!
At long last – a board without bugs! Well, we decided not to bother with the little ‘85 control chip but other than that everything works – no hidden repair links. The white board in the middle is the latest and it is sporting an ESP-12e though we’ve not attempted to make use of the extra pins – however as they’re just as cheap as the ESP-12 we thought.. and why not. The red board is sporting a 12v to 5v convertor as I need a couple that run off a car battery and the other two have 230v supplies on them. Just need to give the board a good hammering now before building up a stock to take with me for the summer.
THIS home control article deals with the commands the board handles.