There was much confusion over the functionality of the original
`TimerEvent::insert` call which was described as "Set relative timestamp
of the internal event".
This then extended to my Chrono conversion, meaning the new `insert`
call is not equivalent.
Clarify the original documentation, correct the deprecation messages,
and add more notes on conversion.
No functional change, as the new Chrono API makes more sense - it's just
different from the old API.
Problem actually spotted when I saw the strange code `convert_timestamp`
was producing for the 32-bit->64-bit timestamp conversion. The caller of
it was actually making the mistake of issuing
"TimerEvent::insert(rel_timeout)`, meaning they'd also misunderstood the
documentation, and were not getting the timeout they expected.
(Chrono would have prevented that mistake as durations and time points
are incompatible types).
The supported erase types of a given flash region are indicated
in bitfields of the variable `type_mask`. Even if an erase type
is unused for the current chunk (e.g. size too large, unaligned, etc.),
its bitfield should NOT be cleared - the same erase type might
actually be useful for the next chunk.
The function argument is now a value instead of a reference.
Aside from the core mbed-os CMake target, a number of targets have been created so they can optionally be included by application executables that require them using `target_link_libraries()`.
Co-authored-by: Martin Kojtal <martin.kojtal@arm.com>
Co-authored-by: Rajkumar Kanagaraj <rajkumar.kanagaraj@arm.com>
sfdp_find_addr_region() was causing issues with SPI
flashes with sector table parsed from SFDP (in
particular SST26VF016B).
In particular, it was returning -1 when address 0 is
passed (probably also if the address in the first
region). I do not know why the search algorithm is
written to search from the higher to lower regions,
but it was obvious that it would fail for the first
region. Also it was harder to read due to the index
manipulation.
Chrono changes "optimised" `Timeout::handler` in a way that broke users
who rescheduled the timeout during their attached callback.
Attempted optimisation is less necessary now that
`platform.callback-nontrivial` is set to false by default - that
setting reduces overhead of copying the `Callback` to almost nothing.