For travis tests, we host pre-built bundles of the arm-gcc and sdcc
toolchains on github, and we download them with curl
Apparently, the URL for those bundles has been changed and the
HTTP response is a 301 redirect. curl doesn't follow it
We change .travis.yml to pull the bundles form the new location
* Decouple 64-bit address from LINKADDR_SIZE
* get and set object from/to the start/end of the src/dest buffer
* We expect size == 8 (rather than size < 8) for both get_ and set_object. Error otherwise
* The RF no longer sets parameters by itself. We let the platform do this, using the extended API.
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'
