cc2538: clock: Request an etimer poll in clock_adjust()

During PM1+, the hardware timer used to implement the Contiki clock is frozen,
so clock_adjust() needs to be called when exiting those modes in order to
compensate for the clock ticks missed while the timer was frozen. Doing so
changes the Contiki clock time, so etimer_request_poll() needs to be called in
order to inform the etimer library that an etimer might have expired.

Note that waiting for the next clock ISR to call etimer_request_poll() is
unreliable because the system might go back to sleep beforehand.

Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
cc2538: clock: Fix secs update in clock_adjust()

Whole elapsed seconds are added to secs first, so only the remaining subsecond
ticks should then be subtracted from second_countdown in order to decide whether
secs should be incremented again.

Otherwise, secs is not correctly updated in some cases, typically if the bit 7
of ticks is 1. E.g., with ticks = 128 (i.e. exactly 1 s elapsed) and
second_countdown = 128, secs was first incremented as expected, then 128 was
subtracted from second_countdown, giving 0 and triggering an unwanted second
increment of secs. Or with ticks = 129 (i.e. 1 s + 1 tick) and
second_countdown = 1, secs was first incremented as expected, then 129 was
subtracted from second_countdown, giving 128 and missing a second increment of
secs that should have occurred because second_countdown wrapped around.

Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
cc2538: clock: Fix time drift occurring with PM1/2

The clock adjustments made when waking up from PM1/2 were very inaccurate. If
relying on ContikiMAC's rtimer to sleep, this led to Contiki's software clock
time, seconds and etimers to be 2.5 s slower after each min, i.e. 1 hour slower
after each day, which is a show stopper issue for most real-life applications.

This was caused by a lack of accuracy in several pieces of code during sleep
entry and wake-up:
 - It was difficult to synchronize the calls to RTIMER_NOW() before and after
   sleep with the deactivation and activation of the SysTick peripheral caused
   by PM1/2. This caused an inaccuracy in the corrective number of ticks passed
   to clock_adjust().
 - The value passed to clock_adjust() was truncated from an rtimer_clock_t
   value, but the accumulated error caused by these truncated bits was ignored.
 - The SysTick peripheral had to be stopped during the call to clock_adjust().

Rather than creating even more complicated clock adjustment mechanisms that
would probably still have mixed results as to accuracy, this change simply uses
the Sleep Timer counter as a base value for Contiki's clock and seconds
counters. The tick from the Systick peripheral is still used as the interrupt
source to update Contiki's clocks and timers. When running, the SysTick
peripheral and the Sleep Timer are synchronized, so combining both is not an
issue, and this allows not to alter the rtimer interrupt mechanism using the
Sleep Timer. The purpose of the Sleep Timer is to be an RTC, so it is the
perfect fit for the clock module, all the more it can not be disturbed by PM1/2.
If the 32-kHz XOSC is used, the Sleep Timer is also very accurate. If the
32-kHZ RCOSC is used, it is calibrated from the 32-MHz XOSC, so it is also
accurate, and the 32753-Hz vs. 32768-Hz systematic error in that case is
negligible, all the more one would use the 32-kHz XOSC for better accuracy.

Besides fixing this time drift issue, this change has several benefits:
 - clock_time(), clock_seconds() and RTIMER_NOW() start synchronized, and they
   change at the same source pace.
 - If clock_set_seconds() is called, then clock_seconds() indicates one more
   second almost exactly one second later, then exactly each second. Before this
   change, clock_seconds() was not synchronized with clock_set_seconds(), so the
   value returned by the former could be incremented immediately after the call
   to the latter in some cases.
 - The code tied to the clock module is simpler and more robust.

Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
cc2538: Add adc driver and example

Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
leds: Fix the API

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>
leds: Add the leds_set() function

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>
Make the period for the uip-ds6 periodic task configurable
Cooja: allow setting RSSI while sending and silence

It is now possible to set the RSSI while the radio is sending or when
no radiodata is received. This is now supported by all radiomediums
exept MRM. This also includes a GUI to configure the values.
typo in event resource handler comment

at line 531 says PERIODIC_RESOURCE, shouldn't it be EVENT_RESOURCE, since it's a EVENT_RESOURCE demo?
New MACRO for creating jsontree_array

This proposed MACRO simplifies jsontree_array declarations. It takes as arguments the name of the array and its size. ( I've modified the indention as requested )
cc2538: Support any UART baudrate.
native: Add CTK to the module list

It is needed for apps compiled WITH_GUI.
Merge pull request #603 from mmuman/native-platform-ctk-module

native: Add CTK to the module list
Fix rounding error in baudrate calculation.
Change uart_set_baudrate() to a do-while statement.
Eliminate UART_CONF_IBRD and UART_CONF_FBRD.
Bugfix: when a packet is sent by the RDC layer, we should count the number of transmissions made because a single callback can pertain to multiple transmissions at the RDC layer.
The UDP socket API code
The TCP socket API code
Fix CPU clock calibration in msp430f2xxx based platforms (e.g. Zolertia Z1).

The following problems were present in the existing DCO calibration algorithm:

Problem #1. In function msp430_quick_synch_dco(), the "for(i=0; i < 1000; i++) { .. }" loop is optimized away by the compiler, as i is not volatile. Making i volatile would improve the results, but would not be sufficient: see the next point.

Problem #2. According to MSP430F2617 Device Erratasheet, bug BCL12 precludes a naive implementations of "fast" calibration altogether. The bug is present on all MCU revisions up to date.

The description of the bug:
"After switching RSELx bits (located in register BCSCTL1) from a value of >13 to a value of <12 OR from a value of <12 to a value of >13, the resulting clock delivered by the DCO can stop before the new clock frequency is applied. This dead time is approximately 20 us. In some instances, the DCO may completely stop, requiring a power cycle.

Furthermore, if all of the RSELx bits in the BSCTL1 register are set, modifying the DCOCTL register to change the DCOx or the MODx bits could also result in DCO dead time or DCO hang up."

In Contiki code for msp430f2xxx @ 8MHz, the RSEL search currently typically goes from 15 down to 11, thus violating the rules.

Step-by-step RSEL change is proposed as the best possible workaround:
"[..] more reliable method can be implemented by changing the RSEL bits step by step in order to guarantee safe function without any dead time of the DCO."

Problem #3. The old Contiki code started from the highest possible calibration values: RSEL=15, DCOx=7. According to MSP430F2617
datasheet, this means that the DCO frequency is set to 26 MHz. For one, Vcc under 3V is not supported for this frequency, so this means that battery-powered nodes have a big problem. The minimal operating voltages are:
- 1.8V for RSEL <= 13
- 2.2V for RSEL = 14
- 3.0V for RSEL = 15
So the correct way is to always start calibration from RSEL <= 13, unless explicityly pre-calibred values are present.

Problem #4. Timer B should be turned off after the calibration, following the "Principles for Low-Power Applications" in MSP430 user's Guide.

The patch fixes these issues by performing step-by-step calibration and turning off Timer B afterwards. As opposed to MSP430F1xxx calibration, this algorithm does not change the ACLK divider beforehand; attempts to make calibration more precise would lead to looping in some cases, as the calibration step granularity at larger frequencies is quite big.

Additionally, the patch improves DCOSYNCH_CONF_ENABLED behavior, allowing the resynchronization to correct for more than one step.