An odd bug (c0951c9) in the NCS36510 ticker code caused the timer/ticker
classes to become desynchronized. Updated the handling to not assume the
timers are perfectly in synch. This will increase the event's tolerance of
less robust platforms.
The NCS36510 is limited to 16bit timers. Construction of larger
intervals is performed in software by counting the number of 16bit
intervals that pass.
Either this counting takes a bit of time, or there is a math error
somewhere (maybe a long critical section?), because there is a
roughly ~1us delay between when the interrupt occurs and the ticker
progresses onto the next 16bit interval. This is normally a completely
reasonable error, except that the error accumulates. After a while,
the equeue tests find themselves with tens of milliseconds of error.
To make matters worse, this error is random because of other interrupts
occuring in the system, making the exact issue quite a bit difficult
to track down.
This fix drops the software counter in favor of just recalculating
the next delay interval from the target time and value of the running
timer. The running timer used to calculate the current tick is left to
overflow in hardware and doesn't have this drift.
For toolchains that do not implicitly run the C pre-processor on their
linker scripts the toolchain is expected to define a `preproc`
attribute. The Makefiles then pick up on this attribute and add another
rule for pre-processing the linker script automatically.
This allows us to define parts of the linker script outside of the
linker script itself. In particular, we are interested in restricting
ROM to a subsection.
The field device_name is intended to match that of a target in a
device family pack. Remove this field for devices which do not have
a pack. Fix the name for devices that have the name incorrect. Update
IAR definitions for device which no longer have a device_name but
still need to have support for the IAR exporter.
The worker_result variable was not guaranteed to have a `'result'` or
`'reason'` key and accessing them before testing for them could result
in an error when they are not provided. This patch changes the checks to
prevent check for their existence before accessing them.
With the RTOS, the STACK_SIZE specified here is unrelated to the stack
size available for the main thread (that runs pre_main). Save memory by
reducing the stack size to a more reasonable amount.
On uVisor, HEAP_SIZE is both a minimum available and maximum available
heap size. The heap can't grow beyond the end of the heap into the
neighboring stack. On all uVisor-supported platforms, guarantee at least
0x6000 bytes of heap space. This increases the portability of uVisor
applications as the memory available for legacy heap allocations is
guaranteed. This helps to avoid out of memory errors on platforms that
were previously guaranteeing less memory.