With a recent version of the GNU ARM Embedded toolchain
(7-2017-q4-major), compilation for ARM targets fails with this message:
```
[COMPILE] .build/ek-lm3s8962/src__fatfs__ff.o
src/fatfs/ff.c:288:9: error: conflicting types for 'sync'
FRESULT sync ( /* FR_OK: successful, FR_DISK_ERR: failed */
^~~~
In file included from
/home/bogdanm/bin/gcc-arm-none-eabi-7-2017-q4-major/arm-none-eabi/include/sys/reent.h:13:0,
from
/home/bogdanm/bin/gcc-arm-none-eabi-7-2017-q4-major/arm-none-eabi/include/reent.h:93,
from inc/newlib/devman.h:7,
from src/fatfs/ffconf.h:14,
from src/fatfs/ff.h:20,
from src/fatfs/ff.c:79:
/home/bogdanm/bin/gcc-arm-none-eabi-7-2017-q4-major/arm-none-eabi/include/sys/unistd.h:289:9:
note: previous declaration of 'sync' was here
void _EXFUN(sync, (void));
^
[builder] Error building target
```
This PR fixes this build issue by renaming the internal "sync" function
in ff.c to "ff_sync".
Improved bit module and cpu module memory r/w functions to accept all
numbers and scale them down to the 2^32 number range. It now works
analogous to the bit32 module of lua 5.2.
Changed patches in commom_tmr.c according to Bogdans recommendations
The bit module did not work correctly with numbers where bit 32 was set,
because the conversion between the eLua floating point numbers from/to
integer was using signed integers.
For example
print(string.format("%x",bit.band(0x80000000,0x80000000))) resulted
output "7fffffff" instead of 80000000.
The patches in this commit ensure that all conversions are done with
unsigned integers.
Fixed the following bugs:
Disabling the timer interrupt with a period of 0 for a virtual timer did
not clear the vtmr_int_periodic_flag, so the timer is still reset
regulary when reaching the old interval. The fix adds clearing of the
flag when tmr.set_match_int is called with a period of 0.
The check afainst the maximum value in tmr.set_match_int was wrong, this
has been fixed. The input value is scaled to the timer ticks before the
check is made.
The original implementation of net.accept did not unlisten the port
after returing. So additional clients can connect to the port, but the
connection is not used. The easiest way to solve this, is to make an
unlisten() call before returning from accept. But I think it is better
to separate listen/unlisten from accept and let the system allow
accepting new connections in the background which can be later taken
with a call to accept. This allows for example using a coroutine waiting
for new connections with a non-blocking accept loop and a yield call.
This commit contains everything to implement the new behaviour and also
add the methods net.listen and net.unlisten. To be compatible with the
old semantics net.accept automatically calls listen to the port.
In addtion the error handling of accept was changed in a way that a
timeout returns the new return value net.ERR_WAIT_TIMEDOUT instead of
returning -1. I find this more consistent.
Allow new incomming connections to be queued between accept calls. This
allows to build servers which accept several connection and server them
all with the help of coroutines.
Most of the stack based allocations were restored a while ago
in commit f86cfd345b145544baf9e4205f86800b3a44a9db. The ones still
left were causing problems (#92), so this commit reverts to
stack-based allocations completely. Note that this might increase
the RAM usage in some cases.
