Lua is one of the two main contenders for firmware for the little ESP8266 WIFI boards which have peaked so much interest recently because of their low price of under £3 (for some reason some people pay more). Alternatively you can brew your own firmware but contrary to popular belief, most of us don’t have time for that and if we did we’d have to take a month to learn Linux commands – so for the majority, the success or failure of these boards will be down to available firmware.
AT Commands – the original AT command set from Espressif is coming along nicely – I would not say it’s perfect but armed with an external processor such as an Arduino, it is possible to interrogate little WIFI boards and for example go and get information from a web server or act as a TCP/IP listener and respond to commands. Right now for anything serious that is my preferred option.
Lua Interpreter. A month ago I’d never heard of Lua and sometimes I still wish I had not, however it is a small, high level interpreted language that can be embedded into the ESP8266 boards and as of last week it will even read the likes of Dallas temperature chips and the A/D on the board. It can read inputs, control outputs and give you many of the facilities that the AT commands can. As you can see in the image above I even developed my own serial terminal specifically to deal with this board and with Lua in particular as I found myself using the same commands over and over again so I developed a non-volatile notepad and filing system to quickly save and retrieve snippets of code as well as easing the process of saving “files” to the board.
Here however is my current list of issues with this otherwise fine piece of work by a gentleman who goes by the name of Zeroday.
1. RAM – the board is chronically short of RAM for variables and the stack – it does not take too much for it to reboot thanks to running out of memory
2. It has only one timer – and that would not be a problem except for the nature of the language – multitasking is arranged cooperatively and unlike the venerable VB6 it does not have the equivalent of doEvents() to let other processes have a go when you are busy. So everything has to be event driven, not ideal for this application. For example one could run the timer at say once per second and increment a load of variables – giving almost unlimited timers but creating a loop in which to poll those timers blocks access to background processes! Ok you could do all of that in the timer callback routine but that limits how much time you can spend on each process severely. Right now for example reading the temperature sensor takes over a second (working on that)
3. Storing variables permanently – lets say the interpreter is running code constantly to listen to an Android of IOS App to control outputs… if the power goes off – how do you restore the outputs to their previous state? There seems to be no equivalent of the Arduino EEPROM facility. I may be wrong on this one but I spend an hour last night staring at the ceiling trying to figure this one out.
Of course all of this is resolved with the AT command set and a separate processor – but for the fact
that you’ve now gone from a sub £3 device to at least twice that….
Time will tell.