% #!" # !" #$ (# ( ' (# (

Size: px
Start display at page:

Download "% #!" # !" #$ (# ( ' (# ("

Transcription

1 Embedded operating systems How do they differ from desktop operating systems? Event-based programming model How is concurrency handled? How are resource conflicts managed? Programming in TinyOS What new language constructs are useful? Features of all operating systems Abstraction of system resources Managing of system resources Concurrency model Launch applications Desktop operating systems General-purpose all features may be needed Large-scale resources memory, disk, file systems Embedded operating systems Application-specific just use features you need, save memory Small-scale resources sensors, communication ports!" #$ % #!" # Timers Sensors Serial port Radio communications Memory Power management Create virtual components E.g., multiple timers from one timer Allow them to be shared by multiple threads of execution E.g., two applications that want to share radio communication Device drivers provide interface for resource Encapsulate frequently used functions Save device state (if any) Manage interrupt handling ' (# ( (# ( Turn LED on/off Parameters: port pin API: on(port_pin) - specifies the port pin (e.g., port D pin 3) off(port_pin) Interactions: only if other devices want to use the same port Turning an LED on and off at a fixed rate Parameters: port pin rate at which to blink LED API: on(port_pin, rate) specifies the port pin (e.g., port D pin 3) specifies the rate to use in setting up the timer (what scale?) off(port_pin) Internal state and functions: keep track of state (on or off for a particular pin) of each pin interrupt service routine to handle timer interrupt 1

2 * #, What if other devices also need to use timer (e.g., PWM device)? timer interrupts now need to be handled differently depending on which device s alarm is going off Benefits of special-purpose output compare peripheral output compare pins used exclusively for one device output compare has a separate interrupt handling routine What if we don t have output compare capability or run out of output compare units? Create a new device driver for the timer unit Allow other devices to ask for timer services Manage timer independently so that it can service multiple requests Parameters: Time to wait, address to call when timer reaches that value API: set_timer(time_to_wait, call_back_address) Set call_back_address to correspond to timetime_to_wait Compute next alarm to sound and set timer Update in interrupt service routine for next alarm Internal state and functions: How many alarms can the driver keep track of? How are they organized? FIFO? priority queue? ) #" # /##" # Multiple programs interleaved as if parallel Each program requests access to devices/services e.g., timers, serial ports, etc. Exclusive or concurrent access to devices allow only one program at a time to access a device (e.g., serial port) arbitrate multiple accesses (e.g., timer) State and arbitration needed keep track of state of devices and concurrent programs using resource arbitrate their accesses (order, fairness, exclusivity) monitors/locks (supported by primitive operations in ISA - test-and-set) Interrupts disabling may effect timing of programs keeping enabled may cause unwanted interactions Traditional operating system multiple threads or processes file system virtual memory and paging input/output (buffering between CPU, memory, and I/O devices) interrupt handling (mostly with I/O devices) resource allocation and arbitration command interface (execution of programs) Embedded operating system lightweight threads input/output interrupt handling real-time guarantees -. 0 Lightweight threads basic locks fast context-switches Input/output API for talking to devices buffering Interrupt handling (with I/O devices and UI) translate interrupts into events to be handled by user code trigger new tasks to run (reactive) Real-time issues guarantee task is called at a certain rate guarantee an interrupt will be handled within a certain time priority or deadline driven scheduling of tasks Palm OS US Robotics Palm Pilot Motorola microcontrollers (68328 Dragonball, migrating to Xscale) simple OS for PDAs only supports single threads Pocket PC PDA operating system spin-off of Windows NT portable to a wide variety of processors (e.g., Xscale) full-featured OS modularized to only include features as needed Wind River Systems VxWorks one of the most popular embedded OS kernels highly portable to an even wider variety of processors (tiny to huge) modularized even further than the ones above (basic system under 50K) 2

3 / 11 Open-source development environment Simple (and tiny) operating system TinyOS Programming language and model nesc Set of services Principal elements Scheduler/event model of concurrency Software components for efficient modularity Software encapsulation for resources of sensor networks Motivation create Unix analog (circa 1969) Uniform programming language: C Uniform device abstractions Open source: grow with different developers/needs Support creation of many tools Created at UC Berkeley 1st version written by Jason Hill in 2000 Large part of development moved to Intel Research Berkeley in Smart Dust, Inc. founded in 2002 Large deployments Great Duck Island (GDI) Center for Embedded Network Sensing (CENS) Support networked embedded systems Asleep most of the time, but remain vigilant to stimuli Bursts of events and operations Support UCB mote hardware Power, sensing, computation, communication Easy to port to evolving platforms Support technological advances Keep scaling down Smaller, cheaper, lower power Can t use existing RTOS s Microkernel architecture VxWorks, PocketPC, PalmOS Execution similar to desktop systems PDA s, cell phones, embedded PC s More than a order of magnitude too heavyweight and slow Energy hogs 2#" 4 2 Similar to building networking interfaces Data driven execution Manage large # of concurrent data flows Manage large # of outstanding events Add: managing application data processing Conclusion: need a multi-threading engine Extremely efficient Extremely simple Two-level scheduling structure Events Small amount of processing to be done in a timely manner E.g. timer, ADC interrupts Can interrupt longer running tasks Tasks Not time critical Larger amount of processing E.g. computing the average of a set of readings in an array Run to completion with respect to other tasks Only need a single stack ) 3

4 #" #$ #" #$5#67 Tasks FIFO queue Interrupts Two-level of concurrency: tasks and interrupts - Tasks FIFO queue Placed on queue by: Application Other tasks Self-queued Interrupt service routine Run-to-completion No other tasks can run until completed Interruptable, but any new tasks go to end of queue Interrupts Stop running task Post new tasks to queue. #" #$5#67 8 $ Two-levels of concurrency Possible conflicts between interrupts and tasks Atomic statements atomic Asynchronous service routines (as opposed to synchronous tasks) async result_t interface_name.cmd_or_event_name Race conditions detected by compiler Can generated false positives norace keyword to stop warnings, but be careful Separation of construction and composition Programs are built out of components Specification of component behavior in terms of a set of interfaces Components specify interfaces they use and provide Components are statically wired to each other via their interfaces This increases runtime efficiency by enabling compiler optimizations Finite-state-machine-like specifications Thread of control passes into a component through its interfaces to another component 9# "# :( Commands Cause action to be initiated Events Notify action has occurred Generated by external interrupts Call back to provide results from previous command Tasks Background computation Not time critical Application event command Component event command Hardware Interface task task task Fountain of events leading to commands and tasks (which in turn issue may issue other commands that may cause other events, ) task to get out of async events commands interrupts tasks Software Hardware 4

5 : main.nc, ;" Interfaces (xxx.nc) Specifies functionality to outside world what commands can be called what events need handling Module (xxxm.nc) Code implementation Code for Interface functions Configuration (xxxc.nc) Wiring of components When top level app, drop C from filename xxx.nc interfacea.nc comp1c.nc (wires) interfaceb.nc interfaceb.nc comp3m.nc (code) interfacem.nc interfacem.nc app.nc (wires) interfacea.nc interfacea.nc comp2m.nc (code) nesc: networks of embedded sensors C Compiler for applications that run on UCB motes Built on top of avg-gcc nesc uses the filename extension ".nc TinyOS kernel (C) Static Language No dynamic memory (no malloc) TinyOS libs (nesc) No function pointers No heap Influenced by Java Includes task FIFO scheduler Designed to foster code reuse Modules per application range from 8 to 67, mean of 24*** Average lines of code in a module only 120*** Advantages of eliminating monolithic programs Code can be reused more easily Number of errors should decrease Application (nesc) nesc Compiler Application TinyOS (C) C Compiler Application Executable ***The NesC Language: A Holistic Approach to Network of Embedded Systems. David Gay, Phil Levis, Rob von Behren, Matt Welsh, Eric Brewer, and David Culler. Proceedings of Programming Language Design and Implementation (PLDI) 2003, June ( Commands are issued with call call Timer.start(TIMER_REPEAT, 1000); Cause action to be initiated Bounded amount of work Does not block Act similarly to a function call Execution of a command is immediate Events are called with signal signal ByteComm.txByteReady(SUCCESS); Used to notify a component an action has occurred Lowest-level events triggered by hardware interrupts Bounded amount of work Do not block Act similarly to a function call Execution of a event is immediate ) Tasks are queued with post post radioencodethread(); Used for longer running operations Pre-empted by events Initiated by interrupts Tasks run to completion Not pre-empted by other tasks Example tasks High level calculate aggregate of sensor readings Low level encode radio packet for transmission, calculate CRC Two types of components in nesc: Module Configuration A component provides and uses Interfaces -. 5

6 $" " Provides application code Contains C-like code Must implement the provides interfaces Implement the commands it provides Make sure to actually signal Must implement the uses interfaces Implement the events that need to be handled call commands as needed A configuration is a component that "wires" other components together. Configurations are used to assemble other components together Connects interfaces used by components to interfaces provided by others. * # %# Bi-directional multi-function interaction channel between two components Allows a single interface to represent a complex event E.g., a registration of some event, followed by a callback Critical for non-blocking operation provides interfaces Represent the functionality that the component provides to its user Service commands implemented command functions Issue events signal to user for passing data or signalling done uses interfaces Represent the functionality that the component needs from a provider Service events implement event handling Issue commands ask provider to do something Consists of one or more components, wired together to form a runnable program Single top-level configuration that specifies the set of components in the application and how they connect to one another Connection (wire) to main component to start execution Must implement init, start, and stop commands < 9%# What the executable does: tos/system/main.nc Directed wire (an arrow: -> ) connects components Only 2 components at a time point-to-point Connection is across compatible interfaces A <- B is equivalent to B -> A [component using interface] -> [component providing interface] [interface] -> [implementation] = can be used to wire a component directly to the top-level object s interfaces Typically used in a configuration file to use a sub-component directly Unused system components excluded from compilation 1. Main initializes and starts the application 2. BlinkM initializes ClockC s rate at 1Hz 3. ClockC continuously signals BlinkM at a rate of 1 Hz 4. BlinkM commands LedsC red led to toggle each time it receives a signal from ClockC Note: The StdControl interface is similar to state machines (init, start, stop); used extensively throughout TinyOS apps libs tos/interfaces/stdcontrol.nc tos/interfaces/stdcontrol.nc tos/interfaces/timer.nc tos/interfaces/singletimer.nc tos/interfaces/timer.nc BlinkM.nc tos/interfaces/leds.nc tos/interfaces/leds.nc tos/system/timerc.nc tos/system/ledsc.nc 6

7 91# 1# configuration Blink implementation components Main, BlinkM, SingleTimer, LedsC; Main.StdControl -> SingleTimer.StdControl; Main.StdControl -> BlinkM.StdControl; BlinkM.Timer -> SingleTimer.Timer; BlinkM.Leds -> LedsC.Leds; interface StdControl command result_t init(); command result_t start(); command result_t stop(); ) 9$1# BlinkM.nc module BlinkM provides interface StdControl; uses implementation interface Timer; command result_t StdControl.init() interface Leds; call Leds.init(); command result_t StdControl.start() return call Timer.start(TIMER_REPEAT, 1000); command result_t StdControl.stop() return call Timer.stop(); event result_t Timer.fired() call Leds.redToggle(); - 1#5,",( 1#7 Parameterized interfaces allows a component to provide multiple instances of an interface that are parameterized by a value Timer implements one level of indirection to actual timer functions Timer module supports many interfaces This module simply creates one unique timer interface and wires it up By wiring Timer to a separate instance of the Timer interface provided by TimerC, each component can effectively get its own "private" timer Uses a compile-time constant function unique() to ensure index is unique configuration SingleTimer provides interface Timer; provides interface StdControl; implementation components TimerC; Timer = TimerC.Timer[unique("Timer")]; StdControl = TimerC.StdControl;. 91#," 1# configuration Blink implementation components Main, BlinkM, TimerC, LedsC; Main.StdControl -> TimerC.StdControl; Main.StdControl -> BlinkM.StdControl; BlinkM.Timer -> TimerC.Timer[unique("Timer")]; BlinkM.Leds -> LedsC.Leds; interface Timer command result_t start(char type, uint32_t interval); command result_t stop(); event result_t fired(); 7

8 #define dbg(mode, format, ) ((void)0) #define dbg_clear(mode, format, ) ((void)0) #define dbg_active(mode) 0 typedef signed char int8_t; typedef unsigned char uint8_t; typedef int int16_t; typedef unsigned int uint16_t; typedef long int32_t; typedef unsigned long uint32_t; typedef long long int64_t; typedef unsigned long long uint64_t; typedef int16_t intptr_t; typedef uint16_t uintptr_t; typedef unsigned int size_t; typedef int wchar_t; typedef struct nesc_unnamed4242 int quot; int rem; div_t; typedef struct nesc_unnamed4243 long quot; long rem; ldiv_t; typedef int (* compar_fn_t)(const void *, const void *); typedef int ptrdiff_t; typedef unsigned char bool; enum nesc_unnamed4244 FALSE = 0, TRUE = 1 ; enum nesc_unnamed4245 FAIL = 0, SUCCESS = 1 ; static inline uint8_t rcombine(uint8_t r1, uint8_t r2); typedef uint8_t result_t; static inline result_t rcombine(result_t r1, result_t r2); enum nesc_unnamed4246 NULL = 0x0 ; typedef void attribute(( progmem )) prog_void; typedef char attribute(( progmem )) prog_char; TOSH_sched_entry_T; typedef unsigned char attribute(( progmem )) prog_uchar; enum nesc_unnamed4253 typedef int attribute(( progmem )) prog_int; TOSH_MAX_TASKS = 8, typedef long attribute(( progmem )) prog_long; TOSH_TASK_BITMASK = TOSH_MAX_TASKS - 1 typedef long long attribute(( progmem )) prog_long_long; ; enum nesc_unnamed4247 TOSH_sched_entry_T TOSH_queue[TOSH_MAX_TASKS]; TOSH_period16 = 0x00, TOSH_period32 = 0x01, TOSH_period64 = 0x02, TOSH_period128 = 0x03, TOSH_period256 = 0x04, TOSH_period512 = 0x05, TOSH_period1024 = 0x06, TOSH_period2048 = 0x07 ; static inline void TOSH_wait(void); static inline void TOSH_sleep(void); typedef uint8_t nesc_atomic_t; inline nesc_atomic_t nesc_atomic_start(void ); ; inline void nesc_atomic_end( nesc_atomic_t oldsreg); static inline void nesc_enable_interrupt(void); static inline void TOSH_SET_RED_LED_PIN(void); static inline void TOSH_CLR_RED_LED_PIN(void); static inline void TOSH_MAKE_RED_LED_OUTPUT(void); static inline void TOSH_SET_GREEN_LED_PIN(void); static inline void TOSH_MAKE_GREEN_LED_OUTPUT(void); static inline void TOSH_SET_YELLOW_LED_PIN(void); static inline void TOSH_MAKE_YELLOW_LED_OUTPUT(void); static inline void TOSH_CLR_SERIAL_ID_PIN(void); static inline void TOSH_MAKE_SERIAL_ID_INPUT(void); static inline void TOSH_MAKE_CC_CHP_OUT_INPUT(void); static inline void TOSH_MAKE_CC_PDATA_OUTPUT(void); static inline void TOSH_MAKE_CC_PCLK_OUTPUT(void); static inline void TOSH_MAKE_CC_PALE_OUTPUT(void); static inline void TOSH_SET_FLASH_SELECT_PIN(void); static inline void TOSH_MAKE_FLASH_SELECT_OUTPUT(void); static inline void TOSH_MAKE_FLASH_CLK_OUTPUT(void); static inline void TOSH_MAKE_FLASH_OUT_OUTPUT(void); static inline void TOSH_MAKE_MISO_INPUT(void); static inline void TOSH_MAKE_SPI_OC1C_INPUT(void); static inline void TOSH_MAKE_PW0_OUTPUT(void); static inline void TOSH_MAKE_PW1_OUTPUT(void); static inline void TOSH_MAKE_PW2_OUTPUT(void); static inline void TOSH_MAKE_PW3_OUTPUT(void); static inline void TOSH_MAKE_PW4_OUTPUT(void); static inline void TOSH_MAKE_PW5_OUTPUT(void); static inline void TOSH_MAKE_PW6_OUTPUT(void); static inline void TOSH_MAKE_PW7_OUTPUT(void); static inline void TOSH_SET_PIN_DIRECTIONS(void ); enum nesc_unnamed4248 TOSH_ADC_PORTMAPSIZE = 12 ; enum nesc_unnamed4249 TOSH_ACTUAL_CC_RSSI_PORT = 0, TOSH_ACTUAL_VOLTAGE_PORT = 7, TOSH_ACTUAL_BANDGAP_PORT = 30, TOSH_ACTUAL_GND_PORT = 31 ; enum nesc_unnamed4250 TOS_ADC_CC_RSSI_PORT = 0, TOS_ADC_VOLTAGE_PORT = 7, TOS_ADC_BANDGAP_PORT = 10, TOS_ADC_GND_PORT = 11 ; typedef long long TOS_dbg_mode; enum nesc_unnamed4251 DBG_ALL = ~0ULL, DBG_BOOT = 1ULL << 0, DBG_CLOCK = 1ULL << 1, DBG_TASK = 1ULL << 2, DBG_SCHED = 1ULL << 3, DBG_SENSOR = 1ULL << 4, DBG_LED = 1ULL << 5, DBG_CRYPTO = 1ULL << 6, DBG_ROUTE = 1ULL << 7, DBG_AM = 1ULL << 8, DBG_CRC = 1ULL << 9, DBG_PACKET = 1ULL << 10, DBG_ENCODE = 1ULL << 11, DBG_RADIO = 1ULL << 12, DBG_LOG = 1ULL << 13, DBG_ADC = 1ULL << 14, DBG_I2C = 1ULL << 15, DBG_UART = 1ULL << 16, DBG_PROG = 1ULL << 17, DBG_SOUNDER = 1ULL << 18, DBG_TIME = 1ULL << 19, DBG_SIM = 1ULL << 21, DBG_QUEUE = 1ULL << 22, DBG_SIMRADIO = 1ULL << 23, DBG_HARD = 1ULL << 24, DBG_MEM = 1ULL << 25, DBG_USR1 = 1ULL << 27, DBG_USR2 = 1ULL << 28, DBG_USR3 = 1ULL << 29, DBG_TEMP = 1ULL << 30, DBG_ERROR = 1ULL << 31, DBG_NONE = 0, DBG_DEFAULT = DBG_ALL ; typedef struct nesc_unnamed4252 void (*tp)(void); volatile uint8_t TOSH_sched_full; volatile uint8_t TOSH_sched_free; static inline void TOSH_wait(void ); static inline void TOSH_sleep(void ); static inline void TOSH_sched_init(void ); bool TOS_post(void (*tp)(void)); static inline bool TOSH_run_next_task(void); static inline void TOSH_run_task(void); enum nesc_unnamed4254 TIMER_REPEAT = 0, TIMER_ONE_SHOT = 1, NUM_TIMERS = 1 enum nesc_unnamed4255 TOS_I1000PS = 32, TOS_S1000PS = 1, TOS_I100PS = 40, TOS_S100PS = 2, TOS_I10PS = 101, TOS_S10PS = 3, TOS_I1024PS = 0, TOS_S1024PS = 3, TOS_I512PS = 1, TOS_S512PS = 3, TOS_I256PS = 3, TOS_S256PS = 3, TOS_I128PS = 7, TOS_S128PS = 3, TOS_I64PS = 15, TOS_S64PS = 3, TOS_I32PS = 31, TOS_S32PS = 3, TOS_I16PS = 63, TOS_S16PS = 3, TOS_I8PS = 127, TOS_S8PS = 3, TOS_I4PS = 255, TOS_S4PS = 3, TOS_I2PS = 15, TOS_S2PS = 7, TOS_I1PS = 31, TOS_S1PS = 7, TOS_I0PS = 0, TOS_S0PS = 0 ; enum nesc_unnamed4256 DEFAULT_SCALE = 3, DEFAULT_INTERVAL = 127 ; static result_t PotM$Pot$init(uint8_t arg_0xa2ce970); static result_t HPLPotC$Pot$finalise(void); static result_t HPLPotC$Pot$decrease(void); static result_t HPLPotC$Pot$increase(void); static result_t HPLInit$init(void); static result_t BlinkM$StdControl$init(void); static result_t BlinkM$StdControl$start(void); static result_t BlinkM$Timer$fired(void); static result_t TimerM$Clock$fire(void); static result_t TimerM$StdControl$init(void); static result_t TimerM$StdControl$start(void); static result_t TimerM$Timer$default$fired(uint8_t arg_0xa31d660); static result_t TimerM$Timer$start(uint8_t arg_0xa31d660, char arg_0xa2fd578, uint32_t arg_0xa2fd6d0); static void HPLClock$Clock$setInterval(uint8_t arg_0xa33b8c0); static uint8_t HPLClock$Clock$readCounter(void); static result_t HPLClock$Clock$setRate(char arg_0xa33adc0, char arg_0xa33af00); static uint8_t HPLPowerManagementM$PowerManagement$adjustPower(void); static result_t LedsC$Leds$init(void); static result_t LedsC$Leds$redOff(void); static result_t LedsC$Leds$redToggle(void); static result_t LedsC$Leds$redOn(void); static result_t RealMain$hardwareInit(void); static result_t RealMain$Pot$init(uint8_t arg_0xa2ce970); static result_t RealMain$StdControl$init(void); static result_t RealMain$StdControl$start(void); int main(void); static result_t PotM$HPLPot$finalise(void); static result_t PotM$HPLPot$decrease(void); static result_t PotM$HPLPot$increase(void); uint8_t PotM$potSetting; static inline void PotM$setPot(uint8_t value); static inline result_t PotM$Pot$init(uint8_t initialsetting); static inline result_t HPLPotC$Pot$decrease(void); static inline result_t HPLPotC$Pot$increase(void); static inline result_t HPLPotC$Pot$finalise(void); static inline result_t HPLInit$init(void); static result_t BlinkM$Leds$init(void); static result_t BlinkM$Leds$redToggle(void); static result_t BlinkM$Timer$start(char arg_0xa2fd578, uint32_t arg_0xa2fd6d0); static inline result_t BlinkM$StdControl$init(void); static inline result_t BlinkM$StdControl$start(void); = 1 << 2; static inline result_t BlinkM$Timer$fired(void); static uint8_t TimerM$PowerManagement$adjustPower(void); static inline void TOSH_SET_FLASH_SELECT_PIN(void) uint32_t TimerM$mState; uint8_t TimerM$setIntervalFlag; uint8_t TimerM$mScale; uint8_t TimerM$mInterval; int8_t TimerM$queue_head; int8_t TimerM$queue_tail; uint8_t TimerM$queue_size; uint8_t TimerM$queue[NUM_TIMERS]; struct TimerM$timer_s uint8_t type; int32_t ticks; int32_t ticksleft; TimerM$mTimerList[NUM_TIMERS]; enum TimerM$ nesc_unnamed4257 TimerM$maxTimerInterval = 230 ; = ~(1 << 3); uint8_t HPLClock$minterval; static inline void HPLClock$Clock$setInterval(uint8_t value); uint8_t i; static inline void TOSH_MAKE_CC_PCLK_OUTPUT(void) static inline uint8_t HPLClock$Clock$readCounter(void); for (i = 0; i < 151; i) static inline result_t HPLClock$Clock$setRate(char interval, char scale); PotM$HPLPot$decrease(); *)(0x11 0x20) void attribute((interrupt)) vector_15(void); for (i = 0; i < value; i) = 1 << 6; bool HPLPowerManagementM$disabled = TRUE; PotM$HPLPot$increase(); enum HPLPowerManagementM$ nesc_unnamed4258 PotM$HPLPot$finalise(); static inline void TOSH_MAKE_CC_PDATA_OUTPUT(void) HPLPowerManagementM$IDLE = 0, PotM$potSetting = value; HPLPowerManagementM$ADC_NR = 1 << 3, * (volatile unsigned char *)(unsigned int ) * (volatile unsigned char *)(0x11 0x20) HPLPowerManagementM$POWER_DOWN = 1 << 4, = 1 << 7; HPLPowerManagementM$POWER_SAVE = (1 << 3) (1 << 4), static inline void TOSH_MAKE_CC_PALE_OUTPUT(void) HPLPowerManagementM$STANDBY = (1 << 2) (1 << 4), HPLPowerManagementM$EXT_STANDBY = (1 << 3) (1 << 4) (1 << 2) static inline result_t LedsC$Leds$init(void); static inline result_t LedsC$Leds$redOn(void); static inline void TOSH_SET_GREEN_LED_PIN(void) * (volatile unsigned char *)(unsigned int ) * (volatile unsigned TOSH_CLR_SERIAL_ID_PIN(); char *)(0x1B 0x20) = 1 << 1; TOSH_MAKE_FLASH_SELECT_OUTPUT(); TOSH_MAKE_FLASH_OUT_OUTPUT(); static inline void TOSH_SET_YELLOW_LED_PIN(void) TOSH_MAKE_FLASH_CLK_OUTPUT(); TOSH_SET_FLASH_SELECT_PIN(); *)(0x1B 0x20) = 1 << 0; TOSH_SET_YELLOW_LED_PIN(); static inline void TOSH_SET_RED_LED_PIN(void) TOSH_SET_GREEN_LED_PIN(); *)(0x1B 0x20) static void TimerM$Clock$setInterval(uint8_t arg_0xa33b8c0); static uint8_t TimerM$Clock$readCounter(void); *)(0x1B 0x20) static result_t TimerM$Clock$setRate(char arg_0xa33adc0, char arg_0xa33af00); = 1 << 3; static result_t TimerM$Timer$fired(uint8_t arg_0xa31d660); static inline void TOSH_MAKE_FLASH_CLK_OUTPUT(void) *)(0x11 0x20) = 1 << 3; static inline void TOSH_MAKE_FLASH_SELECT_OUTPUT(void) *)(0x1A 0x20) = 1 << 3; static inline void TOSH_CLR_SERIAL_ID_PIN(void) = 1 << 6; static inline void TOSH_MAKE_PW7_OUTPUT(void) *)(0x14 0x20) = 1 << 7; static inline void TOSH_MAKE_CC_CHP_OUT_INPUT(void) static inline void TOSH_SET_PIN_DIRECTIONS(void ) TOSH_MAKE_RED_LED_OUTPUT(); TOSH_MAKE_YELLOW_LED_OUTPUT(); TOSH_MAKE_GREEN_LED_OUTPUT(); TOSH_MAKE_CC_CHP_OUT_INPUT(); TOSH_MAKE_PW7_OUTPUT(); TOSH_MAKE_PW6_OUTPUT(); TOSH_MAKE_PW5_OUTPUT(); TOSH_MAKE_PW4_OUTPUT(); TOSH_MAKE_PW3_OUTPUT(); TOSH_MAKE_PW2_OUTPUT(); TOSH_MAKE_PW1_OUTPUT(); TOSH_MAKE_PW0_OUTPUT(); TOSH_MAKE_CC_PALE_OUTPUT(); TOSH_MAKE_CC_PDATA_OUTPUT(); TOSH_MAKE_CC_PCLK_OUTPUT(); TOSH_MAKE_MISO_INPUT(); TOSH_MAKE_SPI_OC1C_INPUT(); TOSH_MAKE_SERIAL_ID_INPUT(); static inline result_t HPLInit$init(void) TOSH_SET_PIN_DIRECTIONS(); *)(0x1A 0x20) = ~(1 << 6); static inline void TOSH_MAKE_GREEN_LED_OUTPUT(void) inline static result_t RealMain$hardwareInit(void) result = HPLInit$init(); *)(0x11 0x20) = 1 << 5; static inline void TOSH_MAKE_FLASH_OUT_OUTPUT(void) static inline result_t HPLPotC$Pot$finalise(void) inline static result_t PotM$HPLPot$finalise(void) result = HPLPotC$Pot$finalise(); static inline result_t HPLPotC$Pot$increase(void) static inline result_t TimerM$StdControl$init(void); * (volatile unsigned char *)(unsigned int ) * (volatile unsigned inline char static *)(0x1B result_t 0x20) PotM$HPLPot$increase(void) = ~(1 << 4); static inline result_t TimerM$StdControl$start(void); static inline result_t TimerM$Timer$start(uint8_t id, char type, result = HPLPotC$Pot$increase(); static inline void TOSH_MAKE_SERIAL_ID_INPUT(void) uint32_t interval); static void TimerM$adjustInterval(void); * (volatile unsigned char *)(unsigned int ) * (volatile unsigned static inline result_t TimerM$Timer$default$fired(uint8_t id); static char inline *)(0x1A result_t 0x20) HPLPotC$Pot$decrease(void) = ~(1 << 4); static inline void TimerM$enqueue(uint8_t value); static inline uint8_t TimerM$dequeue(void); static inline void TOSH_MAKE_SPI_OC1C_INPUT(void) static inline void TimerM$signalOneTimer(void); static inline void TimerM$HandleFire(void); inline static result_t PotM$HPLPot$decrease(void) *)(0x17 0x20) static inline result_t TimerM$Clock$fire(void); = ~(1 << 7); static result_t HPLClock$Clock$fire(void); result = HPLPotC$Pot$decrease(); uint8_t HPLClock$set_flag; static inline void TOSH_MAKE_MISO_INPUT(void) uint8_t HPLClock$mscale; uint8_t HPLClock$nextScale; * (volatile unsigned char *)(unsigned int ) * (volatile unsigned static char inline *)(0x17 void PotM$setPot(uint8_t 0x20) value) static inline result_t PotM$Pot$init(uint8_t initialsetting) PotM$setPot(initialSetting); ; *)(0x11 0x20) = 1 << 4; static inline uint8_t HPLPowerManagementM$getPowerLevel(void); static inline void HPLPowerManagementM$doAdjustment(void); static inline void TOSH_MAKE_PW0_OUTPUT(void) static uint8_t HPLPowerManagementM$PowerManagement$adjustPower(void); uint8_t LedsC$ledsOn; *)(0x14 0x20) enum LedsC$ nesc_unnamed4259 = 1 << 0; LedsC$RED_BIT = 1, LedsC$GREEN_BIT = 2, static inline void TOSH_MAKE_PW1_OUTPUT(void) LedsC$YELLOW_BIT = 4 TOSH_sched_free = 0; ; * (volatile unsigned char *)(unsigned int ) * (volatile unsigned TOSH_sched_full char *)(0x14 = 0; 0x20) = 1 << 1; inline static result_t RealMain$Pot$init(uint8_t arg_0xa2ce970) result = PotM$Pot$init(arg_0xa2ce970); static inline void TOSH_sched_init(void ) static inline result_t rcombine(result_t r1, result_t r2) static inline void TOSH_MAKE_PW2_OUTPUT(void) static inline result_t LedsC$Leds$redOff(void); static inline result_t LedsC$Leds$redToggle(void); return r1 == FAIL? FAIL : r2; * (volatile unsigned char *)(unsigned int ) * (volatile unsigned char *)(0x14 0x20) = 1 << 2; static inline result_t LedsC$Leds$init(void) static inline void TOSH_MAKE_PW3_OUTPUT(void) nesc_atomic_t nesc_atomic = nesc_atomic_start(); *)(0x14 0x20) = 1 << 3; LedsC$ledsOn = 0; static inline void TOSH_MAKE_PW4_OUTPUT(void) TOSH_SET_YELLOW_LED_PIN(); * (volatile unsigned char *)(unsigned int ) * (volatile unsigned TOSH_SET_GREEN_LED_PIN(); char *)(0x14 0x20) = 1 << 4; nesc_atomic_end( nesc_atomic); static inline void TOSH_MAKE_PW5_OUTPUT(void) *)(0x14 0x20) inline static result_t BlinkM$Leds$init(void) = 1 << 5; result = LedsC$Leds$init(); static inline void TOSH_MAKE_PW6_OUTPUT(void) *)(0x14 0x20) static inline result_t BlinkM$StdControl$init(void) BlinkM$Leds$init(); static inline result_t HPLClock$Clock$setRate(char interval, char scale) scale = 0x7; scale = 0x8; nesc_atomic_t nesc_atomic = nesc_atomic_start(); *)(0x37 0x20) = ~(1 << 0); * (volatile unsigned char *)(unsigned int ) * (volatile unsigned char *)(0x1A 0x20) *)(0x37 0x20) = ~(1 << 1); = 1 << 1; *)(0x30 0x20) = 1 << 3; static inline void TOSH_MAKE_YELLOW_LED_OUTPUT(void) *)(0x33 0x20) = scale; *)(0x1A 0x20) *)(0x32 0x20) = 0; = 1 << 0; *)(0x31 0x20) = interval; static inline void TOSH_MAKE_RED_LED_OUTPUT(void) *)(0x37 0x20) = 1 << 1; * (volatile unsigned char *)(unsigned int ) * (volatile unsigned char *)(0x1A 0x20) = 1 << 2; nesc_atomic_end( nesc_atomic); static inline void HPLPowerManagementM$doAdjustment(void) inline static result_t TimerM$Clock$setRate(char arg_0xa33adc0, char uint8_t foo; arg_0xa33af00) uint8_t mcu; foo = HPLPowerManagementM$getPowerLevel(); result = HPLClock$Clock$setRate(arg_0xa33adc0, arg_0xa33af00); mcu = *)(0x35 0x20); mcu = 0xe3; static inline result_t TimerM$StdControl$init(void) if (foo == HPLPowerManagementM$EXT_STANDBY foo == HPLPowerManagementM$POWER_SAVE) TimerM$mState = 0; mcu = HPLPowerManagementM$IDLE; TimerM$setIntervalFlag = 0; while ((* (volatile unsigned char *)(unsigned int ) * (volatile unsigned char *)(0x30 0x20) 0x7)!= 0) TimerM$queue_head = TimerM$queue_tail = -1; asm volatile ("nop"); TimerM$queue_size = 0; TimerM$mScale = 3; mcu = 0xe3; TimerM$mInterval = TimerM$maxTimerInterval; return TimerM$Clock$setRate(TimerM$mInterval, TimerM$mScale); mcu = foo; inline static result_t RealMain$StdControl$init(void) *)(0x35 0x20) = mcu; result = TimerM$StdControl$init(); *)(0x35 0x20) = 1 << 5; result = rcombine(result, BlinkM$StdControl$init()); static inline void nesc_enable_interrupt(void) asm volatile ("sei"); inline static uint8_t TimerM$PowerManagement$adjustPower(void) static inline void TOSH_wait(void) result = HPLPowerManagementM$PowerManagement$adjustPower(); asm volatile ("nop"); asm volatile ("nop"); static inline void HPLClock$Clock$setInterval(uint8_t value) static inline void TOSH_sleep(void) *)(0x35 0x20) = 1 << 5; *)(0x31 0x20) = value; asm volatile ("sleep"); inline static void TimerM$Clock$setInterval(uint8_t arg_0xa33b8c0) inline void nesc_atomic_end( nesc_atomic_t oldsreg) HPLClock$Clock$setInterval(arg_0xa33b8c0); *)(0x3F 0x20) = oldsreg; static inline uint8_t HPLClock$Clock$readCounter(void) inline nesc_atomic_t nesc_atomic_start(void ) return * (volatile unsigned char *)(unsigned int ) * (volatile unsigned char *)(0x32 0x20); nesc_atomic_t result = * (volatile unsigned char *)(unsigned int ) * (volatile unsigned char *)(0x3F 0x20); inline static uint8_t TimerM$Clock$readCounter(void) asm volatile ("cli"); result = HPLClock$Clock$readCounter(); static inline bool TOSH_run_next_task(void) static inline result_t TimerM$Timer$start(uint8_t id, char type, uint32_t interval) uint8_t diff; if (id >= NUM_TIMERS) return FAIL; if (type > 1) return FAIL; TimerM$mTimerList[id].ticks = interval; TimerM$mTimerList[id].type = type; nesc_atomic_t nesc_atomic = nesc_atomic_start(); diff = TimerM$Clock$readCounter(); interval = diff; TimerM$mTimerList[id].ticksLeft = interval; TimerM$mState = 0x1 << id; if (interval < TimerM$mInterval) TimerM$mInterval = interval; TimerM$Clock$setInterval(TimerM$mInterval); TimerM$setIntervalFlag = 0; TimerM$PowerManagement$adjustPower(); nesc_atomic_end( nesc_atomic); inline static result_t BlinkM$Timer$start(char arg_0xa2fd578, uint32_t arg_0xa2fd6d0) result = TimerM$Timer$start(0, arg_0xa2fd578, arg_0xa2fd6d0); static inline result_t BlinkM$StdControl$start(void) return BlinkM$Timer$start(TIMER_REPEAT, 1000); 0x20); if (diff < 16) return HPLPowerManagementM$EXT_STANDBY; return HPLPowerManagementM$POWER_SAVE; else return HPLPowerManagementM$POWER_DOWN; nesc_atomic_t finterruptflags; uint8_t old_full; void (*func)(void ); if (TOSH_sched_full == TOSH_sched_free) return 0; else finterruptflags = nesc_atomic_start(); old_full = TOSH_sched_full; TOSH_sched_full; TOSH_sched_full = TOSH_TASK_BITMASK; func = TOSH_queue[(int )old_full].tp; TOSH_queue[(int )old_full].tp = 0; nesc_atomic_end(finterruptflags); func(); return 1; static inline void TOSH_run_task(void) while (TOSH_run_next_task()) ; TOSH_sleep(); TOSH_wait(); static void TimerM$adjustInterval(void) uint8_t i; uint8_t val = TimerM$maxTimerInterval; if (TimerM$mState) TimerM$mInterval = val; static inline result_t TimerM$Clock$fire(void) static inline result_t TimerM$StdControl$start(void) TimerM$Clock$setInterval(TimerM$mInterval); TimerM$setIntervalFlag = 0; TOS_post(TimerM$HandleFire); nesc_atomic_end( nesc_atomic); inline static result_t RealMain$StdControl$start(void) inline static result_t HPLClock$Clock$fire(void) else result = TimerM$StdControl$start(); nesc_atomic_t nesc_atomic = nesc_atomic_start(); result = TimerM$Clock$fire(); result = rcombine(result, BlinkM$StdControl$start()); TimerM$mInterval = TimerM$maxTimerInterval; TimerM$Clock$setInterval(TimerM$mInterval); bool TOS_post(void (*tp)(void)) static inline uint8_t HPLPowerManagementM$getPowerLevel(void) TimerM$setIntervalFlag = 0; nesc_atomic_t finterruptflags; uint8_t diff; nesc_atomic_end( nesc_atomic); uint8_t tmp; if ( *)(0x37 0x20) ~((1 << 1) (1 << 0))) finterruptflags = nesc_atomic_start(); TimerM$PowerManagement$adjustPower(); return HPLPowerManagementM$IDLE; tmp = TOSH_sched_free; TOSH_sched_free; static inline void TOSH_CLR_RED_LED_PIN(void) else TOSH_sched_free = TOSH_TASK_BITMASK; if ( if (TOSH_sched_free!= TOSH_sched_full) *)(0x0D 0x20) (1 << 7)) *)(0x1B 0x20) = ~(1 << 2); nesc_atomic_end(finterruptflags); return HPLPowerManagementM$IDLE; TOSH_queue[tmp].tp = tp; static inline result_t LedsC$Leds$redOn(void) return TRUE; else if (* (volatile unsigned char *)(unsigned int ) * (volatile unsigned nesc_atomic_t nesc_atomic = nesc_atomic_start(); else char *)(0x06 0x20) (1 << 7)) TOSH_sched_free = tmp; return HPLPowerManagementM$ADC_NR; TOSH_CLR_RED_LED_PIN(); nesc_atomic_end(finterruptflags); LedsC$ledsOn = LedsC$RED_BIT; return FALSE; else else if (* (volatile unsigned char *)(unsigned int ) * (volatile unsigned char *)(0x37 0x20) ((1 << 1) (1 << 0))) nesc_atomic_end( nesc_atomic); diff = * (volatile unsigned char *)(unsigned int ) * (volatile int main(void) unsigned char *)(0x31 0x20) - * (volatile unsigned char *)(unsigned int ) * (volatile unsigned char *)(0x32 static inline result_t LedsC$Leds$redOff(void) nesc_atomic_t nesc_atomic = nesc_atomic_start(); LedsC$ledsOn = ~LedsC$RED_BIT; nesc_atomic_end( nesc_atomic); static inline result_t LedsC$Leds$redToggle(void) result_t rval; nesc_atomic_t nesc_atomic = nesc_atomic_start(); if (LedsC$ledsOn LedsC$RED_BIT) rval = LedsC$Leds$redOff(); else rval = LedsC$Leds$redOn(); nesc_atomic_end( nesc_atomic); return rval; inline static result_t BlinkM$Leds$redToggle(void) result = LedsC$Leds$redToggle(); static inline result_t BlinkM$Timer$fired(void) BlinkM$Leds$redToggle(); static inline result_t TimerM$Timer$default$fired(uint8_t id) inline static result_t TimerM$Timer$fired(uint8_t arg_0xa31d660) switch (arg_0xa31d660) case 0: result = BlinkM$Timer$fired(); break; default: result = TimerM$Timer$default$fired(arg_0xa31d660); static inline uint8_t TimerM$dequeue(void) if (TimerM$queue_size == 0) return NUM_TIMERS; if (TimerM$queue_head == NUM_TIMERS - 1) TimerM$queue_head = -1; for (i = 0; i < NUM_TIMERS; i) if (TimerM$mState (0x1 << i) TimerM$mTimerList[i].ticksLeft < val) val = TimerM$mTimerList[i].ticksLeft; nesc_atomic_t nesc_atomic = nesc_atomic_start(); TimerM$adjustInterval(); TimerM$queue_head; TimerM$queue_size--; return TimerM$queue[(uint8_t )TimerM$queue_head]; static inline void TimerM$signalOneTimer(void) uint8_t itimer = TimerM$dequeue(); if (itimer < NUM_TIMERS) TimerM$Timer$fired(itimer); static inline void TimerM$enqueue(uint8_t value) if (TimerM$queue_tail == NUM_TIMERS - 1) TimerM$queue_tail = -1; TimerM$queue_tail; TimerM$queue_size; TimerM$queue[(uint8_t )TimerM$queue_tail] = value; static inline void TimerM$HandleFire(void) uint8_t i; TimerM$setIntervalFlag = 1; if (TimerM$mState) for (i = 0; i < NUM_TIMERS; i) if (TimerM$mState (0x1 << i)) TimerM$mTimerList[i].ticksLeft -= TimerM$mInterval 1; if (TimerM$mTimerList[i].ticksLeft <= 2) if (TimerM$mTimerList[i].type == TIMER_REPEAT) TimerM$mTimerList[i].ticksLeft = TimerM$mTimerList[i].ticks; else TimerM$mState = ~(0x1 << i); TimerM$enqueue(i); TOS_post(TimerM$signalOneTimer); RealMain$hardwareInit(); RealMain$Pot$init(10); TOSH_sched_init(); RealMain$StdControl$init(); RealMain$StdControl$start(); nesc_enable_interrupt(); while (1) TOSH_run_task(); static uint8_t HPLPowerManagementM$PowerManagement$adjustPower(void) uint8_t mcu; if (!HPLPowerManagementM$disabled) TOS_post(HPLPowerManagementM$doAdjustment); return 0; mcu = *)(0x35 0x20); mcu = 0xe3; mcu = HPLPowerManagementM$IDLE; *)(0x35 0x20) = mcu; *)(0x35 0x20) = 1 << 5; void attribute((interrupt)) vector_15(void) nesc_atomic_t nesc_atomic = nesc_atomic_start(); if (HPLClock$set_flag) HPLClock$mscale = HPLClock$nextScale; HPLClock$nextScale = 0x8; *)(0x33 0x20) = HPLClock$nextScale; *)(0x31 0x20) = HPLClock$minterval; HPLClock$set_flag = 0; nesc_atomic_end( nesc_atomic); HPLClock$Clock$fire(); 1# Implementation of multiple timer interfaces to a single shared timer Each interface is named Each interface connects to one other module ;1#5 7 interface Leds /** * Initialize the LEDs; among other things, initialization turns them all off. */ async command result_t init(); /** * Turn the red LED on. */ async command result_t redon(); /** * Turn the red LED off. */ async command result_t redoff(); /** * Toggle the red LED. If it was on, turn it off. If it was off, * turn it on. */ async command result_t redtoggle(); ;1#5 7 module LedsC provides interface Leds; implementation uint8_t ledson; enum RED_BIT = 1, GREEN_BIT = 2, YELLOW_BIT = 4 ; async command result_t Leds.init() atomic ledson = 0; dbg(dbg_boot, "LEDS: initialized.\n"); TOSH_MAKE_RED_LED_OUTPUT(); TOSH_MAKE_YELLOW_LED_OUTPUT(); TOSH_MAKE_GREEN_LED_OUTPUT(); TOSH_SET_YELLOW_LED_PIN(); TOSH_SET_GREEN_LED_PIN(); async command result_t Leds.redOn() dbg(dbg_led, "LEDS: Red on.\n"); atomic TOSH_CLR_RED_LED_PIN(); ledson = RED_BIT; async command result_t Leds.redOff() dbg(dbg_led, "LEDS: Red off.\n"); atomic ledson = ~RED_BIT; async command result_t Leds.redToggle() result_t rval; atomic if (ledson RED_BIT) rval = call Leds.redOff(); else rval = call Leds.redOn(); return rval; 9 1K lines of C (another 1K lines of comments) = ~1.5K bytes of assembly code 9 # #" #$ static inline result_t LedsC$Leds$redToggle(void) result_t rval; nesc_atomic_t nesc_atomic = nesc_atomic_start(); if (LedsC$ledsOn LedsC$RED_BIT) rval = LedsC$Leds$redOff(); else rval = LedsC$Leds$redOn(); nesc_atomic_end( nesc_atomic); return rval; inline static result_t BlinkM$Leds$redToggle(void) static inline result_t LedsC$Leds$redOn(void) result = LedsC$Leds$redToggle(); nesc_atomic_t nesc_atomic = nesc_atomic_start(); TOSH_CLR_RED_LED_PIN(); static inline result_t BlinkM$Timer$fired(void) LedsC$ledsOn = LedsC$RED_BIT; BlinkM$Leds$redToggle(); nesc_atomic_end( nesc_atomic); static inline result_t LedsC$Leds$redOff(void) nesc_atomic_t nesc_atomic = nesc_atomic_start(); LedsC$ledsOn = ~LedsC$RED_BIT; nesc_atomic_end( nesc_atomic); Asynchronous Code (AC) Any code that is reachable from an interrupt handler Synchronous Code (SC) Any code that is ONLY reachable from a task Boot sequence Potential race conditions Asynchronous Code and Synchronous Code Asynchronous Code and Asynchronous Code Non-preemption eliminates data races among tasks nesc reports potential data races to the programmer at compile time (new with version 1.1) Use atomic statement when needed async keyword is used to declare asynchronous code to compiler ) 8

9 =(= 8, status = call CmdName(args) command CmdName(args) return status; event EvtName)(args) return status; post TskName(); status = signal EvtName(args) task void TskName Component1 Event or task call command, try again if not OK Event handler Check success flag (OK, failed, etc.) Component2 Command post task and return OK, or return busy Task task executes and signals completion with event Phase I call command with parameters command either posts task to do real work or signals busy and to try again later Phase II task completes and uses event (with return parameters) to signal completion event handler checks for success (may cause re-issue of command if failed) -. ( * ##>"> Use mixed case with the first letter of word capitalized Interfaces (Xxx.nc) Components Configuration (XxxC.nc) Module (XxxM.nc) Application top level component (Xxx.nc) Commands, Events, Tasks First letter lowercase Task names should start with the word task, commands with cmd, events with evt or event If a command/event pair form a split-phase operation, event name should be same as command name with the suffix Done or Complete Commands with TOSH_ prefix indicate that they touch hardware directly Variables first letter lowercase, caps on first letter of all sub-words Constants all caps nesc allows interfaces to fan-out to and fan-in from multiple components One provides can be connected to many uses and vice versa Wiring fans-out, fan-in is done by a combine function that merges results implementation components Main, Counter, IntToLeds, TimerC; Main.StdControl -> IntToLeds.StdControl; Main.StdControl -> Counter.StdControl; Main.StdControl -> TimerC.StdControl; Fan-out by wiring Fan-in using rcombine - rcombine is just a simple logical AND for most cases result_t ok1, ok2, ok3;. ok1 = call UARTControl.init(); ok2 = call RadioControl.init(); ok3 = call Leds.init();. return rcombine3(ok1, ok2, ok3); 0 configuration CntToLeds implementation components Main, Counter, IntToLeds, TimerC; 0 # Main.StdControl -> IntToLeds.StdControl; Main.StdControl -> Counter.StdControl; Main.StdControl -> TimerC.StdControl; Counter.Timer -> TimerC.Timer[unique("Timer")]; Counter.IntOutput -> IntToLeds.IntOutput; Which of the following goes inside the module you are implementing if we assume you are the user of the interface? NOTE: Not all of these choices are exposed through an interface. Assume those that are not exposed are implemented in your module. M ain.nc StdControl.nc StdControl.nc Counter.nc Timer.nc IntOutput.nc post taska( ); call commandb(args); signal eventc(args); taska implementation commandb implementation eventc implementation StdControl.nc TimerC.nc Timer.nc IntOutput.nc IntToLeds.nc StdControl.nc 9

10 %# module SenseM provides interface StdControl; uses interface Timer; Sense.nc interface ADC; interface StdControl as ADCControl; configuration Sense interface Leds; implementation cont d components Main, SenseM, LedsC, TimerC, DemoSensorC as Sensor; Main.StdControl -> Sensor.StdControl; Main.StdControl -> TimerC.StdControl; Main.StdControl -> SenseM.StdControl; SenseM.nc SenseM.ADC -> Sensor.ADC; SenseM.ADCControl -> Sensor.StdControl; SenseM.Leds -> LedsC.Leds; SenseM.Timer -> TimerC.Timer[unique("Timer")]; DemoSensorC.nc configuration DemoSensorC provides interface ADC; provides interface StdControl; implementation components Photo as Sensor; StdControl = Sensor; ADC = Sensor; $1# cont d implementation /* Module scoped method. Displays the lowest 3 bits to the LEDs, with RED being the most signficant and YELLOW being the least significant */ result_t display(uint16_t value) if (value 1) call Leds.yellowOn(); else call Leds.yellowOff(); if (value 2) call Leds.greenOn(); else call Leds.greenOff(); if (value 4) call Leds.redOn(); else call Leds.redOff(); command result_t StdControl.init() return call Leds.init(); command result_t StdControl.start() return call Timer.start(TIMER_REPEAT, 500); command result_t StdControl.stop() return call Timer.stop(); event result_t Timer.fired() return call ADC.getData(); async event result_t ADC.dataReady(uint16_t data) display(7-((data>>7) 0x7)); %#? module SenseTaskM provides interface StdControl; uses interface Timer; SenseTask.nc interface ADC; configuration SenseTask interface Leds; implementation cont d components Main, SenseTaskM, LedsC, TimerC, DemoSensorC as Sensor; Main.StdControl -> TimerC; Main.StdControl -> Sensor; Main.StdControl -> SenseTaskM; SenseM.nc SenseTaskM.Timer -> TimerC.Timer[unique("Timer")]; SenseTaskM.ADC -> Sensor; SenseTaskM.Leds -> LedsC; ) $1# task void processdata() implementation enum int16_t i, sum=0; log2size = 3, // log2 of buffer size atomic size=1 << log2size, // circular buffer size for (i=0; i<size; i) sizemask=size - 1, // bit mask sum = (rdata[i] >> 7); ; int8_t head; // head index display(sum >> log2size); int16_t rdata[size]; // circular buffer command result_t StdControl.init() inline void putdata(int16_t val) atomic head = 0; return call Leds.init(); int16_t p; atomic command result_t StdControl.start() p = head; return call Timer.start(TIMER_REPEAT, 500); head = (p1) sizemask; rdata[p] = val; command result_t StdControl.stop() return call Timer.stop(); result_t display(uint16_t value) event result_t Timer.fired() return call ADC.getData(); if (value 1) call Leds.yellowOn(); else call Leds.yellowOff(); async event result_t ADC.dataReady(uint16_t data) if (value 2) call Leds.greenOn(); else call Leds.greenOff(); putdata(data); if (value 4) call Leds.redOn(); post processdata(); else call Leds.redOff(); %$ 0(%# application bit byte packet Route map Router Sensor Application Active Messages Radio Packet Serial Packet Temp Photo SW HW Radio Byte UART ADC RFM Clocks Make liberal use of grep or find in files Look at example applications in the /apps directory All interfaces are in /interfaces directory Utilities are in /system, /lib, /platform, or /sensorboards Try to keep commands and events very short Avoid loops, use queues and callbacks NOTE: This is NOT the radio stack we will be using -. 10

11 2" Cover in more detail in later lectures Applications can be built to run on the PC (TOSSIM) Good to debug Does not perfectly simulate the hardware Toggling LEDs Can only get so much information from 1 LED Useful for indicating specific events (will LED be on long enough?): Radio packet transmit/receive Timer fired Sensor activation 11

Embedded OS Case Study: TinyOS

Embedded OS Case Study: TinyOS Embedded OS Case Study: TinyOS Open-source development environment Simple (and tiny) operating system TinyOS Programming language and model nesc Set of services Principal elements Scheduler/event model

More information

TinyOS an operating system for sensor nets

TinyOS an operating system for sensor nets TinyOS an operating system for sensor nets Embedded operating systems How do they differ from desktop operating systems? Event-based programming model How is concurrency handled? How are resource conflicts

More information

TinyOS an operating system for sensor nets. Embedded Operating Systems

TinyOS an operating system for sensor nets. Embedded Operating Systems TinyOS an operating system for sensor nets Embedded operating systems How do they differ from desktop operating systems? Event-based programming model How is concurrency handled? How are resource conflicts

More information

Programming TinyOS. Lesson 2. Execution Flow. Tasks. commands. Events generated by interrupts preempt tasks Tasks do not preempt tasks

Programming TinyOS. Lesson 2. Execution Flow. Tasks. commands. Events generated by interrupts preempt tasks Tasks do not preempt tasks Programming TinyOS Lesson 2 Some of the content from these slides were adapted from the Crossbow Tutorials and from the TinyOS website from Mobsys Tutorials Execution Flow Tasks events commands Hardware

More information

Operating systems for embedded systems

Operating systems for embedded systems Operating systems for embedded systems Embedded operating systems How do they differ from desktop operating systems? Programming model Process-based Event-based How is concurrency handled? How are resource

More information

Operating systems for embedded systems. Embedded Operating Systems

Operating systems for embedded systems. Embedded Operating Systems Operating systems for embedded systems Embedded operating systems How do they differ from desktop operating systems? Programming model Process-based Event-based How is concurrency handled? How are resource

More information

Programming TinyOS. Lesson 3. Basic Structure. Main.nc

Programming TinyOS. Lesson 3. Basic Structure. Main.nc Programming TinyOS Lesson 3 Some of the content from these slides were adapted from the Crossbow Tutorials and from the TinyOS website from Mobsys Tutorials Main.nc Basic Structure Interfaces (xxx.nc)

More information

Introduction to Programming Motes

Introduction to Programming Motes Introduction to Programming Motes Mohamed M. El Wakil http://mohamed.elwakil.net mohamed.elwakil@wmich.edu Wireless Sensornets (WiSe) Laboratory Department of Computer Science Western Michigan University

More information

nesc Ø Programming language for TinyOS and applications Ø Support TinyOS components Ø Whole-program analysis at compile time Ø Static language

nesc Ø Programming language for TinyOS and applications Ø Support TinyOS components Ø Whole-program analysis at compile time Ø Static language nesc Ø Programming language for TinyOS and applications Ø Support TinyOS components Ø Whole-program analysis at compile time q Improve robustness: detect race conditions q Optimization: function inlining

More information

Sensor Network Application Development ZIGBEE CONCEPTS 0

Sensor Network Application Development ZIGBEE CONCEPTS 0 Sensor Network Application Development ZIGBEE CONCEPTS 0 Cruise Summerschool Johannes Kepler University November 5-7, 2007, Linz / Austria Dipl.-Ing. riener@pervasive.jku.at Overview Structure of this

More information

nesc Prof. Chenyang Lu How should network msg be handled? Too much memory for buffering and threads

nesc Prof. Chenyang Lu How should network msg be handled? Too much memory for buffering and threads nesc Prof. Chenyang Lu CSE 521S 1 How should network msg be handled? Socket/TCP/IP? Too much memory for buffering and threads Data buffered in network stack until application threads read it Application

More information

Programming Sensor Networks

Programming Sensor Networks Programming Sensor Networks Distributed Computing Group Nicolas Burri Pascal von Rickenbach Overview TinyOS Platform Program Development Current Projects MOBILE COMPUTING 2 Sensor Nodes System Constraints

More information

Mobile and Ubiquitous Computing Routing Protocols. Niki Trigoni

Mobile and Ubiquitous Computing Routing Protocols. Niki Trigoni Mobile and Ubiquitous Computing Routing Protocols Niki Trigoni www.dcs.bbk.ac.uk/~niki niki@dcs.bbk.ac.uk Overview Intro to routing in ad-hoc networks Routing methods Link-State Distance-Vector Distance-vector

More information

TinyOS. Jan S. Rellermeyer

TinyOS. Jan S. Rellermeyer TinyOS Jan S. Rellermeyer jrellermeyer@student.ethz.ch Overview Motivation Hardware TinyOS Architecture Component Based Programming nesc TinyOS Scheduling Tiny Active Messaging TinyOS Multi Hop Routing

More information

Mobile and Ubiquitous Computing TinyOS application example. Niki Trigoni

Mobile and Ubiquitous Computing TinyOS application example. Niki Trigoni Mobile and Ubiquitous Computing TinyOS application example Niki Trigoni www.dcs.bbk.ac.uk/~niki niki@dcs.bbk.ac.uk Application Consider an application with the following functionality: The gateway node

More information

TinyOS. Lecture Overview. UC Berkeley Family of Motes. Mica2 and Mica2Dot. MTS300CA Sensor Board. Programming Board (MIB510) 1.

TinyOS. Lecture Overview. UC Berkeley Family of Motes. Mica2 and Mica2Dot. MTS300CA Sensor Board. Programming Board (MIB510) 1. Lecture Overview TinyOS Computer Network Programming Wenyuan Xu 1 2 UC Berkeley Family of Motes Mica2 and Mica2Dot ATmega128 CPU Self-programming 128KB Instruction EEPROM 4KB Data EEPROM Chipcon CC1000

More information

Self-Organization in Autonomous Sensor/Actuator Networks [SelfOrg]

Self-Organization in Autonomous Sensor/Actuator Networks [SelfOrg] Self-Organization in Autonomous Sensor/Actuator Networks [SelfOrg] Dr.-Ing. Falko Dressler Computer Networks and Communication Systems Department of Computer Sciences University of Erlangen-Nürnberg http://www7.informatik.uni-erlangen.de/~dressler/

More information

Group Members: Chetan Fegade Nikhil Mascarenhas. Mentor: Dr. Yann Hang Lee

Group Members: Chetan Fegade Nikhil Mascarenhas. Mentor: Dr. Yann Hang Lee Group Members: Chetan Fegade Nikhil Mascarenhas Mentor: Dr. Yann Hang Lee 1. Introduction 2. TinyGALS programming model 3. TinyOS 4. NesC 5. Middleware 6. Conclusion 7. References 8. Q & A Event driven

More information

Politecnico di Milano Advanced Network Technologies Laboratory. Internet of Things. TinyOS Programming and TOSSIM (and Cooja)

Politecnico di Milano Advanced Network Technologies Laboratory. Internet of Things. TinyOS Programming and TOSSIM (and Cooja) Politecnico di Milano Advanced Network Technologies Laboratory Internet of Things TinyOS Programming and TOSSIM (and Cooja) 19 March 2018 Agenda Playing with TinyOS Programming and components Blink Application

More information

Sensor Network Application Development ZIGBEE CONCEPTS 2

Sensor Network Application Development ZIGBEE CONCEPTS 2 Sensor Network Application Development ZIGBEE CONCEPTS 2 Cruise Summerschool Johannes Kepler University November 5-7, 2007, Linz / Austria Dipl.-Ing. riener@pervasive.jku.at Overview Structure of this

More information

Wireless Sensor Networks (WSN)

Wireless Sensor Networks (WSN) Wireless Sensor Networks (WSN) Operating Systems M. Schölzel Operating System Tasks Traditional OS Controlling and protecting access to resources (memory, I/O, computing resources) managing their allocation

More information

Sensors Network Simulators

Sensors Network Simulators Sensors Network Simulators Sensing Networking Qing Fang 10/14/05 Computation This Talk Not on how to run various network simulators Instead What differentiates various simulators Brief structures of the

More information

WSN PLATFORMS, HARDWARE & SOFTWARE. Murat Demirbas SUNY Buffalo

WSN PLATFORMS, HARDWARE & SOFTWARE. Murat Demirbas SUNY Buffalo WSN PLATFORMS, HARDWARE & SOFTWARE Murat Demirbas SUNY Buffalo 1 Last lecture: Why use WSNs Ease of deployment: Wireless communication means no need for a communication infrastructure setup Low-cost of

More information

WSN Programming. Introduction. Olaf Landsiedel

WSN Programming. Introduction. Olaf Landsiedel WSN Programming Introduction Olaf Landsiedel Programming WSNs What do we need to write software for WSNs? (or: for any system, like your laptop, cell phone?) Programming language With compiler, etc. OS

More information

Sensors as Software. TinyOS. TinyOS. Dario Rossi Motivation

Sensors as Software. TinyOS. TinyOS. Dario Rossi Motivation Sensors as Software Dario Rossi dario.rossi@polito.it Motivation Sensor networks Radically new computing environments Rapidly evolving hardware technology The key missing technology is system software

More information

WSN Programming. Introduction. Olaf Landsiedel. Programming WSNs. ! What do we need to write software for WSNs?! Programming language

WSN Programming. Introduction. Olaf Landsiedel. Programming WSNs. ! What do we need to write software for WSNs?! Programming language WSN Programming Introduction Lecture 2 Olaf Landsiedel Programming WSNs! What do we need to write software for WSNs?! Programming language " With compiler, etc.! OS / runtime libraries " Access to system

More information

Motivation. Introduction to Wireless Sensor Networks. Office Building Fire. EEC173B Lecture:

Motivation. Introduction to Wireless Sensor Networks. Office Building Fire. EEC173B Lecture: EEC173B Lecture: Introduction to Wireless Sensor Networks Leo Szumel lpszumel@ucdavis.edu 3/22/2006 Image credit: www.dho.edu.tr/enstitunet/snetsim Motivation The standard networking problem: How to move

More information

TinyOS. Wireless Sensor Networks

TinyOS. Wireless Sensor Networks TinyOS Laboratorio di Sistemi Wireless Ing. Telematica Università Kore Enna Ing. A. Leonardi Wireless Sensor Networks The number of nodes can be very high Nodes are densely deployed Low cost, low power

More information

CS434/534: Topics in Networked (Networking) Systems

CS434/534: Topics in Networked (Networking) Systems CS434/534: Topics in Networked (Networking) Systems WSN/Mobile Systems Yang (Richard) Yang Computer Science Department Yale University 208A Watson Email: yry@cs.yale.edu http://zoo.cs.yale.edu/classes/cs434/

More information

Politecnico di Milano Advanced Network Technologies Laboratory. TinyOS

Politecnico di Milano Advanced Network Technologies Laboratory. TinyOS Politecnico di Milano Advanced Network Technologies Laboratory TinyOS Politecnico di Milano Advanced Network Technologies Laboratory A Bit of Context on WSNs Technology, Applications and Sensor Nodes WSN

More information

Politecnico di Milano Advanced Network Technologies Laboratory. Internet of Things. TinyOS Programming and TOSSIM

Politecnico di Milano Advanced Network Technologies Laboratory. Internet of Things. TinyOS Programming and TOSSIM Politecnico di Milano Advanced Network Technologies Laboratory Internet of Things TinyOS Programming and TOSSIM 11 April 2011 Agenda Playing with TinyOS Programming and components Blink Application Using

More information

Porting TinyOS on to BTnodes

Porting TinyOS on to BTnodes Porting TinyOS on to BTnodes Attila Dogan-Kinali Winter Term 2004/2005 Student Thesis SA-2005-07 Supervisors: Jan Beutel, Matthias Dyer, Prof. Dr. Lothar Thiele Contents 1: Introduction 1 2: Related Work

More information

System Architecture Directions for Networked Sensors. Jason Hill et. al. A Presentation by Dhyanesh Narayanan MS, CS (Systems)

System Architecture Directions for Networked Sensors. Jason Hill et. al. A Presentation by Dhyanesh Narayanan MS, CS (Systems) System Architecture Directions for Networked Sensors Jason Hill et. al. A Presentation by Dhyanesh Narayanan MS, CS (Systems) Sensor Networks Key Enablers Moore s s Law: More CPU Less Size Less Cost Systems

More information

Politecnico di Milano Advanced Network Technologies Laboratory. Internet of Things. TinyOS Programming and TOSSIM (and Cooja)

Politecnico di Milano Advanced Network Technologies Laboratory. Internet of Things. TinyOS Programming and TOSSIM (and Cooja) Politecnico di Milano Advanced Network Technologies Laboratory Internet of Things TinyOS Programming and TOSSIM (and Cooja) 20 April 2015 Agenda o Playing with TinyOS n Programming and components n Blink

More information

BaseStation Based on GenericComm. Aly El-Osery Electrical Engineering Dept. New Mexico Tech Socorro, NM

BaseStation Based on GenericComm. Aly El-Osery Electrical Engineering Dept. New Mexico Tech Socorro, NM BaseStation Based on GenericComm Aly El-Osery Electrical Engineering Dept. New Mexico Tech Socorro, NM Scenario Have a node send a message to the basestation. Basestation forwards message to UART. Basestation

More information

SpiNNaker Application Programming Interface (API)

SpiNNaker Application Programming Interface (API) SpiNNaker Application Programming Interface (API) Version 2.0.0 10 March 2016 Application programming interface (API) Event-driven programming model The SpiNNaker API programming model is a simple, event-driven

More information

Static Analysis of Embedded C

Static Analysis of Embedded C Static Analysis of Embedded C John Regehr University of Utah Joint work with Nathan Cooprider Motivating Platform: TinyOS Embedded software for wireless sensor network nodes Has lots of SW components for

More information

Lecture notes Lectures 1 through 5 (up through lecture 5 slide 63) Book Chapters 1-4

Lecture notes Lectures 1 through 5 (up through lecture 5 slide 63) Book Chapters 1-4 EE445M Midterm Study Guide (Spring 2017) (updated February 25, 2017): Instructions: Open book and open notes. No calculators or any electronic devices (turn cell phones off). Please be sure that your answers

More information

Concurrency, Thread. Dongkun Shin, SKKU

Concurrency, Thread. Dongkun Shin, SKKU Concurrency, Thread 1 Thread Classic view a single point of execution within a program a single PC where instructions are being fetched from and executed), Multi-threaded program Has more than one point

More information

Lecture 15: I/O Devices & Drivers

Lecture 15: I/O Devices & Drivers CS 422/522 Design & Implementation of Operating Systems Lecture 15: I/O Devices & Drivers Zhong Shao Dept. of Computer Science Yale University Acknowledgement: some slides are taken from previous versions

More information

Embedded Systems. 5. Operating Systems. Lothar Thiele. Computer Engineering and Networks Laboratory

Embedded Systems. 5. Operating Systems. Lothar Thiele. Computer Engineering and Networks Laboratory Embedded Systems 5. Operating Systems Lothar Thiele Computer Engineering and Networks Laboratory Embedded Operating Systems 5 2 Embedded Operating System (OS) Why an operating system (OS) at all? Same

More information

Operating Systems (2INC0) 2018/19. Introduction (01) Dr. Tanir Ozcelebi. Courtesy of Prof. Dr. Johan Lukkien. System Architecture and Networking Group

Operating Systems (2INC0) 2018/19. Introduction (01) Dr. Tanir Ozcelebi. Courtesy of Prof. Dr. Johan Lukkien. System Architecture and Networking Group Operating Systems (2INC0) 20/19 Introduction (01) Dr. Courtesy of Prof. Dr. Johan Lukkien System Architecture and Networking Group Course Overview Introduction to operating systems Processes, threads and

More information

System Architecture Directions for Networked Sensors[1]

System Architecture Directions for Networked Sensors[1] System Architecture Directions for Networked Sensors[1] Secure Sensor Networks Seminar presentation Eric Anderson System Architecture Directions for Networked Sensors[1] p. 1 Outline Sensor Network Characteristics

More information

Übersicht. Laufzeitumgebungen Fallstudie TinyOS

Übersicht. Laufzeitumgebungen Fallstudie TinyOS Übersicht Beispielanwendungen Sensor-Hardware und Netzarchitektur Herausforderungen und Methoden MAC-Layer-Fallstudie IEEE 802.15.4 Energieeffiziente MAC-Layer WSN-Programmierung Laufzeitumgebungen Fallstudie

More information

Bluetooth low energy Protocol Stack

Bluetooth low energy Protocol Stack APPLICATION NOTE R01AN2768EJ0130 Rev.1.30 Introduction This manual describes how to develop an application using the Bluetooth low energy software (hereafter called BLE software), and overview of RWKE

More information

Designing Responsive and Real-Time Systems

Designing Responsive and Real-Time Systems Designing Responsive and Real-Time Systems Chapter 10 Renesas Electronics America Inc. Embedded Systems using the RX63N Rev. 1.0 00000-A Learning Objectives Most Embedded Systems have multiple real time

More information

COMP 7860 Embedded Real- Time Systems: Threads

COMP 7860 Embedded Real- Time Systems: Threads COMP 7860 Embedded Real- Time Systems: Threads Jacky Baltes Autonomous Agents Lab University of Manitoba Winnipeg, Canada R3T 2N2 Email: jacky@cs.umanitoba.ca WWW: http://www.cs.umanitoba.ca/~jacky http://aalab.cs.umanitoba.ca

More information

Embedded Software TI2726 B. 4. Interrupts. Koen Langendoen. Embedded Software Group

Embedded Software TI2726 B. 4. Interrupts. Koen Langendoen. Embedded Software Group Embedded Software 4. Interrupts TI2726 B Koen Langendoen Embedded Software Group What is an Interrupt? Asynchronous signal from hardware Synchronous signal from software Indicates the need for attention

More information

EVENT DRIVEN SENSOR SYSTEMS

EVENT DRIVEN SENSOR SYSTEMS EVENT DRIVEN SENSOR SYSTEMS GROUP MEMBERS > 1. CHETAN FEGADE 1205166348 2. NIKHIL MASCARENHAS 1204752753 MENTOR > Dr. YANN-HANG LEE Submitted on December 11, 2012 2 INDEX 1. Introduction 3 2. TinyOS...

More information

Sensor Networks. Part 3: TinyOS. CATT Short Course, March 11, 2005 Mark Coates Mike Rabbat. Operating Systems 101

Sensor Networks. Part 3: TinyOS. CATT Short Course, March 11, 2005 Mark Coates Mike Rabbat. Operating Systems 101 Sensor Networks Part 3: TinyOS CATT Short Course, March 11, 2005 Mark Coates Mike Rabbat 1 Operating Systems 101 operating system (äp ǝr āt ing sis tǝm) n. 1 software that controls the operation of a computer

More information

Concurrent Programming

Concurrent Programming Concurrent Programming Real-Time Systems, Lecture 2 Martina Maggio 19 January 2017 Lund University, Department of Automatic Control www.control.lth.se/course/frtn01 Content [Real-Time Control System: Chapter

More information

CprE 288 Introduction to Embedded Systems Exam 1 Review. 1

CprE 288 Introduction to Embedded Systems Exam 1 Review.  1 CprE 288 Introduction to Embedded Systems Exam 1 Review http://class.ece.iastate.edu/cpre288 1 Overview of Today s Lecture Announcements Exam 1 Review http://class.ece.iastate.edu/cpre288 2 Announcements

More information

Timers 1 / 46. Jiffies. Potent and Evil Magic

Timers 1 / 46. Jiffies. Potent and Evil Magic Timers 1 / 46 Jiffies Each timer tick, a variable called jiffies is incremented It is thus (roughly) the number of HZ since system boot A 32-bit counter incremented at 1000 Hz wraps around in about 50

More information

Embedded Systems Programming - PA8001

Embedded Systems Programming - PA8001 Embedded Systems Programming - PA8001 http://bit.ly/15mmqf7 Lecture 5 Mohammad Mousavi m.r.mousavi@hh.se Center for Research on Embedded Systems School of Information Science, Computer and Electrical Engineering

More information

Short Notes of CS201

Short Notes of CS201 #includes: Short Notes of CS201 The #include directive instructs the preprocessor to read and include a file into a source code file. The file name is typically enclosed with < and > if the file is a system

More information

Roadmap. Tevfik Ko!ar. CSC Operating Systems Fall Lecture - III Processes. Louisiana State University. Processes. September 1 st, 2009

Roadmap. Tevfik Ko!ar. CSC Operating Systems Fall Lecture - III Processes. Louisiana State University. Processes. September 1 st, 2009 CSC 4103 - Operating Systems Fall 2009 Lecture - III Processes Tevfik Ko!ar Louisiana State University September 1 st, 2009 1 Roadmap Processes Basic Concepts Process Creation Process Termination Context

More information

OCF for resource-constrained environments

OCF for resource-constrained environments October 11 13, 2016 Berlin, Germany OCF for resource-constrained environments Kishen Maloor, Intel 1 Outline Introduction Brief background in OCF Core Constrained environment charactertics IoTivity-Constrained

More information

Incremental Network Programming for Wireless Sensors. IEEE SECON 2004 Jaein Jeong and David Culler UC Berkeley, EECS

Incremental Network Programming for Wireless Sensors. IEEE SECON 2004 Jaein Jeong and David Culler UC Berkeley, EECS Incremental Network ming for Wireless Sensors IEEE SECON 2004 Jaein Jeong and David Culler UC Berkeley, EECS Introduction Loading to Wireless Sensors In System ming Most Common. ming time is in proportion

More information

CS201 - Introduction to Programming Glossary By

CS201 - Introduction to Programming Glossary By CS201 - Introduction to Programming Glossary By #include : The #include directive instructs the preprocessor to read and include a file into a source code file. The file name is typically enclosed with

More information

Technology Perspective

Technology Perspective Wireless Embedded Systems and Networking Foundations of IP-based Ubiquitous Sensor Networks Operating Systems for Communication-Centric Devices TinyOS-based IP-WSNs David E. Culler University of California,

More information

Concurrent Programming. Implementation Alternatives. Content. Real-Time Systems, Lecture 2. Historical Implementation Alternatives.

Concurrent Programming. Implementation Alternatives. Content. Real-Time Systems, Lecture 2. Historical Implementation Alternatives. Content Concurrent Programming Real-Time Systems, Lecture 2 [Real-Time Control System: Chapter 3] 1. Implementation Alternatives Martina Maggio 19 January 2017 Lund University, Department of Automatic

More information

Chapter 13: I/O Systems

Chapter 13: I/O Systems COP 4610: Introduction to Operating Systems (Spring 2015) Chapter 13: I/O Systems Zhi Wang Florida State University Content I/O hardware Application I/O interface Kernel I/O subsystem I/O performance Objectives

More information

Lecture Topics. Announcements. Today: Operating System Overview (Stallings, chapter , ) Next: Processes (Stallings, chapter

Lecture Topics. Announcements. Today: Operating System Overview (Stallings, chapter , ) Next: Processes (Stallings, chapter Lecture Topics Today: Operating System Overview (Stallings, chapter 2.1-2.4, 2.8-2.10) Next: Processes (Stallings, chapter 3.1-3.6) 1 Announcements Consulting hours posted Self-Study Exercise #3 posted

More information

Process Coordination and Shared Data

Process Coordination and Shared Data Process Coordination and Shared Data Lecture 19 In These Notes... Sharing data safely When multiple threads/processes interact in a system, new species of bugs arise 1. Compiler tries to save time by not

More information

Wireless Sensor Networks. Introduction to the Laboratory

Wireless Sensor Networks. Introduction to the Laboratory Wireless Sensor Networks Introduction to the Laboratory c.buratti@unibo.it +39 051 20 93147 Office Hours: Tuesday 3 5 pm @ Main Building, third floor Credits: 6 Outline MC1322x Devices IAR Embedded workbench

More information

CS 471 Operating Systems. Yue Cheng. George Mason University Fall 2017

CS 471 Operating Systems. Yue Cheng. George Mason University Fall 2017 CS 471 Operating Systems Yue Cheng George Mason University Fall 2017 Outline o Process concept o Process creation o Process states and scheduling o Preemption and context switch o Inter-process communication

More information

Four Components of a Computer System

Four Components of a Computer System Four Components of a Computer System Operating System Concepts Essentials 2nd Edition 1.1 Silberschatz, Galvin and Gagne 2013 Operating System Definition OS is a resource allocator Manages all resources

More information

Linux Device Drivers Interrupt Requests

Linux Device Drivers Interrupt Requests Overview 1 2 3 Installation of an interrupt handler Interface /proc 4 5 6 7 primitive devices can be managed only with I/O regions, most devices require a more complicated approach, devices cooperate with

More information

Putting it All Together

Putting it All Together EE445M/EE360L.12 Embedded and Real-Time Systems/ Real-Time Operating Systems : Commercial RTOS, Final Exam, Review 1 Putting it All Together Micrium μcos-ii Reference: www.micrium.com Application Note

More information

This application note describes the specification of the JPEG codec unit (in the following, JCU) driver of SH7268/SH7269.

This application note describes the specification of the JPEG codec unit (in the following, JCU) driver of SH7268/SH7269. APPLICATION NOTE SH7268/7269 Group JPEG Codec Unit "JCU" Sample Driver R01AN2338EJ0104 Rev. 1.04 Introduction This application note describes the specification of the JPEG codec unit (in the following,

More information

Lecture 4: Memory Management & The Programming Interface

Lecture 4: Memory Management & The Programming Interface CS 422/522 Design & Implementation of Operating Systems Lecture 4: Memory Management & The Programming Interface Zhong Shao Dept. of Computer Science Yale University Acknowledgement: some slides are taken

More information

Process Scheduling Queues

Process Scheduling Queues Process Control Process Scheduling Queues Job queue set of all processes in the system. Ready queue set of all processes residing in main memory, ready and waiting to execute. Device queues set of processes

More information

Chapter 13: I/O Systems. Operating System Concepts 9 th Edition

Chapter 13: I/O Systems. Operating System Concepts 9 th Edition Chapter 13: I/O Systems Silberschatz, Galvin and Gagne 2013 Chapter 13: I/O Systems Overview I/O Hardware Application I/O Interface Kernel I/O Subsystem Transforming I/O Requests to Hardware Operations

More information

Chapter 3: Processes. Operating System Concepts 8 th Edition,

Chapter 3: Processes. Operating System Concepts 8 th Edition, Chapter 3: Processes, Silberschatz, Galvin and Gagne 2009 Chapter 3: Processes Process Concept Process Scheduling Operations on Processes Interprocess Communication 3.2 Silberschatz, Galvin and Gagne 2009

More information

CS 333 Introduction to Operating Systems. Class 3 Threads & Concurrency. Jonathan Walpole Computer Science Portland State University

CS 333 Introduction to Operating Systems. Class 3 Threads & Concurrency. Jonathan Walpole Computer Science Portland State University CS 333 Introduction to Operating Systems Class 3 Threads & Concurrency Jonathan Walpole Computer Science Portland State University 1 The Process Concept 2 The Process Concept Process a program in execution

More information

AC OB S. Multi-threaded FW framework (OS) for embedded ARM systems Torsten Jaekel, June 2014

AC OB S. Multi-threaded FW framework (OS) for embedded ARM systems Torsten Jaekel, June 2014 AC OB S Multi-threaded FW framework (OS) for embedded ARM systems Torsten Jaekel, June 2014 ACOBS ACtive OBject (operating) System Simplified FW System for Multi-Threading on ARM embedded systems ACOBS

More information

19: I/O. Mark Handley. Direct Memory Access (DMA)

19: I/O. Mark Handley. Direct Memory Access (DMA) 19: I/O Mark Handley Direct Memory Access (DMA) 1 Interrupts Revisited Connections between devices and interrupt controller actually use interrupt lines on the bus rather than dedicated wires. Interrupts

More information

Embedded System Curriculum

Embedded System Curriculum Embedded System Curriculum ADVANCED C PROGRAMMING AND DATA STRUCTURE (Duration: 25 hrs) Introduction to 'C' Objectives of C, Applications of C, Relational and logical operators, Bit wise operators, The

More information

The Emergence of Networking Abstractions and Techniques in TinyOS

The Emergence of Networking Abstractions and Techniques in TinyOS The Emergence of Networking Abstractions and Techniques in TinyOS Sam Madden MIT CSAIL madden@csail.mit.edu With Phil Levis, David Gay, Joe Polastre, Rob Szewczyk, Alec Woo, Eric Brewer, and David Culler

More information

CS 318 Principles of Operating Systems

CS 318 Principles of Operating Systems CS 318 Principles of Operating Systems Fall 2017 Lecture 5: Thread Ryan Huang Administrivia HW1 solution released on Piazza resources Lab 0 grading - In progress - Cheating policy Lab 1 review session

More information

A Fast Review of C Essentials Part I

A Fast Review of C Essentials Part I A Fast Review of C Essentials Part I Structural Programming by Z. Cihan TAYSI Outline Program development C Essentials Functions Variables & constants Names Formatting Comments Preprocessor Data types

More information

The Big Picture So Far. Chapter 4: Processes

The Big Picture So Far. Chapter 4: Processes The Big Picture So Far HW Abstraction Processor Memory IO devices File system Distributed systems Example OS Services Process management, protection, synchronization Memory Protection, management, VM Interrupt

More information

Using kgdb and the kgdb Internals

Using kgdb and the kgdb Internals Using kgdb and the kgdb Internals Jason Wessel jason.wessel@windriver.com Tom Rini trini@kernel.crashing.org Amit S. Kale amitkale@linsyssoft.com Using kgdb and the kgdb Internals by Jason Wessel by Tom

More information

I/O Systems. Amir H. Payberah. Amirkabir University of Technology (Tehran Polytechnic)

I/O Systems. Amir H. Payberah. Amirkabir University of Technology (Tehran Polytechnic) I/O Systems Amir H. Payberah amir@sics.se Amirkabir University of Technology (Tehran Polytechnic) Amir H. Payberah (Tehran Polytechnic) I/O Systems 1393/9/15 1 / 57 Motivation Amir H. Payberah (Tehran

More information

Chapter 3: Processes. Operating System Concepts Essentials 2 nd Edition

Chapter 3: Processes. Operating System Concepts Essentials 2 nd Edition Chapter 3: Processes Silberschatz, Galvin and Gagne 2013 Chapter 3: Processes Process Concept Process Scheduling Operations on Processes Interprocess Communication Examples of IPC Systems Communication

More information

The Big Picture So Far. Chapter 4: Processes

The Big Picture So Far. Chapter 4: Processes The Big Picture So Far HW Abstraction Processor Memory IO devices File system Distributed systems Example OS Services Process management, protection, synchronization Memory Protection, management, VM Interrupt

More information

Hardware OS & OS- Application interface

Hardware OS & OS- Application interface CS 4410 Operating Systems Hardware OS & OS- Application interface Summer 2013 Cornell University 1 Today How my device becomes useful for the user? HW-OS interface Device controller Device driver Interrupts

More information

Emulation 2. G. Lettieri. 15 Oct. 2014

Emulation 2. G. Lettieri. 15 Oct. 2014 Emulation 2 G. Lettieri 15 Oct. 2014 1 I/O examples In an emulator, we implement each I/O device as an object, or a set of objects. The real device in the target system is connected to the CPU via an interface

More information

Processes. Johan Montelius KTH

Processes. Johan Montelius KTH Processes Johan Montelius KTH 2017 1 / 47 A process What is a process?... a computation a program i.e. a sequence of operations a set of data structures a set of registers means to interact with other

More information

Faculty of Electrical Engineering, Mathematics, and Computer Science Delft University of Technology

Faculty of Electrical Engineering, Mathematics, and Computer Science Delft University of Technology Faculty of Electrical Engineering, Mathematics, and Computer Science Delft University of Technology exam Embedded Software TI2726-B January 28, 2019 13.30-15.00 This exam (6 pages) consists of 60 True/False

More information

Chapter 3: Processes. Operating System Concepts 8th Edition

Chapter 3: Processes. Operating System Concepts 8th Edition Chapter 3: Processes Chapter 3: Processes Process Concept Process Scheduling Operations on Processes Interprocess Communication Examples of IPC Systems Communication in Client-Server Systems 3.2 Objectives

More information

Module 11: I/O Systems

Module 11: I/O Systems Module 11: I/O Systems Reading: Chapter 13 Objectives Explore the structure of the operating system s I/O subsystem. Discuss the principles of I/O hardware and its complexity. Provide details on the performance

More information

Operating Systems. Operating System Structure. Lecture 2 Michael O Boyle

Operating Systems. Operating System Structure. Lecture 2 Michael O Boyle Operating Systems Operating System Structure Lecture 2 Michael O Boyle 1 Overview Architecture impact User operating interaction User vs kernel Syscall Operating System structure Layers Examples 2 Lower-level

More information

Processes. Overview. Processes. Process Creation. Process Creation fork() Processes. CPU scheduling. Pål Halvorsen 21/9-2005

Processes. Overview. Processes. Process Creation. Process Creation fork() Processes. CPU scheduling. Pål Halvorsen 21/9-2005 INF060: Introduction to Operating Systems and Data Communication Operating Systems: Processes & CPU Pål Halvorsen /9-005 Overview Processes primitives for creation and termination states context switches

More information

Lecture 3. Introduction to Real-Time kernels. Real-Time Systems

Lecture 3. Introduction to Real-Time kernels. Real-Time Systems Real-Time Systems Lecture 3 Introduction to Real-Time kernels Task States Generic architecture of Real-Time kernels Typical structures and functions of Real-Time kernels Last lecture (2) Computational

More information

Interrupts & Interrupt Service Routines (ISRs)

Interrupts & Interrupt Service Routines (ISRs) ECE3411 Fall 2015 Lecture 2c. Interrupts & Interrupt Service Routines (ISRs) Marten van Dijk, Syed Kamran Haider Department of Electrical & Computer Engineering University of Connecticut Email: vandijk,

More information

A process. the stack

A process. the stack A process Processes Johan Montelius What is a process?... a computation KTH 2017 a program i.e. a sequence of operations a set of data structures a set of registers means to interact with other processes

More information

! The Process Control Block (PCB) " is included in the context,

! The Process Control Block (PCB)  is included in the context, CSE 421/521 - Operating Systems Fall 2012 Lecture - III Processes Tevfik Koşar Roadmap Processes Basic Concepts Process Creation Process Termination Context Switching Process Queues Process Scheduling

More information

A Predictable RTOS. Mantis Cheng Department of Computer Science University of Victoria

A Predictable RTOS. Mantis Cheng Department of Computer Science University of Victoria A Predictable RTOS Mantis Cheng Department of Computer Science University of Victoria Outline I. Analysis of Timeliness Requirements II. Analysis of IO Requirements III. Time in Scheduling IV. IO in Scheduling

More information

Outline. Threads. Single and Multithreaded Processes. Benefits of Threads. Eike Ritter 1. Modified: October 16, 2012

Outline. Threads. Single and Multithreaded Processes. Benefits of Threads. Eike Ritter 1. Modified: October 16, 2012 Eike Ritter 1 Modified: October 16, 2012 Lecture 8: Operating Systems with C/C++ School of Computer Science, University of Birmingham, UK 1 Based on material by Matt Smart and Nick Blundell Outline 1 Concurrent

More information