1 / 49

7.0 MORE OS SERVICES

7.0 MORE OS SERVICES. 7.1 Message Queues, Mailboxes and Pipes Basic techniques for inter-task communication and data sharing are: interrupt enable/disable and using semaphores. E.g., the tank monitoring tasks and serial port and printer handling tasks

iago
Download Presentation

7.0 MORE OS SERVICES

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 7.0 MORE OS SERVICES • 7.1 Message Queues, Mailboxes and Pipes • Basic techniques for inter-task communication and data sharing are: interrupt enable/disable and using semaphores. E.g., the tank monitoring tasks and serial port and printer handling tasks • Others supported by RTOS: Message Queues, Mailboxes and Pipes • Example of Message Queue: (See Fig 7.1) • Task1 and Task2 (guaranteed to be reentrant) compute separate functions • Use services of vLogError and ErrorsTask (vLogError enqueues errors for ErrorsTask to process) • vLogError is supported by AddToQueue function, which keeps a queue of integers for the RTOS to interpret or map to error-type. Using the ReadFromQueue function, the RTOS then activates ErrorTask to handle the error if the queue is not empty – freeing Task1 and Task2 to continue their tasks. • Functions AddToQueue and ReadFromQueue are non-reentrant, and the RTOS switches between Task1 and Task2 in the middle of their tasks execution are guaranteed to be ok

  2. 7.0 MORE OS SERVICES • 7.1 Message Queues, Mailboxes, and Pipes – 1 • Difficulties in using Queues: • Queue initialization (like semaphore initialization) must be dedicated to a separate task to a) guarantee correct start-up values and b) avoid uncertainty about task priorities and order of execution which might affect the queue’s content • Queues must be tagged (identify which queue is referenced) • Need code to manage the queue (when full and empty) if RTOS doesn’t – 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 • (See Fig 7.2)

  3. 7.0 MORE OS SERVICES • 7.1 Message Queues, Mailboxes, and Pipes • Using Pointers and Queues • Code in Fig 7.2 limits the amount of data to write to or read from the queue • For tasks to communicate any amount of data, create a buffer and write the pointer to the buffer to the queue. (The receiving task reads/retrieves data from the buffer via the pointer, and frees the buffer space.) • (See Fig 7.3)

  4. 7.0 MORE OS SERVICES • 7.1 Message Queues, Mailboxes, and Pipes • Using Mailboxes: • Purpose is similar to queues (both supporting asynchronous task communication) • Typical RTOS function for managing mailboxes – create, write, read, check-mail, destroy • Variations in RTOS implementations of mailboxes • 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 • 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);

  5. 7.0 MORE OS SERVICES • 7.1 Message Queues, Mailboxes, and Pipes • Using Pipes: • Pipes are implemented as (special) files, using normal file-descriptors • RTOS can create, read from, write to, destroy pipes (typically: each pipe has 2 ends) • 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 • Programming queues, mailboxes, and pipes – caution! • Coding tasks to read from or write to intended ‘structure’ (RTOS can’t help on mismatch) • Interpretation and processing of message types (see code segments on p. 182) • Overflow of ‘structure’ size – could cripple the software, so need to set size as large as possible • Passing pointers in ‘structures’ provides ‘unwanted’ opportunity to create shared data problem • (See Fig 7.4)

  6. 7.0 MORE OS SERVICES • 7.2 Timer Functions • Issues: • Embedded systems track time passage, hence, need to keep time (e.g., to save battery life, power need to be shut off automatically after, say, X seconds; a message send-task expects an ACK after Y seconds, it is delayed Y seconds and may retransmit; task is allowed a slice of time after which it is blocked) • RTOS provides these timing services or functions • (See Fig 7.5 – VsWorks RTOS support for taskDelay(nticks) function in telephone call code)

  7. 7.0 MORE OS SERVICES • 7.2 Timer Functions • Issues: • How long is delay – measured in ticks (a tick is like a single ‘heartbeat’ timer interrupt time) • (See Fig 7.6) • RTOS knowledge of time/timer and specifics of nticks or time-interval – relies on microprocessor’s hardware timer and its interrupt cycles (RTOS writers must know this!) OR RTOS writers write ‘watchdog’ timers – based on non-standard timer hardware – and corresponding software interrupts – called each time the software timer expires • RTOS vendors provide board support packages (BSP) – of drivers for timers and other hardware • Length of a tick – depends on the hardware timer’s design – trade-off • Accurate timing – short tick intervals OR use dedicated timer for purpose

  8. 7.0 MORE OS SERVICES • 7.2 Timer Functions • Other Timing Services (all based on system tick) • Waiting time or delay on message, on a semaphore (but not too tight for high priority tasks to miss access to shared data) • Place ‘call to’ or ‘activation of’ time-critical, high priority tasks inside timer interrupts or specialized-time-critical tasks inside the RTOS (Note: OS task have higher priority over other embedded software tasks). • Calling a function of choice after some S nticks • Example: (See Fig 7.7) – The Timer Callback Function • Note how wdStart function is passed a function – vSetFrequency or vTurnOnTxorRx, associated nticks, and the parameter to the function. Also note how the vRadioControlTask communicates with vTurnOnTxorRx and vSetFrequency using the queue ‘queueRadio’ and msgQreceive/msgQSend)

  9. 7.0 MORE OS SERVICES • 7.3 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 • E.g., pulling the trigger of a cordless bar-code scanner sets the flag for a waiting task, which turns of the laser beam for scanning, to start running • (See Fig 7.8 and Fig 7.9)

  10. 7.0 MORE OS SERVICES • 7.3 Events – 1 • Features of events (and comparison with semaphores, queues, mbox, pipes): • More than one task can wait on the same event (tasks are activated by priority) • 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 error prone and message posting/retrieval is compute-intensive

  11. 7.0 MORE OS SERVICES • 7.4 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 • (See Fig 7.10 and Fig 7.11 – high priority FormatTask and low priority OutputTask)

  12. 7.0 MORE OS SERVICES • 7.5 Interrupt Routines in an RTOS Environment • Rules that IR’s must comply with (but not a task code) • Rule 1: an IR can’t call RTOS function that will cause it to block, e.g., wait on semaphores, reading empty queues or mailboxes, wait on events to avoid high latency or large response time and potential deadlock • (See Fig 7.12 which doesn’t work; and Fig 7.13 which works using queues)

  13. 7.0 MORE OS SERVICES • 7.5 Interrupt Routines in an RTOS Environment – 1 • Rule 2: an IR can’t call RTOS functions that will cause the RTOS to switch other tasks (except other IR’s); 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 • (See Fig 7.14 should-work case; and Fig 7.15 – what really happens case)

  14. 7.0 MORE OS SERVICES • 7.5 Interrupt Routines in an RTOS Environment – 2 • 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) • (See Fig 7.16)

  15. 7.0 MORE OS SERVICES • 7.5 Interrupt Routines in an RTOS Environment • 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 • (See Fig 7.17) • Third solution to Rule 2: • Let RTOS maintain a separate queue of specialized, interrupt-supporting functions which are called by the IR (on the appropriate interrupt). When these functions complete, control goes back to that IR (similar to Fig 7.17 with queues)

  16. 7.0 MORE OS SERVICES • 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 IR’s to allow all IR’s to complete before letting the scheduler switch to any task code • (See Fig 7.18)

More Related