The type used to store rtimer ticks on this platform is 32-bit integer, but the macro uses 16-bit comparison.
As a result, the output of the RTIMER_CLOCK_LT(a,b) macro was incorrect when used for comparisons between time values with sufficiently large difference.
The code to repeat this problem on mbxxx platform:
rtimer_clock_t a = 6 * RTIMER_ARCH_SECOND;
rtimer_clock_t b = 0;
printf("%d\n", RTIMER_CLOCK_LT(a,b)); // expected output: "0", actual: "1"
This avoids the limitation of having a single UART available at runtime, without
duplicating code.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Because the CC2538 has a multi-byte SPI RX FIFO, flushing the buffer
requires more than just a single read. This adds a loop that empties the
entire RX buffer on a FLUSH().
Different SPI chips needs different SPI settings. This commit adds a
function that allows chip drivers to configure the SPI peripheral before
using it.
The frame pin the driver was using as a chip select does not work as
most devices expect it to. It toggles after every byte, and most chips
interpret that as end of message. To make drivers more reliable, each
chip driver should setup a GPIO and assert it as needed.
Currently the SPI driver in core/ sets `SPI_FLUSH()` to be a single read
of the spi RX buffer. This is fine for many microcontrollers, but newer
platforms like the CC2538 have a multi-byte FIFO for the RX buffer. In
that case, a single read is not guaranteed to flush the RX. This commit
allows `SPI_FLUSH()` to be platform dependent if needed, but doesn't
change for platforms where it works.
Setting the position based on the number
of total inner frames was very inflexible
and caused pad positioning for larger number
of frames.
Setting the location of new plugin frames
to the second last activated one tries to
meet two requirements:
- Avoid covering the last activated plugin frame,
i.e. the one that was active when new plugin
start was invoked.
- Set new plugin near an actively used desktop pane
location and allow 'diagonal stacking'
Contiki sometimes fails to boot correctly and locks up in
random_init()
This problem only manifests itself for specific versions
of the arm-gcc toolchain and then again only for specific
levels of optimisation (-Os vs -O2, depending on the
value of the SMALL make variable)
The lockup is caused when we write an RFCORE XREG before
the RF clock ungating has taken effect, which in turn
only occurs depending on the assembly generated for those
two instructions:
REG(SYS_CTRL_RCGCRFC) = 1;
REG(RFCORE_XREG_FRMCTRL0) = 0x00000008;
This commit makes the RNG wait for the ungating to take
effect before attempting to write the register
would create a header with the current packet information.
This allows sicslowpan to calculate the max payload size without
consuming a sequence number or clearing/restoring the packet buffer.
