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.
Sleep manager provides API to lock/unlock deepsleep. This API allows a user to
control deep sleep.
This API should be done via atomic operations (to be IRQ/thread safe).
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.
On some platforms, the in-application memory is not memory mapped
and therefore cannot be accessed using memcpy.
The flash_read function added to flash_api.h (with a weak
implementation using memcpy in mbed_flash_api.c) can be used for
reading data from areas that are not memory mapped.
- A new 64 timestamp type has been added: us_timestamp_t.
- Changed type of timestamp in ticker_events iinto us_timestamp_t.
- Event queue now have a to store a current, absolute timestamp.
- Add alternative versions of ticker_insert_event and ticker_read which accept
in input us_timestamp_t.
- Add documentation explaining the limitation and behavior of ticker_read and
ticker_insert_event.
ticker_insert_event() can crash on KLXX (and probably other platforms) if an event is inserted with a timestamp before the current real time.
The problem is easy to trigger: you just need to set up a Ticker object, and then disable interrupts for slightly longer than the Ticker object's interval. It's generally bad practice to disable interrupts for too long, but there are some cases where it's unavoidable, and anyway it would be better for the core library function not to crash. The case where I had an unavoidably long interrupts-off interval was writing flash with the FTFA. The FTFA hardware prohibits flash reads while an FTFA command is in progress, so interrupts must be disabled for the whole duration of each command to ensure that there are no instruction fetches from flash-resident ISRs in the course of the execution. An FTFA "erase sector" command takes a fairly long time (milliseconds), and I have a fairly high frequency Ticker (1ms).
The problem and the fix are pretty straightforward. ticker_insert_event() searches the linked list to figure out where to insert the new event, looking for a spot earlier than any event currently queued. If the event is in the past, it'll usually end up at the head of the list. When the routine sees that the new event belongs at the head of the list, it calls data->interface->set_interrupt() to schedule the interrupt for the event, since it's the new soonest event. The KLXX version of us_ticker_set_interrupt() then looks to see if the event is in the past, which we've stipulated that it is, so rather than actually setting the interrupt, it simply calls the handler directly. The first thing the Ticker interrupt handler does is re-schedule itself, so we re-enter ticker_insert_event() at this point. This is where the problem comes in: we didn't finish updating the linked list before we called set_interrupt() and thus before we recursed back into ticker_insert_event(). We set the head of the list to the new event but we didn't set the new event's 'next' pointer.
The fix is simply to finish updating the list before we call set_interrupt(), which we can do by moving the obj->next initialization ahead of the head pointer update.
If target supports flash algo, it can get common HAL implementation, providing
feature "HAL_FLASH_CMSIS_ALGO". This simplifies target code, and having
one implementation that can be shared by many targets.
Be careful with flash cmsis algo, in some cases they execute code that
can affect the system. For instance, it can disable cache, or affect
some system clocks. Therefore this feature should be well tested.
Add sleep/deepsleep functions to platform layer which are replacing HAL
functions with the same name, rename existing symbols in HAL layer
to hal_sleep/hal_deepsleep. This way sleep functions
are always available, even if target doesn't implement them, which makes
the code using sleep clearer. It also enables us to make decision on in
which builds (debug/release) the sleep will be enabled.