1. 1 8. Basic Design Using a Real-Time Operating System Kim jung kil

2. 2 목차  Overview for Designing Real Time Operating System  Principles - Design considerations  An Example  Encapsulating Semaphores and Queues  Hard Real-Time Scheduling Considerations  Saving Memory Space  Saving Power

3. 3 1. Overview System with absolute deadlines, such as the nuclear reactor system are called hard real-time systems. System that demand good response but that allow some fudge in the deadlines are called soft real-time systems.

4. 4 1. Overview To design effectively, you must know something about the hardware. You also must have some feel for the speed of your microprocessor. You will use your general software engineering skills in designing embedded-systems software. Although the design tools and methodologies can be extraordinarily useful, you must use them together with the advice in this chapter, not instead of it.

5. 5 2 Principles General Operation Embedded systems very commonly have nothing to do until the passage of time or some external event requires a response.  If no print data arrives, laser printers do nothing other than wake up every minute or so and move the printer drum a little. When an interrupt occurs, the interrupt routine uses the RTOS services to signal one or more of the tasks, each of which then does its work and each of which may then signal yet other tasks.

6. 6 Telegraph Operation

7. 7 Write Short Interrupt Routines In general you will be better off if you write short interrupt routines rather than long ones. Since even the lowest priority interrupt routine is executed in preference to the highest-priority task code, writing longer interrupt routines translates directly into slower task-code response. Interrupt routines tend to be more bug-prone and harder to debug than task code.

8. 8 Short Example Suppose that we are writing the software for a system with the following characteristic: 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 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.

9. 9 Short Example(Cont … ) One way to write this systems is to do all of the work in interrupt routine that receives. Another way to write this systems is interrupt routine that simply forwards every character in an RTOS message to a command parsing Task. This is excellent architecture, because the interrupt routine will be short. However, a practical disadvantage is that the interrupt routine will send a lot of messages to the command parsing task

10. 10 Short Example(Cont … ) One possible compromise designs uses an interrupt routine that saves the received characters in a buffer. When the carriage return arrives, sends a single message to the command parsing task, which reads the characters out of the buffers. In this Comprise, the interrupt routine is still relatively simple but the system need not send so many messages.

11. 11 How many Tasks? One of the first problems in an embedded-system is to divide your system ’ s work into RTOS tasks.

12. 12 Advantages 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. Using a separate task for each device allows for cleaner code. With more tasks you can sometimes encapsulate data more effectively.

13. 13 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. Need More memory. Each time the RTOS switches tasks,a certain amount of microprocessor time evaporates saving the context of the task that is stopping and restoring the context of the task that is about to run. More tasks probably means calls to the RTOS.: your system runs faster if it avoids calling the RTOS functions.

14. 14 You need Tasks for Priority First,the obvious advantage of the RTOS architecture is the improved control of task code response. Therefore, 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.

15. 15 You Need Tasks for Encapsulation It often makes sense to have a separate task to deal with hardware shared by different parts of the system.

16. 16 Fig8.3 A Separate Task Helps Control Shared Hardware

17. 17 Other Tasks Might or Might Not Need Have many small tasks, so that each is simple. Simplicity is always a good goal,but this needs trade-offs. Have separate tasks for work that needs to be done in response to separate stimuli.

18. 18 Recommended Task Structure !! Private static data is declared here void vTaskA() { !! More private data declared here, either static !! or on the stack !! Initialization code, if needed. while(FOREVER) { !! Wait for a system signal(event, queue message, etc.) switch(!!type of signal) { case !! signal type 1:. break; case !! signal type 2:. break;. }

19. 19 Avoid Creating & Destroying Tasks First, the functions that create and destroy tasks are typically the most- consuming fuctions in the RTOS. Second,it can be difficult to destroy a task without leaving little pieces lying around to cause bugs.

20. 20 Consider Turning Time-Slicing Off In embedded system, all task is not fair. They 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.

21. 21 Consider Restricting your use of the RTOS Most RTOSs offer more services than you are likely to need on any given project. Configure them and remove any services that you do not use, save memory and reduce bugs.

22. 22 Underground Tank Monitoring System

23. 23 Tasks in the Underground Tank System TaskPriorityReason for creating This task Level calculation Task LowOther processing is much higher priority than this calculation,and this calculation is a microprocessor hog. Overflow detection task HighThis task determines whether there is an overflow; it is important that this task operate quickly Button handling task HighThis task controls the state machine that operates the user interface, relieving the button interrupt routine of that complication, but still responding quickly.

24. 24 Tasks in the Underground Tank System TaskPriorityReason for creating This task Display TaskHighSince various other tasks use the display, this task makes sure they do not fight over it. Print formatting task MediumPrint formatting might take long enough that it interfaces with the required response to the buttons. Also, it may be simpler to handle the print queue in separate task.

25. 25 Tank Monitoring Design

26. 26 Encapsulating Semaphores /* File: tmrtask.c */ static long int lSecondsToday; long lSecondsSinceMidnight() { long lReturnValue; GetSemaphore( SEMAPHORE_TIME_OF_DAY); lReturnValue = lSecondsToday; GiveSemaphore(SEMAPHORE_TIME_OF_DAY); return lReturnValue; } -------------------------------------------- /* File: hacker.c */ long lSecondsSinceMidnight(); void vHackerTask() { lDeadline = lSecondsSinceMidnight()+1800;... if( lSecondsSinceMidnight() > 3600 *12)... }

27. 27 Encapsulating Queues void vWriteFlash(int iSector, BYTE *p_byData) { FLASH_MSG sFlashMsg; sFlashMsg.eFlashOp = FLASH_WRITE; sFlashMsg.vRdCb = NULL; sFlashMsg.iSector = iSector; memcpy(sFlashMsg.a_byData, p_byData, SECTOR_SIZE); mq_send(sQueueFlash, (void*)&sFlashMsg, sizeof sFlashMsg, 5); } void vReadFlash(int iSector, V_RD_CALLBACK *vRdCb) { FLASH_MSGsFlashMsg; sFlashMsg.eFlashOp = FLASH_READ; sFlashMsg.vRdCb = vRdCb; sFlashMsg.iSector = iSector; mq_send(sQueueFlash, (void*)&sFlashMsg, sizeof sFlashMsg, 6); }

28. 28 Hard Real-Time Scheduling Considerations Meet the hard deadline. To some extent, the ability to meet hard deadlines comes from writing fast code. For hard real-time systems, it is important to write subroutines that always execute in the same amount of time or that have a clearly identifiable worst case. Fixed sized buffer is preferred to a general purpose malloc(). Tasks that avoid semaphores are preferable, since the worst case performance does not depend upon other tasks who use the same semaphore

29. 29 Saving Memory Space Code is stored in ROM and data is stored in RAM. To find out the necessary stack space, you can either calculate exact required size by analyzing your code or experiment by finding out the changes made to the pre-written pattern. Ways to save code space. Make sure that you are not using 2 functions to do the same thing. memcpy() and memmove() Calling a function may result in using a group of functions. Configure your RTOS to contain only those functions that you need. Investigate the assembly code to find out if certain part of C code translate into huge numbers of instructions. Refer to Example in p.255. Consider using static variable instead of variables on the stack. If you are using an 8-bit processor, consider using char variables instead of int variables. Writing in assembly language.

30. 30 Saving Power Embedded-system microprocessor have at least one power-saving mode. sleep mode, low-power mode, idle mode, standby mode. Common power-saving mode is one in which the microprocessor stops executing instructions, stops any built-in peripherals, and stops its clock. It can be restarted only by resetting. Another typical power-saving mode is one in which the microprocessor stops executing instructions but the on-board peripherals continue to operate. Any interrupt starts the microprocessor up again. Another common method for saving power is to turn off the entire system and have the user turn in back on when it is needed.