A Dev Board For The ESP Lua Interpreter

From the great minds behind the NodeMCU Lua interpreter for the ESP8266 comes a proper dev board for the WiFi platform of 2015. They are calling it, the NodeMCU-devkit, and it’s a reasonable, cheap, and breadboardable breakout board for the ESP8266.

The version of ESP8266 used in this project is the ESP-12, the newer, fancier model with RF shielding, a questionable FCC logo, and every single one of the GPIOs exposed on castellated connectors. The rest of the board is a USB to serial converter (the CH340G – probably the cheapest USB to serial chip out there), a few passives, and a USB micro connector. It’s simple, cheap, and open source. You can’t do better than that.

This dev board is explicitly designed to work with the NodeMCU firmware, a Lua-based firmware for the ESP. Already we’ve seen some projects make the Hackaday front page with this firmware. Sure, it’s just a garage door opener, but that’s extremely impressive for a chip that’s only a few months old.

Thanks [Baboon] for the tip.

25 thoughts on “A Dev Board For The ESP Lua Interpreter

  1. Anyone know why the article states that the board is “explicitly designed to work with the NodeMCU firmware?” I’m not sure I want to program is lua but I’ll have to admit I haven’t tried it. Can anyone see any reason the board shouldn’t work with the normal ESP8266 development environment?

    1. You can use NodeMCUs with the ESP8266 Core for the Arduino IDE and develop custom WiFi sketches for IoT applications. It;s a natural extension for Arduin programmers for getting into ESP8266 WiFi w/o having to learn a new set of programming lools or a new language like LUA. I think the extensive libraries that are available for Arduino will work in many cases in an ESP8266 with only minor modifications. I got my I2C_1602_LCD working w/o much of any problem using the LiquidCrystal_I2C library. I suspect LUA can’t do I2C_1602_LCDs as easily as we do under the Arduino IDE with the ESP8266 Core installed.

      The one thing I like about Lua and the NodeMCU is that their pin numbering scheme (now? maybe always??) correspond to what I call the Arduino friendly pin names silkscreened onto the NodeMCU PCB. With the ESP8266 Core on the Arduino IDE, it assumes the native GPIO numbers making the NodeMCU a bit more difficult to use because the pin labels don’t correspond to the GPIO numbers. However, this is easily corrected for in the Arduino IDE by using the C preprocessor’s #define command to redefine the pin numbers from the Arduino friendly pin names to the native GPIO pin numbers up front, and then use the Arduino friendly pin names in your code. When you compile, the preprocessor will substitute the GPIO pin numbers in automatically, so it’s not that difficult a problem to deal with. But with the NodeMCU, the Lua firmware takes care of translating the friendly pin names to native GPIO automatically w/o even having to resort to placing preprocessor commands at the beginning of your source file.

      I’m new to Lua, but that system of program is starting to look easier and easier the more I work with it. Hope it will all prove useful as I hate surmounting learning curves that prove to so useful in the long run of things.

      My 2 cents (or liang fen) worth. All these Chinese components, I’ll be talking Chinese before long…

      1. The ESP module has 2.0mm pin spacing and a breadboard is 2.54mm. There is only about 8 pins either side of the module so if you use longer pins (some stiff wire) you can fan them out so they fit into a breadboard. Each side of the module is 8 pins – a total of 14mm. 8 pins on a breadboard spans 17.8mm so the outer pin only need to span out by 1bout 1.9mm.

    1. The spark photon (eval board) isn’t that much cheaper at $19. The module itself requires a reflow and a PCB.

      The ESP-12 on the other hand can be hand soldered easily either to a PCB or to wires. If you can solder SOIC pin pitch at 1.27mm, then you are already over qualified for the 2mm pitch spacing.

  2. I can’t say I will racing out to get one of these. LUA is a very fast language as it is very close to bare metal so it’s a low fruit if you’re choosing a (slightly) higher level language to port across to a uC (MCU).

    It has all the nice data types and the dotted OOP as well as curly bracket procedural (without the curly brackets).

    The problem is the combination of a language rich in primitives while still being quite low level. To get anywhere with complex tasks you have to build a framework which means reams of code. Because it rich in primitives everyone does that same task differently so the reams of code become too hard to follow.

    Most of the primitives sit in the LUA sandbox. To get out into the real word you have build your I/O. Once again everybody will do this differently. The end result is that you have code that is portable as far as the LUA sandbox is concerned but when you go from one device to another you end up having to rewrite the real world interface (framework) for that device anyway.

    LUA is great if you need speed above all else or serious number crunching. Not your floating point SIN COS TAN number crunching but more complex tasks where you have to write your own analytics and math like complex graphics rendering or breaking down complex registered logic equations, all the odd ball stuff where the existing functions of other languages just don’t cut it or are too slow.

    I like LUA. I can render complex graphics at 2000 FPS on a windows system, now that’s fast, but – LUA on a uC – I think I will pass.

    1. That argument applies to C as well. It seems to me that, all else being equal, allowing team members to use hash tables and enforcing better encapsulation would be worth the performance hit, because it would reduce the amount of time everyone has to take to fiddle with C details. I haven’t used Lua for an embedded project yet so maybe I’m off-base in assuming that it would help reduce coding (and design) errors in a team environment, but I can’t help but think it’s got to be better than my everybody-bring-your-own-style C situation.

    2. Also all numbers in Lua are floating point, which makes it not a great fit for memory-constrained environments. The closest thing to an array of 8-bit integers in lua is a table of 64-bit floating point

      This was mentioned in an interview from someone at Electric Imp as the major reason they shifted away from Lua to Squirrel instead.

    3. re: LUA on ESP, main advantage is that you have a very quick turnaround, you just paste your LUA source to the ESP console and it runs (there are font end tools to help with that too). No need to build and flash firmware (which costs about half an hour each time).
      Once you design is stabilized, you may want to push your code to the firmware in native C.
      One drawback is that the LUA interpreter/engine itself will use up almost all of the memory available on the ESP, so you’re getting limited quickly.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.