Embedded Systems More Operating System Services C.-Z. Yang czyang Sept.-Dec. 2001

Embedded SystemsMore Operating System

Services C.-Z. Yang

http://syslab.cse.yzu.edu.tw/~czyang

Sept.-Dec. 2001

[email protected] Embedded Systems - More Operating Systems Services 2

元智大學資訊工程系

Common Communication Services

• Data sharing– Tasks must be able to communicate with one another to co

ordinate their activities or to share data.

• Some mechanisms are provided in most RTOSs.– Queues

– Mailboxes

– Pipes



A Simple Example

• Three tasks– Task1

– Task2

– ErrorsTask

Task1

Task2

ErrorsTask



The Code

• Task1 and Task2



The Code

• ErrorsTask

If the queue is empty, this function will block the calling task.



Some Working Details

• Most RTOSs require that you initialize your queues before you use them.– You should guarantee that queue initialization should be ca

rried out before any task tries to use the queue.

• Most RTOSs allow you to has as many queues as you want.– So you should pass an additional parameter to every queue

function.




• If your code tries to write to a queue when the queue is full, the RTOS must either– return an error to let you know that the write operation fail

ed

– or it must block the task until some other task reads data from the queue and thereby creates some space.

• Many RTOSs include an additional function that will read from a queue if there is any data and will return an error code if not.




• The amount of data that the RTOS lets you write to the queue in one call may not be exactly the amount that want to write.– Many RTOSs are inflexible about this.

– One common characteristic is to allow you to write onto a queue in one call the number of byte taken up by a void pointer.



More Realistic Code

• Queue data structures and operations



More Realistic Code

• main, Task1 and Task2



More Realistic Code

• vLogError



More Realistic Code

• ErrorsTasks



Remarks on the Previous Code

• A fairly common RTOS interface– Write one void pointer to the queue with each call.

• A fairly common coding technique– Cast the data as a void pointers.



Another Example

• Reading temperatures



A Closer Look at OSQPost()

• OSQPost

UBYTE OSQPost(OS_EVENT *pevent, void *msg){ OS_Q *pq; OS_TCB *ptcb; UBYTE x; UBYTE y; UBYTE bitx; UBYTE bity; UBYTE p;

OS_ENTER_CRITICAL(); if (pevent->OSEventGrp) { /* See if any task pending on queue */ …

} else { …

}}




• OSQPost - if part

y = OSUnMapTbl[pevent->OSEventGrp]; /* Find highest prio. task waiting for message */bity = OSMapTbl[y];x = OSUnMapTbl[pevent->OSEventTbl[y]];bitx = OSMapTbl[x];p = (y << 3) + x; /* Find priority of task getting the msg */if ((pevent->OSEventTbl[y] &= ~bitx) == 0) { /* Remove this task from the waiting list */ pevent->OSEventGrp &= ~bity;}ptcb = OSTCBPrioTbl[p]; /* Point to this task's OS_TCB */ptcb->OSTCBDly = 0; /* Prevent OSTimeTick() from readying task */ptcb->OSTCBEventPtr = (OS_EVENT *)0; /* Unlink ECB from this task */ptcb->OSTCBMsg = msg; /* Send message directly to waiting task */ptcb->OSTCBStat &= ~OS_STAT_Q; /* Clear bit associated with event type */if (ptcb->OSTCBStat == OS_STAT_RDY) { /* See if task is ready (could be susp'd) */ OSRdyGrp |= bity; /* Put task in the ready to run list */ OSRdyTbl[y] |= bitx;}OS_EXIT_CRITICAL();OSSched(); /* Find highest priority task ready to run */return (OS_NO_ERR);




• OSQPost - else part

pq = pevent->OSEventPtr; /* Point to queue control block */if (pq->OSQEntries >= pq->OSQSize) { /* Make sure queue is not full */ OS_EXIT_CRITICAL(); return (OS_Q_FULL);} else { *pq->OSQIn++ = msg; /* Insert message into queue */ pq->OSQEntries++; /* Update the nbr of entries in the queue */ if (pq->OSQIn == pq->OSQEnd) { /* Wrap IN ptr if we are at end of queue */ pq->OSQIn = pq->OSQStart; } OS_EXIT_CRITICAL();}return (OS_NO_ERR);



Mailboxes



Mailboxes

• In general, mailboxes are much like queues.

• The typical RTOS has functions to create, to write to, and to read from mailboxes.

• Perhaps there are functions to check whether the mailbox contains any messages and to destroy the mailbox if it is no longer needed.



Some Variations in RTOSs

• The number of messages in a mailbox– Some RTOSs allow a certain number.

– Others allow only one.

• Some RTOSs do not have such limitation for each mailbox, but they have a limit to the total number.

• In some RTOSs, you can prioritize mailbox messages.



An Example - MultiTask!

• Each message is a void pointer

– uMbId: the mailbox on which to operate.

– sndmsg: the function adding p_vMsg into the message queue with the priority indicated by uPriority

– rcvmsg: returning the highest-priority message

– chkmsg: returning the first message in the mailbox



Pipes



Pipes

• Pipes are also much like queues.

• Variations– Some RTOSs allow you to write message of varying lengt

hs onto pipes.

– Pipes in some RTOSs are entirely bye-oriented.

– Some RTOSs use the standard C library functions fread and fwrite to read from and write to pipes.



Which Should I Use?

• This depends on – flexibility

– speed

– memory space

– length of time that interrupts must be disabled within the RTOS functions



Some Pitfalls

• Most RTOSs do not restrict which tasks can read from or write to any given queue, mailbox, or pipe.– You must ensure that tasks use the correct one each time.

• The RTOS cannot ensure that data written onto a queue, mailbox, or pipe will be properly interpreted by the task that reads it.– You must declare your programming interface very clearly.



An Example

• A bug easy to be found by compilers



An Example

• A concealed bug



More Pitfalls

• Running out of space in queues, mailboxes, or pipes is usually a disaster for embedded software.

• Passing pointers from one task to another through a queue, mailbox, or pipe is one of several ways to create shared data inadvertently.



An Example

• No malloc and free

Before After



An Example

• No malloc and free

Before After



An Example

• However, there is a bug.– When the main task gets a value for pTemperatures fr

om the queue, pTemperatures will point to the iTemperatures array in vReadTemperaturesTask.

– If the RTOS switches from vMainTask to vReadTemperaturesTask while vMainTask was comparing iTemperatures[0] to iTemperatures[1], and if vReadTemperaturesTask then changes the values in iTemperatures, the shared-data bug occurs.



Timer Functions



Timing Is a Very Important Issue

• Most embedded systems must keep track of the passage of time.

• One simple service that most RTOSs offer is a function that delays a task for a period of time.



An Example for Making a TEL Call

• The code



Several Questions

• How do I know that the taskDelay function takes a number of milliseconds as its parameters?– Check your programming manuals.

– Usually the delay function in most RTOSs takes the number of system ticks as its parameters.

• How accurate are the delays produced by the taskDelay function?– The nearest system tick.

– A heartbeat timer.



Timer Accuracy

• vTaskDelay(3)



More Questions

• How does the RTOS know how to setup the timer hardware on ly particular hardware?– This is the job of the developer who is responsible for OS

porting.

– If you are the person, you may have to write your own timer setup software and timer interrupt routine.

• What is a “normal” length for the system tick?– There really isn’t one.

– A trade-off: more accurate, more timer interrupts.



More Questions

• What if my system needs extremely accurate timing?– Two choices:

– (1) to make the system tick short enough that RTOS timing fit your definition of “extremely accurate”.

– (2) to use a separate hardware timer for those timings that must be extremely accurate.



Other Timing Services

• Most RTOSs offer an array of other timing services.

• All of them are based on the system tick.

• Some cautions are needed.– Timeout for getting a semaphore

• Code for recovering must be provided.

• We should try to find other good solutions.



A Useful Service

• To call the function of your choice after a given number of system ticks.

• An example– Radio on/off

– Turning-on procedure

• power on

• 12ms, setting the frequency

• 3ms, turning on the transmitter



The Code



Events



Events

• An event is essentially a Boolean flag that tasks can set or reset and that other tasks can wait for.

Task1 Task2



Some Standard Features

• More than one task can block waiting for the same event, and the RTOS will unblock all of them when the event occurs.

• RTOSs typically form groups of events, and tasks can wait for any subset of events within the group.

• Different RTOSs deal in different ways with the issue of resetting an event after it has occurred and tasks that were waiting for it have been blocked.



An Example

• AMX code



A Brief Comparison of the Methods for Intertask Communication



• Semaphores are usually the fastest and simplest methods.– However, not much information can pass through a semap

hore.

• Events are a little more complicated than semaphores and take up just a hair more microprocessor time than semaphores.– ADV: A task can wait for any one of several events at the s

ame time, whereas it can only wait for one semaphore.

– ADV: Some RTOSs make it convenient to use events and make it inconvenient to use semaphores.



• Queues allow you to send a lot of information from one task to another.– The drawbacks

• putting messages into and taking messages out of queues is more microprocessor-intensive

• that queues offer you many more opportunities to insert bugs into your code.



Memory Management



Memory Management

• Most RTOSs have some kind of memory management subsystem.

• Real-time engineers often avoid using malloc() and free() because– they are typically slow and

– their execution times are unpredictable.

• They favor instead functions that allocate and free fixed-size buffers.



An Example in MultiTask!

• Pools– Each of which consists of some number of memory buffers.

– In any give pool, all of the buffers are the same size.

• Two functions to allocate a buffer– getbuf()

– reqbuf()



An Example in MultiTask!

• You have to tell MultiTask! where the free memory is.

• A function to initialize the pool– init_mem_pool



A Simple Example Code

• The printing subsystem



Some Important Notes

• The code always allocates a full 40-char buffer.– This waste of memory is the price you pay for the

improved speed that fixed-size buffers allow.

• A common compromise that retains the high-speed memory routines but uses memory reasonably efficiently is to allocate three of four memory buffer pools, each with a different size of buffer.



Interrupt Routines in an RTOS Environment



Interrupt Routines

• Two rules must be followed.

• Rule 1– An interrupt routine must not call any RTOS function that

might block the caller.

• Rule 2– An interrupt routine may not call any RTOS function that

might cause the RTOS to switch tasks unless the RTOS knows that an interrupt routine, and not a task, is executing.



Rule 1: No Blocking

• The nuclear reactor



An Example of Nonblocking



Rule 2: No RTOS Calls without Fair Warning

• A naïve view



Rule 2: No RTOS Calls without Fair Warning

• What really happen



The First Solution

• Requiring your cooperation to intercept all the interrupts.



The Second Solution

• The RTOS provides a function that the interrupt routines call to let the RTOS know that an interrupt routine is running.



The Third Mechanism

• Some RTOSs provide a separate set of functions especially for interrupt routines.

• So there might be OSISRSemPost in addition to OSSemPost.



Rule 2 and Nested Interrupts

• If your system allows interrupt routines to nest, then another consideration comes into play.

• If the high-priority interrupt routine makes any calls to RTOS functions, then the lower-priority interrupt routine must let the RTOS know when the lower-priority interrupt occurs.



Rule 2 and Nested Interrupts

• The RTOS scheduler should not run until all interrupt routines are complete.

Documents

Embedded Systems More Operating System Services C.-Z. Yang czyang Sept.-Dec. 2001