MANTIS OS CS294- 11 SensorNet CS294- 11 SensorNet Fall 2005 Fall 2005 Murali Rangan Murali Rangan (Liberally drawn from slides by R. Han, et al) (Liberally drawn from slides by R. Han, et al)
MOS (MANTIS OS) Goals Goals General- purpose sw/ hw platform for General- purpose sw/ hw platform for sensornets sensornets Simplify sensornets for novices Simplify sensornets for novices Flexible for advanced research Flexible for advanced research Adapt to resource constraints Adapt to resource constraints Why multimodal? Why multimodal? Supports variety of apps, hw platforms, Supports variety of apps, hw platforms, deployment scenarios deployment scenarios
Overview Lightweight POSIX- like multithreading Lightweight POSIX- like multithreading Simple, vanilla ANSI C API Simple, vanilla ANSI C API Modest learning curve Cross platform portability Preemptive time- sliced scheduling Preemptive time- sliced scheduling I/ O sync via mutual exclusion I/ O sync via mutual exclusion Layered network stack, device drivers Layered network stack, device drivers Dynamic reprogramming Dynamic reprogramming Flexible power management Flexible power management Build com plex apps
Classic MT OS in 500 bytes User- level Com m and T3 T4 T5 Network threads Server Stack MANTIS System API MANTIS OS Kernel/ Scheduler Device Drivers Hardware
Lightweight MOS kernel Preemptive multi- threading Preemptive multi- threading Priority/ round- robin scheduling Priority/ round- robin scheduling Fast context switching (~60microsecs) Fast context switching (~60microsecs) 144 byte footprint for scheduler 144 byte footprint for scheduler Static thread table (default 12 threads) Static thread table (default 12 threads) 10 bytes per thread entry 10 bytes per thread entry Dynamic thread stack allocated on heap Dynamic thread stack allocated on heap Thread context saved on thread stack Thread context saved on thread stack Counting and binary semaphores Counting and binary semaphores
User Level network stack Non- strict layered design Non- strict layered design Network, transport, app layers in user level Network, transport, app layers in user level MAC protocol in “comm” layer MAC protocol in “comm” layer Implement in one or more threads Implement in one or more threads Performance Vs Flexibility trade off Performance Vs Flexibility trade off Easy to implement/ experiment Easy to implement/ experiment Can implement different routing protocols Can implement different routing protocols Cross- platform prototyping Cross- platform prototyping
MOS Comm/ Device Layers ● Com m Layer ● Interface to com m devices ● Manage shared pool of buffers ● Device Layer ● Interface to all devices
Comm layer Blocking com_send/ com_recv calls Blocking com_send/ com_recv calls Interrupt- driven packet reception Interrupt- driven packet reception Fills comBuf from a pool of comBufs Fills comBuf from a pool of comBufs com_recv gets pointer to a full comBuf pkt com_recv gets pointer to a full comBuf pkt Zero- copy on both send and receive Zero- copy on both send and receive Downside- App receiving pkt must free comBuf Downside- App receiving pkt must free comBuf com_mode for power management (on/ off/ idle) com_mode for power management (on/ off/ idle) com_ioctl for comm specific functions com_ioctl for comm specific functions MAC protocol implemented in radio device driver MAC protocol implemented in radio device driver
Device drivers Each driver implements four functions Each driver implements four functions dev_read, dev_write, dev_mode, dev_ioctl dev_read, dev_write, dev_mode, dev_ioctl read/ write calls are blocking, synchronous read/ write calls are blocking, synchronous Each driver keeps a mutex for I/ O sync Each driver keeps a mutex for I/ O sync Single static call table of driver function pointers Single static call table of driver function pointers Devices addressed using index in this table Devices addressed using index in this table dev_register() - to initialize call table, mutex dev_register() - to initialize call table, mutex dev_mode for power management (on/ off/ idle) dev_mode for power management (on/ off/ idle) dev_ioctl for device specific calls dev_ioctl for device specific calls
Power Management Traditional idle/ active modes Traditional idle/ active modes No CPU throttling, voltage variation No CPU throttling, voltage variation Apps have varying duty cycles Apps have varying duty cycles Let the app tell when it wants to sleep Let the app tell when it wants to sleep mos_enable_power_mgt() mos_enable_power_mgt() Power save mode turned off by default Power save mode turned off by default to be compatible with UNIX sleep! to be compatible with UNIX sleep! mos_thread_sleep(PERIOD) mos_thread_sleep(PERIOD) Timer wakes processor on earliest Timer wakes processor on earliest deadline expiry deadline expiry
Energe aware scheduler
Code example - send_forward.c #include < inttypes.h > #include "led.h" #include "dev.h" #include "com.h" #include "msched.h" #include "clock.h" static comBuf send_pkt; //comBuf goes in heap void send_thread(); void start(void) { mos_thread_new(send_thread, 128, PRIORITY_NORMAL); } void send_thread() { send_pkt.size=2; //2 bytes while(1) { mos_led_toggle(0); (uint16_t)send_pkt.data[0] = dev_get(DEV_MICA2_TEMP); com_send(IFACE_RADIO, &send_pkt); mos_thread_sleep(1000); } }
Code example - receive.c #include "led.h" #include "com.h" //give us the communication layer #include "msched.h" void receiver(); void start(void) { comBuf *recv_pkt; //give us a packet pointer com_mode(IFACE_RADIO, IF_LISTEN); while(1) { recv_pkt = com_recv(IFACE_RADIO); //blocking recv a packet com_send (IFACE_SERIAL, recv_pkt); //send packet out over serial com_free_buf(recv_pkt); //free the recv'd packet to the pool mos_led_toggle(0); } }
Cross platform Sensor Node X86 PC Com m and Com m and Network Network T3 T4 T5 T3 T4 T5 Server Server Stack Stack MANTIS System API MANTIS System API POSIX Shim Layer Kernel/ Scheduler Device Drivers UNIX Sensor Hardware X86 Hardware “AMOS” “XMOS”
Application Integration Application, e.g. Application, e.g. Com m and Network Visualization app Visualization app T3 T4 T5 Server Stack Bridging Gateway Bridging Gateway MANTIS System API Socket API Database API X Windows GUI POSIX Shim Layer UNIX X86 Hardware
Virtual XMOS Nodes Virtual Sensor Network Of XMOS Nodes USB/ Serial Bridging XMOS Gateway Visualiz ation Application
Dynamic Reprogramming Reprogram entire deployed node Reprogram entire deployed node MOS boot loader can re- flash entire OS MOS boot loader can re- flash entire OS Load stored code image from EEPROM Load stored code image from EEPROM Source- independent reprogramming Source- independent reprogramming Standard API to store code image to Standard API to store code image to EEPROM EEPROM Reprogramming possible over arbitrary Reprogramming possible over arbitrary connection (multi- hop), or from connection (multi- hop), or from application application Simple, flexible network management Simple, flexible network management
Remote Shell/ Command Server Remote “login” Remote “login” to nodes to nodes Debugging Debugging functions functions Peek/ poke Peek/ poke Kernel status Kernel status info info Configuration Configuration Spawn threads Spawn threads Call functions Call functions Reprogram node Reprogram node
Summary Lightweight, preemptive multi- threaded, cross- Lightweight, preemptive multi- threaded, cross- platform OS platform OS Easily integrates sensornets with other apps Easily integrates sensornets with other apps User friendly User friendly Familiar API and language Familiar API and language Powerful management tools Powerful management tools
Discussion (1) Classic Threads Vs Events argument Classic Threads Vs Events argument Threads Threads + Ease of application development, relatively better application debugging, good for complex computations - Stack management, concurrency issues, cost of context switching Events Events + Single stack – easy to manage, no concurrency issues, no context switching, good for simple computations - Hard to program, very hard to debug
Discussion (2) Context switching Context switching How critical is this? How critical is this? Paper says 60 microsecs, website says 200 microsecs Complex tasks in sensornets? Complex tasks in sensornets? How far are we? How far are we? Paper mentions compression/ crypto algos
Recommend
More recommend
