There are some platform that will not get a system timer implementation
(mainly because they don't really have a user base). These are i386,
lpc288x and str7. They will continue to work without a system timer.
Since the system timer might be too demanding for some platforms
(although this isn't currently the case for any eLua plarform) it
is now optional. Any platform that implements it must define the
PLATFORM_HAS_SYSTIMER macro in its platform_conf.h
When a systimer timer overflow is detected, handle it by temporarily disabling
the systimer interrupt rather than disabling the systimer completely. It gives
better accuracy and fixes some hardware-related issues on some platforms.
- Very low frequencies with very high clock rates (ratio > 1048576)
selected random requencies (overflow of 20-bit period register was
not checked
- initialization of prescaler selector to 0 was missing.
It just happened to get 0 off the stack every time by chance (!).
Instead of "correcting" or ignoring bad parameter values in i2c and pwm
(see commit e6b20231b4eea4054070b1f6a4e36216e80d2d1d)
apply the eLua policy of signalling the error on the console and aborting.
All "clock" and "frequency" errors here use the same message ("frequency")
so as to reduce the firmware bloat from extra message strings.
- the infinite timeout value is again represented by a special value
(not a special timer ID), but this time it's a non-negative value
- all timers in the UART module default to the system timer
- all timers in the TMR module default to the system timer
- implemented a generic system timer mechanism that can be used in
conjunction with a timer interrupt.
- implemented system timers on LM3S (tested) and STM32 (not tested).
Both are based on the Cortex M3 SysTick timer.
Previously, if you set a frequency value ten times the PWM clock
frequency, it would calculate a period of 0 and return foo/0, which
gives -1 on AVR32. With this change, everything > pwmclk sets and
returns a frequency of pwmclk.
Previously, pwm.setup() would set a frequency equal to or less
than the one asked for, and report an integer less than or equal
to the actual frequency set. This change makes it set the closest
available frequency and report the closest integer to that.
Previously, you could ask for a PWM frequency of 0 and negative
duty cycles, and each platform would do a different thing: failing
or setting some random values. This change replaces such values
with the minimum, the same way that duty is bounded to 100.
- added explicit support for the system timer in common_tmr.c
- all the functions in the tmr module will now use the system timer
by default (if no id is specified)
- infinite timeout will be specified by using a special timer ID
rather than using negative timeout values (this allows the timer
data type to be unsigned and increases the timer range)
THe MAXUPVALUES was reduced to reduce stack and RAM usage, but turns out
to create incomprehensible erorrs for beginners when they use more than
10 global variables ina function.
This change puts is back tot eh Lua defualt, which uses 100 bytes more
RAM when parsnig functions, or 200 if they have nested functions.
This seems less bad than throwing incomprehensible errors when beginners
code the sort of things that beginners always code.
==================
From: Raimondas Sasnauskas <raimondas.sasnauskas@cs.rwth-aachen.de>
Date: Sun, Sep 20, 2009 at 1:29 PM
Subject: Re: RE: Re: RE: Re: Re: RE: Bug (?) in uip TCP/IP stack: lost SYNACK causes connection reset
OK, here I'm proposing the following patch (see git diff attached).
Again the problem we face here is the subsequent SYN arriving in
UIP_SYN_RCVD state after the SYNACK packet was lost. First, to avoid
other issues, suggest to reset any _active_ connection where a SYN
arrives in a state != UIP_SYN_RCVD.
==================
This is a combination of the patch submitted by Raimondas Sasnauskas and
the patch applied by Oliver Schmidt to Contiki
===================
Original bug report
===================
From: Raimondas Sasnauskas
<raimondas.sasnauskas@cs.rwth-aachen.de>
Subject: Bug (?) in uip TCP/IP stack: lost SYNACK causes
connection reset
Date: 2009-09-02 19:07:51 GMT
Hi all,
I've found the following issue in the TCP (UIP_ACTIVE_OPEN)
connection establishment phase leading to connection failure.
This happens whe the SYNACK packet gets lost during the TCP
3-way handshake.
Client: SYN
Server: SYNACK (this packet gets lost)
Client: SYN (retransmission)
Server: ACK (<-- server thinks it's data?)
Client: RESET (correct, no SYNACK received yet)
Server: ABORT (got reset, aborting connection)
I do not have a patch/workaround yet, but I think that
correctly handling incoming TCP_SYN packets in UIP_SYN_RCVD
state would fix this issue.
http://article.gmane.org/gmane.network.uip.user/1506
Here's the content of the patch (so it can be more easily
discussed if need be). What basically happens is uip_len and
uip_slen never get reset to 0 when calling the poll handler.
Here's an example of how things go wrong:
Let's say you get some new incoming data (uip_newdata()), your
application handler processes the new data and sends something
out (thus setting uip_slen). Back in the main loop again, you
poll a connection. uip_slen is still set from the last send and
if your poll handler doesn't send out something new, uip ends up
just sending out the exact same data on the now polled
connection. In every other applicable case, uip_len and
uip_slen get reset, but for whatever reason this one just got
missed...
http://article.gmane.org/gmane.network.uip.user/1312
I have been working on implementing a port to the atmel
ATMega128 and I have noticed that sending UDP packets does not
work (the transferred data is always 0).
A look into the code reveals that in uip.c, the address of
uip_appdata gets set incorrectly.
Somewhere around line 1159 the code needs to be changed:
--- uip_appdata = &uip_buf[UIP_LLH_LEN + UIP_IPTCPH_LEN];
+++ uip_appdata = &uip_buf[UIP_LLH_LEN + UIP_IPUDPH_LEN];
http://article.gmane.org/gmane.network.uip.user/68
i just saw that the stats taking in uip is missing entries for udp
receive and
transmit.
To fix this insert a UIP_STAT after the udp_found label:
udp_found:
+ UIP_STAT(++uip_stat.udp.recv);
And a UIP_STAT before the goto ip_send_nolen instruction:
+ UIP_STAT(++uip_stat.udp.sent);
goto ip_send_nolen;
