For the Real-âTime Internet of Things
Transcription
For the Real-âTime Internet of Things
RIOT: For the Real-‐Time Internet of Things Team 7 : Michael Warrick, Ethan McGee Internet of Things My teddy bear is connected to the internet. Internet of Things The Internet of Things (IoT) is the interconnecEon of uniquely idenEfiable embedded compuEng devices within the exisEng Internet infrastructure It comprises a variety of fields, domain, applicaEons and protocols Expected to usher in a huge degree of automaEon across nearly every discipline imaginable Examples Environmental Monitoring Electric Clams in Ocean to monitor Clam PopulaEon Intelligent River Project Household Washer / Dryer Monitoring Thermostats / Fire Detectors Health Pace Maker Monitoring Health Blueprints RIOT: Real-‐Time Internet of Things One OS to Rule Them All, to Find Them, One OS to Bring Them, and in the Cloud Bind Them Why RIOT? Scenario: Airport IoT Requirments Hardware Memory and Processing Power Pla3orm Support Autonomy Power Efficiency Reliability Networking Stack Programmability Language Support A Comparison Features MarkeEng Time!!!! Hardware Support Somewhat Limited Range Airfy Beacon Arduino Due Arduino Mega 2560 Atmel samr21-‐Xplained Pro f4vi HiKoB FOX mbed NXP LPC1768 MSB-‐IoT Nordic nrf51822 (DevKit) OpenMote Spark-‐Core STM32F4DISCOVERY STM32F3DISCOVERY STM32F0DISCOVERY ScaferWeb MSB-‐A2 ScaferWeb MSB-‐430H TelosB Texas Instruments cc2538 Developer Kit Texas Instruments EZ430-‐Chronos UDOO Board (Cortex-‐M3 part) WSN 430 (v1.3b and v1.4) yunjia-‐nrf51822 ZolerEa Z1 Sensors -‐ Radio Transceivers -‐ Environmental Sensors: Humidity and Temperature Sensor, Pressure Sensor, Alcohol Gas Sensor -‐ Bafery Gas Gauge -‐ AcceleraEon Sensors: Tri-‐axial Sensor, Compass and Accelerometer -‐ Gyroscopes: Three-‐Axis Digital Gyroscope -‐ Ultra Sonic Range Finders -‐ Light: RGB LED, Light Sensor -‐ Servo Motor Reliable By Inheritance & Design OS derived from an FeuerWare (used by most embedded devices in rescue scenarios) Kernel is kept extremely small MulEthreading Mutexes Inter-‐Process CommunicaEon Device drivers cannot run in kernel Must run in thread Cannot crash kernel MulE-‐Threading Full Support Does not rely on explicit yields (unlike TinyOS) Threads can be switched out of context (unlike ConEki) Networking Support Network Stacks Other Features Wiselib Support Algorithm library designed for embedded devices Rou?ng, clustering, security, ?me sync, localiza?on MulEplajorm RIOT Con?ki Shawn, etc JSON Support Security Support– (ie SHA 256, 3DES, RC5) C++ 11 Support Awesome Stuff!! Futures / Promises Extremely popular in the JavaScript world Helps to make handling return values from threads easier h#p://en.cppreference.com/w/cpp/thread/future Tuples Easier to return mulEple values from a single funcEon std::tuple<bool, int> someFuncEon(int x, int y); yes, you could just use a struct NaEve Mode NaEve Mode Runs on Mac or Linux Provides simple tesEng and experimentaEon InstallaEon (Ubuntu Linux) gcc-‐mulElib bridge-‐uEls (tuntap needed for mac, preinstalled on ubuntu) Makefile templates provided Specify target hardware/modules Bloom Filters Bloom Filter An extremely fast data structure that allows you to test for inclusion within a set ProbabilisEc data structure Extremely fast comes at a price Bloom filters can tell you if something is not in the set Bloom filters can tell you if something might be in the set h#p://billmill.org/bloomfilter-‐tutorial/ Shell Shell Provides basic shell access Not a full shell – specific commands available Runs on serial port/uart Commands: addr reboot route ImplementaEon And you thought the stuff on Bloom Filters was bad... Modularity h#ps://github.com/RIOT-‐OS/RIOT FireKernel Real Eme support Scheduler Scheduler Uses a pre-‐empEve Eming scheduler A Eme-‐slice scheduler is not needed because there is no need to maintain the appearance of a responsive GUI Reduces interrupt load on system Main idea Priority based scheduling Every task gets a unique priority Tasks run unEl compleEon unless someone with higher priority comes along RIOT's Scheduler Tasks with same priority are possible Must cooperaEvely share Eme 32 possible prioriEes PrioriEes on same level are kept in linked list Switches done in almost constant Eme Blocking ObservaEons If a high priority task does not finish in Eme, it would not have finished in Eme even on a single-‐threaded system All processing Eme is devoted to it Allowed to run to compleEon If a lower priority task does not finish in Eme, probably doesn't have the right priority Increased priority means more processing Eme Won't be interrupted Energy Efficiency Idle Task It is a special task created during the OS boot Does not end but has lowest priority Used to help achieve ulEmate power efficiency Only task is to determine which low-‐power mode the OS can enter Can only be exited by hardware interrupt Tickless Timer Most kernels: a repeated Emer interval set (e.g. 1 microsecond) Generates and interrupt System wakes to update data structure, compare Tickless: No Emer is kept by the kernel Timer Architecture provided to applicaEons Mapped to hardware MulEple registers used Interrupts Overview Most systems have interrupts bypass OS because the OS can't handle interrupts RIOT is different Interrupt made via OS API call Allows for befer context switching Easier return to original context Can be wrifen using ISR notaEon used with other systems, or using RIOT's API ISR in RIOT is a wrapper around it's API Diagram Latency Needs to be as small as possible In RIOT, obviously higher because OS is involved However sEll extremely low 50 clock cycles or 700 nanoseconds Mutexes Mutexes Implemented as a Stack (-‐ish) When a mutex is encountered Push self onto stack unless top of stack has higher priority Then use random access to find the first entry with a lower priority than you Enter blocked mode Issue context switch When criEcal region is done Pick first thread off top of stack Inter-‐Process CommunicaEon IPC Synchronous message passing Send thread blocks unEl a thread receives Similar to mutex implementaEon Examples Yes, we are actually going to present something pracEcal for change . QuesEons / Comments? Whew... bet you're glad that's over!