Mobile and Embedded Device

Mobile and Embedded Device Selecting an Operating System Why use an OS? ● In our previous work we have seen how to execute a number of tasks on our system ● Some of these tasks can run asynchronously – For example interrupt driven tasks ● So if we want to exploit the resources of our system efficiently we require some software support to do this – Namely an operating system Which Operating System? ● There are a number of choices when selecting an OS – Size, cost, features ● Free – FreeRTOS: http://www.freertos.org – TinyOS: http://www.tinyos.net – Chibios: http://www.chibios.org/ – eCos, uKOS, EROS, Nut/OS – Various Linux flavours ● Commercial – VxWorks: http://www.windriver.com – QNX: http://www.qnx.com – SafeRTOS: http://www.highintegritysystems.com/safertos.html – uC/OSII: http://www.micrium.com – Salvo: http://www.pumpkininc.com – INTEGRITY, VelOSity, THEOS, RMX Why FreeRTOS ● Free (Both “Speech” and “Beer”) – No Royalties, Open Source – Although documentation costs ● Lightweight – Low overhead, simple code ● Portable – ~8 major architectures officially supported, more unofficially ● Cooperative or Preemptive – We're going to be using preemptive ● Good Documentation – http://www.freertos.org – Look under FreeRTOS API – Functional docs plus code examples ● Developed by an Ex-Student! – Richard Barry, BSc CRTS What required from an OS? ● For small embedded systems they are required to be – Small memory footprint – Efficient use of resources – Fast ● We require what is normally called an 'executive' rather than an operating system – Lots of features can be missing or excluded ● No file system ● No/limited user protection ● Limited system accounting Tasks ● At a minimum the RTOS should offer the ability to run a series of tasks ● These are separate programs ● They should be able to be scheduled ● Co-ordinated ● Prioritised ● Protected Task life cycle Task states ● Running: – currently executing task ● ready: – candidate for scheduling – running task has higher or equal priority – scheduler must choose next ready task with maximum priority ● Blocked: – task waiting on an event – temporal delay or external user interaction ● Suspended: – neither running, ready, nor blocked – cannot be executed until it becomes ready again ● Idle task: – systematically created in every application – lowest priority – may have idle-task hook – e.g., to put device in low power mode FreeRTOS tasks portBASE_TYPE xTaskCreate( pdTASK_CODE pvTaskCode, const signed portCHAR * const pcName, unsigned portSHORT usStackDepth, void *pvParameters, unsigned portBASE_TYPE uxPriority, xTaskHandle *pxCreatedTask ); pvTaskCode the actual function/program to run pcName the name – only sued for debugging usStackDepth the size of the stack in words uvParameters pointers to the parameters – can be NULL UxPriority the task priority – must be greater than 0 (Idle task) pxCreatedTask a handle to the task – like a file handle, used by other functions Scheduling ● Requires tick interrupt – Time slicing ● Uses priorities ● Can be cooperative or preemptive ● Requires an idle task ● Priorities 12 10 8 Column 1 6 Column 2 Column 3 4 2 0 Row 1 Row 2 Row 3 Row 4 Semaphores ● As tasks will frequently have access to data that may be difficult to share the system will require semaphores ● These will allow certain resources to be available yet protected ● There are – Binary, mutexs and counting semaphores Queues ● As many tasks will be waiting on some of the scheduler's queues or waiting for resources or events, FreeRTOS needs to be able to provide safe and reliable access to queues ● There are a whole series of primitives that are provided for queue management which allow queues to interact with semaphores and interrupts Porting ● The ARM architecture is well supported ● There are ports to some Cortex M3 devices ● There is little in the way of devices – These must be written by the developer ● Although there are a number around ● The file FreeRTOSConfig.h is used for all the main configuration information .

Load more