IN2305-II Embedded Programming prof.dr.ir. Arjan J.C. van Gemund Embedded Software Lab Software Technology Dept.

in2305-II: L12 Arjan van Gemund? BS Physics Engineering MS, 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)

in2305-II: L13 In2305-ii? Info: via

in2305-II: L14 Embedded Systems? ES =computer system (HW+SW) embedded within another system largely determining its functionality printing system user I/F printer netw I/F

in2305-II: L15 Telegraph out-of-order data negotiate with multiple clients (print jobs) service status requests adapt to different printers response time to certain requests data throughput / buffering Telegraph networkprinter

in2305-II: L16 Underground Tank Monitoring System guard levels, detect leaks extremely low-cost design (proc) simple arithmetic - CPU hog - response time problem tank 1 tank N Emb Sys buttonsLCD disp printer... level CH level H 2 O temperature

in2305-II: L17 Cruise Control System (Lab Project) stabilize car speed when engaged extremely low processor cycle budget small control loop jitter due to other activities reliable operation speedo meter gas pedal Emb Sys buttonsSSD

in2305-II: L18 Embedded Systems Boom provides functionality (intelligence) of almost everything annual growth 25-60% (Emb Linux > 60%) 100 x PC market accounts for 25-40% costs in automotive very large societal dependence very high performance demands

in2305-II: L19 Embedded Software Crisis functionality migrates from HW to SW existing cores combined with FPGA’s, rather than ASICs programming-centered design (incl. HDLs) TV, mobile, car, MLOC code, expon. growth! despite SW engineering: 1 – 10 bug / KLOC 100 G$ / yr on bugs (Mars Polar Lander, Mars Climate Orbiter, Ariane 5, Patriot, USS Yorktown, Therac-25,... )

in2305-II: L110 Embedded Programming more difficult than “classical” programming interaction with hardware real-time issues (timing) concurrency (multiple threads, scheduling, deadlock) need to understand underlying RTOS principles event-driven programming (interrupts) lots of (novice) errors (hence the crisis) so that’s why we have this course already in 2 nd year

in2305-II: L111 Example naïve 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)

in2305-II: L112 Specification: FSM (Moore) 0: door’, timer_enable’ 1: door, timer_enable’ 2: door, timer_enable s = sensor, t = timeout s’ 10 s 2 s s t.s’ red transition absent in example code -> door can slam into your face! tmret clk

in2305-II: L113 How to Program? VHDL: FSM in entity door_controller pros: 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 t cons: VHDL to cumbersome / prohibitive for large applications lots of legacy code written in, e.g., C

in2305-II: L114 A VHDL Solution process -- fsm begin wait until rising_edge(clk); case state is when S0 => if (s = ‘1’) then state <= S1; when S1 => if (s = ‘0’) then state <= S2; when S2 => if (s = ‘1’) then – red arc in FSM state <= S1; if (t = ‘1’ and s = ‘0’) then state <= S0; end case; door <= ‘1’ when (state != S0) else ‘0’; timer_enable <= ‘1’ when (state = S2) else ‘0’; end process;

in2305-II: L115 What if C? C: FSM in a task door_controller pros: simple (sequential) programming model cons: can’t be invoked periodically by a high-frequency clock (timer) because of polling overhead busy 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 wrong only use a delay which is not based on busy wait ergo: interrupt programming, using an RTOS

in2305-II: L116 A C Solution void 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); }

in2305-II: L117 Issues efficient, 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 }

in2305-II: L118 Alternative C Solution void 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; }}}

in2305-II: L119 Conclusion Embedded programming is not so easy Nor in C nor VHDL C: Concurrency needed (seq. prog. model): RTOS support Event 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 subsystem Hardware: FPGA board with 32 bit soft core + C tools In2305 via:

in2305-II: L120 Lab Assignment: Cruise Control engage button: engage cruise control inc button: increment throttle or cruising speed dec button: decrement throttle or cruising speed speed and throttle on SSD monitor link to PC terminal (status, logging,..) throttle speed vehiclecontroller inc/dec engage

in2305-II: L121 Cruise Control Setup m (speed) (vehicle) Embed. Syst. (FPGA board) a b (throttle) PC host (Linux) encoder DC motor

in2305-II: L122 ES Setup controller inc engage dec 32 PWM decoder m a b setpoint speed count throttle 32 m a b

in2305-II: L123 Demo Demo..

in2305-II: L124 Finally.. Grade = f (MC exam, Quiz, Lab) Without lab NO grade Lab: presence mandatory, AWOL -> no grade! Lab enrollment: TA ASAP In2305-ii first time edition! Accept glitches.. Response group (3 student volunteers – via ) In2305 via: Credits: Mark Dufour, Sijmen Woutersen