Interrupts
2024-09-11
来源：爱问旅游网
nesCProf. Chenyang LuCSE 521S1How should network msgbe handled?•Socket/TCP/IP?•Too much memory for buffering and threads•Data buffered in network stack until application threads read it•Application threads blocked until data is available•Transmit too many bits (sequence #, ack, re-transmission)•Tied with multi-threaded architecture•TinyOS solution: active messagesCSE 521S2Active Message•Every message contains the name of an event handler•Sender: split-phase operation•Phase I•Declaring buffer storage in a frame•Naming a handler•Requesting Transmission; exit•Done completion signal•Phase II•Receiver•Event handler is called when message is received9No blocked or waiting threads on sender or receiver9Behaves like any other events9Reduce bufferingCSE 521S3Send Messagechar TOS_COMMAND(INT_TO_RFM_OUTPUT)(intval){int_to_led_msg* message = (int_to_led_msg*)VAR(msg).data;if (!VAR(pending)) {message->val= val;if (TOS_COMMAND(INT_TO_RFM_SUB_SEND_MSG)(TOS_MSG_BCAST, AM_MSG(INT_READING), &VAR(msg))) {VAR(pending) = 1;return 1;}}return 0;}access applnmsgbuffercast to defined formatapplication specific ready checkbuild msgrequest transmissiondestination identifierget handler identifiermsgbufferCSE 521Smark busy4Space Breakdown…Code size for ad hoc networkingapplication350030002500Bytes200015001000500InterruptsMessage DispatchInitilizationC-RuntimeScheduler: 144 Bytes codeLight SensorTotals: 3430 Bytes codeClock226 Bytes data SchedulerLed ControlMessaging LayerPacket LayerRadio InterfaceRouting ApplicationRadio Byte EncoderD. Culler et. Al., TinyOSboot camp presentation, Feb 2001 0CSE 521S5Power Breakdown… ActiveCPURadioEE-PromLED’sPhoto Diode5 mA7 mA (TX)3 mA4 mA200 µAIdle2 mA4.5 mA (RX)0000Sleep5 µA5 µA0000Panasonic CR2354560 mAhTemperature200 µA•Lithium Battery runs for 35 hours at peak load and years at minimum load!•That’s three orders of magnitude difference!•A one byte transmission uses the same energy as approx 11000 cycles of computation.CSE 521S6Time Breakdown…ComponentsAMPacketRatio handlerRadio decode threadRFMRadio ReceptionPacket reception work breakdownCPU UtilizationEnergy (nj/Bit)0.05%1.12%26.87%5.48%66.48%--100.00%0.20%0.51%12.16%2.48%30.08%-54.75%100.00%0.337.58182.3837.2451.171350-2028.66IdleTotal•50 cycle thread overhead (6 byte copies)•10 cycle event overhead (1.25 byte copies)CSE 521S7•Small memory footprint•Power efficientAdvantages•Only needed OS components are complied/loaded•Non-preemptable FIFO task scheduling•Sleep whenever task queue is empty•Function call (event, command) interface between components•Event/command + tasks•Efficient interrupt/event handling (function calls, no user/kernel boundary)CSE 521S8•Efficient modularity•Concurrency-intensive operationsLack of Real-Time Support•FIFO, non-preemptive task scheduling•Urgent task may wait for non-urgent onesCSE 521S9Solution of Impala/ZebraNet•Timetable for periodic operations•Prioritize eventsCSE 521S10Impala: SchedulingCSE 521S11Impala: EventsCSE 521S12What’s missing?•Support for •different workload•varying workload•predictability•Leverage on real-time scheduling techniques•Static scheduling + schedulability analysis•Dynamic scheduling + overload protection•Topic for an interesting project!CSE 521S13Programming Networked Embedded SystemsnesCCSE 521S14Principles•Support TinyOScomponents and event/command interfaces•Static language•no malloc, no function pointers•Call graph and variable access are known at compile time•Whole-program analysis at compile time•Detect race conditions•Cross-component optimization: function inlining, eliminate unreachable code…CSE 521S15nesCApplication•Implementation•module: C behavior-configuration: select and wire•Interfaces-providesinterface-requiresinterfaceCSE 521S16Interfaceinterface Clock {command result_tsetRate(charinterval, char scale);event result_tfire();}interface Send {command result_tsend(TOS_Msg*msg, uint16_t length);event result_tsendDone(TOS_Msg*msg, result_tsuccess);}interface ADC {command result_tgetData();event result_tdataReady(uint16_t data);}Bidirectional interface supports split-phase operationCSE 521S17Modulemodule SurgeM{provides interface StdControl;uses interface ADC;uses interface Timer;uses interface Send;}implementation {uint16_t sensorReading;command result_tStdControl.init() {return call Timer.start(TIMER_REPEAT, 1000);}event result_tTimer.fired() {call ADC.getData();return SUCCESS;}event result_tADC.dataReady(uint16_t data) {sensorReading= data;... send message with data in it ...return SUCCESS;}...}CSE 521S18Configurationconfiguration TimerC{provides {interface StdControl;interface Timer;}}implementation {components TimerM, HWClock;StdControl= TimerM.StdControl;Timer = TimerM.Timer;TimerM.Clock-> HWClock.Clock;}CSE 521S19SurgeCSE 521S20Race ConditionsCSE 521S21Example: Race Conditionsmodule SurgeM{ ... } implementation { boolbusy;uint16_t sensorReading;eventresult_tTimer.fired() { if (!busy)busy = TRUE;call ADC.getData();}return SUCCESS;}Asynchronous CodeCSE 521S22Example: Race ConditionsIn a command handler:/* Contains a race: */if (state == IDLE) {state = SENDING;count++;// send a packet}CSE 521S23Concurrency in TinyOS•Asynchronous code (AC): code that is reachable from at least one interrupt handler•Synchronous code (SC): code that is only reachable from tasks•Key properties•Any update to shared state (variable) from AC is a potential race condition•Any update to shared state from SC that is also updated from AC is a potential race conditionCSE 521S24TinyOS Two-level Scheduling•Two priorities•Event/command•Tasks•Event/command can preempt task•Tasks cannot preempt another task or event/commandPreemptPOSTeventsTasksFIFOcommandscommandsInterruptsHardwareCSE 521S25TimeConcurrency in TinyOS•Asynchronous code (AC): code that is reachable from at least one interrupt handler•Event/command•Synchronous code (SC): code that is only reachable from tasks•Key properties•Any update to shared state (variable) from AC is a potential race condition•Any update to shared state from SC that is also updated from AC is a potential race conditionCSE 521S26Solution•Race-Free Invariant: Any update to shared state is either not a potential race condition (SC only), or occurs within an atomicsection.•Compiler check: identifies all shared states and return errors if the above invariant is violated•Fix code•Make the access to all shared states with potential race conditions atomic•Move access to SCCSE 521S27Atomic Sectionsatomic {}
•Disable interruptwhen atomic code is being executed•Alternative: semaphores based on test-set operations•But cannot disable interrupt for long! Ærestrictions•No loops•No commands/events•Calls OK, but calleemust meet restrictions tooCSE 521S28module SurgeM{ ... } implementation { boolbusy;noraceuint16_t sensorReading;disable interruptenable interrupteventresult_tTimer.fired() { boollocalBusy;atomic { localBusy= busy;test-and-setbusy = TRUE;}if (!localBusy)call ADC.getData();return SUCCESS;}taskvoid sendData() { // send sensorReadingadcPacket.data= sensorReading;call Send.send(&adcPacket, sizeofadcPacket.data);return SUCCESS;}eventresult_tADC.dataReady(uint16_t data) { sensorReading= data;post sendData();return SUCCESS;}CSE 521S29Example 2/* Contains a race: */if (state == IDLE) {state = SENDING;count++;// send a packet}/* Fixed version: */uint8_t oldState;atomic {oldState= state;if (state == IDLE) {state = SENDING;}}if (oldState== IDLE) {count++;// send a packet}CSE 521S30ResultsCSE 521S31Results•Tested on full TinyOS tree, plus applications•186 modules (121 modules, 65 configurations)•20-69 modules/app, 35 average•17 tasks, 75 events on average (per app)•Lots of concurrency!•Found 156 races: 103 real (!)•About 6 per 1000 lines of code•53 false positives•Fixing races:•Add atomic sections•Post tasks (move code to task context)CSE 521S32Optimization: inlining•Inliningreduces code size AND improves performance!CSE 521S33Issues: Programming Model•No dynamic memory allocation•How to size buffer when amount of data varies? •Bound memory footprint•Prevent run-time corruption•Allow offline footprint analysis(not done)•Restriction: no “long-running” code in•Push errors to applications•command/event handlers•atomic sections•Burden application programmers•Allow application-specific optimization•No kernel/user protection•Ex., which message needs retransmission?•Application can corrupt an entire systemCSE 521S34Reminder•Project•You should (at least) have a team now!•If not, email cs537s@cseASAP•Discuss your ideas with me•Critiques•Nocritique is due on Tuesday•This isa critique (on MAC) due on Sunday•Presentations•Go over your slides with me one week beforeyour presentationCSE 521S35Proposal Outline1.Team2.Motivate the problem3.Define the problem4.Related work•Assumptions, requirements, goals and non-goals•What have been done before?•How does your solution compare to them?•Intuition and rationale: Why is it a good idea?•Sketch of your approach and design.•What hardware (e.g., sensor boards) or simulation tools are you going to use?•What experiments are you going to run?•What criteria and metrics are you going to use to evaluate your solutions?5.Approach (optional)6.Experimental plan7.Milestones (with dates)8.ReferencesCSE 521S36Proposal Requirements•4-5 pages, 10 point, double column, single space.•Email meyour proposal by midnight, 9/27 (Monday).•See project Web page (updated today) for outline and requirements.CSE 521S37