Adam Dunkels writes on 2/5/2017 on the Contiki mailing list:
[...] the original idea was that the application could just point the uip_appdata pointer to wherever the data was, but we then changed it so that the data actually had to be copied into the uip_aligned_buf buffer. So, yes, the network device driver should only need to read from this buffer. [...]
This change removes comments on the possibility of uip_appdata pointing somewhere outside the uip_aligned_buf. And it removes code in the SLIP drivers not necessary anymore.
Additionally it makes code in a SLIP driver optional that takes care of the Microsoft-specific CLIENT / SERVER / CLIENTSERVER chat.
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.
The leds_set() function is added on top of leds_arch_set() in order to have a
means of displaying a pattern on a set of LEDs, while keeping the ENERGEST
information up to date, which would be missing with a direct call to
leds_arch_set().
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
The leds API did not work in some cases. E.g. with the following sequence:
leds_off(LEDS_ALL);
leds_toggle(LEDS_GREEN);
leds_off(LEDS_ALL);
the green LED was remaining on after the last call.
This was caused by the toggle feature made synonymous with the invert feature,
although it is unrelated. leds_toggle() is indeed supposed to toggle an LED,
while leds_invert() is supposed to change the active level of an LED. However,
all users of leds_invert() actually meant leds_toggle(), and the invert feature
does not make sense in this module because it is not handy due to successive
calls to leds_invert() changing the intended behavior, and hardware active
levels should be managed in leds_arch_set() (e.g. by XORing the passed value
with a hardware-specific constant before setting the output levels of the pins).
Consequently, this change:
- removes the leds_invert() function,
- makes leds_toggle() behave as expected relatively to leds_off() / leds_on(),
- sanitizes the code in the leds module.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
The CCA-threshold now defaults to -46 which give better simulation
results and typically also better experimental results.
This adjustment is also needed due to commit 0a13f99 in mspsim. As
promised in https://github.com/mspsim/mspsim/pull/18 it broke the
regression tests.
This patch removes a defunct EEPROM implementation from the native
platform and provides a new EEPROM implementation for the native cpu.
The previous implementation appears to be vestigal.
This is useful for testing code which uses the EEPROM without running
the code on the actual hardware.
By default the code will create a new temporary file as the EEPROM
backing, reinitializing each time. If you would like to preserve the
EEPROM contents or specify a specific EEPROM file to use, you can set the
`CONTIKI_EEPROM` environment variable to the name of the EEPROM file you
wish to use instead. If it already exists, its contents will be used.
If it does not already exist, it will be created and initialized by
filling it with `0xFF`---just like a real EEPROM.
A new example is also included, which was used to verify the correctness
of the implementation. It can easily be used to verify the EEPROM
implementations of other targets.
