Software Programming tiny devices You would like to have: - PowerPoint PPT Presentation

Software

Programming tiny devices You would like to have: structured programs with multiple concurrent threads good responsiveness to events (some applications pose RT requirements) readable, reusable code

Programming tiny devices So what is the problem? Practically, the only problem is multithreading, i.e., keeping track of multiple concurrent activities This is because normally such activities require a considerable amount of RAM for their stacks

Thread = constant, in flash, shared, not a problem code global, shared, determined by the data application, not by the program structure stack per thread, implied by program structure, needed to provide save area for context switch, wasted from the viewpoint of the application x N

Allocating stack to threads … … results in nasty memory fragmentation: threads can be preempted every which way you never know when a thread will be preempted, so you have to allocate to it the maximum amount of stack it may ever need

Note that interrupts fare better … because they use the stack in order this one will not receive control until this one is gone … so they can reasonably share the same stack

TinyOS This is one popular operating system for devices with very little RAM; here’s its approach to multithreading: Well, there isn’t any: what they call “tasks” are chunks of code executed back to back (not co-existing) All the truly fine parts of the program are implemented as interrupt service routines

In our OS, dubbed PicOS , … … there are threads, but their preemption mechanism is restrictive: A thread can only lose the CPU at a moment when it has given up the stack

In TinyOS: A lot of finesse (“multithreading”), causes stack containment problems Too little finesse may make the program respond poorly to events This is because the interrupt stack is the critical place for implementing all concurrency in the system The moral: the stack provides a poor way of saving thread context for preemption

Reactive thread model in PicOS: thread = FSM Wait for events state ... Wake up ... state ... ... Do things state ... ... state Declare events

PicOS thread (strand) example: strand (sniffer, sess_t) char c; entry (RC_TRY) data->packet = tcv_rnp (RC_TRY, efd); data->length = tcv_left (packet); entry (RC_PASS) if (data->user != US_READY) { wait (&data->user, RC_PASS); delay (1000, RC_LOCKED); release; } c = 1; ... ... entry (RC_ENP) tcv_endp (data->packet); signal (&data->packet); proceed (RC_TRY); endstrand

Two types of threads: thread has no private (differentiating) data; usually, a thread exists in a single copy at a time thread ( name ) strand has a private data pointer (representing its specific data structure) strand ( name , data_pointer_type )

Co-existing threads: State A 0 State B 0 State A 1 State B 1 State A 2 State A 3 State B 2 State A 4 State B 3 Hitting the end of a state amounts to a temporary “return” from the thread’s code

IPC thread (coordinator) entry (MN_START) mon = runthread (monitor); for (int i = 0; i < NP; i++) { runstrand (consumer, bufptr [i]); runstrand (producer, bufptr [i]); } entry (MN_WAIT) if (!running (consumer) || !running (producer)) { killall (producer); killall (consumer); ptrigger (mon, 0); finish; } joinall (consumer, MN_WAIT); joinall (producer, MN_WAIT); endthread

Flowcharts SEND INIT 3 sec thread (hrate) calculate address packet; entry (HR_INIT) HR delay (3 * 1024, HR_SEND); release; entry (HR_SEND) yes if ((HeartRate = hrc_get ()) > 255) XWS? HeartRate = 255; if (XWS == 0) { no // Don't do this if a sample is being sent packet = tcv_wnp (HR_SEND, BSFD, 2); get xmt put1 (packet, PT_HRATE); buffer put1 (packet, HeartRate); tcv_endp (packet); } send proceed (HR_INIT); HR endthread

Layer-less I/O programming A NULL plug-in Application P I P L U TARP plug-in VNETI G Device I N . P . S open-ended . H Y … Device

Plugin structure preprocessing upon reception typedef struct { int (*tcv_ope) (int, int, ...); how to open a session int (*tcv_clo) (int, int); int (*tcv_rcv) (int, address, int, int*, tcvadp_t*); int (*tcv_frm) (address, int, tcvadp_t*); int (*tcv_out) (address); int (*tcv_xmt) (address); how to close a session int (*tcv_tmt) (address); int tcv_info; } tcvplug_t; application packet boundary preprocessing for output after packet transmission on timeout

Praxis view Open a session, specifying the PHY and the Plug-in: SFD = tcv_open (RS_RETRY, 1, 2); Use the session ID for receiving and sending packets: packet = tcv_rnp (RS_RDP, SFD); ... tcv_endp (packet); packet = tcv_wnp (RS_WRP, SFD, length); ... tcv_endp (packet);

VNETI Implements a tagged pool of packet buffers Packets can be queued at sessions (for reception by the praxis) Packets can be queued at PHYs for dispatching to the device Plug-in functions can manipulate those packets by returning disposition codes They can also modify their contents and determine header boundaries

Plug-ins tell VNETI what to do with their packets int tcv_out_oep (address pbuff) { ... return TCV_DSP_XMT; ... return TCV_DSP_DROP; ... } int tcv_rcv_oep (int phy, address rawp, int len, int *ses, tcvadp_t *bounds) { if (not_ours (rawp)) return TCV_DSP_PASS; ... *ses = ...; bounds->head = ...; bounds->tail = ...; return TCV_DSP_RCV; }

System layout

VUEE (or VUE 2 ): virtual execution This part can be re-compiled and executed in a virtual environment called VUEE (Virtual Underlay Execution Engine)

This means that … … you can emulate a whole network of nodes possibly running a multiplicity of praxes in a way practically indistinguishable from a realistic execution In particular, any programs (OSS) developed to communicate with the nodes, can easily be fooled to talk to the model instead

How it works PicOS PicOS PicOS … code code code + VUEE SMURPH library wrapper data set Internet IF agent … UART OSSI node 10 program

Real time aspects of PicOS Criticism: limited preemptibility of threads gets in the way of RT response First note that interrupts are handled outside of threads thread interrupt wait for retrieve data (into event a buffer) scheduler trigger event handle event (wake the thread)

Reducing the granularity of states ... entry (RCV_READ) do { Pkt = tcv_rnp (RCV_READ, Ses); update (Pkt [SensorValue]); tcv_endp (Pkt); } while (Pkt [MsgType != MSG_LAST); ... ... entry (RCV_READ) Pkt = tcv_rnp (RCV_READ, Ses); update (Pkt [SensorValue]); tcv_endp (Pkt); if (Pkt [MsgType != MSG_LAST) proceed (RCV_READ); ...

Event polling ... entry (RCV_READ) while (MoreToDo) { lots_of_work (...); } ... ... entry (RCV_READ) allows the while (MoreToDo) { scheduler to run if (ImportantEventPending) more important proceed (RCV_READ); threads lots_of_work (...); } ...