Commit d4f03efb96973d73056d87b4173c394ca673bebf halves the running
speed of the interpreter on Mizar32 because the vitrual timer tick
happens 128906 ties a second when there is no FOSC32 crystal.
This commit restores VTMR granularity by calling the 10Hz routines
once every 12890 ticks.
Fixed an error which made the getmindelay/getmaxdelay functions
invalid (thanks to Martin for spotting this). Also refactored the
code that computes min/max delay from platform files to common code.
- Always set a speed <= the one requested, never higher
- Return the closest integer to the actual speed that we set,
instead of just returning the speed they asked for
- Limit the range of the speed to the possible values
to avoid divisions by zero
INT_GPIO_POSEDGE and INT_GPIO_NEGEDGE support for AVR32. Tested on
an ATEVK1100 board (NEGEDGE only, POSEDGE is 100% symmetrical and
thus it should work too)
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.