Hochschule für Technik und Wirtschaft Dresden - Contiki-OSwiki_sn/images/9/91/Master... · 2016....
Transcript of Hochschule für Technik und Wirtschaft Dresden - Contiki-OSwiki_sn/images/9/91/Master... · 2016....
Contiki-OS
Angelos Drossos Hermann Lorenz
Hochschule für Technik und Wirtschaft DresdenMaster Angewandte Informationstechnologien
Sensornetze
26. November 2012
Übersicht
Einführung in Contiki
ImplementationsaspekteTheorieProtothreadsInterprozess-KommunikationBeispielprojekt
MAC-ImplementierungNet Stack LayersAufgaben und ImplementationenNachrichtenaustausch
Dynamic Module LoadingAnforderungen und UmsetzungenVom Empfang bis zur AusführungAusblick
Schlussbemerkungen
2/39
Was ist Contik-OS?
I Open-Source-Betriebssystem (3-Klausel-BSD-Lizenz)I für
I eingebettete, batteriebetriebene SystemeI Netzwerkgeräte
I bereits auf verschiedenste Hardwareplattformen portiert
»Open Source Operation System for the Internet of Things«
3/39
Was ist Contik-OS?
I Open-Source-Betriebssystem (3-Klausel-BSD-Lizenz)I für
I eingebettete, batteriebetriebene SystemeI Netzwerkgeräte
I bereits auf verschiedenste Hardwareplattformen portiert
»Open Source Operation System for the Internet of Things«
3/39
Welche Funktionalität bietet Contiki?
I Netzwerkunterstützung: UDP, TCP, HTTP, 6LoWPAN,RimeStack, RPL, CoAP
I ProtothreadsI Speicherverwaltung:
I memory block allocation (memb)I managed memory allocator (mmem)
I Dateisystem: CoUee Wash Vle system (CFS)I Programme zur Laufzeit nachladen→ »Dynamic Module
Loading«I Tools:
I Netzwerk-Simulation durch den Cooja SimulatorI Überwachung des Energieverbrauchs (EnergEst-Modul)
4/39
Wie ist Contiki aufgebaut?
Applikationen
ServicesWebserver FTP Telnet . . . eigene
KernProcess Timer Netzwerk ELF-Loader . . .
TreiberPlattform CPU
Tools
5/39
Übersicht
Einführung in Contiki
ImplementationsaspekteTheorieProtothreadsInterprozess-KommunikationBeispielprojekt
MAC-ImplementierungNet Stack LayersAufgaben und ImplementationenNachrichtenaustausch
Dynamic Module LoadingAnforderungen und UmsetzungenVom Empfang bis zur AusführungAusblick
Schlussbemerkungen
6/39
TheorieAnforderungen
Strom Knoten sollen Jahre mit einer Batterieauskommen
Speicher nur wenige KB RAM
Programmierung einfache ProgrammierungNetzwerkprotokolle sind kontrollWuss- und nichtzustandsorientiert
7/39
TheorieSystemarchitekturen
ereignisgesteuertnur ein Stack→ geringer Speicherbedarf
Programmierung als Zustandsmaschine notwendig
threadorientiertintuitivere Programmierung, keine Zustandsmaschinennotwendig
hohe Speicherreservierung je Thread
8/39
ProtothreadsUmsetzung der Makros (schematisch)
QuellcodePROCESS_THREAD(xyz){
int i = 0;PROCESS_BEGIN();
do_something();PROCESS_WAIT();
do_something_else();PROCESS_END();
}
ausgewertete DeVnesint process_xyz(int marke){
int i = 0;switch(marke){case 0:
do_something();return 123;
case 123:do_something_else();return PROCESS_DONE;
}}
CPU-Abgabe return mit nächster SprungmarkeCPU-Zuweisung Funktionsaufruf mit Sprungmarke
I lokale Variablen verlieren Werte beiKontextwechsel
I globale Variablen oder static nutzen
9/39
ProtothreadsUmsetzung der Makros (schematisch)
QuellcodePROCESS_THREAD(xyz){
int i = 0;PROCESS_BEGIN();
do_something();PROCESS_WAIT();
do_something_else();PROCESS_END();
}
ausgewertete DeVnesint process_xyz(int marke){
int i = 0;switch(marke){case 0:
do_something();return 123;
case 123:do_something_else();return PROCESS_DONE;
}}
CPU-Abgabe return mit nächster SprungmarkeCPU-Zuweisung Funktionsaufruf mit Sprungmarke
I lokale Variablen verlieren Werte beiKontextwechsel
I globale Variablen oder static nutzen
9/39
ProtothreadsUmsetzung der Makros (schematisch)
QuellcodePROCESS_THREAD(xyz){
int i = 0;PROCESS_BEGIN();
do_something();PROCESS_WAIT();
do_something_else();PROCESS_END();
}
ausgewertete DeVnesint process_xyz(int marke){
int i = 0;switch(marke){case 0:
do_something();return 123;
case 123:do_something_else();return PROCESS_DONE;
}}
CPU-Abgabe return mit nächster SprungmarkeCPU-Zuweisung Funktionsaufruf mit Sprungmarke
I lokale Variablen verlieren Werte beiKontextwechsel
I globale Variablen oder static nutzen9/39
Prozesse und Protothreads
Prozess ist einzelner Protothread
Protothread I leichtgewichtiger ThreadI kein eigener StackI kooperatives Multitasking
wait Protothread gibt Kontrolle ab, bis Eventeintritt
yield Protothread gibt Kontrolle abI keine direkte Switchanweisung
10/39
Kommunikation zwischen ProzessenEvents und Polling
Event Signal an einen Prozess in die Event Queue einordnen
Event-Queue. . .
Prozess A
Prozess B Prozess C
process_post(prozessC)
process_post_synch(prozessC)
Poll I jeder Prozess besitzt Polling FlagI vor der Event Queue werden alle Polling Flags geprüftI bei gesetzten Polling Flag wird der Polling Handler
ausgeführt
11/39
Kommunikation zwischen ProzessenEvents und Polling
Event Signal an einen Prozess in die Event Queue einordnen
Event-Queue. . .
Prozess A
Prozess B Prozess C
process_post(prozessC)
process_post_synch(prozessC)
Poll I jeder Prozess besitzt Polling FlagI vor der Event Queue werden alle Polling Flags geprüftI bei gesetzten Polling Flag wird der Polling Handler
ausgeführt
11/39
Kommunikation zwischen ProzessenEvents und Polling
Event Signal an einen Prozess in die Event Queue einordnen
Event-Queue. . .
Prozess A
Prozess B Prozess C
process_post(prozessC)
process_post_synch(prozessC)
Poll I jeder Prozess besitzt Polling FlagI vor der Event Queue werden alle Polling Flags geprüftI bei gesetzten Polling Flag wird der Polling Handler
ausgeführt
11/39
Kommunikation zwischen ProzessenEvents und Polling
Event Signal an einen Prozess in die Event Queue einordnen
Event-Queue. . .
Prozess A
Prozess B
Prozess C
process_post(prozessC)
process_post_synch(prozessC)
Poll I jeder Prozess besitzt Polling FlagI vor der Event Queue werden alle Polling Flags geprüftI bei gesetzten Polling Flag wird der Polling Handler
ausgeführt
11/39
Kommunikation zwischen ProzessenEvents und Polling
Event Signal an einen Prozess in die Event Queue einordnen
Event-Queue. . .
Prozess A
Prozess B Prozess C
process_post(prozessC)
process_post_synch(prozessC)
Poll I jeder Prozess besitzt Polling FlagI vor der Event Queue werden alle Polling Flags geprüftI bei gesetzten Polling Flag wird der Polling Handler
ausgeführt
11/39
Kommunikation zwischen ProzessenEvents und Polling
Event Signal an einen Prozess in die Event Queue einordnen
Event-Queue. . .
Prozess A
Prozess B Prozess C
process_post(prozessC)
process_post_synch(prozessC)
Poll I jeder Prozess besitzt Polling FlagI vor der Event Queue werden alle Polling Flags geprüftI bei gesetzten Polling Flag wird der Polling Handler
ausgeführt
11/39
Kommunikation zwischen ProzessenEvents und Polling im Einsatz
Event-Queue. . .
Prozess A
Prozess A Polling-Handler
ISR
process_poll(prozessA)
process_post(prozessA)
12/39
Kommunikation zwischen ProzessenEvents und Polling im Einsatz
Event-Queue. . .
Prozess A
Prozess A Polling-Handler
ISR
process_poll(prozessA)
process_post(prozessA)
12/39
Kommunikation zwischen ProzessenEvents und Polling im Einsatz
Event-Queue. . .
Prozess A
Prozess A Polling-Handler
ISR
process_poll(prozessA)
process_post(prozessA)
12/39
Kommunikation zwischen ProzessenEvents und Polling im Einsatz
Event-Queue. . .
Prozess A
Prozess A Polling-Handler
ISR
process_poll(prozessA)
process_post(prozessA)
12/39
Kommunikation zwischen ProzessenSemaphore und Protosockets
Semaphore zur Synchronisation der ProtothreadsI PT_SEM_INIT(s, c)I PT_SEM_WAIT(pt, c)I PT_SEM_SIGNAL(pt, c)
Protosockets ZugriU auf das uIP-Interface, analog zu BSD-SocketsI PSOCK_INIT(. . . )I PSOCK_SEND_STR(. . . )I PSOCK_READBUF(. . . )I . . .
13/39
Beispielprojekt
RepositoryI klonen
git clone https://github.com/contiki-os/contiki
I anpassenI contiki/cpu/avr/Makefile.avr
I avrdude → sudo avrdude
I platform/avr-atmegarfa1/Makefile.avr-atmegarfa1I AVRDUDE_PROGRAMMER=jtag2 → dragon_jtagI AVRDUDE_PORT=usb:00B000000D79 → usb
ProjektI Projektverzeichnis erstellen
mkdir -p project/hellosworld
I Bibliotheken des Sensorterminalboards kopierenconfig.h, usb.c, usb.h, io_access.c, io_access.h
und io_access_ext.h
14/39
Beispielprojekthellosworld.c
hellosworld.c#include "contiki.h"#include "usb.h"#include <string.h>
/*-------------------------------------------------------*/PROCESS(hellosworld_process, "HeLLo’s World process");AUTOSTART_PROCESSES(&hellosworld_process);/*-------------------------------------------------------*/PROCESS_THREAD(hellosworld_process, ev, data){
char * str = "HeLLo’s World!\n";int i;PROCESS_BEGIN();
usb_init();for(i = 0; i < strlen(str); ++i)
usb_putc_std(str[i], stdout);
PROCESS_END();}/*-------------------------------------------------------*/
15/39
BeispielprojektMakeVle
MakeVleCONTIKI_PROJECT = hellosworldCONTIKI_SOURCEFILES += io_access.c usb.cTARGET = avr-atmega128rfa1
all: $(CONTIKI_PROJECT)
program: $(CONTIKI_PROJECT).$(TARGET).u.PHONY: program
CONTIKI = ../..include $(CONTIKI)/Makefile.include
Verzeichnisbaum
contiki
project
hellosworld
config.c
hellosworld.c
io_access.c
io_access.h
io_access_ext.h
usb.c
usb.h
Makefile
Makefile.include
I make program
16/39
Übersicht
Einführung in Contiki
ImplementationsaspekteTheorieProtothreadsInterprozess-KommunikationBeispielprojekt
MAC-ImplementierungNet Stack LayersAufgaben und ImplementationenNachrichtenaustausch
Dynamic Module LoadingAnforderungen und UmsetzungenVom Empfang bis zur AusführungAusblick
Schlussbemerkungen
17/39
Contiki Net Stack layersDer Aufbau
1. Radio (Hardware)
2. Radio Duty Cycling (RDC)
3. Framer
4. Medium Access Control (MAC)
5. Network
18/39
Contiki Net Stack layersDie KonVguration
core/net/netstack.hextern const struct network_driver NETSTACK_NETWORK;extern const struct rdc_driver NETSTACK_RDC;extern const struct mac_driver NETSTACK_MAC;extern const struct radio_driver NETSTACK_RADIO;extern const struct framer NETSTACK_FRAMER;
contiki-conf.h (Platform, Projekt)#define NETSTACK_CONF_MAC nullmac_driver#define NETSTACK_CONF_RDC sicslowmac_driver#define NETSTACK_CONF_FRAMER framer_802154#define NETSTACK_CONF_RADIO rf230_driver#define NETSTACK_CONF_NETWORK sicslowpan_driver
19/39
Contiki Net Stack layersDie KonVguration
core/net/netstack.hextern const struct network_driver NETSTACK_NETWORK;extern const struct rdc_driver NETSTACK_RDC;extern const struct mac_driver NETSTACK_MAC;extern const struct radio_driver NETSTACK_RADIO;extern const struct framer NETSTACK_FRAMER;
contiki-conf.h (Platform, Projekt)#define NETSTACK_CONF_MAC nullmac_driver#define NETSTACK_CONF_RDC sicslowmac_driver#define NETSTACK_CONF_FRAMER framer_802154#define NETSTACK_CONF_RADIO rf230_driver#define NETSTACK_CONF_NETWORK sicslowpan_driver
19/39
Radio – layerAufgaben und Implementationen
AufgabenI Kommunikation mit dem FunksensorI CPU-abhängige ImplementationI Bestimmte Funktionalität auf die Hardware umlegen
(Auto-ACK)
Implementationen (CPU)I NullRadioI rf230 (AVR)I cc2430_rf (cc2430)I cc2530_rf (cc253x)I stm32w (stm32w108)I Contiki MACA (mc1322x)
20/39
Network – layerAufgaben und Implementationen
AufgabenI Schnittstelle zu den Applikationen (Empfangen und Versenden
von Nachrichten)I Interagiert mit dem MAC–layer
ImplementationenI RIMEI SicsLowPAN
21/39
Radio Duty Cycling – layerAufgaben und Implementationen
AufgabenI schaltet den Radio Transceiver so oft wie möglich ausI sorgt damit für energie-eXzientes Arbeiten
ImplementationenI ContikiMAC (Low-Power-Listening, LPL)I LPP (Low-Power Probing)I X-MACI CX-MAC (Compatiblity X-MAC)I SicsLowMAC (no Radio Cycling)I NullRDC (no Radio Cycling)I NullRDC No Framer (no Radio Cycling)
22/39
Framer – layerAufgaben und Implementationen
AufgabenI Erzeugen von Frames zum VersendenI Parsen von Frames beim EmpfangenI Wird vom RDC–layer aufgerufen und legt die bearbeiteten
Frames in einen Packet-BuUer
ImplementationenI Framer 802.15.4I Framer NullMAC
23/39
MAC – layerAufgaben und Implementationen
AufgabenI empfängt eingehende Packete vom RDC layerI benutzt den RDC layer, um Packete zu versendenI sorgt dafür, dass Packete erneut gesendet werden, sofern der
RDC layer eine Kollision detektiert hat
ImplementationenI CSMA (Carrier Sense Multiple Access)I TDMA (Time Division Multiple Access)I CTDMA (Carrier / Time Division Multiple Access)I RIME UDPI NullMACI SicsLowMAC (AVR, nutzt nicht RDC-Protokoll)
24/39
NachrichtenaustauschEintreUende Nachricht
Network
RDC
MAC
input
input
input
Nachricht
Framerparse
ISR
input
Radio
PacketBuUer
APP
Callback / TCP/IP
25/39
NachrichtenaustauschAusgehende Nachricht (TCP/IP)
Network
RDC
MAC sendpacket
Nachricht
Framercreate
ISR
Radio
PacketBuUer
APP
packetsent
outputTCP/IP
set outputtcpip output
sendpacket
sendpacket ?
outputCallback
26/39
NachrichtenaustauschAusgehende Nachricht (RIME)
NetworkRIME
RDC
MAC sendpacket
Nachricht
Framercreate
ISR
Radio
PacketBuUer
APP
packetsent
rimeoutput
abc send
sendpacket
sendpacket ?
recvCallback
RIMEabc
abc sent
27/39
Übersicht
Einführung in Contiki
ImplementationsaspekteTheorieProtothreadsInterprozess-KommunikationBeispielprojekt
MAC-ImplementierungNet Stack LayersAufgaben und ImplementationenNachrichtenaustausch
Dynamic Module LoadingAnforderungen und UmsetzungenVom Empfang bis zur AusführungAusblick
Schlussbemerkungen
28/39
Dynamic Module LoadingEinführung
AnwendungI an schwer zugänglichen Orten (Daten sammeln, extern
auswerten, Software anpassen)I Korrektur von SoftwarefehlernI Schließen von SicherheitslückenI Erweiterung der Funktionalität: spezielle Applikationen
situationsbedingt (temporär) ausführen
ProblemstellungI genügend Speicher zum Zwischenspeichern des »Programms«I energieaufwändige Übertragung (Verkürzung der
Batterielaufzeit)
LösungeXzientes Verteilen der neuen »Softwareversion«
29/39
Dynamic Module LoadingEinführung
AnwendungI an schwer zugänglichen Orten (Daten sammeln, extern
auswerten, Software anpassen)I Korrektur von SoftwarefehlernI Schließen von SicherheitslückenI Erweiterung der Funktionalität: spezielle Applikationen
situationsbedingt (temporär) ausführen
ProblemstellungI genügend Speicher zum Zwischenspeichern des »Programms«I energieaufwändige Übertragung (Verkürzung der
Batterielaufzeit)
LösungeXzientes Verteilen der neuen »Softwareversion«
29/39
Dynamic Module LoadingEinführung
AnwendungI an schwer zugänglichen Orten (Daten sammeln, extern
auswerten, Software anpassen)I Korrektur von SoftwarefehlernI Schließen von SicherheitslückenI Erweiterung der Funktionalität: spezielle Applikationen
situationsbedingt (temporär) ausführen
ProblemstellungI genügend Speicher zum Zwischenspeichern des »Programms«I energieaufwändige Übertragung (Verkürzung der
Batterielaufzeit)
LösungeXzientes Verteilen der neuen »Softwareversion«
29/39
Dynamic Module LoadingAnforderungen
AnforderungenI Das ganze System ist austauschbar.I Nur ein Modul ist zur Laufzeit nachzuladbar und ausführbar.I Wenn ein kleiner Codeabschnitt geändert werden soll, dann
soll nicht das komplette System neu aufgespielt werden.I niedriger Energieverbrauch sowohl bei der Übertragung als
auch Ausführung
Methoden der UmsetzungI Full-Image ReplacementI DiUerential Image ReplacementI Virtual MachinesI Dynamic Operation Systems
30/39
Dynamic Module LoadingAnforderungen
AnforderungenI Das ganze System ist austauschbar.I Nur ein Modul ist zur Laufzeit nachzuladbar und ausführbar.I Wenn ein kleiner Codeabschnitt geändert werden soll, dann
soll nicht das komplette System neu aufgespielt werden.I niedriger Energieverbrauch sowohl bei der Übertragung als
auch Ausführung
Methoden der UmsetzungI Full-Image ReplacementI DiUerential Image ReplacementI Virtual MachinesI Dynamic Operation Systems
30/39
Dynamic Module LoadingUmsetzungsarten
Methoden der UmsetzungI Full-Image ReplacementI DiUerential Image ReplacementI Virtual MachinesI Dynamic Operation Systems
Lösungen in bekannten BetriebssystemenI TinyOSI SOS (Weiterentwicklung 2008 eingestellt)I Contiki-OS
31/39
Dynamic Module LoadingVom Empfang bis zur Ausführung des Moduls
Schritte vom Empfang bis zur Ausführung1. Empfangen
2. EEPROM beschreiben
3. »Link & Relocation«
4. Flash ROM beschreiben
⇒ Das Programm ist ausführbar.
Technologien im ContikiI ELFI CELF (compact ELF)I Java Virtual MachineI CVM (Contiki Virtual Machine)I (und weitere)
32/39
Dynamic Module LoadingVom Empfang bis zur Ausführung des Moduls
Schritte vom Empfang bis zur Ausführung1. Empfangen
2. EEPROM beschreiben
3. »Link & Relocation«
4. Flash ROM beschreiben
⇒ Das Programm ist ausführbar.
Technologien im ContikiI ELFI CELF (compact ELF)I Java Virtual MachineI CVM (Contiki Virtual Machine)I (und weitere)
32/39
Dynamic Module LoadingVom Empfang bis zur Ausführung des Moduls
Notwendige Schritte in den verschiedenen Technologien
ELF CELF Java VM CVM
Empfangen ! ! ! !
EEPROM beschreiben ! !
Link & Relocation ! !
Flash ROM beschreiben ! ! !
Energie-Verbrauch [mJ]
ELF CELF Java VM CVM
Empfangen 29 12 22 2EEPROM beschreiben 2 1Link & Relocation 3 3Flash ROM beschreiben 1 1 5
33/39
Dynamic Module LoadingVom Empfang bis zur Ausführung des Moduls
Notwendige Schritte in den verschiedenen Technologien
ELF CELF Java VM CVM
Empfangen ! ! ! !
EEPROM beschreiben ! !
Link & Relocation ! !
Flash ROM beschreiben ! ! !
Energie-Verbrauch [mJ]
ELF CELF Java VM CVM
Empfangen 29 12 22 2EEPROM beschreiben 2 1Link & Relocation 3 3Flash ROM beschreiben 1 1 5
33/39
Dynamic Module LoadingVom Empfang bis zur Ausführung des Moduls
Ausführungszeit (einfaches Programm)
Native Java VM CVM
Ausführungszeit [ms] 0.479 1.79 0.845Energieverbrauch [µJ] 0.54 2.0 0.95
Energieverbrauch [µJ] 36 000 27 000 2 000bei der Übertragung
Ausführungszeit (komplexes Programm)
Native Java VM CVM
Ausführungszeit [ms] 0.67 65.6 58.52Energieverbrauch [µJ] 0.75 73 65
34/39
Dynamic Module LoadingVom Empfang bis zur Ausführung des Moduls
Ausführungszeit (einfaches Programm)
Native Java VM CVM
Ausführungszeit [ms] 0.479 1.79 0.845Energieverbrauch [µJ] 0.54 2.0 0.95
Energieverbrauch [µJ] 36 000 27 000 2 000bei der Übertragung
Ausführungszeit (komplexes Programm)
Native Java VM CVM
Ausführungszeit [ms] 0.67 65.6 58.52Energieverbrauch [µJ] 0.75 73 65
34/39
Dynamic Module LoadingAusblick
FazitI Optimale Lösung kommt auf den Anwendungsfall an.I Virtual Machines haben ihren Reiz bei der Übertragung, aber
DeVzite bei der AusführungI Virtual Machine Code kann nicht auf Hardware-nahe
Funktionen zugreifen: Es sind native Schnittstellen erforderlich.
Dynamic Module Loading in der HausautomatisierungI Application ReconVguration ist eine mögliche AnwendungI Sicherheit ist ein Problem: z.B. ManipulationenI für Entwicklungsumgebungen sinnvollI in der Praxis i.d.R. zu hoher Energieverbrauch
35/39
Dynamic Module LoadingAusblick
FazitI Optimale Lösung kommt auf den Anwendungsfall an.I Virtual Machines haben ihren Reiz bei der Übertragung, aber
DeVzite bei der AusführungI Virtual Machine Code kann nicht auf Hardware-nahe
Funktionen zugreifen: Es sind native Schnittstellen erforderlich.
Dynamic Module Loading in der HausautomatisierungI Application ReconVguration ist eine mögliche AnwendungI Sicherheit ist ein Problem: z.B. ManipulationenI für Entwicklungsumgebungen sinnvollI in der Praxis i.d.R. zu hoher Energieverbrauch
35/39
Übersicht
Einführung in Contiki
ImplementationsaspekteTheorieProtothreadsInterprozess-KommunikationBeispielprojekt
MAC-ImplementierungNet Stack LayersAufgaben und ImplementationenNachrichtenaustausch
Dynamic Module LoadingAnforderungen und UmsetzungenVom Empfang bis zur AusführungAusblick
Schlussbemerkungen
36/39
Schlussbemerkungen
I die Implementierung von Contiki ist sehr verwobenI die Programmierung für Contiki ist recht elegantI der Dokumentation fehlen Einführungen für das
SystemverständnisI die Netzwerk-Anbindung ist gut ausgebautI die Funktionalität im Net Stack sind klar getrenntI die praktischen Einsatzmöglichkeiten des Dynamic Module
Loading ist in Sensornetzen beschränkt
37/39
Ausblick
I Net Stack: Security–layer (ContikiSec)I Sleep Modi einbauenI Debug-System (bisher nur als Macro pro Datei)I Echtzeit-Eigenschaften
38/39
Ausgewählte Quellen
Farooq, O. M. & Kunz, T.: Operating Systems for Wireless SensorNetworks: A Survey,www.mdpi.com/1424-8220/11/6/5900/pdf, 2011
Strübe, Jan Moritz: Dynamische Re-Programmierung vonSensorknoten zur Laufzeit,strübe.de/wp-content/uploads/2008/08/da.pdf,Diplomarbeit, 2008
Dunkels, Adam et al.: Run-Time Dynamic Linking forReprogramming Wireless Sensor Networksdunkels.com/adam/dunkels06runtime.pdf, 2006
39/39