L24 - 26 Realtime Executives

Software for embedded systems Cs424 First Semester 2012-13
Realtime Executives
CS C 424 Software for Embedded systems
RTOS- Introduction
Needs complex software architecture to handle
multiple tasks coordination communication interrupt handling
Distinction:
Desktop OS
OS is in control at all times and runs applications OS runs in different address space
RTOS
OS and embedded software are integrated ES starts and activates the OS Both run in the same address space RTOS is less protected RTOS includes only service routines needed by the ES application RTOS vendors: VsWorks , VTRX, Nucleus, LynxOS, uC/OS
Most conform to POSIX (IEEE standard for OS interfaces) Desirable RTOS properties: use less memory, application programming interface, debugging tools, support for variety of microprocessors, alreadydebugged network drivers
Tasks and Task States

A task a simple subroutine ES application makes calls to the RTOS functions to start tasks, passing to the OS, start address, stack pointers, etc. of the tasks Task States: Running Ready (possibly: suspended, pended) Blocked (possibly: waiting, dormant, delayed) Tasks can block them selves. Moved to ready state via other tasks interrupt signaling (when blockfactor is removed/satisfied)
Scheduler
Keeps track of the state of each task. Schedules/shuffles tasks between Running and Ready states Will not fiddle with task priorities When a task is unblocked with a higher priority over the running task, the scheduler switches context immediately (for all preemptive RTOSs)
Task states
What ever the task needs, happens
Blocked
This is highest priority ready task Task needs something to happen before it continues
Ready
Another ready task is of higher priority
Running
Scheduler and task states

How does the scheduler know when a task has become blocked or unblocked? Tasks tell the scheduler on what events they are waiting. What happens if all the tasks are blocked? Scheduler waits indefinitely for some thing to happen. What if two tasks with same priority are ready? Bad design. Different RTOS handle in different way. What happens if one task is running and another high priority task unblocks? Preemptive RTOS gets to ready state and higher priority task gets to running state. Non preemptive RTOS pulls current task to ready state when that task blocks itself.
Example
//"Button task void vButtontask(void) //Higher priority { while (TRUE) { !! Block until user pushes button !! Button pressed. Respond to user } } //"levels task void vlevelsTask(void) //low priority { While (TRUE) { !! Read levels of floats !! calculate average float level } }
Task sequence
RTOS initialization
void main(void) { //Initialize the RTOS InitRTOS(); //Tell tghe RTOS about our tasks StartTask(vRespondTobutton,HIGH_PRIORITY); StartTask(vcalculateTankLevel,LOW_PRIORITY); //Start the RTOS StartRTOS(): //This function never returns
RTOS data organization

RTOS
RTOS Data structures
Task 1 stack
Task1
Global data
Task 1 registers
Task2
Task3
Task 2 stack
Task 2 registers
Task 3 stack
Task 3 registers
Shared data
struct { long ltanklevel; long lTimeUpdated; }tankdata[MAX_TANKS] //Button task void vRespondToButton (void) //High priority { !!Block until user pushes a button i=ID of the button pressed printf("", tankdata[i]); } //levels task void vcalculaeTankLevels(void) { int i=0; while (TRUE) { !!Read levels of tank !! do calculations //store the result tankdata[i].lTimeUpdated==CurrentTime // Bad place for task switching tankdata[i].lTanklevel= !1result of calculation }
Bug!!
Code sharing by tasks

void task1(void) { // vCountErrors(9); // } void task2(void) { // vCountErrors(11); // }
static int cErrors; void vCountErrors (int cnewErrors) { cErrors += cNewerrors; }
Bug!
Reentrancy
Reentrancy A function that works correctly regardless of the number of tasks that call it between interrupts
Characteristics (checks) of reentrant functions

1. Only access shared variable in an atomic-way, or when variable is on callees stack 2. A reentrant function calls only reentrant functions 3. A reentrant function uses system hardware (shared resource) atomically
Reentrancy
Inspecting code to determine Reentrancy: Where are data stored in C? Shared, nonshared, or stacked? Is this code reentrant? What about variable fError? Is printf reentrant? If shared variables are not protected, could they be accessed using single assembly instructions (guaranteeing non-atomicity)?
Semaphores
Semaphores and Shared Data

Semaphore a variable/lock/flag used to control access to shared resource (to avoid shared-data problems in RTOS) Protection at the start is via primitive function, called take, indexed by the semaphore Protection at the end is via a primitive function, called release, also indexed similarly Simple semaphores Binary semaphores are often adequate for shared data problems in RTOS
Semaphores
struct { long ltanklevel; long lTimeUpdated; } tankData[MAX_TANKS] //Button task void vRespondToButton(void) { int i; while (TRUE) { !! Block until user pushes the button i=!!get ID of the button pressed TakeSemahore(); printf(""tankData[i].lTimeUpdated, ltankLevel); ReleaseSemaphore(); } } //levels task //Low priority void vcalculatetankLevels(void) { int i=0; while (TRUE) { ..; ..; TakeSemaphore(); !! Set ankdata[i].lTimeUpdated; !! set tankdata[i].lTakLevel; ReleaseSemaphore(); } }
Execution flow with semaphores

#define TASK_PRIORITY_READ 11 #define TASK_PRIORITY_CONTROL 12 #define STK_SIZE 1024 static unsigned int ReadStk[STK_SIZE]; static unsigned int ControlStk[STK_SIZE]; static int itemperatures[2]; OS_EVENT *p_semtemp; void ReadTask(void) { while (TRUE) { OSTimeDly (5) OSSemPend (p_SemTemp,WAIT_FOREVER); !!1 read in iTemperatures[0]; !!read in iTemperatures[1]; OSSemPost (p_semtemp); } }
void main(void) { //Init the RTOS OSInit(); //Tell the RTOS about the tasks OSTaskCreate (vReadTemparatureTask,NULLP, void Controltask(void) (void*) Readstk[STK_SIZE],TASK_PRIORITY_READ); { OSTaskCreate (vControlTask,NULLP, p_semtemp=OSSemInit(1); (void*) &Controlstk [STK_SIZE], TASK_PRIORITY_CONTROL) ; while (TRUE) OSStart(); { } OSSempend (p_semptemp,WAIT_FOREVER); if (iTemperatures[0]!=iTemparatures[1]) !! Set of alaram; Bug! OSSemPost (p_semtemp); !!1 Do other useful work Put this before ..; OSStart()! } }

void task1(void) { ..; ..; vCountErrors(9); ..; ..; } void task2(void) { ..; ..; vCountErrors(11); ..; ..; } static int cErrors; static NU_SEMAPHORE semErrors; void vCountErrors (int cnewErrors) { NU_Obtain_Semaphore (&semErrors,NU_SUSPEND); cErrors += cNewErrors; NU_Release_Semaphore (&semerrors); }
Re-entrant
Multiple semaphores
A lower priority task may block higher priority task on a semaphore. Have more granulaity Have one semaphore for each type of resource. Try avoidig a block of higher priority task unless it is must.
Semaphore as a signaling device

//Place to construct a report static char a_chprint[10][12]; void vprinterInterrupt(void) //Count the lines in the report { static int iLinesTotal; if (ilinesPrinted==ilinesTotal) //count of lines printed so far //The report is done. release the semaphore satic int ilinesPrinted; OSSempost (semPrinter); //semaphore to wait for report to finish else static OS_EVENT *semprinter; //print the next line void vPrintertask(void) vhardwareprinterOutputLine (a_chprint { [iLinesprinted++]) ; BYTE byError //Place for an error return } int wmsg; //Initialize the semaphore as already taken semprinter=OSSemInit(0); while (TRUE) { //wait for a message telling what report to format wMsg=(int) OSPend(QprinterTask,WAIT_FOREVER,&byError); !! Format the report into a_chprint iLinesTotal=!!count of lines in the report //print the first line of the report iLinesprinted=0; vhardwareprinterOutputLine (a_chprint[iLinesprinted++]); //wait for print job to finish OSSempend (semprinter,WAIT_FOREVER); } }
Precautions with Semaphore

The initial values of semaphores when not set properly or at the wrong place The symmetry of takes and releases must match or correspond each take must have a corresponding release somewhere in the ES application Taking the wrong semaphore unintentionally (issue with multiple semaphores) Holding a semaphore for too long can cause waiting tasks deadline to be missed Priorities could be inverted and usually solved by priority inheritance/promotion Causing the deadly embrace problem (cycles)
Priority inversion
Resolved by priority inheritance by some RTOS They temporarily boost the priority of task C to that of task A whenevr task C holds the semaphore and task A is waiting for it.
Deadly embrace
int a; int b; AMXID hSemaphoreA; AMXID hSemaphoreB; void vtask1(void) { ajsmrsv(hsemaphoreA,0,0); ajsmrsv (hsemaphoreB,0,0); a=b; ajsmrls (hSemaphoreB); ajsmrls (hSemaphoreA); } void vtask2 (void) { ajsmrsv (ajsmrsv(hsemaphoreB,0,0); ajsmrsv (hsemaphoreA,0,0); b=a; ajsmrls (hSemaphoreA); ajsmrls (hSemaphoreB); }
Semaphore Variants
Binary semaphores single resource, one-at-a time, alternating in use (also for resources) Counting semaphores multiple instances of resources, increase/decrease of integer semaphore variable Mutex protects data shared while dealing with priority inversion problem
Protecting shared data

Disabling/Enabling interrupts (for task code and interrupt routines), faster Taking/Releasing semaphores (cant use them in interrupt routines), slower, affecting response times of those tasks that need the semaphore Disabling task switches (no effect on interrupt routines), holds all other tasks response
More RTOS services
Message Queues, Mailboxes and Pipes

Basic techniques for inter-task communication and data sharing Semaphores. Message Queues Mailboxes Pipes
Sample queue
//RTOS queue function prototypes void vLogError(int iErrorType) void AddToQueue (init iData); { void ReadFromQueue(int *p_iData); AddToQueue (iErrorType); void pTask1(void) } { static int cErrors; ; void ErrorsTask(void) ; { if (!!problem arises) int iErrorType; vLogError(ERROR_TYPE_X); while (TRUE) !!Other things that need to be done { soon ReadFromQueue (&iErrorType); ; ++cErrors; ; !! Send cErrors and iError type on } network void Task2(void) } { } ; ; if (!!problem arises) vLogError(ERROR_TYPE_Y); !! other things that need to be done soon CS C 424 Software for Embedded systems }
Queues
Queue initialization (like semaphore initialization) must be dedicated to a separate task to a) guarantee correct startup values and b) avoid uncertainty about task priorities and order of execution which might affect the queues content Queues must be tagged (identify which queue is referenced) Need code to manage the queue (when full and empty) if RTOS doesnt block reading/writing task on empty/full, plus returning an error code RTOS may limit the amount of info to write/read to queue in any single call
More realistic use of a queue

//RTOS queue function prototypes OS_EVENT *OSQCreate(void *PPStart,BYTE bySize; unsigned char OSQPost (OS_EVENT *pOse,void *pvMsg); void *OSQPend (OS_EVENT *pOse,WORD wTimeout, BYTE *pByErr); #define WAIT_FOREEVER 0 //Our message queue static OS_EVENT *pOseQueue; void task2(void) { ; if (!!problem arises)
vLogError(ERROR_TYPE_Y); !! other things that need to be done ; } void vLogError(int iErrorType) { #define SIZEOF_QUEUE 25 //Return code from writing from queue void *apvQueue[SIZEOF_QUEUE]; BYTE byReturn; void main() byReturn=OSQPost(pOseQueue,(void*) { iErrorType); ; if (byReturn!=OS_NO_ERR) pOseQueue=OSQCreate (apvQueue,SIZEOF_QUEUE); !! handle the situation that arises when the ; queue is full !!start task1; }static int cErrors; !!start task2; void ErrorsTask (void) ; { } int iErrorType; void task1(void) BYTE byErr; { while(FOREVER) ; { if (!!problem arises) iErrorType=(int) vLogError(ERROR_TYPE_X); OSQPend(pOseQueue,WAIT_FOREEVER,&byErr); !! other things that need to be done ++cErrors; ; } } }systems CS C 424 Software for Embedded
Passing pointers on queues

/RTOS queue function prototypes OS_EVENT *OSQCreate(void *PPStart,BYTE bySize); unsigned char OSQPost (OS_EVENT *pOse,void *pvMsg); void *OSQPend (OS_EVENT *pOse,WORD wTimeout, BYTE *pByErr); #define WAIT_FOREEVER 0 //Our message queue static OS_EVENT *pOseQueuetemp; void vReadTemperaturesTask (void) { int ptemperatures; while (TRUE) { !!1Wait untilit is time to read next temp. //Get a new buffer for next set of temps. ptemperatures=(int*) malloc(2*sizeof *ptemparatures); ptemparature[0]=!! read the value ptemparature[1]=!! read the value //Add a pointer to the new temps to the queue OSQPost (pOseQueueTemp, (void*) ptemparatures); } } void vMainTask(void) { int *pTemperatures; BYTE byErr; while (TRUE) { ptemparatures= (int*) OSQPend(pOseQueue,WAIT_FOREEVER,&byErr); if (pTemparaturews[0] != pTemparatures[1] !!Set off howling alaram; free (pTemperatures);
} }
Using Mailboxes:
Similar to queues Typical RTOS function for managing mailboxes
create, write, read, check-mail, destroy

Either a single-message mailbox or multi-message mailbox (set # entries at start) # of messages per mailbox could be unlimited, but total # in the system could be (with possibility of shuffling/distributing messages among mailboxes) Mailboxes could be prioritized
Variations in RTOS implementations of mailboxes
Examples:(from the RTOS MultiTask! )

int sndmsg (unsigned int uMbid, void *p_vMsg, unsigned int uPriority); void *rcvmsg(unsigned int uMbid, unsigned int uTimeout); void *chkmsg(unsigned int uMbid);
Pipes:
Similar to a physical pipe RTOS can create, read from, write to, destroy pipes Details of implementation depends on RTOS Pipes can have varying length messages (unlike fixed length for queues / mailboxes) Pipes could be byte-oriented and read/write by tasks depends on # bytes specified In standard C, read/write of pipes use fread/fwrite functions, respectively
Timer Functions
RTOS provides these timing services or functions
Some points:
Time measured in ticks Relies on microprocessors hardware timer and its interrupt cycles Length of a tick depends on the hardware timers design trade-off Accurate timing short tick intervals OR use dedicated timer for purpose
Events
In standard OS, an event is typically an indication which is related to time In RTOS, an event is a boolean flag, which is set and reset by tasks/routines for other tasks to wait on RTOS is supposed to manage several events for the waiting tasks. Blocked or waiting tasks are unblocked after the event occurrence, and the event is reset
Using events
//Handle for the trigger group of events #Define TRIGGER_MASK 0X0001 #Define TRIGGER_SET 0X0001 #Define TRIGGER_RESET 0X0000
void main(void) { ajevcre(&amxIdTrigger ,0,"EVTR"); ; ; } void Interrupt vTriggerISR(void) { //Set the event ajevsig(amxIdTrigger,TRIGGER_MASK,TRIGGER_SET); ; } void vScanTask(void) { ; ; while (TRUE) { //Wait for the user to pull the trigger ajewat(amxIdTrigger,TRIGGER_MASK,TRIGGER_SET,WAIT_FOR_ANY,WAIT_FOREVER); //Reset the trigger event ajevsig(amxIdTrigger,TRIGGER_MASK,TRIGGER_RESET); ; } }
Features of events
More than one task can wait on the same event Events can be grouped, and tasks may wait on a subset of events in a group Resetting events is either done by the RTOS automatically or your embedded software Tasks can wait on only one semaphore, queue, mbox or pipe, but on many events simultaneously. Semaphores are faster, but unlike queues, mboxes, and pipes, they carry 1-bit info Queues, mboxes, and pipes are message posting/retrieval is compute-intensive
Memory Management
In general RTOS offer C lang equivalent of malloc and free for MM, which are slow and unpredictable Real time system engineers prefer the faster and more predictable alloc/free functions for fixed size buffers. E.g., MultiTask! RTOS allocates pools of fixed size buffers, using getbuf() [with timed task blocking on no buffers] and reqbuf() [with no blocking and return of NULL pointer on no buffers] relbuf() to free buffers in a given pool (buffer pointer must be valid) Note that most embedded sw is integrated with the RTOS (same address space) and the ES starts the microprocessor; hence your ES must tell the memory-pool
Initialize memory pool

#Define LINE_POOL 1 #DEFINE MAX_LINE_LENGTH 40 #DEFINE MAX_LINES 80 static char a_Lines[MAX_LINES][MAX_LINE_LENGTH] void main(void) { ; ; Init_mem_pool(LINE_POOL,a_Lines, MAX_LINES, MAX_LINE_LENGTH,TASK_POOL); ; }
P_vMemory
uBuffCount
uBuffSize
Init_mem_pool function in muti task
ISRs in RTOS Environment

Rules that IRs must comply with (but not a task code) Rule 1: An IR cant call RTOS function that will cause it to block like wait on semaphores reading empty queues or mailboxes wait on events..

Rule 2: An IR cant call RTOS functions that will cause the RTOS to switch other tasks (except other IRs); Breaking this rule will cause the RTOS to switch from the IR itself to handle the task, leaving the IR code incomplete or delay lower priority interrupts

One solution to Rule 2 Let the RTOS intercept all the interrupts, aided by an RTOS function which tells the RTOS where the IRs are and the corresponding interrupt hardware The RTOS then activates the calling IR or the highest priority IR Control returns to the RTOS, and the RTOS scheduler decides which task gets the microprocessor (allowing the IR to run to completion)

Second solution to Rule 2: Let the IR call a function in the RTOS to inform the RTOS of an interrupt After the IR is done, control goes back to the RTOS, where another function calls the scheduler to schedule the next task Third solution to Rule 2: Let RTOS maintain a separate queue of specialized, interruptsupporting functions which are called by the IR (on the appropriate interrupt). When these functions complete, control goes back to that IR
Interrupt Routines in an RTOS Environment

Nested Interrupts If a running IR is interrupted by another (higher) priority interrupt (kind of interrupt stacking), the RTOS should unstack the IRs to allow all IRs to complete before letting the scheduler switch to any task code
Basic design using a Real time OS

pick a software architecture construct a specification of the ES to meet such requirements / properties Problem Decomposition into Tasks Write Short IRs
Problem Decomposition into Tasks How many tasks?

Considerations
(+)More tasks offer better control of overall response time (+)Modularity different task for different device handling or functionality (+)Encapsulation data and functionality can be encapsulated within responsible task (-) More tasks means data-sharing, hence more protection worries and long response time due to associated overheads (-) More task means intertask messaging, with overhead due to queuing, mailboxing, and pipe use (-) More tasks means more space for task stacks and messages (-) More tasks means frequent context switching (overhead) and less throughput (-) More tasks means frequent calls to the RTOS functions (major overhead adds up)
Priorities
Priorities (advantage of using RTOS software architecture):
Decomposing based on functionality and time criticality, separates ES components into tasks (naturally), for quicker response time using task prioritization high priority for time-critical ones, and low priority for others
Encapsulating functionality in Tasks

A dedicated task to encapsulate the handling of each shared device (e.g., printer display unit) or a common data structure (e.g., an error log)
Avoid Creating and Destroying Tasks

Avoid Creating and Destroying Tasks
Creating tasks takes more system time Destroying tasks could leave destroy pointers-to-messages, remove semaphore others are waiting on (blocking them forever) Rule-of-thumb: Create all tasks needed at start, and keep them if memory is cheap!
Turn Time-Slicing Off

Useful in conventional OSs for fairness to user programs In ESs fairness is not an issue, response-time is! Time-slicing causes context switching time consuming and diminishes throughput Where the RTOS offers an option to turn time-slicing off, turn it off!
Restrict the use of RTOS functions/features

Restrict the use of RTOS functions/features
Customize the RTOS features to your needs If possible write ES functions to interface with RTOS select features to minimize excessive calls to several RTOS functions (increases opportunity for errors) Develop a shell around the RTOS functions, and let your own ES tasks call the shell (and not the RTOS directly) improves portability since only the shell may be rewritten from RTOS to RTOS
Example
There are 255 EVMs which have to be connected to a central processing unit (CP). CP holds the IDs of voters, their thumb signatures and voted option. Communicates with EVMs through messages. Role of EVM:
When user places thumb, EVM generates a signature. Sends the signature to CP. Receives the assertion/negation message sent by CP. CP asserts if the signature is correct and the user has not voted. CP negates otherwise. Glows select one from right and when user selects one option, it prevalidates (i.e one option is kept pressed for 5 sec) and sends the selection to CP. Receives ACK sent by CP in response to EVMs message. EVM glows done! and ready to take next user. Maintains IDs of voters, their thumb signatures and voted options. Gets messages from all EVMs and responds the action taken. Receives the signature from EVM. Verifies if the signature is correct and the user has not voted. Sends assert/negate message in response to this Receives candidate selection from EVM . updates the selection and acknowledges to Software for Embedded systems CS C 424 EVM
C1 C3
Place thumb here Select one from right
C3 C4
Done!
Invalid!
Role of CP:

Tasks
Message_Receiver Vote_registration Receives the messages from every EVM . Receives a record from the buffer needing to store Puts into received messages queue candidate selection Suspends itself for next message to arrive. Interacts with data access layer and updates the data Removes the record from buffer once the registration is successful Message Decoder Posts acknowledgement data to be sent to EVM to Decodes the received message message encoder Updates the action buffer with the information decoded from message. Message Encoder Ex: EVM ID, verify operation, signature. Receives data Adds a session number Frames appropriate message Posts into Transmit Queue Set verify event Waits for a message to be encoded Suspends till the next message to be decoded Message_Transmitter Signature verifier Receives a record from the buffer needing Pulls a message from transmit queue an action to verify the signature. Transmits to the EVM to be notified. Interacts with data access layer and verifies Sleeps if there are no messages to be transmitted the signature. Watchdog Extracts the ID of the person. Updates the buffer with the ID Checks action buffer every one second for any time outs. Updates the buffer state. Generates error message and posts to message encoder Posts data to be sent to EVM to message Deletes the record from action buffer. encoder Clear verify event Waits on verify event. CS C 424 Software for Embedded systems
Objects
Received Queue Message Receiver posts received message Message decoder waits on this object and pulls the messages for decoding. Action buffer A buffer with one record for each transaction from EVM This can be a FIFO . Randomly accessible as the tasks will update each session Message decoder posts /updates a record All action tasks (signature verifier/Vote_registration/watch dog..) wait on the buffer data to do actions and update them. Transmit Queue Message encode posts after a message is framed Message transitter pulls out each message and sends. Events OnMessage Received (message receiver waits on this event) Onmessageposted in RXQ(message posted in RXQ) OnBufferPosted (several action tasks wait on this) On verify event (verifier waits on this event) Onvoterselect (Encodeed message is to set the voter selection) OnTxQueuePosted(Message transmitter waits on this)
Interaction
sd task interaction Message receiver EVM MessageDecoder signatureVerifier MessageEncoder Messagetransmi... Vote_registration
OnMessageReceived()
PostMessageinReceivequeue() OnmessagePostedinreceivequeue()
Decode and post in action buffer() Onverifyset()
Verify the signature and update action buffer() Encode message()
Post ACK message in TXqueue()
Onvoter select() Update database and set action buffer, send message to encoder()
Encode ACK message()
Post ACK message ()
References
An embedded software primer by David E Simon, Addison Wesley Real-Time Systems by Jane Liu, Pearson ed.,2000.

L24 - 26 Realtime Executives

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

L24 - 26 Realtime Executives

Caricato da

Copyright:

Formati disponibili

Software for embedded systems Cs424 First Semester 2012-13

CS C 424 Software for Embedded systems

CS C 424 Software for Embedded systems

Tasks and Task States

CS C 424 Software for Embedded systems

CS C 424 Software for Embedded systems

What ever the task needs, happens

Another ready task is of higher priority

CS C 424 Software for Embedded systems

Scheduler and task states

CS C 424 Software for Embedded systems

CS C 424 Software for Embedded systems

CS C 424 Software for Embedded systems

CS C 424 Software for Embedded systems

RTOS data organization

CS C 424 Software for Embedded systems

CS C 424 Software for Embedded systems

Code sharing by tasks

static int cErrors; void vCountErrors (int cnewErrors) { cErrors += cNewerrors; }

CS C 424 Software for Embedded systems

Characteristics (checks) of reentrant functions

CS C 424 Software for Embedded systems

CS C 424 Software for Embedded systems

CS C 424 Software for Embedded systems

Semaphores and Shared Data

CS C 424 Software for Embedded systems

CS C 424 Software for Embedded systems

Execution flow with semaphores

CS C 424 Software for Embedded systems

Semaphores and Shared Data

CS C 424 Software for Embedded systems

Semaphores and Shared Data

CS C 424 Software for Embedded systems

CS C 424 Software for Embedded systems

Semaphore as a signaling device

CS C 424 Software for Embedded systems

Precautions with Semaphore

CS C 424 Software for Embedded systems

CS C 424 Software for Embedded systems

CS C 424 Software for Embedded systems

Protecting shared data

CS C 424 Software for Embedded systems

More RTOS services

CS C 424 Software for Embedded systems

Message Queues, Mailboxes and Pipes

CS C 424 Software for Embedded systems

CS C 424 Software for Embedded systems

More realistic use of a queue

Passing pointers on queues

CS C 424 Software for Embedded systems

create, write, read, check-mail, destroy

Variations in RTOS implementations of mailboxes

Examples:(from the RTOS MultiTask! )

CS C 424 Software for Embedded systems

CS C 424 Software for Embedded systems

CS C 424 Software for Embedded systems

CS C 424 Software for Embedded systems

CS C 424 Software for Embedded systems

CS C 424 Software for Embedded systems

CS C 424 Software for Embedded systems

Initialize memory pool

Init_mem_pool function in muti task