Now there is a generic resource that can generate and parse
application/json as well as text/plain. It can be re-used, only the
from_string and to_string routines have to be written and the resource
properly set up. A new resource format is specified, see
GENERIC_RESOURCE in, e.g., examples/osd/pwm-example. This is now used in
all my examples, namely pwm-example, arduino-sketch, wallclock-time.
There was an off by one error for the month in time formatting (in
gmtime and localtime). And the leap-year computation was broken. Both
fixed now, so we get a correct date. For localtime we are still 2 hours
off because daylight saving isn't implemented yet.
Also renamed gmtime to utc.
Hardware init function profit a great deal from being inlined if the
given parameters are constant -- which is the common use-case, we could
probably call this for all timers and still have less overhead. The
hwtimer_pwm_ini (which calls hwtimer_ini) gets completely computed at
compile-time resulting only in the register settings of hwtimer_ini.
This is now possible because we get rid of static storage for the
max_ticks and instead compute this in hwtimer_pwm_max_ticks from the
timer register settings.
New discovery: Contiki also uses timer 0. With almost the same interface
as Arduino. So we now completely get rid of wiring.c (only the main
file, the other wiring_xxx stay) and implement Arduino timer, delay, etc
in terms of the corresponding Contiki routines. Verified that now delay
works as expected. The LED in examples/osd/arduino-sketch blinks!
Before this, the arduino_init routine in wiring.c destroyed the timer-0
initialization of contiki, making both, contiki timer implementation
*and* contiki timer implementation fail if the arduino_init routine was
called. Now both work.
Some platforms are missing timer channels, this is now left to the
(missing) preprocessor definitions on those platforms, no
platform-specific defines needed anymore.
Also fix usage of timer counter register 3 (hardcoded) in
cpu/avr/dev/clock.c -- this code isn't used on many platforms as it
requires a very special quartz clock frequency but this now also uses
the platform timer specification.
We can now directly compile arduino sketches (.pde) files.
Arduino compatible analogWrite works now.
But there is still a long way to go, serial I/O and timer stuff (delay,
millis etc) currently don't work (not tested but I don't expect this to
work).
It can be used in an arduino sketch or in a normal contiki program.
We get a PWM frequency of 490.2 Hz (a period of 2.040 ms), that's
Arduino compatible. If you need different frequencies see native timer
usage in examples/osd/pwm-example
In a contiki program you have to call arduino_pwm_timer_init to
initialize the timer before pwm works. The arduino sketch wrapper
already does this.
For running a sketch, see examples/osd/arduino-sketch
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 problem came from the fact that there two opposite macro (UIP_CONF_ROUTER) that could not activate the code responsible to send the PIO option in NDP.
In Neighbor Discovery Protocol, when IPv6 host adds a prefix (coming from PIO) but it is always failing whatever if is successfully add in prefix table. The reason comes from the fact that the function uip_ds6_prefix_add in host version always return NULL. This is opposite of the specification of the router version.
The next-hop address did not get updated in the routing table
in case an entry for the destination already existed.
This patch resolves the issue by removing the entry and
having it re-created from scratch.
The issue causes a routing error triggering reconstruction of
the DODAG through version increase.
In case of somewhat frequent downward traffic in not (yet) stabilized DODAG
a vicious circle is formed: unstable topology means churn, downward
routing under churn causes reconstruction of DODAG. In this situation
the network does not have chance to stabilize.
We encountered a constant churn caused by this bug
in a network of 50 nodes and a periodic traffic (a packet every 5
seconds) generated at the root.
More info and a PCAP demonstrating the issue can be found here:
https://github.com/contiki-os/contiki/issues/496
Made Ethernet drivers easier to consume by assembly programs.
* Replaced function pointers with JMP instructions.
* Provide return values additionally via Carry flag.
Reset Ethernet chips on initialization.
Both for the CS8900A and the W5100 the data sheets just say that
the RESET bit is automatically cleared after the RESET. This may
be interpreted in two ways:
1) There's no need to be afraid of reading the RESET bit as 1 and
unintentionally trigger a RESET by writing it back after ORing in
some other bit.
2) The RESET process isn't complete before the RESET bit hasn't
become 0 again.
It's impossible for me to empirically falsify the latter option
as the drivers are supposed to work on faster machines than the
ones I have access to. And if the RESET process includes things
like oscillators then the time to complete the RESET could differ
even between multiple exemplars of the same chip. Therefore I
opted to presume the latter option.
However that means a non-exsistent chip may cause an infinite
loop while waiting for the RESET bit to be cleared so I finally
added code to detect the presence of the Ethernet chips. There's
a risk of a chip being locked up in a way that makes the detection
fail - and therefore the RESET not being performed. This catch-22
needs to be solved by the user doing a hard RESET.
type process_data_t. This was an artifact when the choice was
made to use the void * type for the data parameter in processes.
Changed parameter 'void * data' of process_post_synch to
process_data_t for consistency.
Checked all the uses of process_start() in contiki and fixed casts
of the data parameter.
Some calls to `rpl_set_root` select a hardcoded DODAG ID
(0x1111, 0x1100, 0, 0, 0, 0, 0, 0x0011)
This is against what RFC 6550 says. We change these calls
to select a DODAG ID corresponding to a routable v6 address
corresponding to the root
