Setting up the build environment, and debugger.
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.:
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:
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:
147832 560 2912 151304 24f08 NYETDuinoPlusLua.elf
217364 560 2912 220836 35ea4 NYETDuinoPlusLua.elf
157660 560 2912 161132 2756c NYETDuinoPlusLua.elf
160292 560 2912 163764 27fb4 NYETDuinoPlusLua.elf
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.
Try a smoke-test with eLua source