1. Embedded Systems Basic Design Using a Real- Time Operating System C.-Z. Yang http://syslab.cse.yzu.edu.tw/~czyang Sept.-Dec. 2001

2. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System2 Something You Must Be Aware This unit assumes that your system will include an RTOS. You have to decide whether the RTOS architecture is the appropriate one. The embedded-system software design is an endeavor that has as many exceptions as it has rules.

3. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System3 Real-Time Requirements

4. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System4 Overview Two fundamental questions –What must the system do? –How fast must it do it? You must know how critical each timing is. Two categories –Hard real-time System with absolute deadlines –Soft real-time Systems that demand good response but that allow some fudge in the deadlines.

5. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System5 Overview To design effectively, you must know something about the hardware. You must have some feel for the speed of your microprocessor. –Unfortunately, only experience and experimentation can help you with this.

6. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System6 Design Principles

7. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System7 General Operation Embedded systems very commonly have nothing to do until the passage of time or some external event requires a response. Interrupts tend to be the driving force of embedded software.

8. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System8 A Telegraph System The insight of the system

9. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System9 Interrupt Routines Write short interrupt routines –Since even the lowest-priority interrupt routine is executed in preference to the highest-priority task code, writing longer interrupt routines translates directly slower task- code response. –Interrupt routines tend to be more bug-prone and harder to debug than task code. Since the timing requirements vary, it makes sense for the interrupt routine to do the immediate actions and then to signal a task to do the rest.

10. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System10 An Example The system has the following characteristics –The system must respond to commands coming from a serial port. –Commands always end with a carriage return. –Commands arrive one at a time; the next command will not arrive until the system responds to the previous one. –The serial port hardware can only store one received character at a time, and characters may arrive quickly. –The system can respond to commands relatively slowly.

11. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System11 Two Programming Extremes One way is to do all of the work in the interrupt routine that receives characters. –Long and complex –Difficult to debug –Slow response Another extreme is to simply forward every character in an RTOS message to a command parsing task.

12. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System12 Short ISR Theoretically Forwarding messages to a task is an excellent architecture. However, –The ISR will send a lot of messages. –Putting messages onto an RTOS queue is not instantaneous. –If the characters arrive quickly enough, the ISR might not be able to keep up.

13. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System13 One Possible Compromise Design An interrupt routine saves the received characters in a buffer and watches for the carriage return that ends each command. –When the carriage return arrives, the ISR sends a single message to the command parsing task, which reads the characters out of the buffer. –Therefore, the ISR is short enough, but the system need not send so many messages.

14. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System14 The Code MailBox

15. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System15 How Many Tasks? One of the first problems in an embedded- system design is to divide your system’s work into RTOS tasks. Am I better off with more tasks or with fewer tasks?

16. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System16 A Large Number of Tasks The advantages –With more tasks you have better control of the relative response times of the different parts of your system’s work. –With more tasks your system can be somewhat more modular. –With more tasks you can sometimes encapsulate data more effectively.

17. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System17 A Large Number of Tasks The disadvantages –With more tasks you are likely to have more data shared among two or more tasks. –With more tasks you are likely to have more requirements to pass messages from one task to another through pipes, mailboxes, queues, and so on. –Each task requires a stack; therefore, with more tasks you will probably need more memory, at least for stack space, and perhaps for intertask messages as well. –Each time the RTOS switches tasks, a certain amount of microprocessor time evaporates for context switching.

18. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System18 A Large Number of Tasks The disadvantages –More tasks probably means more calls to the RTOS. –Your system runs faster if it avoids calling the RTOS functions. –The irony rule Once you decide to use an RTOS, your best design is often the one that uses it least.

19. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System19 The Most Perverse Thing The disadvantages of having more tasks are visited upon you almost automatically. You reap the advantages only if you divide your system into tasks carefully. The moral –Other things being equal, use as few tasks as you can get away with; add more tasks to your design only for clear reasons.

20. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System20 The Time for Adding More Tasks - 1 One obvious reason for having multiple tasks is to be able to assign higher priorities to parts of the work with tighter response time requirements. If some part of the code need better response, this part should be separated into another task.

21. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System21 The Time for Adding More Tasks - 2 It often makes sense to have a separate task to deal with hardware shared by different parts of the system. Task1 Task2 ErrorsTask

22. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System22 A Laser Printer Example The task graph

23. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System23 Another Example - Flash Memory The task vHandleFalshTask

24. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System24 Some Suggestions Have many small tasks, so that each is simple. –Trade-off: simple but a lot of shared data –Also, your system will have a lot of intertask communications. Have separate tasks for work that needs to be done in response to separate stimuli.

25. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System25 Some Suggestions The sample code

26. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System26 Recommended Task Structure The pseudo code

27. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System27 Advantages of This Task Architecture The task blocks in only one place. –When another task puts a request on the task’s queue, this task is not off waiting for some other event that may or may not happen in a timely fashion. When there is nothing for this task to do, its input queue will be empty and the task will block and use up no microprocessor time. This task does not have public data that other tasks can share.

28. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System28 Avoid Creating and Destroying Tasks Every RTOS allows you to create tasks as the system is starting. Two reasons –The functions that create an destroy tasks are typically the most time-consuming functions in the RTOS. –Whereas creating a tasks is relatively reliable operation, it can be difficult to destroy task without leaving little pieces lying around to cause bugs.

29. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System29 Time-Slicing RTOSs also allow you to turn this option off. Time-slicing is not helpful when –The tasks are not all equally urgent and therefore get different priorities. –They are of equal importance, and you don’t care which of them finishes first. Time-slicing causes more task switches and therefore cuts throughput.

30. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System30 Restricting Your Use Most RTOSs, even fairly small ones, offer more services than you are likely to need on any given project. You can save memory by figuring out a subset of the RTOS features that is sufficient for your system and using only that.

31. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System31 An Example - the Underground Tank Monitoring System

32. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System32 Tank Monitoring System The figure

33. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System33 Some Initial Questions When the float in one tank is rising rapidly, how often do we need to read it? How quickly must the system respond when the user pushes a button? How fast does the printer print?

34. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System34 Resolving a Timing Problem The system must check each tank in which the float is rising several times a second, but it takes 4 or 5 seconds to calculate the quantity of gasoline n a tank after the float is read. –Using a faster CPU? –No calculations? Just using raw float readings?

35. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System35 Deciding to Use an RTOS We must first decide whether an RTOS architecture is suitable. Can you build a system that does all this work in ISRs? Will it be easy to build a system tat does all this work in ISRs?

36. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System36 Dividing the Work into Tasks A level calculation task An overflow detection task A float hardware task A button handling task A display task An alarm bell task A print formatting task

37. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System37 Moving the System Forward Sending necessary signals! –Whenever the user presses a button, the button hardware interrupts the microprocessors. –When the user wishes to print a report, the print formatting task can send the first line of the report to the printer.

38. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System38 Dealing with the Shared Data The level data is shared by several tasks –The level calculation task –The display task –The print formatting task A semaphore or another task? –What is the longest that any one task will hold on to the semaphore? –Can every other task wait that long?

39. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System39 Conclusion Tasks

40. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System40 Conclusion The message flow

41. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System41 Encapsulating Semaphores and Queues

42. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System42 Encapsulating Semaphores The construction forces any code that wants to know the value of a shared variable to call a function to get it.

43. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System43 A Buggy One The wretched code

44. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System44 Another Example The tank system

45. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System45 Encapsulating Queues Some potential bugs in the code for handling a shared flash memory. –Any programmer can blow it and send a message that does not contain a FLASH_MSG structure. –Somebody may assign a value to eFlashOp other than one of the two legal values. –Anybody might accidentally write a message intended for the flash task to the wrong queue. –Any task might destroy the flash task input by mistake.

46. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System46 Encapsulating Queues The queue has been encapsulated inside of the flash.c module.

47. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System47 Hard Real-Time Scheduling Considerations

48. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System48 Hard Deadlines The ability to meet hard deadlines comes from writing fast code. In some cases, it might make sense to write some frequently called subroutines in assembly language.

49. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System49 Saving Memory Space

50. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System50 Limited Memory Embedded systems often have limited memory. Tradeoff between the code space and the data space Saving stack space

51. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System51 Saving Code Space Make sure that you aren’t using two functions to do the same thing. Check that your development tools aren’t sabotaging you. Configure your RTOS to contain only those functions that you need. Look at the assembly listings created by your cross-compiler to see if certain of your C statement translate into huge numbers of instruction.

52. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System52 An Example Initialization

53. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System53 Saving Code Space Consider using static variables instead of variables on the stack.

54. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System54 Saving Code Space If you are using an 8-bit processor, consider using char variables instead of int variables.

55. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System55 Saving Code Space If all else fails, you can usually save a lot of space by writing your code in assembly language.

56. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System56 Saving Power

57. 元智大學資訊工程系 czyang@acm.orgEmbedded Systems - Basic Design Using a Real-Time Operating System57 Power Issue The primary method for preserving battery power is to turn off parts or all of the system whenever possible. Two common modes –The CPU stops executing instructions, stops any built-in peripherals and stops its clock circuit. –The CPU stops executing instructions but the on-board peripherals continue to operate.