This change is required by the Samsung S111(S5JS100). On this board timer clock used for us ticker operates at 26MHz.
According to current requirements, 8 MHz is the top limit for us ticker timer.
This change relaxes top limit to 100 MHz, but only for 32-bit timers.
Ticker common layer schedules one interrupt per timer rollover to trace elapsed time. We need to ensure that this operation is not performed too frequently. I.e. in case of 16-bit timer at 32 MHz, the timer rollover will happen after ~2 ms. This may cause that there will be no time for other tasks. That is why we increase the top limit, but only for 32-bit timers.
As the timer code became more generic, coping with initialization on
demand, and variable width and speed us_ticker_api implementations,
wait_us has gradually gotten slower and slower.
Some platforms have reportedly seen overhead of wait_us() increase from
10µs to 30µs. These changes should fully reverse that drop, and even
make it better than ever.
Add fast paths for platforms that provide compile-time information about
us_ticker. Speed and code size is improved further if:
* Timer has >= 2^32 microsecond range, or better still is 32-bit 1MHz.
* Platform implements us_ticker_read() as a macro
* Timer is initialised at boot, rather than first use
The latter initialisation option is the default for STM, as this has
always been the case.
Current version:
The function ticker_init resets the internal count and disables the ticker interrupt.
Proposed version:
The function ticker_init allows the ticker to keep counting and disables the ticker interrupt.
This is a result of the following discussion:
https://github.com/ARMmbed/mbed-os/pull/5233#pullrequestreview-86677815
This API is added primarily for testing purposes, to be able to test HAL drivers without using upper layers to handle ticker interrupt.
By default IRQ handler is set to ticker_irq_handler() for us ticker and lp ticker - original one.
Usage example (setting custom ticker irq handler):
void my_irq_handler(const ticker_data_t *const) {
// handle interrupt
}
ticker_irq_handler_type old_handler = set_us_ticker_irq_handler(my_irq_handler);
Respectively for lp timer set_lp_ticker_irq_handler() API should be used.
Allow tickers to specify their native frequency and number of bits.
This allows the conversion to happen in common code rather than in
each vendor's implementation.
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.