- Main menu refactored to reduce info levels. Old "tutorials" are now part
of the "More Information" (which already contained tutorials) on eLua
Internals
- Shell help command adapted to rw filesystems addition (ls lists all files
of all filesystems)
- Minor order and name changes on main menu sub-items
- Minor refinements in some doc pages
- Added the elua module to str7, str9, lpc24xx, lpc288x, stm32, avr32, at91sam7x and lm3s platforms
- OBS: the elua module is NOT working on at91sam7x yet (and I don't know why)
- Minor refinements in the License text
dip pins p5-p30 are mapped as P0_5 to P0_30
LEDs are mapped to P1_0 to P1_3
This approach could be switched to using a platform specific Lua module to
define all the pins, or C code to do the same.
LuaRPC exists both in eLua and as a standalone module for a standard Lua
build. This and some forthcoming related changes are to enable building of
the standalone version from the same luarpc sources.
- 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.
