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.
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>