- automatically searches for compatible toolchain (and checks that it at least runs)
- running "scons -h" now shows descriptions of command line options and enumerates valid values
- caches last specifically requested configuration
More to come...
- enable file creation, reading, writing on mbed for the built-in filesystem
- implementation currently lacks support for directory listings, this will be
added when mbed implementation details are available.
Note: this should work with other ARM arm ports that are connected to a JTAG
debugger that implements semihosting, though I have not tested it.
- 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
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.
- 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.
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
- disabled by default (enable on a target-by-target basis) so it shouldn't
cause much breakage for non-rpc users
- some modifications to the binary chunk reader which should allow reading of
chunks encoded on various platforms (with certain limitations like lualong
can't read float lua bytecode, one must generate lualong bytecode from a float
lua)
- other misc changes.
- code cleanup
- the platform is now named 'sim'. You build it like this:
$ scons cpu=linux
The idea is to support more than one host OS by changing the "cpu" variable
above (for example cpu=osx, or cpu=win32). Also, a crude "host interface" was
defined in hostif.h. In theory, a host OS should only implement that interface
in order to run the eLua simulator. The implementation must reside in a file
called hostif_{os}.c (in this case hostif_linux.c). Too bad I don't have a MAC,
I would've loved to try this :)
REMEMBER: whem implementing a host interface, you CAN NOT rely on your regular
libc! You'll have to rewrite the syscalls (see host.c for an example on how to
do this in Linux).
- after you build it, don't start it directly, use the new "run_elua_sim.sh"
script to run it. It will set the terminal to raw mode, no echo, so it will
behave more like "traditional" eLua (even hangman.lua will run in this mode :) ).
Remember to run in on an ANSI capable terminal (although most of them support
ANSI emulation nowadays).
- you can exit from the simulator with "exit". You can't do this with CTRL+C if
you run it with "run_elua_sim.sh".
All in all, this looks pretty good and it's an excellent test platform. It will
do wonders when we integrate our own libc and we won't be able to figure out why
it doesn't work :)
- ADC adjusted to work with sequenced acquisition setups. It should now
accomodate both sequenced and non-sequenced approaches on the backend.
A few more adjustments should be made to handle multiple sequencers
but right now neither LM3S or STM32 platforms use more than one sequencer.
- Added adcpoll.lua to demonstrate a simple approach for using clocked
acquisition and displaying results as they become available.
- ADC now works for STM32 (all 16 channels!). This should receive more
extensive testing, but everything should be working at this stage.
- the build system now pays attention to changes in header files meaning that
if any headers change or if the romfs changes (since it is generated as a
header) these changes will get recompiled without having to do a clean.
- The Eagle 100 binary image now starts at 0x2000 by default (instead of the regular 0x0) to allow users to take advantage of the provided Ethernet bootloader.
- deleted the old docs/ directory. The "real" documentation is in the doc/ directory
- "building" page completely rewritten
- a new page about the toolchains used in eLua
- a graphical representation of the system architecture (doc/wb_img/elua_arch.png) that will be used in a soon to come page about the eLua architecture
Also:
- validate.h updated with some new tests (still needs more work)
- "arm-gcc-eabi" toolchain name changed to "codesourcery", since this is obviously way more intuitive :)
$ scons board=... toolchain=arm-gcc|arm-gcc-eabi
(the default is still arm-gcc, but this can be changed by editing SConstruct).
This is a Very Good thing for us, because users won't need to build their own toolchains anymore, they can just download the one from CS and use it. Thanks again for this.
Actually, the whole build system was changed to support arbitrary toolchains (although there's much work to be done in this area).
Also, changed a few things in the STM32 port (the linker script file, the stack definitions).
And other (very minor) changes (mostly to fix some compiler warnings).
SConstruct edited just to leave group/files definitions close to the platform/groups.
Doc content files mirroed to pt, to ease the portuguese version initial migration
