fire_interrupt function should be used for events in the past. As we have now
64bit timestamp, we can figure out what is in the past, and ask a target to invoke
an interrupt immediately. The previous attemps in the target HAL tickers were not ideal, as it can wrap around easily (16 or 32 bit counters). This new
functionality should solve this problem.
set_interrupt for tickers in HAL code should not handle anything but the next match interrupt. If it was in the past is handled by the upper layer.
It is possible that we are setting next event to the close future, so once it is set it is already in the past. Therefore we add a check after set interrupt to verify it is in future.
If it is not, we fire interrupt immediately. This results in
two events - first one immediate, correct one. The second one might be scheduled in far future (almost entire ticker range),
that should be discarded.
The specification for the fire_interrupts are:
- should set pending bit for the ticker interrupt (as soon as possible),
the event we are scheduling is already in the past, and we do not want to skip
any events
- no arguments are provided, neither return value, not needed
- ticker should be initialized prior calling this function (no need to check if it is already initialized)
All our targets provide this new functionality, removing old misleading if (timestamp is in the past) checks.
The use of mktime was causing a fault when called in interrupt handler because on GCC it lock the mutex protecting the environment, To overcome this issue, this patch add dedicated routine to convert a time_t into a tm and vice versa.
In the process mktime has been optimized and is now an order of magnitude faster than the routines present in the C library.
There is an easy default implementation of spi_master_block_write that
just calls spi_master_write in a loop, so the default implementation
of spi_master_block_write has been added to all targets.
Previously, when "length = 0" as failsafe, "return 0" is executed.
But we changed so that only START bit and STOP bit are executed same as other devices.
Until now, when the frequency function of CAN driver was executed, signal no output, and the frequency could not be changed.
Since there was an error in the frequency changing procedure I modified it.
Bugs are as below.
- In the case of MTU2 mode, modify a problem that does not excute "pwmout_write ()" at the end of "pwmout_pulsewidth_us ()" function.
- In the case of MTU2 mode in "pwmout_period_us ()" function, modify a problem that the executing result of "set_mtu2_duty_again ()" function does not reflect in the register of TGRA_MATCH [] and TGRC_MATCH [].
mbedNoobNinja
Jimmy Brisson
Deepika
Martin Kojtal
Sam Grove
Vincent Coubard
Christopher Haster
adustm
TomoYamanaka
Toyomasa Watarai