- FAT changed to support the new opendir/readdir/closedir mechanism, and to use lseek directly instead of ioctl (also fixed a bug in FAT's lseek that always returned 0 instead of file position).
- ET-STM32 console moved to UART2@19200bps (to allow RFS to run on UART0). If UART0 is needee for console, remember to disable RFS.
- freed 700+ bytes of RAM by changing the devman implementation to keep pointers instead of actual DM_DEVICE structures
- other minor code changes and fixes
- Current online site will be updated acordingly
- LM3S6965 version still needs to be adapted, tested and uploaded (sent to me). I do not have an LM3S6965 board to test :(
- A text paragraph describes the idea (revisions/refinements always welcomed)
- The links are correct but the files are not there yet. I'll upload the LM3S8962
as soon as I figure out where to send them too @BerliOS :)
Help is needed to adapt (on the repo's LM3S Games branch) and test the eLua Games
build to the LM3S6965 kit.
SCons decider for main build and luarpc have been switched to MD5-timestamp,
which will prevent scons from re-digesting files it has cached unless
timestamp has changed (should shave a little off of build times, but be safe).
Some of the PNG screenshots that didn't get crunched before the 0.7 release
have been run through optipng, advpng and pngout to wring out as many bytes as
possible without losing data/quality.
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)
