Summary:

I managed to get the shell receiving data by crowbarring eLua to not install interrupt handlers.

Deets:

Where I left off, I found that my UART receive function was never called.  At the time it seemed that the eLua is expecting there to be a separate activity -- perhaps interrupt oriented -- that filled a receive buffer.  This turned out to be the case, and moreover eLua wants to install it's own interrupt handlers under conditions unknown to me.

Since I'm wanting to use the STM32 HAL libraries (at this point in time, I may switch to the Low-Level ('LL') libs later), I don't want eLua doing anything interrupt oriented or otherwise down to the metal.

At length, I found a couple defines that cause the interrupt handler to be installed

CON_BUF_SIZE
BUF_ENABLE_UART

These get emitted into the generated board header (in this case 'netduinoplus2.h').  I tried changing the board def to specify 0 for the buffer length of the serial port, but this cause the build system to break.  So for the moment, I manually undef'ed them in netduinoplus2.h to remove the defines.  Now the getch() for the console does make it all the way down to my platform receive function, and I get characters!

So, now I need to find if there is a more orthodox means of removing the buffer and interrupt management from eLua.  Along the way, I noticed a BUILD_C_INT_HANDLERS define.  This seems to come from a board config setting 'cints = true', so I turn that to 'false'.  This causes other problems in a BUILD_LUA_INT_HANDLERS, which in turn is derived from a 'lints = true' so I turn that off also.  Eventually, this did not fix my console buffer size hack, so I had to leave that in for the time being until I learn more as to what all this stuff is.

At this point, I am able to run eLua, but I can't do much.  I can run things like:

print ( "Hello World!" )

for i = 1, 10 do print ( "Hello" ) end

 but more complex things, like:

print ( collectgarbage ("count") );

winds up in the HardFault handler.  *sigh*.  Surely I am not out of heap on these?  Well, I did reduce the heap artificially to 64k 'just cuz'.  I also changed FreeRTOS to 'static only' so that I could deterministically see it's use.  FreeRTOS also has a heap implementation that lets me see some statistics such as 'what was the least amount of heap available, ever'.  The trick is to get all this other code (eLua and libc) to use it, whereas they are coded (and in the case of libc, already compiled) to use 'malloc'.  So I'm going to look into some magikry to redirect those calls into my (er, FreeRTOS') malloc implementation.

Next:

Try to replace memory management.