1. Embedded Software Design Peter R. Wihl (former Guest Lecturer)

2. Overview Data flow practices (Throughput) Real time systems Software design overview Communication protocols An example software design Feel free to ask questions at any time

3. Execution Flow A diagram that describes the major steps in the sequential software flow. Illustrates each logical step and decision point in the overall design of the software. Provides a starting point for the design of the software. Is to embedded software as logical architecture is to hardware. Is mapped later to Routines, Functions or Objects

4. Before Designing Execution Flow 1.Identify which logical architectural modules are mapped to software. 2.Identify what time period all logical software function must be completed in. 3.Identify any additional overhead functionality due to modules mapped to software and/or characteristics of the physical design. ie. Polling/Interrupts

5. Logical Design Architecture Example

6. Physical Architecture Mapping

7. Logical Design Architecture Example

8. Role of Microcontroller Read 16-bit word from ADC Calculate Error Correction Code (2-bit) Inject possible error Detect if there is an error If there is an error correct it Write new 16-bit word to DAC

9. Execution Flow Diagram

10. Data Throughput in SW What is synchronous data flow? –Data arrives at regular intervals What is asynchronous data flow? –Data does not arrive at regular intervals What is isochronous data flow? –Data must be delivered within certain time constraints

11. Data Flow Practices Polling Interrupt triggered (blocking) Interrupt triggered (non-blocking) Event driven –Often referred to as interrupt driven

12. Sample Problem Need to receive 16 bytes into a buffer and then process the buffer Bytes arrive asynchronously

13. Polling Overview

14. Polling main do forever count = 0 while count < 16 while byte not ready nop get byte buffer[count] = byte incr count process buffer

15. Interrupt (Blocking) Overview

16. Interrupt Triggered (Blocking) interrupt rx_byte disable interrupts count = 0 while count < 16 get byte buffer[count] = byte incr count process buffer enable interrupts return main enable interrupts do forever nop

17. Interrupt (Non-Blocking) Overview

18. Interrupt Triggered (Non-blocking) interrupt rx_byte if count < 16 get byte buffer[count] = byte incr count else if count = 16 process buffer count = 0 return main count = 0 enable interrupts do forever nop

19. Event Driven Overview

20. Event Driven interrupt rx_byte if count < 16 get byte buffer[count] = byte incr count return main count = 0 enable interrupts do forever if count = 16 process buffer count = 0

21. Real Time Hard real time –Absolute deterministic response to an event Soft real time –Average response to an event

23. Embedded Software Practices Peter R. Wihl ECE 164 Spring 2004

24. Overview Data flow practices Real time systems Communication protocols Software design overview An example software design Feel free to ask questions at any time

25. Data Flow Types What is synchronous data flow? What is asynchronous data flow? What is isochronous data flow?

26. Data Flow Types What is synchronous data flow? –Data arrives at regular intervals What is asynchronous data flow? –Data does not arrive at regular intervals What is isochronous data flow? –Data must be delivered within certain time constraints

27. Data Flow Practices Polling Interrupt triggered (blocking) Interrupt triggered (non-blocking) Event driven –Often referred to as interrupt driven

28. Sample Problem Need to receive 16 bytes into a buffer and then process the buffer Bytes arrive asynchronously

29. Polling main do forever count = 0 while count < 16 while byte not ready nop get byte buffer[count] = byte incr count process buffer

30. Interrupt Triggered (Blocking) interrupt rx_byte disable interrupts count = 0 while count < 16 get byte buffer[count] = byte incr count process buffer enable interrupts return main enable interrupts do forever nop

31. Interrupt Triggered (Non-blocking) interrupt rx_byte if count < 16 get byte buffer[count] = byte incr count else if count = 16 process buffer count = 0 return main count = 0 enable interrupts do forever nop

32. Event Driven interrupt rx_byte if count < 16 get byte buffer[count] = byte incr count return main count = 0 enable interrupts do forever if count = 16 process buffer count = 0

33. Real Time Hard real time –Absolute deterministic response to an event Soft real time –Average response to an event

34. Trick Questions Which is better, hard or soft real time? Which design methods are hard real time? Which design methods are soft real time?

35. Communication Protocols What is a communication protocol? –An established set of conventions by which multiple systems exchange data The speech analogy –The sounds you can make are the communication medium –The language you use is the protocol

36. Sample Protocol ByteData 0Synchronization 1Payload size 2…2+sizePayload 2+size+1Packet checksum

37. Protocol Interrupt interrupt rx_byte get byte checksum = byte  checksum switch (state) SYNC if byte = sync checksum = byte state = SIZE SIZE size = byte if size > 0 count = 0 state = PAYLOAD else state = CHECKSUM PAYLOAD buffer[count] = byte incr count if count = size state = CHECKSUM CHECKSUM if checksum = 0 state = ACCEPT else state = SYNC ACCEPT drop byte return

38. Protocol Main main state = SYNC enable interrupts do forever if state = ACCEPT process buffer state = SYNC This is a simple event loop that provides mutual exclusion for the buffer

39. Time For A Break

40. Software Design Overview Requirements Analysis Architecture Design Implementation Module Testing Design Validation Testing

41. Example Problem I want to build a Heads Up Display for my car. I would like to see both my engine RPM and fuel economy on my windshield. My car has a serial diagnostic interface that provides this data.

42. Requirements System shall have a Heads Up Display (HUD) System shall interface with vehicle’s onboard diagnostic system HUD shall display current RPM HUD shall display current fuel economy (MPG)

43. Hardware Constraints Vehicle’s onboard diagnostic system –Needs a wake-up signal sent every 1 second –Operates at 10,500 bps Heads Up Display –256x128 pixels –Full display must be calculated and mirrored –Operates at 115,200 bps

44. Processor Requirements Processor shall have 2 UARTs 1.Vehicle’s onboard diagnostic system 2.Heads Up Display Processor shall have a timer –Vehicle’s onboard diagnostic system wake-up Processor shall have more than 8192 bytes of memory –Processed display image (4096 bytes) –Mirrored display image (4096 bytes)

45. Hardware Design

46. Software Architecture

47. Software Design Modules –Vehicle Diagnostic Interface (VDI) –RPM Data Formatting (RDF) –MPG Data Formatting (MPG) –Display Processing (DP) –Display Control Interface (DCI)

48. Software Design Modules –Vehicle Diagnostic Interface (VDI) –RPM Data Formatting (RDF) –MPG Data Formatting (MPG) –Display Processing (DP) –Display Control Interface (DCI) Main/Initialization

49. Vehicle Diagnostic Interface

50. interrupt rx_byte … rx_state = ACCEPT … return extract_data if data type = RPM extract RPM data rpm_format(data) else if data type = MPG extract MPG data mpg_format(data) return main … do forever … if rx_state = ACCEPT extract_data rx_state = SYNC …

51. Vehicle Diagnostic Interface interrupt timer wakeup = 1 return tx_wakeup send wakeup control block return main … do forever … if wakeup = 1 tx_wakeup wakeup = 0 …

52. RPM Data Formatting

53. MPG Data Formatting

54. Display Processing

55. Display Control Interface

56. Test Plan 1.Test functionality of every module 2.Test functionality of every module interaction 3.Test functionality of the final system

57. Implementation This is when you actually write your code.

58. Module Testing Simple implementations to test a single module or module interaction Total testing code will often be larger than the actual system’s code base Is this good or bad?

59. Design Verification Testing A scripted test plan that guides a tester through use of the system A table with the following: –Every system requirement –Whether or not the requirement was met