The MMCFS implementation can now handle more than one MMC card. To
use this feature, define these macros in platform_conf.h:
MMCFS_NUM_CARDS - the total number of cards
MMCFS_CS_PORT_ARRAY - array of CS ports
MMCFS_CS_PIN_ARRAY - array of CS pins
MMCFS_SPI_NUM_ARRAY - array of SPI port numbers
For example:
#define MMCFS_NUM_CARDS 2
#define MMCFS_CS_PORT_ARRAY { 7, 2 }
#define MMCFS_CS_PIN_ARRAY { 0, 5 }
#define MMCFS_SPI_NUM_ARRAY { 0, 0 }
defines a system with 2 MMC cards. The first one uses SPI0 and has its
CS on PG0. The second one also uses SPI0 (this is perfectly possible)
but has its CS on PC5. This was the configuration used to test this
feature on a EK-LM3S8962 board.
The build system now accepts a single C file as a target and compiles that
file only. For example:
$ lua build_elua.lua board=ek-lm3s8962 src/main.c
Two other switches were added to the build sysem (both of which work only
with the single file target shown above):
"-E": preprocess file instead of compiling it
"-S": generate assembler source for the file instead of compiling it
Get rid of the "reserved" byte in the TString data type. Might actually
save more than one byte, depdending on the compiler structure alignment
rules (and the architecture). Tested with the Lua 5.1 test suite.
- For now only supported for MMCFS
- 'dir' function in shell augmented to show directories and
to traverse a path recursively if requested
- new command 'mkdir' in shell
Newer Newlib versions use different functions to implement integer-only versions
of printf/scanf. Our stubs were modified to take advantage of these changes and
keep the code size low in integer-only versions of eLua.
Fixed bug reported by Tim Van der Hulst:
-------------------------------------------------------------------------------
dofile('/mmc/test.lua') -- OK
require('test') -- Fail!!
-------------
/mmc
test.txt 5 bytes
gprs.lua 2910 bytes
util.lua 385 bytes
test.lua 385 bytes
Total on /mmc: 3685 bytes
-------------
Error: [string "xmodem"]:23: module 'test' not found:
no field package.preload['test']
no file '/mmc/test.lua;/mmc/test.lc;/rom/test.lua;/rom/test.lc'
no file '/mmc/test.lc;/rom/test.lua;/rom/test.lc'
no file '/rom/test.lua;/rom/test.lc'
no file '/rom/test.lc'
-------------------------------------------------------------------------------
The problem was actually in the way read-only strings were created. If a read-only
string creation call specified a size which was different than the actual (C) size
of the string, the string didn't get null-terminated, which in turn led to some
interesting errors (like the one above).
This should really be more than one commit, but I wrote everything in one
shot and I don't feel like arranging the changes logically into different
commits. So, these are the changes:
- added WOFS (Write Once File System). This is a writeable file system that
exists in the MCU's internal Flash memory and allows files to be written,
but only once, in a single shot. More details to follow.
- the platform interface has a new MCU flash access interface.
- added WOFS "reference implementations" for two CPUs: LM3S8962 and
STM32F103RE. They are easily extendable to other CPUs in the same platform
and can be taken as a model for other platforms.
- the ROMFS file layout in memory was slightly changed.
- the simulator (src/platform/sim) got a new function (lseek).
- shell: now each shell command receives its arguments in a C-main-style
(argc, argv) pair. This was originally Marcelo's idea and it finally
made it to the master (although this particular implementation is mine),
after I got fed up with all the argument parsing in the shell functions.
- new shell command: wofmt ("formats" a WOFS, effectively clearing it).
- a couple of small fixes in the shell code
1. the filename for 'recv <filename>' was not set correctly
2. error messages for 'cp' were not always correct
3. check for copy errors and issue a message accordingly
All the functions that implement a FS receive the instance data
of the FS (given at registration time to dm_register) as their
last argument. ROMFS was changed to take advantage of this.
Now it's possible to have more than one instance of a given file
system. For example, one could use more that one ROM file system
in different physical locations (a possible configuration is
internal Flash and external serial memories). This mechanism is
currently implemented only in the device manager (devman.c),
actual instance implementation require per-FS support (to be
implemented later).
On some platforms, the hardware timers were counting down instead
of up, which broke the assumptions of the new timer implementation.
Fixed by inverting the timer value (relative to its maximum value).
This patch adds more RAM optimizations to eLua:
- direct file memory mapping: files in ROMFS will be read directly from Flash,
without allocating any additional buffers. This doesn't help with RAM
consumption in itself, but enables the set of optimizations below.
- pseudo read-only strings. These are still TStrings, but the actual string
content can point directly to Flash. Original Lua strings are kept in
TStrings structures (lobject.h):
typedef union TString {
L_Umaxalign dummy; /* ensures maximum alignment for strings */
struct {
CommonHeader;
lu_byte reserved;
unsigned int hash;
size_t len;
} tsv;
} TString;
The actual string content comes right after the union TString above.
Pseudo RO strings have the same header, but instead of having the string
content after TString, they have a pointer that points to the actual
string content (which should exist in a RO memory (Flash) that is directly
accesbile from the MCU bus (like its internal Flash memory)). lua_newlstr
detects automatically if it should create a regular string or a pseudo RO
string by checking if the string pointer comes from the Flash region of the
MCU. This optimization works for both precompiled (.lc) files that exist in
ROMFS and for internal Lua strings (C code).
- functions in Flash: for precompiled (.lc) files that exist in ROMFS, the code
of the functions and a part of the debug information will be read directly
from Flash.
- ROMFS was changed to support files that are larger than 2**16 bytes and it
aligns all its files to an offset which is a multiple of 4 in order to prevent
data alignment issues with precompiled Lua code.
- the Lua bytecode dumper was changed to align all the instructions in a Lua
function and a part of the debug information to an offset which is a multiple
of 4. This might slightly increase the size of the precompiled Lua file.
These changes were succesfully checked against the Lua 5.1 test suite.
These changes were tested in eLua on LM3S and AVR32.
From the Lua Power Patches page:
"Use NaN packing for TValue on x86 to reduce memory usage
and tiny performance gain (same as in LuaJIT i2).
It's fully ABI compatible with standard Lua libraries.
On one test script memory consumption reduced from 28Mb
to 21Mb and performance improved about 3.5-5%"
Added support for big endian architectures and LTR compatibility.
luaD_checkstack could damage the stack, possibly making further
references to 'func' invalid. Fix this by using the information
inside the CallInfo structure instead of 'func'.
helper_remote_index() contained an error which allowed for incorrect
calculation of the string length to be sent. This should now be
fixed. Additionally, read_cmd_call() did not check whether indexing
was successful at each step, we now check whether the indexed result
is callable or a table and attempt to provide an indication of the
type of error made by the user.
Methods: mizar32.rtc.get() returns a table like Lua's os.date()
and os.time() with fields year, monthm day, wday, hour min, sec
and mizar32.rtc.set() takes a similar table, only changing the
fields that are present in the table.
Works with DS1337 and PCF8563 clock chips.
