IN2305-II Embedded Programming

IN2305-IIEmbedded Programmingprof.dr.ir. Arjan J.C. van Gemund

Embedded Software LabSoftware Technology Dept.

Arjan van Gemund?BS Physics EngineeringMS, PhD Computer Science

DSM (Embedded Systems HW + SW)TNO (High-Performance Computing)TUD (EE, Computer Architecture)TUD (CS, Software Technology, 0.4 fte Prof Emb SW)

2 kids, dog, cat, living in Ravenswoud (Fr)http://www.st.ewi.tudelft.nl/~gemund/

In2305-ii? Info: via http://www.st.ewi.tudelft.nl/~gemund/

Embedded Systems?ES =computer system (HW+SW) embedded within another system largely determining its functionality

Telegraphout-of-order datanegotiate with multiple clients (print jobs)service status requestsadapt to different printersresponse time to certain requestsdata throughput / buffering

Telegraphnetworkprinter

Underground Tank Monitoring Systemguard levels, detect leaksextremely low-cost design (proc)simple arithmetic - CPU hog - response time problem

tank 1tank NEmb SysbuttonsLCDdispprinter. . .level CHlevel H2Otemperature

Cruise Control System (Lab Project)stabilize car speed when engagedextremely low processor cycle budgetsmall control loop jitter due to other activitiesreliable operationEmb Sys

Embedded Systems Boomprovides functionality (intelligence) of almost everythingannual growth 25-60% (Emb Linux > 60%)100 x PC marketaccounts for 25-40% costs in automotivevery large societal dependencevery high performance demands

Embedded Software Crisisfunctionality migrates from HW to SWexisting cores combined with FPGAs, rather than ASICsprogramming-centered design (incl. HDLs)TV, mobile, car, .. 10+ MLOC code, expon. growth!despite SW engineering: 1 10 bug / KLOC100 G$ / yr on bugs (Mars Polar Lander, Mars Climate Orbiter, Ariane 5, Patriot, USS Yorktown, Therac-25, ... )

Embedded Programmingmore difficult than classical programming interaction with hardware real-time issues (timing)concurrency (multiple threads, scheduling, deadlock)need to understand underlying RTOS principlesevent-driven programming (interrupts)

lots of (novice) errors (hence the crisis)so thats why we have this course already in 2nd year

Examplenave automatic door task (thread):

for (;;) { while (inp(sensor) != 1) ; // wait to open out(door,OPEN); while (inp(sensor) == 0) ; // wait to close sleep(1000); out(door,CLOSE); // close after timeout}what are the (many) issues? (discussed on the next slides)

Specification: FSM (Moore)0: door, timer_enable1: door, timer_enable2: door, timer_enable

s = sensor, t = timeoutred transition absent in example code-> door can slam into your face!tmretclk

How to Program?VHDL: FSM in entity door_controllerpros: separate hardware: no problems sharing a processor with other tasks (scheduling, priorities)fast and synchronous programming model: high frequency clocked process with simple polling for s and tcons: VHDL to cumbersome / prohibitive for large applicationslots of legacy code written in, e.g., C

What if C?C: FSM in a task door_controllerpros: simple (sequential) programming modelcons: cant be invoked periodically by a high-frequency clock (timer) because of polling overheadbusy waiting (polling) is not an option (see above) -> concurrent (event) programming (e.g., using interrupts and semaphores)

so the while loops in the example code are wrongonly use a delay which is not based on busy waitergo: interrupt programming, using an RTOS

A C Solutionvoid isr_sensor(void) // process sensor IRQ{ OS_Post(semaphore_event_on_s); // signal s changed}

void task_door_controller(void) { for (;;) { OS_Pend(semaphore_event_on_s); // wait for s = 1 out(door,OPEN); do { OS_Pend(semaphore_event_on_s); // wait for s = 0 OS_Delay(1000); } while (inp(sensor) != 0); // timeout out(door,CLOSE); }}

Issuesefficient, no busy waiting any more (OS_Pend, OS_Delay)still, code is not correct: interrupts (entering/leaving persons within delay period are not properly handled, and are only accumulated in semaphore (wrong)cannot afford to just sit in a delay, need control flow flexibility of a real FSM, i.e., to jump, AND ..the ability to simultaneously wait for two events (s or t):void isr_sensor_and_timer(void) { // handle both IRQs OS_Post(s_or_t); // either s or t changed}

Alternative C Solutionvoid task_door_controller(void) { for (;;) { switch (state) { STDBY: OS_Pend(s_or_t); // wait for 0-1 out(door,OPEN); state = OPEN; OPEN: OS_Pend(s_or_t); // wait for 1-0 timer_enable(); state = TIMING; TIMING: OS_Pend(s_or_t); // wait for 0-1 or t if (inp(sensor) == 0) { // timeout out(door,CLOSE); timer_disable(); state = STDBY; } else state = OPEN;}}}

ConclusionEmbedded programming is not so easyNor in C nor VHDLC: Concurrency needed (seq. prog. model): RTOS supportEvent programming needed: interrupts + RTOS support

Learn the basics of interrupt programming and using an RTOS (in C)Learning is (lots of) programming!Lab: simple Cruise Control subsystemHardware: FPGA board with 32 bit soft core + C tools

In2305 via: http://www.st.ewi.tudelft.nl/~gemund/

Lab Assignment: Cruise Controlhttp://auto.howstuffworks.com/cruise-control.htmengage button: engage cruise controlinc button: increment throttle or cruising speeddec button: decrement throttle or cruising speedspeed and throttle on SSDmonitor link to PC terminal (status, logging, ..)

Cruise Control Setupm(speed)(vehicle)Embed. Syst.(FPGA board)ab(throttle)PC host(Linux)encoderDC motor

ES SetupincengagedecPWMdecodermabsetpointspeedcountthrottlemab

Demo

Demo ..

Finally ..Grade = f (MC exam, Quiz, Lab)Without lab NO gradeLab: presence mandatory, AWOL -> no grade!Lab enrollment: email TA ASAP

In2305-ii first time edition! Accept glitches ..Response group (3 student volunteers via email)

In2305 via: http://www.st.ewi.tudelft.nl/~gemund/

Credits: Mark Dufour, Sijmen Woutersen