This helps apps to treat natively-supported LM3S OLED RIT display as just another onboard device.
Doc will be enhanced to give examples on these modules' usages.
- added some more documentation (not yet done)
- alternate uarts can be selected (boot mode defaults to console uarts)
- renamed "remote" references to "rpc" (may as well keep the original name)
- switch default error handler to luaL_error (presumably wasn't available for
old 4.x LuaRPC)
- tweaks to exception handling to make things more consistent (hopefully)
Added another "romfs" parameter to SConstruct. It can take one of 3 values:
- "verbatim" (default): copy all the files from the eLua romfs/ directory to the binary image (exactly what happened until now)
- "compress": use LuaSrcDiet (http://luaforge.net/projects/luasrcdiet, now included in the eLua distribution) to "compress" the source code by using different tricks (shorter identifiers, removing comments and EOLS, and so on). The output is still a compilable Lua file (although in most case it looks completely different from the original) which is copied in the eLua binary image instead of the original Lua file. The compression obtained by using this method seems to be very good in practice, thus it will save flash when needed.
- "compile": use the eLua cross compiler (that must be built first by running 'scons -f cross-lua.py') to precompile the Lua files to bytecode, and write the bytecode to the image instead of the source file. This way, one can save both time (the scripts don't need to be compiled anymore) and RAM (for the same reason, especially since the Lua parser uses the stack a lot, which can lead to very nasty and hard to diagnose stack overflow bugs). It will be even more useful in the future, when (hopefully) more and more Lua bytecode data structures will be available directly from Flash (without having to copy them RAM as it happens now). It might also decrease the romfs memory footprint, but then again, it might not; it pretty much depends on the Lua programs included in the romfs.
cat (or type) prints file contents one after another, just like Linux cat
command line lenght is currently limited, not too long (can be extended if needed)
debugging.
Might be nice to have a generalized form of something like this to help in
pointing in the right direction when one doesn't have a JTAG debugger.
any platform. No need to specify it in the file_list table.
- minor comments added to SConstruct
- LM3S platform specific modules commented
- Minor comments in Pong
- Debugging prints removed from Tetrives
