Diseño de S.E. usando placa Lanín EmTech S.A.

Que es un sistemas embebido? Un sistema embebido se puede definir como un sistema electrónico diseñado específicamente para realizar determinadas funciones. El hardware y el software están diseñados y optimizados para resolver un problema en concreto. Su característica es que emplea uno o varios procesadores digitales, pudiendo ser un microprocesador, microcontrolador o DSP. Generalmente en un sistema embebido el hardware y el software están diseñados y optimizados para resolver un problema en concreto. Por parte del hardware se busca minimizar su tamaño, reducir su consumo de energía (puede ser alimentado por baterías) y emplea componentes específicos para resolver el problema. Respecto al software se debe tener en cuenta que se dispone de recursos limitados (memoria, capacidad de cálculo, etc.) por lo que se debe realizar un estudio previo en la fase de diseño para determinar que dispositivo y que metodología de programación es el adecuado (Usar o no un sistema operativo)

Donde encontramos un sistema embebido? Aplicaciones Electrodomésticos Juguetes Instrumentación Automatización Vehículos Sector Aeroespacial Comunicaciones Robótica

¿Cuál es la arquitectura de un sistema embebido? Interfaz con el usuario Alimentación CPU El microcontrolador, microprocesador, dsp es el dispositivo que le da “inteligencia” al sistema, y que permite ser programado para realizar las funciones específicas. En el mercado actualmente hay muchas opciones, de 8-bits, 16-bits, 32-bits, distintas capacidades de cálculo, distintas arquitecturas, de consumo reducido de energía, etc… Comunicaciones. Esto permite comunicar el sistema embebido con otros sistemas embebidos, sensores, usuario, etc… Entre las más conocidas tenemos, comunicación serial, USB, Ethernet, bluetooth, GPRS, etc. Entrada y salida. Módulos que se encargan de enviar o hacer llegar señales al CPU realizando el procesamiento adecuado para la lectura de sensores, activación de actuadores, etc. Pueden ser digitales o analógicos. Interfaz con el usuario. Algunos sistemas necesitan interacción con el usuario y entre estos dispositivos tenemos: Leds, botones, LCD alfanumérico, pantalla gráfica, pantalla táctil, etc. Alimentación. Es el modulo que se encarga de generar los distintos niveles de tensión para alimentar cada uno de los dispositivos dentro del sistema embebido, compuesto por reguladores de tensión, filtros de interferencias, circuitos supervisores de tensión, protectores de sobretensión, etc. Comunicaciones Entrada/Salida

Placa Lanín

Durante el transcurso del curso vamos a utilizar la placa Lanin, placa desarrollada por Emtech que permita realizar aplicaciones personalizadas disponiendo de los recursos necesarios para un rápido desarrollo y permitiendo además agregar otros mediante la creación de placas hijas

ARM

¿Que es ARM? ARM es un empresa que se dedica al diseño de cores y algunos otros aditamentos (periféricos, controladores de memoria, etc), pero no a la fabricación de chip. Como corazón se utiliza un microcontrolador ARM de la empresa ST. Que es ARM? ARM es un empresa que se dedica al diseño de cores y algunos otros aditamentos (periféricos, controladores de memoria, etc), pero no a la fabricación de chip. Ellos se dedican a vender estos diseños los cuales se pueden adaptar a diferentes productos, y son las empresas que dependiendo de la estrategia que utilice seleccionara los periféricos para diferenciarse de otras que utilizan el mismo procesador.

Empresas consumidoras de arquitecturas ARM

Familias de arquitecturas ARM ARM a partir de su arquitectura v7 introduce el concepto de perfiles denotándolo por una letra en su nomenclatura: A: Procesador de alta performance orientados a sistemas complejos. R: Procesadores orientados a sistemas de tiempo real o de seguridad critica. M: Procesadores orientados a microcontroladores, de arquitectura más “sencillas”

Cortex-M Los que nos interesa en este curso son los Cortex M y actualmente está compuesta por: Cortex M0, M0+, M1, M3, M4. M1 solo se puede usar como softcore dentro de una FPGA.

Cortex-M Las modificaciones y diferencias de esta arquitectura están fundamentalmente enfocadas a obtener una operación determinística, mínima latencia de interrupciones, contar con una pipeline mínima y prescindir del uso de caches. El set de instrucciones está diseñado para soportar de forma simple y eficiente la gran mayoría de las operaciones realizadas en lenguaje C, incluyendo bitfields. Un micro con un set de instrucciones diseñado para que el compilador pueda generar código eficiente en la mayoría de las operaciones típicas que se desarrollan en C Presenta un mapa unificado de memoria, lo que le permite ocultar su estructura Harvard a los oj os del programador (y fundamentalmente del compilador). La definición del mapa de memoria por parte del proveedor del core (ARM), permite que todos los fabricantes que lo utilizan ubiquen tanto memoria como periféricos en las mismas direcciones (en general). Esto, sumado a la existencia de periféricos comunes como el NVIC (Nested Vectored Interrupt Controller) y el timer Sy sTick , y el software de abstracción CMSIS (Cortex Microcontroller Software Interface Standard), logran que el usuario final pueda portar su aplicación de un fabricante a otro sin may ores inconvenientes. Esto es tal vez la mayor fortalez a de ARM en microcontroladores, el usuario no queda atado a un fabricante ni a una herramienta de desarrollo.

Cortex-M Modelo de manejo de prioridades Cada excepción tiene un nivel de prioridad, y sólo aquéllas de mayor prioridad pueden interrumpir a otra que esté siendo atendida. Los números más bajos tienen precedencia, es decir, una prioridad más alta. Las excepciones Reset, NMI y HardFault, según vimos, tienen las prioridades más altas, fijas e inamovibles, -3, -2 y -1 respectivamente. El resto de las excepciones permite que su prioridad se pueda configurar por software mediante registros en el SCB o el NVIC, comenzando con el valor 0 (la prioridad más alta). ARMv7-M se orienta a microcontroladores, y un buen manejo de interrupciones anidadas con baja latencia es una pieza fundamental en una buena arquitectura. Con esta finalidad, se incorporan una serie de características únicas, a saber: Tail chaining (encadenado a la cola): Permite pasar de atender una excepción a otra sin recuperar y volver a salvar los registros que ya han sido salvados (R0 a R3, R12, LR y PC). Late arrival (arribo tardío): Permite atender primero a una excepción de mayor prioridad que se produce durante el proceso de guardar los registros en el stack en atención a una excepción anterior, de menor prioridad. POP pre-emption (suspensión de la recuperación de registros del stack ): Si una excepción ocurre en medio del proceso de recuperación de registros del stack , como consecuencia del retorno del procesamiento de una excepción anterior, es posible interrumpir dicho proceso y atender la nueva excepción inmediatamente

La placa Lanín está desarrollada utilizando un ARM Cortex M4 STM32F417ZGT6 de la empresa ST. El procesador M4 es una de las implementaciones de la arquitectura ARMv7-M. Cortex-M4 es el resultado de la evolución de la arquitectura Cortex-M3 de ARM de 32-bits, sus microcontroladores se caracterizan principalmente por proporcionar capacidades para el procesamiento de señal digital (DSP), funcionalidad matemática y una unidad opcional de punto flotante (FPU). Esta es una característica que agrega M4 pero que no todos los fabricantes la incorporan.  FPU: Este bloque opcional agrega un conjunto extra de treinta y dos registros para números en coma flotante de simple precisión (32-bits). Entre las cuales encontramos suma y multiplicación en un ciclo de clock , división en catorce ciclos, y multiplicación y acumulación en tres ciclos de clock . Adicionalmente, la arquitectura Cortex-M4 cuenta con mejoras respecto a eficiencia energética, lo que representa un aspecto de vital importancia en el desarrollo de tecnologías modernas, siempre apuntando al cuidado del medio ambiente.

4 LEDs y 2 Pulsadores Ideales para corroborar el correcto funcionamiento de las diferentes aplicaciones, para ingresar estímulos externos a la aplicación o como interfaz de usuario

Conexión en los puertos del microcontrolador

Conexión USB host Para conectar diferentes periféricos a la placa, tales como teclado, mouse, pendrive, etc.

Conexión USB host con el microcontrolador Se ha utilizado un controlador de corriente máxima, lo que permite habilitar/des-habilitar la alimentación y detectar si ocurre una sobre-corriente (>500mA) al operar con el dispositivo.

Conexión RS 485 Posee dos canales RS485 half-duplex RS485 es un bus de transmisión multipunto diferencial, ideal para transmitir a altas velocidades sobre largas distancias (35 Mbit/s hasta 10 metros y 100 kbit/s en 1200 metros) y a través de canales ruidosos.

Conexión RS 485 con el microcontrolador

Zócalo para memoria µSD Alta capacidad de almacenamiento tanto para guardar datos de adquisiciones como para almacenamiento de paginas web, archivos de audio, etc. Las líneas utilizadas en este zócalo también se disponen en un conector, ya sea para debugger o para realizar una placa adicional que utilice estas líneas.

Conexión µSD

Conexión USB device Para conexión de datos y alimentación desde una PC. Adicionalmente permite utilizar el bootloader del microcontrolador. Conector mini-USB tipo B para implementar el sistema embebido como dispositivo USB. De esta manera podemos implementar alguna clase USB (CDC, HID, MSD) para comunicación con una PC, permitiendo realizar aplicaciones para control y/o configuración del mismo o para transferencia de datos. Adicionalmente el microcontrolador puede ser iniciado en modo bootloader y utilizar este medio de comunicación para actualizar el firmware. La placa dispone de los jumper BOOT0 y BOOT1 para seleccionar desde donde bootear al resetear el microcontrolador. Las opciones son desde Flash (modo default), desde system Memory (que tiene el bootloader) o desde una memoria externa SRAM.

Conexión USB device

Ethernet Ethernet 10/100Mbps para implementación de stack TPC/IP Dispone de un conector Ethernet 10/100 Mbps con trasformadores incluidos para la implementación del stack tcp/ip. Esto permite embeber páginas web ya sea para visualizar el estado del sistema o para configurar sus funcionalidades. O implementar protocolos TCP/UDP para la transferencia de datos o para implementar otros protocolos sobre ellos tales como Modbus, DNP3, etc.

Conexión Ethernet

Headers Pines de uso general, compatibles con placas DTR desarrolladas por Emtech S.A. Implementa algunas líneas del periférico FSMC para control de memoria Nand-Flash, Muxed-Nor-Ram o LCD Se implementan dos conectores con un estándar establecido por Emtech para mantener en el desarrollo de placas de este estilo y poder generar placas hijas a ser utilizadas en cualquiera de ellos. Se disponen de 64 pines de entrada y salida que pueden usarse para propósitos generales y de las alimentaciones disponibles en la placa 3.3V y 5V. En la selección de pines a implementar en estos conectores se tuvo en cuenta los mínimos necesarios utilizados por el periférico denominado FSMC (flexible static memory controller) para poder controlar una memoria Nand-Flash o Muxed-Nor-Ram. En el caso de una memoria multiplexada se puede direccionar hasta 2^26=64 MBytes.

Conexión Headers

DTRs

DTRs

Alimentación Externa o USB, selección mediante jumper Se dispone de dos conectores de alimentación para una fuente externa de 5V, pero adicionalmente se puede seleccionar como fuente de alimentación los 5V obtenidos de los conectores USB.

Serial/USB y JTAG/USB Mediante un chip de FTDI se implementa la conversión de UART1 a USB para uso general y de JTAG a USB para programador/depurador on-board. Se agregó un chip de la empresa FTDI (FTH2232H). Este dispositivo USB tiene dos puertos con la capacidad de ser configurados en una gran variedad de interfaces serie o paralelo estándar de la industria. En este caso se utiliza un canal para comunicación serial (USART1 del microcontrolador) y otro para JTAG lo que permite tener un programador/debugger on-board utilizando el server JTAG OpenOCD (código abierto)

JTAG Adicionalmente se dispone del conector para utilizar un programador/depurador externo. Adicionalmente también se dispone de un conector JTAG con pin-out estándar para poder utilizar cualquier otro programador externo

Entorno de desarrollo

Que es un entorno de desarrollo? Es aquel que permite integrar distintas herramientas de desarrollo dentro de un solo programa. Editor, compilador, depurador. Lanín-CM4 SDK. (Eclipse) Entornos de desarrollo: Keil La firma Keil es una empresa famosa por sus compiladores para MCS-51 (8051), desde hace unos años “una empresa del grupo ARM”. Como tal, el compilador es algo así como “el oficial”, al menos para este entorno de microcontroladores. El entorno de desarrollo utilizado es uVision, el nombre del producto es ARM-MDK (Microcontroller Development Kit), del que puede obtenerse en página web una versión sin costo con límite de 32KB de código generado. IAR Systems La empresa sueca IAR Systems desarrolla el producto Embedded Work bench for ARM (EWARM), cuya versión sin costo con límite de 32KB de código generado. CooCox Dicho nombre hace referencia a Cooperate on Cortex, un grupo de desarrolladores que provee un entorno de distribución gratuita, CoIDE, basado en Eclipse y la distribución lite de Sourcery CodeBench de Mentor Graphics. Este grupo de desarrolladores provee además código para muchos periféricos, una capa de abstracción (CoX), y hasta un RTOS (CoOS), todo de forma gratuita.

Porque Eclipse? Código abierto Interfaz amigable Existen diferentes plugins que incrementan sus capacidades

Configuración de Eclipse Toolchain Código fuente Plataforma CodeSourcery GNU YAGARTO GNU ARM

Configuración de Eclipse CodeSourcery GNU toolchain para ARM: Permite construir aplicaciones ARM embebidas. YAGARTO GNU ARM toolchain: Es una EABI (embedded-application binary interface). Esto especifica las convenciones estándares para formatos de archivos, tipos de datos, uso de registros, etc.

Lanin-CM4 SDK

Diseño de aplicaciones en sistemas embebidos

Recordando… Aplicaciones Electrodomésticos Juguetes Instrumentación Automatización Vehículos Sector Aeroespacial Comunicaciones Robótica

Aplicaciones Cualquier sistema puede clasificarse en : Sistema sin requerimientos de respuestas en tiempo real. Sistemas con requerimientos flexibles de respuesta en tiempo real. Sistemas con requerimientos estrictos de respuesta en tiempo real. N-RT: Es un sistema en los que no hay plazos involucrados. "Es un sistema en el que la reacción programada a un estímulo sin duda ocurrirá en algún momento en el futuro." Ej: Encontrar la solución de una ecuación matemática. Un sistema de tiempo real flexible es un sistema en el que el no cumplimiento de un plazo puede producir efectos no deseados, pero no catastróficos, una degradación del rendimiento, por ejemplo. "Un sistema de tiempo real flexible es un sistema en el que la reacción programada a un estímulo casi siempre se completó dentro de un tiempo finito conocido". Un sistema de tiempo real estricto es un sistema en el que el no cumplimiento de un plazo puede tener efectos catastróficos. Es un sistema en el que está garantizada la reacción a un estímulo programado para ser completado en un tiempo finito conocido".

Dos paradigmas de programación Bare Metal El software tiene acceso directo sobre los recursos del hardware. Para llevar a cabo este método en la placa Lanín, se utiliza la librería CMSIS. El software utiliza un sistema operativo RTOS. En nuestro ejemplo práctico en la placa Lanín utilizaremos el ChibiOS. También se pueden correr diferentes sistema operativos, por ejemplo: Nuttx, FreeRTOS. etc. RTOS Nuestro sistema y bajo que restricciones de tiempo real se encuentras, se pasa a elegir bajo que paradigma de programación se va a diseñar nuestra aplicación. Bare Metal ó RTOS

Método de programación:

¿Qué nos ofrece el fabricante para interactuar con el uC? La CMSIS es una librería común a todos los fabricantes de procesadores ARM Cortex-M y pretende establecer la abstracción del hardware. Core Peripheral Access Layer Device Peripheral Access Layer Access Functions for Peripherals (optional) ARM provides as part of the CMSIS the following software layers that are available for various compiler implementations: Core Peripheral Access Layer: contains name definitions, address definitions and helper functions to access core registers and peripherals. It defines also a device independent interface for RTOS Kernels that includes debug channel definitions. These software layers are expanded by Silicon partners with: En principio necesitaremos algunas librerías que sirvan de interfaz para acceder a los componentes del microcontrolador. Device Peripheral Access Layer: provides definitions for all device peripherals Access Functions for Peripherals (optional): provides additional helper functions for peripherals CMSIS defines for a Cortex-M Microcontroller System: A common way to access peripheral registers and a common way to define exception vectors. The register names of the Core Peripherals and the names of the Core Exception Vectors. An device independent interface for RTOS Kernels including a debug channel.

CMSIS Estas librerías deben agregarse al proyecto creado en Eclipse, las cuales se encuentran comprimidas en un único archivo titulado “STM32F4 DSP and standard peripherals library”. Link de descarga: http://www.st.com/stonline/stappl/resourceSelector/app?page=resourceSelector&doctype=FIRMWARE&SubClassID=1521 Básicamente bajo este método de programación estamos por las nuestras, con la ayuda de las librerías de la CMSIS

Algunos archivos de la librería

system_stm32f4xx.c/.h Lugar donde se encuentra la configuración del reloj para los dispositivos STM32F4xx. Exporta la función SystemInit() que configura el reloj, los factores multiplicadores y divisores del PLL, AHB / APBx prescalers y Flash. Esta función es invocada en la inicialización justo después del reset y antes de comenzar el programa principal. La llamada se realiza dentro del archivo startup_stm32f4xx.s.

stm32f4xx.h startup_stm32f4xx.s Lugar donde se encuentran las definiciones de todos los registros de periféricos, bits de los registros, y mapeo de memoria para dispositivos STM32F4xx. startup_stm32f4xx.s Proporciona el código de inicialización del Cortex-M4 y los vectores de interrupción para todos los manejadores de interrupción del dispositivo STM32F4xx.

Creación de un proyecto en C Para comenzar cambiar el Workspace a Placa Lanin/BareMetal: File -> Switch Workspace -> Others

Creación del proyecto EL NOMBRE SIN ESPACIOS

Importando librerías

USE_STDPERIPH_DRIVER Configuraciones *.ld STM32F4XX USE_STDPERIPH_DRIVER

Proyecto terminado Si se abre un ejemplo anteriormente compilado en otra PC, borrar la carpeta Debug.

Importar un proyecto

Configuración del Debugger arm-none-eabi-gdb Antes de iniciar, compilar el ejemplo!

Pasos para debuggear una aplicación

Ejemplos método:

Configuración general La inicialización de cualquier periférico en los cortex M4 consta de cuatro pasos básicos: Programación del reloj: En MCUs de muy bajo consumo, generalmente los periféricos tienen su señal de reloj inhabilitada. Programación de configuraciones: Los pines del MCU son compartidos entre periféricos, salvo muy contadas excepciones. La conexión del periférico a una fuente de reloj debe hacerse explícitamente mediante un registro de configuración del procesador. Este proceso se llama multiplexado y un registro de configuración del procesador es el que determina hacia que periférico debe “apuntar” el pin a usar

Configuración general Configuración del periférico: Determinar las características particulares para el funcionamiento en una aplicación específica. Configuración de la interrupción: Si se tratan eventos del periférico a través de INTs, éstas deben ser configuradas. En los cortex M4 esta configuración se hace sobre el Nested Vector Interrupt Controller (NVIC).

Configuración de Pines de Entrada y Salida de propósito general GPIO El uso de las GPIO son la forma más fácil de interactuar con periféricos como botones, leds, interruptores, y otros componentes. De acuerdo al tipo de operación que se desee realiza con las GPIO, se pueden configurar de acuerdo a los siguientes parámetros: Modo: Entrada, Salida, Análogo, Función alternativa. Tipo del pin de salida: Push-pull, Open drain. Velocidad del pin de salida: Baja (2MHz), Media (10MHz), Alta (50MHz). Resistencias internas: Pull-up, Pull down. La configuracion de velocidad es para ahorrar energía, ya que una configuración de 2M consume menos energía que la de 50.

Configuración de Pines de Entrada y Salida de propósito general GPIO

Código para configuración de las salidas digitales Ejercicio: Analizar y ejecutar el ejemplo del demo de prendido y apagado de led’s.

Entradas digitales Modificar el ejemplo para cambiar el estado de un led cada vez que se pulse S2. Ayuda: Manual de la “STM32F4 DSP and standard peripherals library” (stm32f4xx_dsp_stdperiph_lib_um. chm) if(GPIO_ReadInputDataBit(GPIOG, GPIO_Pin_15)==1){ GPIO_ToggleBits(GPIOG,GPIO_Pin_3); Delay(5000); }

Configuración de la USART

Código para configuración de la USART

Entradas analógicas 3 conversores AD 19 canales multiplexados (16 externos) Hasta12 bits de resolución Muchos modo de funcionamiento: Simple, continuo, disparo interno, externo, temporizado, ... Transferencia por programa, interrupción, DMA Modos entrelazados, simultáneos Canales “regulares” e “inyectados”

Hay 16 canales multiplexados Hay 16 canales multiplexados. Es posible organizar las conversiones en dos grupos: regular y de inyecta. Un grupo consiste en una secuencia de conversiones que se pueden hacer en cualquier canal y en cualquier orden. Por ejemplo, es posible llevar a cabo la conversión secuencia en el orden siguiente: ADC_IN3, ADC_IN8, ADC_IN2, ADC_IN2, ADC_IN0, ADC_IN2, ADC_IN2, ADC_IN15. ● Un grupo regular se compone de hasta 16 conversiones. ● Un grupo de inyecta se compone de un máximo de 4 conversiones.

Configuración ADC

Método de programación: SISTEMA OPERATIVO RTOS

Sistema Operativo en Tiempo Real RTOS Un RTOS, es un Sistema Operativo especializado en operaciones de respuesta en tiempo real y debe cumplir con las siguientes características: Respuesta de tiempo Previsible. Determinista. Es importante entender que el diseño del sistema en sí, es lo que lo hace, estricto, flexible a las restricciones de tiempo real, el RTOS es sólo una herramienta que se puede utilizar de forma correcta o incorrecta. En su sistema, puede utilizar un RTOS simplemente porque puede ser cómodo de usar en comparación con un sistema de metal desnudo. Un RTOS, especialmente diseñado para aplicaciones integradas, también puede ofrecer otros servicios como, por ejemplo, un entorno de ejecución estable, controladores de dispositivos, sistemas de archivos, redes y otros subsistemas útiles. Determinista: Ningún factor externo podría modificar su comportamiento. Respuesta de tiempo previsible: Es posible calcular el tiempo en que se demoraría en ejecutar alguna tarea.

Ejemplo de Sistema en tiempo Real Software de Tiempo Real Entorno Externo Sensores Reloj Tarea Actuadores SO Tarea Tarea Ej: Sistema de control de un automóvil.

RTOS Un RTOS permite diseñar la aplicación por bloques funcionales, donde cada bloque en teoría sería un hilo (thread). Cada hilo se responsabilizaría de una parte de la aplicación, respondiendo a diferentes restricciones de tiempo, por lo cual deberán tener diferentes prioridades. Un SO ofrece las ventajas de asegurar la correcta ejecución de tareas de tiempo real con tiempos de ejecución críticas, las cuales no se ven afectadas por la ejecución de tareas con menos prioridad.

RTOS Un sistema operativo, ofrece, la posibilidad de asignar prioridades a las tareas, así como los mecanismos para que se comuniquen entre ellas, y las herramientas que aseguren que las tareas que tienen tiempo crítico, sean ejecutadas dentro de las restricciones de tiempo real establecidas.

Características de un RTOS Tiempo de Respuesta: Un RTOS eficaz sólo añade una pequeña sobrecarga en el tiempo de respuesta mínimo teórico del sistema por ejemplo: El tiempo desde una petición de interrupción y el de interrupción. El tiempo de un evento de hardware, por lo general una interrupción y el reinicio de la tarea que debe manejarlo. El tiempo de cambio de contexto, necesario para cambiar de forma sincronizada desde el contexto de un hilo en el contexto de otro hilo. Bajo Jitter. Tamaño: Un RTOS más compacto es preferible siendo todos los demás parámetros iguales, por el costo de memoria. Confiabilidad: Algunos sistemas pueden ser más fiables que otros, la asignación dinámica es un buen ejemplo, tanto falta de fiabilidad y el tiempo de imprevisibilidad. Primitivas de Sincronización: Variedad de primitivas disponibles para utilizar. Tiempo de respuesta Un parámetro importante en la evaluación de un RTOS es su tiempo de respuesta. Un RTOS eficaz sólo añade una pequeña sobrecarga en el tiempo de respuesta mínimo teórico del sistema. Los parámetros típicos que caen en esta categoría son: Interrupt latency, el tiempo desde una petición de interrupción y el de interrupción. Un RTOS puede añadir un poco de sobrecarga en el servicio de interrupción. La sobrecarga puede ser causada por código adicional introducido por el RTOS en los controladores de interrupción rutas de código o por zonas críticas RTOS relacionados. Threads fly-back time, el tiempo de un evento de hardware, por lo general una interrupción y el reinicio de la tarea supone que manejarlo. Tiempo de cambio de contexto, el tiempo necesario para cambiar de forma sincronizada desde el contexto de un hilo en el contexto de otro hilo. Por supuesto, un RTOS capaz de reaccionar en 2μS es mejor que un sistema que reacciona en 10μS. Tenga en cuenta que lo que es realmente significativo es el peor valor del caso, si un sistema reacciona en medio en 5μS pero, debido a la fluctuación, puede tener picos de hasta 20μS entonces el valor a considerar es 20μS. Jitter A good RTOS is also characterized by low intrinsic Jitter Un buen RTOS también se caracteriza por una baja fluctuación de fase intrínseca en el tiempo de respuesta. Intrínseca debido a fluctuación de fase también está determinada por el diseño global del sistema. Algunos de los factores que determinan el comportamiento del sistema en relación con fluctuación de fase son: Tema prioridades de asignación. Interrumpir asignación prioridades. La longitud y el número de zonas críticas. Las interacciones entre los temas a través de recursos compartidos protegidos por la exclusión mutua. El uso de la herencia de prioridad u otros algoritmos / estrategias jitter-reductores. tamaño En un sistema embebido el RTOS es una sobrecarga importante en términos de memoria ocupada, un RTOS más compacto es preferible siendo todos los demás parámetros iguales, porque el costo de memoria. confiabilidad Hay opciones de diseño que hacen que algunos sistemas intrínsecamente más fiable que otros. La asignación dinámica es un buen ejemplo de una opción de diseño pobre porque tanto falta de fiabilidad y el tiempo de imprevisibilidad respuesta de algunos esquemas de asignación. Totalmente diseños estáticos no tienen esas limitaciones intrínsecas. primitivos de sincronización Variedad de primitivas disponibles es también un factor importante a considerar. Tener la herramienta correcta para el trabajo puede reducir el tiempo de desarrollo y, a menudo también ayuda a la hora de integrar código externo con el RTOS. Un buen ejemplo es el TCP / IP stack lwIP, asume un RTOS ofrece semáforos con tiempos de espera, si el RTOS no es compatible con semáforos y los tiempos de espera, entonces usted tiene un problema y tendrá que encontrar una solución.

ChibiOS - Características El ChibiOS es una opción fiable, ya que de acuerdo a sus especificaciones responde positivamente a las características de un buen sistema operativo y ofrece herramientas que facilita la programación de aplicaciones incluso sin restricciones de tiempo real.

Como funciona un sistema operativo en tiempo real? El kernel es el cuerpo del SO, contiene todas las funciones y características del RTOS. El Programador (schedule) es el corazón del SO y decide que tarea debe correr. Kernel Scheduler T1 T2 Tn Eventos Semáforos El núcleo de un sistema operativo es el kernel. (Con el api, se puede acceder al kernel y crear tareas). Cada tarea es como si fuera una función con su propia pila (privada) y su propio bloque de control (TCB) el cual tiene la información del estado de la tarea. El kernel tiene un scheduler (programador), responsable de ejecutar las tareas de acuerdo al mecanismo de asignación de tareas. Los más populares son basados en la prioridad (Priority-based) ó con derecho preferente (preemptive scheduling). Típicamente las tareas con la misma prioridad, se ejecutan mediante el método de round-robin. El ChibiOs tiene un scheduler basado en prioridad. Mensajes Colas Los mensajes y las colas son usadas para enviar datos entre tareas. Las tareas son las trabajadoras del SO y contienen el código de la aplicación. Los eventos y semáforos son señales de sincronización entre las diferentes tareas.

Asignando prioridades Utilice el menor número de niveles de prioridad como sea posible. Esto para reducir la cantidad de cambios de contexto en el sistema. Asegúrese de que la restricciones críticas de tiempo se cumplan en la aplicación.

ChibiOS - Componentes ChibiOS esta internamente divido en varios componentes: Kernel Port Layer Hardware Abstraction Layer Platform Layer Board Initialization

Kernel Bloque principal del sistema operativo. Se subdivide en varios componentes System: Se encarga de la inicialización. Timers: Timers virtuales y temporización Scheduler: Todo el mecanismo de sincronización se implementa a través de este subsistema. Threads

Port Layer Este componente es el responsable de la puesta en marcha del sistema, interrupciones, primitivas de bloqueo/desbloqueo, cambio de contexto y las estructuras relacionadas con interrupción de código

Hardware Abstraction Layer (HAL) El HAL es un conjunto de drivers de dispositivos, que se basa en los componentes de la placa para la implementación de bajo nivel en el hardware específico.  El propósito de este componente es abstraer al usuario del hardware. 

Arquitectura HAL

Board Initialization Layer Platform Layer Esta capa contiene un conjunto de implementaciones de drivers de dispositivos. Board Initialization Layer Este archivo es usado por el startup del sistema para inicializar la placa.

Dependencias En la imagen puede verse la interdependencia de los compontes antes descriptos

Externs Son librerías que se pueden agregar al directorio del sistema operativo para manejo de más periféricos, como la  librería para el manejo de la FAT, el stack TCP/IP, etc.

Ejemplos práctico utilizando un RTOS como herramienta de programación SISTEMA OPERATIVO RTOS

Creación de threads Hay dos clases de hilos en ChibiOS / RT: Static Threads: Reserva estáticamente la memoria en tiempo de compilación. Dynamic Threads: Se realiza la asignación de memoria en tiempo de ejecución de un conjunto de memoria o de un banco de memoria (reduce la fiabilidad del sistema).

Creación de un thread estático Para crear un thread estático se debe usar “ WORKING_AREA” static WORKING_AREA(myThreadWorkingArea, 128); En este caso, se reservan 128 bytes de la pila para uso del thread

Un thread estático se puede iniciar mediante la invocación de chThdCreateStatic () Thread *tp = chThdCreateStatic (myThreadWorkingArea, sizeof(myThreadWorkingArea), NORMALPRIO, /* Initial priority. */ myThread, /* Thread function. */ NULL); /* Thread parameter. */

Ejemplo, Leds intermitentes utilizando RTOS Ejercicio: Modificar el ejemplo para hacer titilar todos los leds a distintas frecuencias

Comunicación entre Tareas La comunicación puede tener la forma de un evento, un semáforo (flag), o un mensaje que se envía a otra tarea. La forma más básica de comunicación es mediante un evento. Un servicio de interrupción puede enviar un evento a una tarea, algunos SOs también pueden enviar un evento a varias tareas. Semáforos: Se utilizan para proteger recursos compartidos, por ejemplo, si hay más de una tarea que necesita escribir/leer en la misma memoria (variable) el uso de un semáforo asegura que solamente una tarea va a escribir o leer a la vez. Mensajes: Permite enviar datos a uno o más tareas. Se implementan como mailbox o queue.

Ejemplo de sincronización de tareas con semáforos binarios Recurso 2, inicia como tomado. Toma el recurso 1, ejecuta la tarea. Libera el recurso 2 Toma el recurso 2 Libera el recurso 1

Ejemplo de aplicación de mensajes

Ejemplo de aplicación de mensajes

Línea de comandos por USB Instrucciones por medio de una línea de texto simple. Generando un COM virtual mediante CDC (Comunication Device Class)

Línea de comandos por USB Al conectar el puerto USB modo device se piden instalar driver, utilizar VCP_Setup.zip, driver de ST.

Ejemplo de utilización de librerías externas con ChibiOS (Fatfs y Lwip) Por las características de mensajería y sincronización del RTOS es posible utilizar una librería externa como Lwip o Fatfs.

Ejemplo de utilización de librerías externas con ChibiOS (Lwip)

Ejemplo de utilización de librerías externas con ChibiOS (Lwip)

Ejemplo de utilización de librerías externas con ChibiOS (Lwip)

Interactuar con la página Web Formularios, delimitados con la etiqueta <FORM> ... </FORM> METHOD: POST, envía los datos al agente de procesamiento almacenándolos en el cuerpo del formulario GET, envía los datos agregándolos a la dirección URL y separándolos de la dirección con un signo de interrogación. ACTION: indica la dirección a la que se enviará la información. La etiqueta FORM actúa como una especie de contenedor para almacenar elementos que permiten al usuario seleccionar o introducir datos. Todos los datos se enviarán a la dirección URL indicada en el atributo ACTION de la etiqueta FORM, por el método indicado en el atributo METHOD. Se puede insertar cualquier elemento HTML en una etiqueta FORM (como texto, botones, tablas y enlaces), pero los elementos interactivos son los más interesantes. Estos elementos interactivos son: La etiqueta INPUT: Todos los botones y casillas de texto La etiqueta TEXTAREA: una casilla de texto La etiqueta SELECT: una lista de opciones múltiples

Interactuar con la página Web El atributo type se usa para especificar qué tipo de elemento se representa con la etiqueta INPUT. Estos son los valores posibles: checkbox: Las casillas de elección pueden adoptar uno de dos estados: checked (seleccionado) o unchecked (no seleccionado). Cuando la casilla es seleccionada, el par nombre/valor se envía al CGI. hidden: Este campo, que el navegador no muestra, es para definir una configuración única que se enviará al CGI como par nombre/valor. file: Un campo que permite al usuario especificar una ruta de archivo que lleva al archivo que se enviará con el formulario. Los tipos de archivo que pueden ser enviados deben especificarse utilizando el atributo ACCEPT de la etiqueta FORM. image: Un botón de envío personalizado que aparece cuando se ubica una imagen en la ubicación definida por el atributo SRC. password: Una casilla de texto donde los caracteres escritos aparecen como asteriscos para camuflar el texto de entrada. radio: Un botón que permite al usuario elegir entre varias opciones. Cada uno de estos botones debe tener el mismo atributo name. El par nombre/valor del botón radio seleccionado se enviará al CGI. Al aplicar el atributo checked para uno de estos botones se definirá como seleccionado de forma predeterminada. reset: Un botón de restauración para quitar todos los elementos en el formulario y restablecer sus valores predeterminados. submit: Un botón de envío para enviar el formulario. El texto en el botón puede definirse usando el atributo value. text: Una casilla de texto para escribir una línea de texto. El tamaño de la casilla puede definirse usando el atributo size y la extensión máxima del texto con el atributo maxlength. En web.c, función http_server_serve -> Para enteder se puede colocar un break point y observar que solicitud llega cada vez en buf. if ((buflen >=5) && (strncmp(buf, "GET /", 5) == 0)) { if(strncmp(buf, "GET /index.html?bt_led=1", 24) == 0){ palTogglePad(GPIOG, GPIOG_LED1); } /* Send our HTML page */ netconn_write(conn, http_index_html, sizeof(http_index_html)-1, NETCONN_NOCOPY); Ejercicio: Capturar la siguiente solicitud en el server Web y cambiar el estado de un led

Ejemplo de utilización de librerías externas con ChibiOS (Fatfs)

Ejemplo de utilización de librerías externas con ChibiOS (Fatfs)

Ejemplo de utilización de librerías externas con ChibiOS (Fatfs)

Lectura SD, escritura DAC Wave Player Server HTML Lectura SD, escritura DAC Play, Pause, Stop

Referencias http://www.arm.com/ http://cmsis.arm.com/ http://www.chibios.org/ Basic Concepts for Real Time Operating Systems by Mats Pettersson, IAR Systems Desarrollo con microcontroladores ARM. Sergio Caprile.

Preguntas?