WSN Wiki

User Tools

Site Tools

You are here: Wireless Sensor Networks » Timers & Events in Contiki
lab12

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
lab12 [2019/01/11 08:52]
dan.tudose [The Event Timer] 		lab12 [2019/01/11 09:27] (current)
dan.tudose [Processes]
Line 2: Line 2:
  
 This tutorial will show how to make use of timers in Contiki. It will also give a basic into to events. This tutorial will show how to make use of timers in Contiki. It will also give a basic into to events.
-Contiki provides 3 kind of timers: 
-  * Unordered List ItemSimple timer: The timer library provides functions for setting, resetting and restarting timers, and for checking if a timer has expired. An application must "manually" check if its timers have expired, meaning that this library does not post an event when the timer expires, so we must implement a routine that checks the timer for expiration.  
-  * Unordered List ItemCallback timer: The callback timer library provides the same functions as above, but when the timer expires can callback a C function.  
-  * Unordered List ItemEvent timer: The same as above, with the difference that instead of calling a function, when the timer expires it post an event signalling the timer expiration.  
  
 +===== Processes =====
 +
 +All Contiki programs are processes. A process is a piece of code that is executed regularly by the Contiki system. Processes in Contiki are typically started when the system boots, or when a module that contains a process is loaded into the system. Processes run when something happens, such as a timer firing or an external event occurring.
 +
 +Code in Contiki can run in one of two execution contexts: cooperative or preemptive. Code running in the cooperative execution context is run sequentially with respect to other code in the cooperative context. Cooperative code must run to completion before other cooperatively scheduled code can run. Preemptive code may stop the cooperative code at any time. When preemptive code stops the cooperative code, the cooperative code will not be resumed until the preemptive code has completed. The concept of Contiki's two scheduling contexts is illustrated above.
 +
 +Processes always run in the cooperative context. The preemptive context is used by interrupt handlers in device drivers and by real-time tasks that have been scheduled for a specific deadline. 
 +
 +An example process that receives events and prints out their number:
 +<code C>
 + #include "contiki.h"
 + 
 + PROCESS(example_process, "Example process");
 + AUTOSTART_PROCESSES(&example_process);
 + 
 + PROCESS_THREAD(example_process, ev, data)
 + {
 +   PROCESS_BEGIN();
 + 
 +   while(1) {
 +     PROCESS_WAIT_EVENT();
 +     printf("Got event number %d\n", ev);
 +   }
 + 
 +   PROCESS_END();
 + }
 +</code>
 +
 +The complete reference on Contiki processes can be found [[https://github.com/contiki-os/contiki/wiki/Processes|here]].
 +
 +Contiki provides three kinds of timers:
 +  * **Simple timer:** The timer library provides functions for setting, resetting and restarting timers, and for checking if a timer has expired. An application must "manually" check if its timers have expired, meaning that this library does not post an event when the timer expires, so we must implement a routine that checks the timer for expiration. 
 +  * **Callback timer:** The callback timer library provides the same functions as above, but when the timer expires can callback a C function. 
 +  * **Event timer:** The same as above, with the difference that instead of calling a function, when the timer expires it post an event signalling the timer expiration. 
 +
 +More information on timer can be found on the Contiki's [[https://github.com/contiki-os/contiki/wiki/Timers|wiki page on timers]].
 ===== The Event Timer ===== ===== The Event Timer =====
  
Line 40: Line 72:
 But when waiting for this event in this way -- all other events will be ignored so the first approach is more flexible as this will enable handling multiple types of events more easily. But when waiting for this event in this way -- all other events will be ignored so the first approach is more flexible as this will enable handling multiple types of events more easily.
  
-<note>**Task 1:** Write a new test example for the Sparrow node (ideally place it in ///contiki/platform/sparrow/tests//) and define an event timer that expires once every second. At expiration, toggle on or off one of the LEDs. Use the LED driver written in //../dev/leds.h//</note>+<note>**Task 1:** Write a new test example for the Sparrow node (ideally place it in ///contiki/platform/sparrow/tests//) and define an event timer that expires once every second. At expiration, toggle on or off one of the LEDs. Use the LED driver written in //contiki/core/dev/leds.h//</note> 
 + 
 +<note>**Task 2:** Modify the test example to include two processes. First process, named read_temperature will read the node's temperature every 5 seconds. For the temperature sensor, please refer to the driver in //contiki/platform/sparrow/dev/temperature-sensor.h//. The second process called collect_all will display the temperature sampled by the first process and turn on an LED if it exceeds a preset threshold.</note>
  
  
lab12.1547189558.txt.gz · Last modified: 2019/01/11 08:52 by dan.tudose

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial 4.0 International
CC Attribution-Noncommercial 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki