TIMER2_7_IRQ is shared among several timer sources, including
us_ticker. Raising TIMER2_7_IRQ pending bit will trigger the timer
interrupt, but the timer interrupt handler will not know which timer
source this interrupt is for. This patch sets timer load value to one
tick and force us_ticker to fire almost "immediately".
TIMER2_7_IRQ is handled through a common interrupt handler, and
is automatically cleared. Therefore, there is no need to clear IRQ.
The underlying timer HAL treats load value as micro-seconds and does
conversion internally. Therefore, simply pass micro-seconds to timer
HAL without converting to tick first.
Signed-off-by: Tony Wu <tung7970@gmail.com>
commit f7bc126 (Re-work Rtl8195AM ticker) tried to address ticker drifting
issue, but in fact broke ticker functionality. This patch adjusts us_ticker
porting to unbreak it, and to fix the following tests:
mbed-os-tests-mbed_drivers-ticker
mbed-os-tests-mbed_drivers-timeout
mbed-os-tests-mbedmicro-rtos-mbed-isr
mbed-os-features-frameworks-utest-tests-unit_tests-minimal_async_scheduler
mbed-os-features-frameworks-utest-tests-unit_tests-case_control_async
mbed-os-features-frameworks-utest-tests-unit_tests-case_async_validate
Changes are:
1. Dont disable timer after every us_ticker interrupt. That basically
breaks ticker functionality.
2. Fine-tune us to tick conversion macro. Previous conversion method
yields 1 tick drift every 2 ms.
3. Remove special placement of ticker objects. No longer necessary.
Signed-off-by: Tony Wu <tonywu@realtek.com>
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.
Yuguo Zou
Tony Wu
Martin Kojtal