Code which was previously using buffer has been updated to work with the
changes.
API has also changed in accordance:
int buf_set(unsigned resid, unsigned resnum, u8 logsize, size_t dsize);
int buf_is_enabled( unsigned resid, unsigned resnum );
unsigned buf_get_size( unsigned resid, unsigned resnum );
unsigned buf_get_count( unsigned resid, unsigned resnum );
int buf_write( unsigned resid, unsigned resnum, t_buf_data *data, size_t dsize );
int buf_read( unsigned resid, unsigned resnum, t_buf_data *data, size_t dsize );
Essentially buf_rx_cb and buf_get_char have been renamed to buf_write and
buf_read. For these, one now passes a pointer to where the data is coming
from or going to, and a dsize parameter indicating how many bytes should be
copied. Also, buf_set takes this same dsize parameter, and keeps it in the
struct. This allows us to ensure that when data is read or written the
number of bytes matches the buffer element size.
I thought about maintaining compatibility functions to provide the original
buf_rx_cb and buf_get_byte API calls, however there weren't a large number
of uses of buf, so it wasn't hard to convert things.
One caveat: BUF_MOD_INCR assumes that byte counts for alternate type sizes
will be powers of 2.
Also, BUF_SIZE_xx's are assumed to refer to element counts.
- UART buffering enabled on LM3S
This doesn't include switching the ADC code over to using these buffers quite
yet.
I'm open to comments on these modifications if theres a better or simpler
approach. I've checked to make sure buffers work on LM3S, but I don't own any
other platforms to make sure there aren't unintended side-effects.
- now uses bitfields rather than HWREGBITW for keeping track of state
- started generalizing functionality for smoothing, state tracking etc... into
separate functions
- burst mode now works, including with smoothing enabled (only operates in a
blocking mode, non-blocking to come later)
channel. Smoothing support (rolling average) has been added. adcscope has
been updated to reflect these changes, and show output from 4 channels at
once.
- fix for typo in stm32/platform.c
the heap instead of the stack. Also, the stack size was bumped to at least
2048 bytes on all backends. Hopefully this will take care of most issues
related to stack overflows.
- new buffering system available. Originally I planned to make it fully
generic, but I came to the conclusions that this would take too much
development work and system resources (RAM/Flash) if done properly, so
currently it's only used on UART RX (although it could be easily extended
for other peripherals). For an example of use check the AT91SAM7X and
AVR32 backend (platform_init and associated interrupt handlers and also
platform_conf.h).
- new XMODEM implementation. Better, cleaner, bug fixed, and BSD instead of
GPL.
- AVR32 can use the huge (32MBytes) SDRAM on the board as system memory now.
- fixed an error in elua_sbrk/_sbrk_r (and revised the compilation options
for dlmalloc).
- added the CPU module and interrupt support on the STR9 platform.
- uart module changes: 'sendstr' is out, but the regular 'send' will send
strings instead of simple chars (which makes sense since Lua doesn't have
a "char" type). Also, the 'timer_id' and 'timout' parameters of the 'recv'
function are now optional.
DETAILS: for most platforms, the main stack size was set to 256 bytes to
save RAM. During a routine Lua debugging session, I discovered that there
are at least two data structures in Lua (declared on the stack) that can
lead to a stack overflow problem because of their size:
lparser.h -> struct FuncState (original size: 572) is allocated on the stack
when the parser needs to compile a Lua function
lstrlib.c -> MatchState (original size: 272) is allocated on the stack
everytime the string library does match-related operations.
To fix the first problem I modified these macros in luaconf.h:
/*
@@ LUAI_MAXUPVALUES is the maximum number of upvalues per function
@* (must be smaller than 250).
*/
LUAI_MAXUPVALUES from 60 to 10
/*
@@ LUAI_MAXVARS is the maximum number of local variables per function
@* (must be smaller than 250).
*/
LUAI_MAXVARS from 200 to 25
The new size of the FuncState structure: 124
To fix the second problem I modified this macro in luaconf.g
/*
@@ LUA_MAXCAPTURES is the maximum number of captures that a pattern
@* can do during pattern-matching.
** CHANGE it if you need more captures. This limit is arbitrary.
*/
LUA_MAXCAPTURES from 32 to 10
The new size of the MatchState structure: 96
All these values are experimental, but they should work well.
Also, I forced the main stack to 512 bytes in all the backends. Hopefully
this will take care of this problem.
- all eLua modules updated to work with LTR
- "cpu" module added to avr32, at91sam7x, str7
- "disp" module no longer generic (now stays in src/modules/lm3s). For this reason, the "disp" platform interface was also removed.
- the "modcommon" mechanism in STM32 (ROM loader) was depreciated in favour of the Lua Tiny RAM patch (and the "stm3210lcd" module from the STM32 backend now uses LTR).
- small bugfixes
- added virtual timers (on LM3S, AVR32 and AT91SAM7 for now)
- added interrupt handling code for AT91SAM7 and AVR32
- fixed two serious bugs that prevented the eLua image to run on both STR9 and LPC2888 (linker command file issues)
- fixed line endings (DOS->UNIX) in the STM32 library files
- fixed preprocessor errors (hopefully all of them) like #if ELUA_CPU == LM3S8962
- other minor or less than minor fixes :)
an eLua_Manual.pdf was added to docs
separate .txt files will be removed soon
The eLua_Manual.odt development will be part of another area (branch) of the repo
It now illustrates how to create and use a module in Lua for eLua.
An LM3S platform-dependend module is created, exposing it's buttons, leds and offering some utility functions.
This very first version is basic an assembly of the previous txt files written
by Bogdan.
Documentation for the new disp module was included and some initial revisions too.
This document, in PDF format, will soon replace the separated txt files in the docs
folder of the eLua distros and it will also be available separetely on the site.
