All derived frequencies (sdram, USB, tmr, VTMRs, SPI, UARTs, PWM, MMC,
and ethernet) compensate correctly for the different PBA freq and
tmr.getmaxdelay() is still just over 0.5 sec (by a hair!).
This may work for EVK110X too - the reason they chose 60MHz is unknown.
This fixes the following AVR32 SPI clock setting bugs:
- it used to set the SPI frequency at a quarter of what you asked for
(by calculating it from the wrong clock)
- it did not report what actual frequency it had set
- spi.setup() always seemed to succeed even if it failed
- it used to set the nearest frequency instead of the next lowest available
so half the time would drive devices at higher than their maximum speed.
This was hidden by it always setting a quarter of what you asked for (!)
- it would set a junk frequency if you asked for a clock lower than its minimum
- asking for a baud rate of zero made it divide by zero, which went undetected
and set a random baud rate instead of the minimum available
- Now, if you ask for an invalid number of data bits (< 8 or > 16),
spi.setup() returns zero.
This is still wrong and undocumented.
It should give an error message in platform-independent spi_setup() and stop
but unfortunately the current code structure does not allow this, since the
possible numbers of data bits is platform-specific.
The AVR32 SPI setup code passed the wrong clock to the SDK's SPI
init function. The result should have been that it set one quarter
of the required frequency.
This change is "obvious" but untested, since the spi.*() module
interface seems not to work yet on AVR32. The MMC card on SPI1
continues to work as it did before, presumably at full speed
instead of quarter speed.
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.
