Summary:

In this project, I are going to try to get Lua running on a Netduino Plus 2 ('NP2') (STM32F405RG) board.

Deets:

The Genesis

Recently, in an unrelated professional project, I had occasion to realize a systems architecture that I had been wanting to have the opportunity to do for many years (>1 decades!).  Part of that involved a scripting component, and for that project I chose to use Lua as the scripting language/engine.  I had only cursorily worked with Lua before, so it was a bit of a project risk for me to have integrated it, but I can say that after having done so, I look back on that as a good choice for what I needed.  (This system is a desktop system component, so I won't discuss it further.  I only mention here because it was the spark that started this -- I hope to be -- fire.)

There is a long-languishing (8 years!) project that I mean to come back to, but my thinking has evolved since then, and now I think I might choose to implement it with Lua as a high-level integration mechanism, rather than the harder-coded C/C++ stuff I originally intended to use.  That is also a separate project, but it caused me to think:  Why don't I make a mini-project of getting Lua up on dev board I have lying around as a first step?  This would allow me to understand and verify Lua on a microcontroller separate from retooling my existing work, and maybe it is useful to other folks in some way.

The Board

The board I am going to use for this mini-project is the 'Netduino Plus 2'.  Why?  Well, simply because I have a few on-hand that are otherwise going unused.  It is a general purpose board, so the experiences with this should be useful for others with other boards.  Also convenient to me is that it has a few peripherals wired in:  a button, a light, a micro SD card holder (will have to be in SPI mode), and an ENC28J60 ethernet adapter (so I can test out networking if I want to).

These boards were shipped to run Microsoft .Net Micro Framework ('.NetMF'), which is an interpreted manifestation of the Common Language Runtime ('CLR'), and with some libraries particular to embedded needs (e.g. gpio stuff, i2c, spi, etc).  Microsoft created .NetMF for the ill-fated SPOT smartwatch, and later released the source for the people to use.  The creator of the Netduino (now defunct - and it's quite an interesting saga - though another company acquire the assets and continues to sell them) had packaged that runtime in an Arduino-compatible physical form, hence the Netduino name.

I came into possession of these boards some years back when I was doing a contract job for a client who purely adored .Net.  It was what would probably now be described as an 'IoT' (or even 'IIoT') product in that I was Internet-enabling gates to parking garages, and had things like wired, wireless, and cellular data, barcode scanner, and some encryption functions.  This .NetMF approach would not have been my first choice otherwise (I'm really more of a C/C++ programmer), but as mentioned the client loved .Net so I thought I would at least give it a go.  I didn't really expect it to work out, but it actually worked fairly well, and I did very much appreciate the high-level environment and the goodies it provided.  But, oh!, sweet Jesus!, it ran slow as Christmas.  Fortunately, I did not need speed for that project.

So, that's the story of why and how I got to this point.  Since this is alternative firmware, I hereby dub this project the 'NYETduinoPlusLua' thereby achieving the first goal of any project:  a suitable name, ideally comprising corny puns.

For those that might want to follow along, I have attached some technical documents regarding the Netduino Plus 2 board in the 'files' section.

Now it was time to do some basic research.

The Initial Research

As per usual, I did research for existing projects, and did not find specifically Lua on the NP2, so that means that it is useful for me to try.  I did find out that there is and existing 'eLua' port of Lua specifically for microcontroller use, so that is almost certainly what I'm going to work with.  The gist of that port is some memory-management tweaks to save precious RAM, and includes a bunch of libraries meaningful to embedded work.  (I'll describe those things in more details in a later post.)  So, notionally, this is similar to what Microsoft was doing with the .NetMF.

The eLua has several chip and board support packages.  It does seem to have chip support for the STM32-something-or-other (there's a myriad of different ones, and they often do not use the same IP blocks), so ostensibly what I should do is create a board support package for eLua.  However, I think I am not going to take this approach.  Instead, I will move the eLua code with modifications into an STM32 Workbench project.  Why?  Several reasons:

1. While I don't exactly love STM32 Workbench -- especially because it is based on Eclipse (big and slow and so quirky), I /do/ love that there is an out-of-box installer that deploys everything needed in one shot, including debugging tools.  Oh, yeah, and debugging:  I /do/ love interactive, source level, single-step debugging.  Also, my eventual other project will be an STM32 Workbench project, so this will facilitate such migration when that time comes.
2. By contrast, eLua has some build system of it's own and I'm too lazy to learn another build tool at this juncture.  (But maybe I'll come back to it later).
3. I'm probably going to have to hack on the eLua source in some way, anyway.  eLua is based on Lua 5.1.4, which is 10 years old.  The current version is 5.3.4.  I don't know why eLua is lagging behind, but I would prefer to use the current version.  Maybe there's a good reason, but I guess I'm going to find out for myself!
4. I'm probably going to have to do some hacking for the peripherals support in some way.

The downsides of this approach of course include:

1. I will have a constant porting maintenance challenge reflecting changes from the eLua project into my own.  How difficult that will be remains to be seen, and may not be that bad in the end.
2. I would be polite of me to contribute back my NP2 board support package.  I generally like to do that for open source projects when possible, and I won't be able to in my Frankenstein form of eLua changes, but we'll see.  If my changes seem worth submitting, then I'll put forth some effort to integrate them into the canonical build system for eLua.
3. Maybe I'm making more work for myself than needed.  Maybe.  Sometimes I do that, alas.

But for now, I'm going to do it anyway despite the risks.

And now, as per usual, my first step is to get a build system setup....

Next:

Setting up the build system.