Lua Revisited

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.

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

WS2812B LEDs on nodeMCU LuaI plugged a (short) length of WS2812b strip (a custom board we had made) into the ESP-210, fired the instruction and… worked first time out of the box. Impressive.

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.

Facebooktwittergoogle_pluspinterestlinkedin

12 thoughts on “Lua Revisited

  1. I have an esp03 subscribed to some mqtt topics (published by other esp) and displaying results in a display. It works really well, but leaves no ram for other tasks (reading 1wire sensors and so)

    1. Well that's on benefit of DIY with C - you end up with much more memory to play with. on the other hand, having all of those sub-functions available in LUA is nice. The simple setup I have here has Lua subscribed to a topic and leaves 15K free - mind you as I've said elsewhere, in my experience that's not real as by the time you get down to around 5K you're heading to crash land (or to be fair, were some months ago in earlier versions). Of course another way to look at this is to have say an ESP-01 talking to the WIFI and handling MQTT - and talking via serial to another board with no WIFI - doing everything else - they're cheap enough!

  2. I would say Sming is probably be the way to go, once it is working on my 4MB NodeMCU V2 board 😉

    You have a C/C++ environment compatible with Arduino libs, but you don't have to use the horrible Arduino IDE: you can either choose your own editor and command line, or use mouse-controlled IDEs like Eclipse or Visual Studio.

    Having Arduino-compatible libs, you have a much higher level API than the basic Espressif SDK, resulting in a faster learning curve, and less code to write.

    But again, it is still in a very early stage!

    1. I switched to Sming when it first came out. I was able, in Sming, to get something running in under two hours that had taken me several hours in the Espressif C SDK. Since then, the Sming project has been moving briskly. It's maturing, but I must still stress that it's been pretty dependable and seldom flaky as it grows. I'm using Eclipse on a Win 8.1 laptop, and Michael Grigoriev's Windows SDK, with few issues. I have a Java, object-oriented code background, so moving to C++ and thinking in objects has been productive for me. You can still make direct C calls to the Espressif C SDK as the need arises.

      I never touched the NodeMCU-Lua offering, for religious reasons: I don't believe that scripting languages belong on a microntroller (Of course I will eventually be proven wrong; look how popular friggin' JavaScript has become, as processors got better and RAM got cheaper).

    2. I've done the many wasted hours on early stage stuff, some of which came up trumps, others went by the wayside. When I see examples of large, working projects I'll give the Arduino version a go.... 🙂

  3. Sounds great and like cool progress!
    I'm (slowly) working on porting our FastLED library to the ESP8266 and I'm interested in the timing issues. Could you point me to the 'compiler directive' you referred to that affects cycle timing? Thanks very much; I'm hoping to minimize the amount of code I have to implement in Xtensa assembly, mostly just for readability, maintainability, and my own sanity.

      1. Oh, yes, the optimiser flag.. well if you look the nodeMCU code, that's where I found the the flag. Different way of doing it.

        static void __attribute__((optimize("O2"))) send_ws_0(uint8_t gpio){
        uint8_t i;
        i = 4; while (i--) GPIO_REG_WRITE(GPIO_OUT_W1TS_ADDRESS, 1 << gpio); i = 9; while (i--) GPIO_REG_WRITE(GPIO_OUT_W1TC_ADDRESS, 1 << gpio); } static void __attribute__((optimize("O2"))) send_ws_1(uint8_t gpio){ uint8_t i; i = 8; while (i--) GPIO_REG_WRITE(GPIO_OUT_W1TS_ADDRESS, 1 << gpio); i = 6; while (i--) GPIO_REG_WRITE(GPIO_OUT_W1TC_ADDRESS, 1 << gpio); } I had trouble with the first pulse width for ages - and this is how they solved it.. hmm, may give that a shot myself.

Comments are closed.