Summary:

Setting up the build environment, and debugger.

Deets:

For my first amazing feat, I get the debugging pod working, and verify that I can program the device.

I have done this before, so for the moment I'll just link a reference to another project where I went into the details of such at greater length, q.v.:

https://hackaday.io/project/25616/log/62106-setting-up-build-environment
https://hackaday.io/project/25616/log/62150-torment-and-torture-by-tortuous-tools
https://hackaday.io/project/25616/log/62581-tool-everything-tool-terrible-two-openocd-rift
https://hackaday.io/project/25616/log/62656-serial-killer-the-sorrow-of-sad-sorry-serial-stuff

ST Microelectronics ('ST') has a 'wizard' style tool called 'SM32CubeMX' which lets you select peripherals, pinouts, clocks, etc., and then it generates a skeleton project with all the relevant libraries referenced and initialized.  The code generated is oftentimes of dubious quality, but it certainly is convenient, and the device has a large flash, so I usually opt for the convenience for starters, then optimize if needed later with custom code.

I created a boilerplate config file for ST32CubeMX describing the Netduino Plus 2 by meticulously combing through the schematic and reflecting those clocks, pin assignments, and peripheral choices into the description board.  I saved this off as 'NetduinoPlus2.ioc' which can be used as a basis for starting other projects for that board.  Then I made a copy for the NYETduinoPlusLua project and generated the skeleton.

I build the project and verified that I could flash the firmware and step through the code.  It does nothing - not even a 'blinky', but that's good enough for me since I've worked with this toolchain before.

Eager for an early 'go/no-go' on Lua, I decided to simply dump the Lua source into the project, and build it and see what happens.  This is the official Lua source, version 5.3.4 specifically, and it is structured simply (just a bunch of source and headers in one directory.  I copied that stuff over and included it all (except for luac.c, which is the stand-along compiler) and built it.

To my great surprise, it compiled with not a single error/warning.  This is very rare, but Lua is known for it's ease of integration.

When built as non-optimized for debug (-Og), arm-none-eabi-size "NYETDuinoPlusLua.elf" reports:

(-Og):
  text     data     bss     dec     hex filename
157756      560    2912  161228   275cc NYETDuinoPlusLua.elf

For completeness, and for the curious, I built it with the other optimization levels, as well, and have included their final statistics:

(-Os):
147832      560    2912  151304   24f08 NYETDuinoPlusLua.elf

(-O0):
217364      560    2912  220836   35ea4 NYETDuinoPlusLua.elf

(-O1):
157660      560    2912  161132   2756c NYETDuinoPlusLua.elf

(-O2):
160292      560    2912  163764   27fb4 NYETDuinoPlusLua.elf

(-O3):
201324      560    2912  204796   31ffc NYETDuinoPlusLua.elf

So that's pretty compact!  Lua is known for being a 'bare-bones' system out-of-the-box, so this doubtlessly includes nothing other than the interpreter, runtime, and a few standard libraries.  But it does look like there is breathing room to add stuff on this device, which has 1MB flash.  I have not idea about the RAM usage at this point, though.  There's a little bit of initialized static/global data (.data) and uninitialized (.bss), but who knows about runtime heap usage.

On a lark, I wired in it's main, passing dummy parameters for the expected argc, argv, and stepped through it.  It did allocate and initialize the environment, so I let it go and it made a quick trip to the fault handler.  I'm not really surprised by this, since surely there would be a bunch of stuff needed to be customized -- if nothing else stdin and stdout.  This was just a quick smoke test, and as such I'm not going to try debugging into it.

For my next test, I am goign to try to do something similar with the eLua source.  This source is for an much older Lua: 5.1.4.  I really want 5.3.x, but I'll try to get the old stuff working for real first, and also assess what is needed to upgrade to 5.3.x.  Maybe the eLua maintainers are holding it back for some good reason.

Next:

Try a smoke-test with eLua source