Sistemas embebidos para tiempo real
| Tema | Nombre | Descripción |
|---|---|---|
Cronograma tentativo de las clases, laboratorios, etc. |
||
Bibliografía del curso |
||
Reglamento del Curso |
||
Listado de estudiantes |
||
Calificaciones Laboratorio |
||
Notas finales del curso |
||
| Teórico 2024 | Contenido del curso, objetivos, metodología, forma de aprobación, etc. |
|
Introducción y conceptos basicos: sistemas embebidos y de tiempo real. |
||
Encuesta sobre el mercado de sistemas embebidos |
||
Introducción al lenguaje C. |
||
Herramientas de desarrollo y depuración. Proceso de compilación de una aplicación (Compilación, linker/locator, diferencias entre compiladores nativos y embebidos). Inicialización de datos y arranque de programa. Cargado de programa. |
||
Diapositivas usadas en la clase de introducción al control de versiones |
||
Microcontroladores: arquitectura, periféricos, etc. |
||
Periféricos de microcontroladores |
||
Alternativas a deshabilitar interrupciones: lecturas sucesivas, doble buffer, cola circular. |
||
Estudio de las diferentes arquitecturas de software embebido |
||
Nivel circuito y sistema. Programación para bajo consumo |
||
Conceptos generales, tipos de test, test en host, simuladores, aserciones |
||
Introducción a los RTOS. Tareas. Planificador. Datos compartidos entre tareas. |
||
Semaforos: recursos compartidos y señalización. |
||
Comunicación entre tareas. Gestión del tiempo, eventos, gestión dinámica de memoria, interrupciones en RTOS |
||
Trabajos para los estudiantes que falten a alguna clase de teórico. |
||
| Laboratorios 2024 | Versión 1.6 del 4/3/2022 |
|
En este laboratorio se darán los primeros pasos de utilización del entorno de desarrollo integrado (IDE, Integrated Development Environment) Code Composer Studio (CCS) para la creación de aplicaciones embebidas y se introducirá la plataforma de hardware Launchpad MSP-EXP430G2ET con un microcontrolador MSP430G2553 a utilizar durante los laboratorios, desarrollando parcialmente un módulo de reloj de tiempo real. Este laboratorio también servirá como una introducción a GIT y a las buenas prácticas de programación. |
||
En este laboratorio se implementará un reloj de tiempo real utilizando un timer (temporizador hardware) de un microcontrolador y el módulo de reloj desarrollado en el Laboratorio 1. |
||
Archivos auxiliares necesarios para la realización del laboratorio 2 |
||
En este laboratorio se implementará un registrador de temperatura involucrando comunicación serie asíncrona, el uso de un reloj de tiempo real y un sensor de temperatura. Para reducir el consumo se deberá configurar al microcontrolador en modo de bajo consumo (LPM3) con interrupciones habilitadas cuando no tenga ninguna tarea pendiente. Se deberán implementar dos versiones de la misma aplicación, usando: i) una arquitectura de software de Round-Robin con interrupciones, ii) una arquitectura de software de encolado de funciones con interrupciones. |
||
Este conjunto de reglas para gitignore no ha sido verificado, y se entrega en modalidad "as is". Cualquier comentario sobre su estructura es bienvenido. Tomado de https://github.com/keen/keen-cc3200 |
||
Ejemplo comentario módulo (doxygen) |
||
Ejemplo avanzado comentario módulo (Doxygen) |
||
| Proyectos | ||
Template en Latex para Documentación Final |
||
Proyectos de fin de curso de años anteriores. |
||
| Material adicional: Ejercicios complementarios de lenguaje C | Ejercicios complementarios al Laboratorio 1. |
|
Ejercicios complementarios al Laboratorio 2. |
||
Ejercicios complementarios al laboratorio 3. |
||
Ejercicios complementarios al Laboratorio 4. |
||
| Material adicional: Lenguaje C para sistemas embebidos | Convenciones sobre estilo de programación. |
|
Modularidad y abstracción de software. |
||
Finding and killing latent bugs in embedded software is a difficult business. Heroic efforts and expensive tools are often required to trace backward from an observed crash, hang, or other unplanned run-time behavior to the root cause. In the worst cases, the root cause damages the code or data in a way that the system still appears to work fine or mostly fine-at least for a while. Too often engineers give up trying to discover the cause of infrequent anomalies that cannot be easily reproduced in the lab- dismissing them as user errors or "glitches." Yet these ghosts in the machine live on. Here's a guide to the most frequent root causes of difficult to reproduce bugs. Look for these top five bugs whenever you are reading firmware source code. And follow the recommended best practices to prevent them from happening to you again. |
||
Columna: "Assert Yourself" por Niall Murphy |
||
| Material adicional: RTOS y afines | In this course Jack Ganssle will describe how an RTOS is an essential part of a large class of embedded systems, and how its use can greatly simplify the design of a system while decreasing time to market. Further, he explains the essential parts of an RTOS's kernel and how the developer uses these resources in a typical application (March 2011). |
|
Part 6 reviews various RTOS scheduling algorithms and explains the pros and cons of each. Part 8 shows how to analyze systems with aperiodic tasks. It also shows how to avoid priority inversion by using priority inheritance. Part 7 shows how to analyze scheduling behavior, and how to ensure tasks meet their deadlines. |
||
Lui Sha; Rajkumar, R.; Sathaye, S.S., "Generalized rate-monotonic scheduling theory: a framework for developing real-time systems," Proceedings of the IEEE , vol.82, no.1, pp.68-82, Jan 1994 Abstract: Real-time computing systems are used to control telecommunication systems, defense systems, avionics, and modern factories. Generalized rate-monotonic scheduling theory, is a recent development that has had large impact on the development of real-time systems and open standards. In this paper we provide an up-to-date and self-contained review of generalized rate-monotonic scheduling theory. We show how this theory can be applied in practical system development, where special attention must be given to facilitate concurrent development by geographically distributed programming teams and the reuse of existing hardware and software components. |
||
by Mats Pettersson, IAR Systems. Abstract This article will explain some Real-Time Operating Systems (RTOS) basics. The material presented here is not intended as a complete coverage of different RTOSes and their features. For the purposes of simplification, I will briefly cover the most important features of a representative RTOS. After we explore what constitutes an RTOS and why we might want to use one, I’ll explain each of the basic components of a typical RTOS and show how these building blocks are integrated into the system. |
||
Autores: Miro Samek (Quantum Leaps) y Robert Ward (Netopia Inc.) |
||
Autores: Andy Gayne & Steve Duckworth, Field Application Engineers, GD Technik Ltd. |
||
Artículo de Jim Turley (Embedded Systems Design) sobre el uso de RTOS. |