UNIVERSIDAD DE BUENOS AIRES

FACULTAD DE INGENIERÍA

CARRERA DE ESPECIALIZACIÓN EN SISTEMAS

EMBEBIDOS

MEMORIA DEL TRABAJO FINAL

Porting de FreeOSEK a la plataformaMSP430

Autor:Msc. Ing. Franco Bucafusco

Director:Esp. Ing. Pablo Ridolfi (UTN-FRBA, FIUBA)

Jurados:Ing. Juan Manuel Cruz (FIUBA, UTN-FRBA)

Esp. Ing. Patricio Bos (FIUBA)Dr. Ing. Pablo Gomez (FIUBA)

Este trabajo fue realizado en las Ciudad Autónoma de Buenos Aires, entre Enerode 2016 y Diciembre de 2016.

III

Resumen

En este trabajo se presenta la implementación de una adaptación del sistemaoperativo en tiempo real FreeOSEK a la plataforma MSP430. Esta plataforma,pensada desde sus orígenes para desarrollar sistemas de ultra bajo consumo,

permite incorporar al ecosistema CIAA un microcontrolador con característicastotalmente diferentes a los que posee actualmente (basados en ARM).

Se implementaron también los manejadores de dispositivos de los puertos deentrada/salida de propósito general y de las UARTs, de forma integrada el

sistema operativo. La implementación del primero se realizó basándose en elestándar HIS. El segundo se implementó basado en el estándar POSIX.

Durante la implementación se fue versionando el progreso utilizando el sistemade control de versiones GIT y más tarde, para validar el funcionamiento de esta

adaptación, se realizaron las pruebas de conformidad estándar del sistemaoperativo OSEK corriéndolas sobre un microcontrolador MSP430F5529.

V

Agradecimientos

A María José y a mis chiquitos por aguantar mis ausencias durante las largas ho-ras de desarrollo y otras locuras que me consumió valioso tiempo.Al director de este trabajo, Esp. Ing. Pablo Ridolfi, por ayudarme incondicional-mente cuando no supe como avanzar.A Dr. Ing. Ariel Lutenberg, por guiarme con la redacción del mismo.A Mg. Ing. Mariano Cerdeiro, por brindarme ayuda remota en algunos aspectosde la implementación.

VII

Índice general

Resumen III

1. Introducción General 11.1. Sistemas Operativos en Tiempo Real y Interfaces de Programación

de Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2.1. Acerca de la elección de FreeOSEK . . . . . . . . . . . . . . . 21.2.2. Acerca de la elección de HIS . . . . . . . . . . . . . . . . . . . 3

1.3. Objetivos y Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Introducción Específica 52.1. OSEK y HIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1. Esquema de trabajo con OSEK y HIS . . . . . . . . . . . . . . 62.2. Microcontrolador MSP430 . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.1. CPU y CPUX . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.2. Interrupciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.3. Ultra Bajo Consumo . . . . . . . . . . . . . . . . . . . . . . . 92.2.4. Diferencias con Cortex-M4 . . . . . . . . . . . . . . . . . . . 11

2.3. Herramientas de desarrollo . . . . . . . . . . . . . . . . . . . . . . . 112.3.1. Herramienta de compilación: MSPGCC . . . . . . . . . . . . 122.3.2. Herramienta de proxy gdb: MSPDEBUG . . . . . . . . . . . 122.3.3. Kit de desarrollo: MSP-EXP430F5529 . . . . . . . . . . . . . . 122.3.4. Entorno de desarrollo intergrado . . . . . . . . . . . . . . . . 12

3. Diseño e Implementación 153.1. Implementación del CIAA-Firmware para MSP430 . . . . . . . . . . 15

3.1.1. MSP430WARE . . . . . . . . . . . . . . . . . . . . . . . . . . 153.1.1.1. DriverLib . . . . . . . . . . . . . . . . . . . . . . . . 163.1.1.2. LinkerScript . . . . . . . . . . . . . . . . . . . . . . 16

3.1.2. Makefiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.1.2.1. Configuraciones de Compilación y Linkeo . . . . . 16

3.1.3. Modificación en plantillas del generador de FreeOSEK . . . 173.1.3.1. Definición de vectores de interrupciones . . . . . . 173.1.3.2. Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.4. Implementación de FreeOSEK . . . . . . . . . . . . . . . . . 203.1.4.1. Acerca de la implementación de los handlers de

interrupción. . . . . . . . . . . . . . . . . . . . . . . 223.1.4.2. Rutina de Tick . . . . . . . . . . . . . . . . . . . . . 223.1.4.3. Rutina de cambio de contexto . . . . . . . . . . . . 233.1.4.4. Gestión de interrupciones . . . . . . . . . . . . . . 233.1.4.5. Bajo consumo . . . . . . . . . . . . . . . . . . . . . 24

3.1.5. Driver UART (Posix) . . . . . . . . . . . . . . . . . . . . . . . 243.2. Implementación de driver HIS Para GPIO . . . . . . . . . . . . . . . 24

VIII

3.2.1. Configuracion . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2.2. Archivos OIL, DIL y Generador . . . . . . . . . . . . . . . . 253.2.3. Plantillas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2.4. Notificaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.3. Mejoras en el generador de FreeOSEK . . . . . . . . . . . . . . . . . 273.4. Modificaciones para la realización de los tests cases . . . . . . . . . 293.5. Integración de las herramientas de desarrollo en CIAA-Firmware . 30

4. Ensayos y Resultados 334.1. Pruebas de desempeño de OSEK . . . . . . . . . . . . . . . . . . . . 334.2. Tests de conformidad de OSEK . . . . . . . . . . . . . . . . . . . . . 344.3. Pruebas de Driver HIS - GPIO . . . . . . . . . . . . . . . . . . . . . . 344.4. Pruebas de Driver POSIX - UART . . . . . . . . . . . . . . . . . . . . 34

5. Conclusiones 355.1. Conclusiones generales . . . . . . . . . . . . . . . . . . . . . . . . . 355.2. Próximos pasos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Bibliografía 37

IX

Índice de figuras

1.1. Estructura de capas general del firmware de la CIAA. . . . . . . . . 2

2.1. Esquema de generación y compilación del firmware usando OSEKy HIS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2. Diagrama en bloques del CPU MSP430X[6]. . . . . . . . . . . . . . . 82.3. Diagrama en bloques del controlador de interrupciones[6]. . . . . . 92.4. Movimiento del SP durante el ingreso y retorno de una interrup-

ción.[6]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.5. Diagrama reducido del Sistema de Reloj Universal (UCS). . . . . . 102.6. Kit de evaluación usado en el trabajo[8]. . . . . . . . . . . . . . . . . 13

3.1. Diagrama en bloques del timer utilizado como fuente de tick[6]. . . 213.2. Posible escenario de asignación de eventos. . . . . . . . . . . . . . . 28

4.1. Medición de tiempos en tick y SWI. . . . . . . . . . . . . . . . . . . . 334.2. Medición de tick. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

1

Capítulo 1

Introducción General

El desarrollo de la Computadora Industrial Argentina, desde un principio estuvoorientado a satisfacer una necesidad en el sector industrial, intentando introdu-cirse como reemplazo de cierto segmento de los equipos de control utilizados enesos entornos (PLCs).

Todas las versiones de CIAA, utilizan microcontroladores pertenecen al segmentode alta performance en donde, en algunos casos, se cuenta con más de un núcleo,y que en general no estan pensados para ser utilizados en productos en donde elconsumo sea un factor determinando.

1.1. Sistemas Operativos en Tiempo Real y Interfaces deProgramación de Aplicaciones

Un sistema operativo es un programa encargado de gestionar los recursos dehardware y software un sistema computacional [1]. Un Sistema operativo detiempo real se diferencia de uno de propósito general en cuanto puede asegu-rar tiempo de respuesta a eventos críticos (dentro de un margen de error). Esequivalente a decir que la variación del momento en que una tarea es aceptada yluego finalizada, está acotada.

La mayoría de los sistemas operativos en tiempo real poseen avanzados sistemasde planificación de tareas y son del tipo apropiativos (prehemptive). Los planifi-cadores priorizan la ejecución de una tarea u otra según el tipo de algoritmo queutilice. Existen diversos algoritmos de planificación, pero el más común utiliza-do en RTOS destinados a los sistemas embebidos están basados en priorizar lastareas según una prioridad estática que define el usuario al implementarla.

Por otro lado, un RTOS provee al implementador del sistema embebido herra-mientas que permiten interactuar con el sistema y con el hardware que hay pordebajo. Estas herramientas son interfaces de software denominadas API (Appli-cation Programming Interfece de sus siglas en ingles).

Para interactuar con el hardware, los sistemas operativos proveen drivers que, engeneral, están vinculados con las operaciones de éstos. Es decir, que los driverstambién utilizan recursos del sistema.

Esta arquitectura mencionada es la que se conoce como arquitectura de softwareen capas. Este tipo de arquitectuda es el utilizado en el firmware de la CIAA y sepuede observar en la Figura 1.1.

2 Capítulo 1. Introducción General

FIGURA 1.1: Estructura de capas general del firmware de la CIAA.

Interpretando esta estructura en capas, puede observarse que existen interfacesentre:

Programa de usuario - RTOS

Programa de usuario - DRIVERS

RTOS - Drivers Fabricante

DRIVERS - Drivers Fabricante

Drivers Fabricante - Hardware

1.2. Motivación

1.2.1. Acerca de la elección de FreeOSEK

Existen en el mercado varios sistemas operativos portados a la plataforma MSP430.Puntualmente, existen varios orientados a la implementación de redes de senso-res (que son los que se orientan a optimizar recursos y que están orientados asistemas alimentados con baterías), pero en menor o mayor parte todos poseenalguna característica no deseable:

FreeRTOS [2] Con respecto a las herramientas de desarrollo, la mayoría delos ports están basados en compiladores comerciales. Existe uno basado enGCC, pero implementado para un microcontrolador de una de las familiasmás viejas de esta arquitectura. Lo más importante, es un sistema operativodinámico.

TiniOS [3]: Se programa con un lenguaje que no es estándar (nesC).

Contiki [4]: Utiliza memoria dinámica.

A modo general todos los ports encontrados basados en GCC utilizan versionesviejas del mismo [5] y no han sido actualizadas a las nuevas versiones desde queTexas Instruments se hizo cargo de mantenerlo.

Las motivaciones principales para la utilización del FreeOSEK se fundaron prin-cipalmente en:

1.3. Objetivos y Alcance 3

En su naturaleza estática y determinística, en cuanto a la utilización de re-cursos del microcontrolador.

El aporte a la comunidad CIAA, no solo introduciendo un nuevo actor, sinotambién permitiendo nuevas posibilidades para la realización de proyectosen un segmento diferente al actual.

1.2.2. Acerca de la elección de HIS

El firmware de la CIAA, originalmente, se concibió que fuera tipo POSIX. POSIXes un estándar que define metodologías para implementar interfaces portablesentre plataformas. La gran portabilidad de este sistema, tiene una contraparteque es que, para la utilización de un objeto, se debe abrir el objeto, operar con elobjeto y luego cerrarlo.

Esto hace que, por ejemplo, para manejar un LED a través de los puestos deentrada-salida de propósito general haya que realizar dichas acciones, cuandoen realidad se podría reemplazar por una sentencia más simple (una posibilidades utilizar directamente las librerías del fabricante del microcontrolador, pero deesa manera no sería estándar entre plataformas).

HIS por otro lado, es un estándar que reduce la complejidad de la interfaz, y fueconcebido para ser integrado a OSEK. Similar a este, posee un archivo de configu-ración que permite la generación de objetos estáticos en tiempo de compilación.

1.3. Objetivos y Alcance

El objetivo del proyecto fue el de implementar la adaptación del RTOS FreeO-SEK, perteneciente al firmware de la CIAA, a un microcontrolador de la familiaMSP430 junto a la implementación de drivers para los periféricos GPIO y UART.

Estos objetivos permitieron definir el alcance del trabajo:

Obtener el conjunto de herramientas de desarrollo para MSP430, integrarloa la estructura del Firmware de la CIAA.

Generar el conjunto de makefiles para la nueva plataforma.

Redactar un documento didáctico que permita preparar el entorno de desa-rrollo en eclipse, y otras herramientas.

Implementar el porting del FreeOSEK a la plataforma MSP430, puntual-mente al uC MSP430F5529.

Implementar los manejadores de dispositivos (drivers) para que se permi-tan ejecutar los ejemplos más básicos (GPIO y UART).

A su vez se definieron las tareas que no estuvieron incluidas en el presente traba-jo:

Diseño de una versión de hardware de la CIAA para este microcontrolador.

Otros tipos de drivers.

5

Capítulo 2

Introducción Específica

En este capítulo se describirá lo relevante del sistema operativo OSEK y del es-tándar HIS al trabajo, explicando aspectos importantes sobre la arquitectura en lacual se trabajó, con el objeto de comprender las decisiones tomadas en la etapa dedesarrollo. Se presentarán también las herramientas de desarrollo que se eligie-ron para avanzar con el trabajo, y que quedarán integradas en el Firmware de laCIAA.

2.1. OSEK y HIS

De la necesidad de estandarizar los sistemas de software complejos utilizados enproductos automotrices (ECUS) altamente focalizados en las redes vehiculares,surgió en 1995 la propuesta del sistema operativo OSEK-VDX (Offene Systemeund deren Schnittstellen für die Elektronik in Kraftfahrzeugen - Vehicle Distribu-ted eXecutive o Sistemas Abiertos y sus interfaces para la Electrónica en Automó-viles - Ejecutivo Distribuido para Vehículos). Por otra parte, otro grupo denomi-nado HIS (Hersteller-Initiative Software o Iniciativa de los fabricantes de softwa-re) definió una arquitectura de acceso al hardware (definida en capas) utilizandouna interfaz genérica.

En definitiva, OSEK y HIS definen un conjunto de estándares.

El firmware de la CIAA está basado en los estándares OSEK OS y OSEK OIL, perono en estándar HIS IO.

OSEK OS especifica al sistema operativo basado en prioridades, y define sus fun-cionalidades y API.

OSEK OIL establece el lenguaje con el cual se deberá configurar al sistema (endonde OSEK OS es parte).

HIS IO Library especifica las interfaces para la implementación de los drivers, deforma general. Establece también el lenguaje con el cual el desarrollador deberáconfigurar a los drivers. Ese lenguaje se denomina DIL (Driver ImplementationLibrary).

HIS IO Driver establece las interfaces específicas para cada tipo de driver y lasfuncionalidades de cada una de ellas para implementar manejadores de disposi-tivos (drivers) para diversos tipos de hardware.

6 Capítulo 2. Introducción Específica

2.1.1. Esquema de trabajo con OSEK y HIS

Los archivos de configuración (OIL y DIL), utilizados para definir los recursosque utilizará el sistema, requieren de una operación previa a la compilación, de-nominada generación.

La generación, es el proceso por el cual un software analiza los archivos OIL yDIL y de ellos obtiene un conjunto de archivos de código fuente .h y .c. Para rea-lizar esta operación, el firmware de la CIAA emplea el lenguaje PHP para definirplantillas de estos archivos .h y .c que al procesarlos, van completándolos.

Luego de que el desarrollador finalice el código fuente de su aplicación, ya puedecompilar todo el conjunto que incluye:

Archivos generados

Programa de usuario

Código fuente del OSEK

Código fuente de los drivers HIS

Bibliotecas estáticas

De la compilación de obtiene una imagen binaria para descarar al microcontrola-dor.

Todo este proceso se esquematiza en siguiente figura:

FIGURA 2.1: Esquema de generación y compilación del firmwareusando OSEK y HIS.

2.2. Microcontrolador MSP430 7

Este esquema permite al desarrollador, escribir en un lenguaje claro, la configu-ración tanto de las tareas del OS que va a implementar, como también los driversadaptados a sus necesidades operativas con el hardware.

2.2. Microcontrolador MSP430

El MSP430 es una familia de microcontroladores de Texas Instruments diseñadoy optimizado para aplicaciones de ultra bajo consumo.

En esta sección se realizará una descripción de los aspectos más importantes dela arquitectura.

2.2.1. CPU y CPUX

El core MSP430 original es de 16 bits de direccionamiento y 16 bits de bus de datos(core MSP430), pero con el tiempo necesitaron extender el rango de memoria ymodificaron la arquitectura a 20 bits de direccionamiento y 16 bits de Bus dedatos (core MSP430X).

Esta arquitectura nueva, fue diseñada de forma tal que sea completamente com-patible con la versión original (dos sets de instrucciones separados)

El core de la MSP430X es un procesador cuya arquitectura posee las siguientescaracterísticas:

RISC

Arquitectura ortogonal

Von Neumann

Acceso directo a todos los registros

Transferencias de memoria a memoria directas.

Modos de direccionamiento de 8, 16 y 20 bits.

Instrucciones de 2, 4, 6 y 8 bytes.

Los registros del MSP430X son de 20bits. Como puede observase en la Figura 2.2doce registros de 20 bits son de propósito general, y otros tres están reservadospara:

Program Counter (R0): Almacena la dirección de memoria de la siguienteinstrucción. Su valor siempre es un numero par, debido a la alineacion conlas instrucciones que siempre comienzan en un address par (LSb = 0).

Stack Pointer (R1): Dirección de memoria del stack. Debe ser inicializadopor el usuario.

Status Register (R2): Registro de status donde se almacenan los bits de losresultados de las operaciones, los bits de configuración de los modos deoperación y la bandera de habilitación global de interrupciones (GIE). Esun registro de 16 bits, donde solo 11 bits son usables.

8 Capítulo 2. Introducción Específica

FIGURA 2.2: Diagrama en bloques del CPU MSP430X[6].

Generador de constantes (R3): Permite generar seis de las constantes másutilizadas para acelerar operaciones con ellas (0, +1, -1, +2, +4, +8).

2.2.2. Interrupciones

El vector de interrupciones contiene direcciones de 16 bits, por lo tanto, los hand-lers de interrupción deben estar en los primeros 64 kb del mapa de memoria.

Todos los vectores de interrupción poseen prioridad fija. El orden depende delmodelo de microcontrolador.

Existen 3 tipos de interrupción:

Reset: Vector de interrupción de inicio de sistema.

No Enmascarables (NMI): Interrupciones que no son enmascarables por elGIE1. A su vez se dividen en NMI de sistema y NMI de usuario.

1Global Interrupt Enable

2.2. Microcontrolador MSP430 9

Enmascarables: Proveniente de periféricos con capacidad de interrupción.Cada fuente de interrupción de este tipo, puede ser deshabilitada indivi-dualmente o de forma global mediante el GIE.

FIGURA 2.3: Diagrama en bloques del controlador de interrupcio-nes[6].

Durante una interrupción, el CPU guarda automáticamente el Program Countery el Status Register en el stack. Esta operación reduce al SP en 2 WORDS. Como laarquitectura MSP430x y la MSP430 se diseñaron para ser compatibles, y el StatusRegister se mantuvo de 11 bits, entonces el PC (de 20 bits) se apila en el stackde forma partida. Los 4 bits más significativos junto al SR y los 16 bits menossignificativos en word adyacente.

La siguiente figura muestra el proceso:

FIGURA 2.4: Movimiento del SP durante el ingreso y retorno deuna interrupción.[6].

Al cargarse el SR al stack, se inicializa con todos sus bits a cero automáticamente,menos el que define el modo de mayor consumo. Esto produce dos situaciones:

Se borra la bandera GIE deshabilitando interrupciones de forma global paraque no se puedan anidar otras interrupciones pendientes (el usuario puedeoptar por habilitarlas)

Se sale del modo de bajo consumo del cual estuviera el procesador antes dela interrupción.

2.2.3. Ultra Bajo Consumo

El MSP430 está fuertemente orientado a productos de ultra bajo consumo. Parallevar a cabo esta característica, implementa una cierta cantidad de modos de bajo

10 Capítulo 2. Introducción Específica

consumo que están apoyados en la arquitectura de señales de reloj que posee2.

Para entrar en algún modo, puntualmente para el MSP430F5529, se proveen ban-deras dentro del Status Register.

La Figura 2.5 muestra un esquema muy reducido3 del módulo UCS (UniversalClock System) con el objeto de explicar cuales señales se controlan para establecerlos modos de bajo consumo.

CPUOFF: Abre la línea de la señal de reloj principal (MLCK) apagando elCPU.

SCG1 (System clock generator 1): Enciende o Apaga el Oscilador contro-lado por tension (DCO), interno, que se usa cuando el CPU está en modoActivo4.

SCG0 (System clock generator 0): Enciende o Apaga el módulo encargadode comparar las frecuencias de la referencia con la de la salida del DCO. Encaso de no encenderlo, el DCO oscilará a una frecuencia (configurada) sinajustes.

OSCOFF: Abre o cierra la línea del reloj auxiliar. Este reloj es MUY impor-tante debido a que se utiliza para alimentar a los periféricos cuando el relojprincipal se apaga.

FIGURA 2.5: Diagrama reducido del Sistema de Reloj Universal(UCS).

Cuando el hilo principal de ejecución, entra en un modo de bajo consumo posi-blemente apague uno o todos los relojes. Esto hará que el CPU quede apagado, yque los periféricos queden o no encendidos. El caso más extremo es que todas lasfuentes de reloj se apaguen. En ese caso, la única manera de que el CPU retomela ejecución, será a través de una interrupción de GPIO (u otro periférico que nonecesite de reloj para funcionar).

2La cantidad de modos de bajo consumo y la arquitectura de las señales de reloj dependen de lafamilia de MSP430 con la que se esté trabajando.

3Las líneas punteadas muestran que esa conexión es condicional de la configuración del perifé-rico.

4Dependiendo de la configuración de usuario, el modo activo podría definirse utilizando otrafuente de reloj

2.3. Herramientas de desarrollo 11

Recordando lo explicado en 2.2.2, cuando el CPU salta a ejecutar un handler deinterrupción, resguarda el PC y el SR en el stack, pero también enciende solo elDCO (dejando al SR en 0 en el resto de las banderas). Si dentro del handler no sehace nada, más que realizar alguna acción operativa, cuando el CPU retorne delhandler, el SR que se había resguardado, va a reestablecerse, y con el modo de bajoconsumo que tenía antes (posiblemente con el CPU apagado). Si quisiera hacersealgún procesamiento, fuera del handler y posterior a este, habrá que modificar elmodo de bajo consumo guardado en el SR almacenado en el stack.

2.2.4. Diferencias con Cortex-M4

En esta sección se presentarán algunas diferencias entre la arquitectura MSP430Xcon Cortex-M4, que tuvieron que ser sorteadas o consideradas en la adaptacióndel sistema operativo.

En NVIC de CortexM permite deshabilitar la interrupción de un handler.En MSP430 cada periférico está conectado a un handler, y tiene capacidadde enmascarar individualmente interrupciones del periférico, pero no deforma global. Para realizar esto, hay que deshabilitar todas las fuentes deinterrupción del periférico.

Las velocidades de procesamiento del MSP430 no son tan altas como las delCortex. El MSP430F5529 puede correr como máximo a 25 Mhz.

El MSP430 posee un pipeline5 pero las instrucciones son de tamaño varia-ble y los tiempos de ejecución de las mismas son de tiempo variable. EnCortexM, todas las instrucciones se ejecutan en 1 ciclo de máquina.

En el MSP430 no existe modos de usuario y privilegiados.

El MSP430 no posee capacidad de tail chaining, por lo tanto si durante laejecucion de un handler de IRQ, ocurre otra, la ejecucion del handler si-guiente se realizará solo cuando el CPU haya salido del handler original yentrado en el nuevo.

2.3. Herramientas de desarrollo

El microcontrolador MSP430 posee tanto herramientas comerciales como libres.

El presente trabajo se logró realizar utilizando herramientas libres, bajo Linux.No obstante, las mismas herramientas podría utilizarse en Windows sin muchoscambios sustanciales.

Existen varias herramientas de uso libre para trabajar con esta plataforma (con-sultar [7]) pero se eligió un conjunto de ellas, para poder trabajar con el kit dedesarrollo disponible para realizar este trabajo.

5Esta información no está en los manuales del microcontrolador de forma directa. Se mencionaen una nota del manual, en donde reconoce una errata y lo justifica a partir de la existencia de unpipeline. Esta información también se puede encontrar leyendo en el foro técnico de TI, en dondeempleados de la compañía lo mencionan.

12 Capítulo 2. Introducción Específica

El conjunto de herramientas, se denomina toolchain (cadena de herramientas,traducción del inglés) porque conceptualmente se pueden diagramar en cadena,comprendiendo que la vinculación de la misma es una vinculación en serie.

2.3.1. Herramienta de compilación: MSPGCC

Es el conjunto de herramientas libres de GNU para poder compilar programas enC/C++ que incluye también binutils y herramientas para bajar la imagen al chipy depurar.

Esta herramienta era, hasta el 2012, mantenida por la comunidad de desarrollado-res libres, pero desde entonces Texas Instruments se hizo cargo del mantenimien-to de las herramientas (y en las dos últimas versiones delegó el mantenimiento aSomnium Technologies).

Este conjunto de herramientas posee un proxy gdb, que permite subir la imagenal chip una vez compilado, pero lamentablemente no es compatible con el kit dedesarrollo usado para realizar el trabajo (ver 2.3.3 ), por lo que se optó por otrasolución.

2.3.2. Herramienta de proxy gdb: MSPDEBUG

Es un depurador libre que reemplaza al gdb proxy, pero que es compatible conun mayor número de Programadores (FET: Flash Emulation Tool en inglés).

Permite también ser utilizado como depurador independiente del gdb.

2.3.3. Kit de desarrollo: MSP-EXP430F5529

Para la realización de este trabajo se utilizó el kit de desarrollo MSP-EXP430F5529(Figura 2.6). Utiliza un microcontrolador MSP430F5529 (core X). Es un kit muycompleto que permite evaluar muchísimas características del microcontrolador ytrabajar con periféricos como microSD, pantalla de cristal líquido, potenciómetro,acelerómetro, teclas táctiles capacitivas, dispositivo USB, pulsadores, leds, puer-tos de expansión y conectores dedicados para placas auxiliares de RF.

Además, posee integrada en la placa el Programador (FET) para no depender deuno externo.

El puerto de depuración también es USB, y brinda además un puerto serie paraque el usuario utilice durante la depuración.

2.3.4. Entorno de desarrollo intergrado

Este trabajo utilizó como IDE el entorno eclipse. Se le sumaron unos plugins des-cargados del Marketplace que mejoraron la experiencia.

2.3. Herramientas de desarrollo 13

FIGURA 2.6: Kit de evaluación usado en el trabajo[8].

15

Capítulo 3

Diseño e Implementación

Es este capítulo se repasarán los puntos clave del desarrollo del trabajo haciendohincapié en los cambios importantes que tuvieron que hacerse para integrar unaplataforma totalmente diferente al firmware de la CIAA.

El código fuente asociado puede consultarse en la siguiente URL:https://github.com/fbucafusco/fw_on_msp430

3.1. Implementación del CIAA-Firmware para MSP430

Para el desarrollo del port de FreeOSEK para MSP430 se tomó referencia en el deCortex M4.

La línea de trabajo fue la siguiente:

Integrar librerías provistas por el fabricante (3.1.1).

Entender el port a Cortex M4/M0, y reproducir la estructura de carpetas ymakefiles (3.1.2).

Analizar y evaluar las modificaciones referidas al compilador y debugger.

Implementar el Port (3.1.4).

Crear nuevas funciones para dar soporte a diferencias de arquitectura (3.1.4.4).

Adaptar los test de conformidad (3.4).

Además de las problemáticas fundadas en las diferencias entre arquitecturas, seencontraron otras problemáticas relacionadas con:

Estructura del linker script provisto por TI.

EABI del MSP430

Estas problemáticas irán siendo descritas en las siguientes subsecciones.

3.1.1. MSP430WARE

Texas Instruments provee una colección de documentación, ejemplos de código,entrenamiento, drivers y otros recursos de diseño bajo licencia BSD para toda lagama de microcontroladores MSP430 llamada MSP430WARE. Se ofrece para des-cargar como software adicional para el Code Composer Studio (IDE, compilador,depurador, comercial de TI) o como paquete separado para integrar en otro IDE.

16 Capítulo 3. Diseño e Implementación

Esta librería es muy voluminosa, por lo cual se extrajo lo necesario para integrarlodentro del Firmware de la CIAA.

3.1.1.1. DriverLib

Un submódulo del MSP430WARE es la librería de drivers llamada DriverLib. Esuna librería que provee una API para manejar los dispositivos fácilmente. Esta li-brería se incluyó en el Firmware de la CIAA bajo la ruta: externals\drivers\msp430.Cabe aclarar que sólo se agregaron las librerías asociadas a la familia MSP430x5xxque es la correspondiente al microcontrolador empleado.

3.1.1.2. LinkerScript

Asimismo, MSP40WARE provee de linker scripts para cada microcontrolador.Los linker scripts son archivos que se utilizan durante el proceso de enlace, quecontienen información sobre la estructura de memoria del microcontrolador quese va a utilizar (de RAM, ROM, donde se ubican los vectores de interrupción)[9].En este trabajo se adoptó el uso del mismo sin modificaciones y se ubicó en elárbol del Firmware de la CIAA en: externals\base\msp430\linker Una particu-laridad del linker script provisto por TI, es que no permite la definición del vectorde interrupción en un archivo de código fuente en C. Esto trajo un retrabajo en lametodología de generación a partir de los OIL (ver 3.1.3.1)

3.1.2. Makefiles

La estructura de makefiles del Firmware de la CIAA permite flexibilizar paracada plataforma:

El juego de herramientas de desarrollo (compilador, linker y el resto).

El Linker Script a utilizar.

Las configuraciones de compilación y linkeo

La extensión del archivo objeto

La ubicación en el árbol de las distintas dependencias de compilación.

Otros

Con el objetivo del presente trabajo, se tuvo que agregar cada makefile en su res-pectiva ubicación dentro del firmware. Son muchos los archivos makefile que seagregaron, por lo cual no se listarán en esta sección. Se explicarán las modifica-ciones clave para compilar el firmware en la nueva plataforma.

3.1.2.1. Configuraciones de Compilación y Linkeo

Para cambiar estas configuraciones se debieron modificar los macros LFLAGS yCFLAGS. No se incluyó la macro AFLAGS (tal como se encuentra definida paraCortexM) debido a que todo el trabajo de adaptación a MSP430 fue realizado enlenguaje C. CFLAGS son macros que definen los modificadores para la compila-ción. Tiene relevancia comentar los siguientes:

3.1. Implementación del CIAA-Firmware para MSP430 17

-O0: Modificador que establece el nivel de optimización de la compilación.Se dejó este nivel, para permitir tanto la depuración durante este trabajocomo para la depuración de los programas de los desarrolladores. No obs-tante, para versiones release del firmware desarrollado, se recomienda alta-mente incrementar el nivel de optimización (como mínimo O1, que reduceconsiderablemente la generación de código).

-mmcu: Determina el CPU a utilizar.

-ggdb: Genera información de debug para usar la herramienta GDB.

-msmall: Indica al compilador que utilice solamente los primeros 64kb dememoria del microcontrolador, como si fuera de core MSP430 (aun cuandoel core es MSP430x). Esto indica al compilador que utilice punteros de 16bits y el tipo de dato size_t también sea de 16 bits. Esto no significa que elcompilador no utilice ambos sets de instrucciones. 1

También se definieron otros CFLAGS, propios de cada proyecto (esto se refleja enlos ejemplos), para permitir indicar a la compilación características distintas, se-gún preferencia del usuario. Todas estas nuevas definiciones fueron simplementeindicaciones de preprocesador:

-DDCIAA_HEAP_MEM_SIZE = xxx: Se introdujo esta definición para elpreprocesador de C, para permitir indicar un espacio diferente de memo-ria de HEAP (xxx en bytes). Originalmente este valor era de 10000, siendoimposible compilar el firmware para el microcontrolador utilizado2.

-DCIAA_CFG_HISIO: Permite indicar que se utilizarán drivers HIS en vezde drivers POSIX.

LFLAGS son los macros que definen los modificadores para el linkeo. En este casono tiene relevancia mencionar los modificadores.

3.1.3. Modificación en plantillas del generador de FreeOSEK

Las plantillas del generador son los archivos necesarios para que el Software ge-nerador tome los OIL y DIL y genere los .c y .h, por lo tanto las platillas tienen unaextensión del tipo .h.php y .c.php. Todas las plantillas asociadas a la generaciónse encuentran en la ruta del firmware: modules\rtos\gen Esta fue una de las másgrandes modificaciones aportadas en el trabajo y se subdivide en dos grandesgrupos: modificaciones propiamente dichas a adaptar el firmware a la platafor-ma y otras modificaciones de mejoras al proceso, comunes a cualquier plataforma(ver 3.3) Aquí se presentarán las modificaciones del primer grupo.

3.1.3.1. Definición de vectores de interrupciones

Como se mencionó anteriormente (3.1.1.2) el linker script no está preparado paradefinir un vector de interrupciones en un archivo .c como si fuera una función

1Esto se hizo así por dos razones. El core MSP430X posee ciertas ineficiencias al utilizar todo elmapa de memoria y la cantidad de bugs de hardware que se pueden observar en la hoja de datosde Errata es considerable [10]. En el futuro, podría cambiarse por -mlarge que utilizará direccionesde 20 bits y size_t de 32 bit, con las modificaciones pertinentes al tipo de dato

2De no incluir esta definición, el preprocesador opta por dejar el valor por omisión.

18 Capítulo 3. Diseño e Implementación

común. Éste agrega entradas en el vector solamente para los handlers definidosdentro del código fuente con el atributo: interrupt_vec(UNMI_VECTOR)

A los handlers no definidos, gcc le asigna un handler "tonto"que lo único quehace es retornar.

Es por eso que la plantilla Os_internal_Arch_Cfg.c.php fue modificada siguiendolas siguientes pautas:

Array $intList: Originalmente la definición del mismo estaba en esta plan-tilla. Este array se separó de la misma para poder ser reutilizado en otrasplantillas (puntualmente con los drivers HIS).El array se ubicó en Os_Internal_Defs.php y se puede acceder a través dePlatform.php.

Array de handlers de interrupciones: Debido a lo comentado anteriormen-te, la plantilla no genera un array de handlers, sino que define, para cadaelemento de $intList, al handler en c usando el atributo correspondiente.Este proceso separa:

• Interrupciones definidas por el usuario en el OIL de categoría 1.

• Interrupciones que no definió el usuario.

• Interrupciones reservadas por el sistema operativo (ver 3.1.4 )

Para el caso de las interrupciones de categoría 1 se tuvo que definir un handlerwrapper al handler definido por el usuario a través de la macro ISR(). El listado3.1 muestra un ejemplo generado de un handler de este tipo.

LISTADO 3.1: Resultado de una posible generación de una ISRCAT 1 para la interrupción de GPIO en el puerto 1

1 interrupt_vec(PORT1_VECTOR)2 void OSEK_ISR_PORT1_VECTOR_WRAPPER(void)3 {4 PreIsr1_Arch(6);5 OSEK_ISR_PORT1_VECTOR();6 PostIsr1_Arch(6);7 }

En esta plantilla no se definen los handlers de interrupción de categoría 2. Estoshandlers se definen en la plantilla Os_internal_Cfg.c.php.

Como esta plantilla es general para todas las arquitecturas, su modificación tu-vo que trasladar elementos a otros sectores del firmware asociados a las mismas,para brindar compatibilidad. Cada handler de interrupciones de categoría 2 que-dó implementado por el código presentado en el listado 3.2. En este listado seplasma el resultado de la implementación.

Si se quiere consultar el código de las plantillas referirse al código fuente ubicadoen Os_internal_Cfg.c.php.

3.1. Implementación del CIAA-Firmware para MSP430 19

LISTADO 3.2: Resultado de una posible generación de una ISRCAT 2 para la interrupción de GPIO en el puerto 2

1 interrupt_vec(PORT2_VECTOR)2 void OSEK_ISR2_PORT2(void)3 {4 PreIsr2_Arch( 1 );5 /* store the calling context in a variable */6 ContextType actualContext = GetCallingContext();7 /* set isr 2 context */8 SetActualContext(CONTEXT_ISR2);9 /* trigger isr 2 */

10 OSEK_ISR_PORT2();11 /* reset context */12 SetActualContext(actualContext);13

14 PostIsr2_Arch( 1 );15 AfterIsr2_Schedule() ;16 }

Este handler (generado) sufrió modificaciones respecto de la implementación ori-ginal. Los cambios se resumen en la siguiente lista:

PreIsr2_Arch: A esta función originalmente no se le pasaba ningún argu-mento. La modificación de la plantilla hace que ahora se calcule el índice dehandler dentro del vector de interrupciones, y se le pase a esa función. Parael port a MSP430 esta función se implementa con una macro vacía.

PostIsr2_Arch: A esta función también se le agregó el índice del handler,tal cual la anterior. En el port a MSP430 esta funcionalidad es necesaria,dado que borra la bandera de interrupción pendiente. Si no se hiciera eso,ocurrirían infinitos llamados al handler de forma serializada 3.

AfterIsr2_Schedule: Esta función no estaba en la implementación originaldel firmware. En su lugar, había un llamado condicional a la función Sche-dule() (a través de PostIsr2_Arch). La macro agregada, ya incluye el llamadocondicional, haciendo más legible el código (ver Os_Internal.h).

3.1.3.2. Stack

Para la implementación de la definición del stack para cada tarea, se cambió eltipo de datos del mismo a uint16, pero se le asignó la mitad del tamaño definidapor el usuario en el OIL. Como resultado de esto, es un array en RAM del mismotamaño definido por el usuario, pero alineado al bus de datos de 16 bit. Esto es unrequerimiento porque el CPU requiere de accesos alineados a memoria al accedercon instrucciones de assembler .W o para operaciones internas del mismo. Estecambio puede consultarse en Os_internal_Cfg.c.php.

3La acción de borrar el flag de interrupción pendiente es responsabilidad del desarrollador,dentro del handler que éste define. No obstante, hacerlo de forma forzada asegura que ocurra.Además de esa justificación, se realizó para permitir que se superen los tests de conformidad.

20 Capítulo 3. Diseño e Implementación

3.1.4. Implementación de FreeOSEK

En esta sección se explicarán los agregados y los cambios referidos a la imple-mentación del Sistema Operativo. Debido a las grandes diferencias entre las ar-quitecturas que ya estaban portadas, hubo que resolver las siguientes grandesdiferencias:

Inicialización del Stack: Dado que la operatoria del CPU al entrar en unhandler de interrupción cambia con respecto a Cortex-M, se tuvo que mo-dificar InitStack_Arch() para que inicialice correctamente al stack. Esto per-mite que, en el 1er cambio de contexto de FreeOSEK permita entrar sinproblemas a la primera tarea en estado Ready. Este cambio se puede verreflejado en Os_Internal_Arch.c dentro de modules\rtos\inc\msp430. Enesta rutina, se establece el punto de entrada de la tarea y el StatusRegisterCorrespondiente de la tarea, al arrancar. Como el SR determina el modo debajo consumo, se definió un valor por defecto que configura al microcon-trolador en modo activo y con las interrupciones habilitadas.

Tick del sistema: Para implementar el tick del sistema se utilizó el pe-riférico TimerA3.1 (canal 0), que es el que posee menor prioridad en elMSP430F5529. Para mayores detalles ver 3.1.4.2. Cabe aclarar que existendos periféricos cuyas fuentes de interrupción poseen menor prioridad queTimerA. Lamentablemente, en esta plataforma no se puede cambiar la prio-ridad de hardware4.

Interrupción por software: El MSP430 no posee un vector de interrupciónque permita dispararse por software5. Con el objetivo de no modificar signi-ficantemente la estructura del firmware, se intentó encontrar un mecanismosimilar con los recursos disponibles. Como resultado se llegó a la idea de si-mular el comportamiento de SWI utilizando el mismo periférico "Timer",pero un canal diferente. El periférico Timer, posee (en este microcontrola-dor) 3 canales. El canal 0 se usó para el tick. El canal 1 se eligió para laSWI. Para utilizar la interrupción del timer como SWI, simplemente se im-plementó habilitando la interrupción del canal, y luego escribiendo el bit depending (acciones utilizadas en las macros JmpTask y CallTask). Eso hace queel CPU directamente ejecute el handler. El timer, posee otro canal extra, quequedó en desuso. Para mayores detalles ver 3.1.

Prioridades de las ISR: El MSP430 posee un vector de interrupciones conprioridades fijas. No se pueden cambiar por software.

Arranque del sistema: Se dejó a GCC que definiera el handler de reset. Estotrajo aparejados algunos problemas relacionados con el watchdog (que estáhabilitado por hardware al resetearse). Hubo que indicarle al compiladorque adjuntara una porción de código al inicio del sistema (Listado 3.3), antesde inicializar variables globales a cero u otros valores.

Por otro lado, la inicialización del hardware se incluyó en la función Star-tOs_Arch_Cpu. Allí se configuran:

4El handler de menor prioridad es el del periférico RTC. Originalmente se pensó en sacrificarese periférico, para implementar el tick. Como es un periférico que está preparado para seguir lalógica de un reloj, la cantidad de configuraciones que permite está muy limitada.

5Especialmente dedicado para este tipo de aplicación

3.1. Implementación del CIAA-Firmware para MSP430 21

FIGURA 3.1: Diagrama en bloques del timer utilizado como fuentede tick[6].

• Inicializar los relojes del sistema

• Configurar el módulo de Gestión de energía.

LISTADO 3.3: Implementación de la deshabilitación delwatchdog apenas se resetea el microcontrolador

1 static void __attribute__((naked, section(".crt_0042"), used))2 disable_watchdog (void)3 {4 //https://sourceware.org/ml/newlib/2015/msg00627.html5 WDTCTL = WDTPW | WDTHOLD; // Stop watchdog timer6 }

Uso de modos de bajo consumo: La macro osekpause() es la encargada deesperar que el sistema se interrumpa por un tick o por otra fuente de inte-rrupción. Tuvo que ser modificada, junto a otros elementos para permitirque el microcontrolador entrara en modo de bajo consumo, cuando no ten-ga tareas que ejecutar. Para mayores detalles, referirse a 3.1.4.5

22 Capítulo 3. Diseño e Implementación

En los siguientes sub secciones se describirán en mayor detalle algunos elementosdesarrollados.

3.1.4.1. Acerca de la implementación de los handlers de interrupción.

En este apartado se mencionarán algunas justificaciones respecto de cómo se im-plementaron todas las interrupciones del sistema (las explicadas en 3.1.3.1, 3.1.4.2y 3.1.4.3).

El EABI de MSP430 (Embedded Aplication Binary Interface [11] ) impone al com-pilador que, cuando entre en un handler de interrupción, salve todos los registrosde uso general en el stack (no solo los que utiliza el handler). Esto trae aparejadouna latencia extra a algunos handlers que no necesitan guardar la totalidad de losregistros. Esta acción equivale a salvar y restaurar el contexto en cada llamado aun handler (sin que realmente se necesite). Aun así, si a las definiciones de loshandlers se le agrega el atributo naked[12] (cuyo comportamiento es remover elprólogo y el epílogo agregado por el compilador, o sea las acciones de guardadoy restaurado de registros) la documentación de gcc recomienda hacerlo sólo parafunciones que se van a escribir puramente en assembler y en las cuales se conocede antemano los recursos del CPU que va a utilizar. En handlers como el tick ocualquier handler de usuario, se llaman a funciones de C, por lo tanto, no pudoevitarse el proceso de guardado y restaurado. Para el handler de cambio de con-texto, si bien se pudo implementar en assembler, conceptualmente es un requisitoguardar y restaurar el contexto.

3.1.4.2. Rutina de Tick

Para la utilización del módulo TimerA como tick de sistema, se lo alimentó conla señal de reloj interna auxiliar (ACLK). Como fuente de reloj de esta señal, seconfiguró al multiplexor interno del periférico UCS para que utilice al osciladora cristal de 32768 Hz.

El canal 0 del timer A se configuró para que interrumpiera cada 1 ms (en realidadun valor cercano, debido al valor del cristal). El canal 0 del periférico posee unhandler de interrupción por separado del resto de los canales del mismo perifé-ricos. La rutina de tick, implementada en C, es muy similar a la implementadapara Cortex-M, salvando los siguientes detalles:

Sección Crítica: Para MSP430 no se deshabilita/habilita la bandera de in-terrupción global debido a que al entrar en el handler el CPU automática-mente la deshabilita y la restablece al salir.

Llamado al Scheduler: Se utilizó la misma macro empleada para las ISRde categoría 2 (ver 3.1.3.1) para implementar el llamado (condicional) alScheduler al final del Tick 6.

6La lógica respecto de la implementación para Cortex-M no cambia, pero se formaliza de esamanera, dado que es la misma que se utiliza en ISR Cat2

3.1. Implementación del CIAA-Firmware para MSP430 23

La implementación de esta rutina se hizo en c y con algunas líneas inline as-sembly, declarando al handler (en c) con el atributo naked para que el compiladorno agregara overhead la función 7.

La rutina de tick se puede consultar en el archivo Os_Internal_Arch.c.

3.1.4.3. Rutina de cambio de contexto

La rutina de cambio de contexto se implementó en C utilizando inline assembly yestuvo basada en la rutina PendSV (pending service), implementada para Cortex-M.

Como el handler es compartido por dos canales (1 y 2) del módulo TimerA, larutina verifica que el origen del llamado haya sido por el canal 1. Si no lo es,directamente retorna 8.

La implementación de esta rutina se hizo puramente con inline assembly, decla-rando al handler (en c) con el atributo naked para que el compilador no agregaraoverhead a la función.

3.1.4.4. Gestión de interrupciones

Existen funciones de la API de OSEK encargadas de gestionar las interrupciones.Estas son EnableAllInterrupts, DisableAllInterrupts, ResumeAllInterrupts, SuspendA-llInterrupts,ResumeOSInterrupts y SuspendOSInterrupts.

Las primeras 4 se implementaron, sacando las diferencias de lado, utilizando ladesabilitación global que provee el CPU (GIE).

Las otras dos son selectivas y aplican sólo a las interrupciones de categoría 2.Como el MSP430 NO posee capacidad de deshabilitar un handler entero, huboque implementar dos funciones que, para cada handler, deshabilite y habilite lasinterrupciones que necesite el periférico en cuestión.

Esas dos funciones son MSP430_EnableIRQ y MSP430_DisableIRQ, implementa-das en Os_Internal_Arch.c e invocadas en el archivo que surge de la generacióndel sistema: Os_Internal_Arch.c.

Las nuevas funciones implementadas son muy grandes y poseen para cada peri-férico compilación condicional.

Un último comentario respecto de la utilización de estas funciones: Existe otrafunción llamada Enable_User_ISRs que habilita todas las interrupciones defini-das en el OIL al invocarse el llamado a StartOS. Para MSP430 esa función no tienesentido debido, justamente, a que no se pueden conocer en esa instancia que in-terrupciones individuales de cada periférico van a ser usadas por el usuario. Porlo tanto, no fue implementada para MSP430. Esta habilitación la deberá hacer elpropio usuario (o un driver del periférico en cuestión)9.

7De esta forma fué como programar la rutina en assembler puro8Notar que ese canal no podrá ser utilizado por el desarrollador, debido a que necesitaría invo-

lucrarse con el código fuente del Kernel9Esto luego trajo aparejados algunos agregados a las rutinas de pruebas de conformidad. Ver

3.4

24 Capítulo 3. Diseño e Implementación

3.1.4.5. Bajo consumo

La macro osekpause() es la encargada de esperar que el sistema se interrumpa porun tick o por otra fuente de interrupción. Es el estado en el que el sistema opera-tivo no se encuentra haciendo nada. Por lo tanto, se implementó que, al llamarse,el microcontrolador entre en modo de bajo consumo 3, que es el que permite aloscilador de baja frecuencia seguir activo para alimentar el timer del tick. En estemodo, el oscilador principal y el auxiliar están apagados, junto al CPU.

Esta funcionalidad no se limita solo a poner al microcontrolador en bajo consumoen esa instancia, sino que también hay que modificar el comportamiento de losvectores de interrupción.

De 2.2.3 se sabe que el CPU guarda en stack el status register durante el serviciode la interrupción y cuando retorna de la misma, lo restablece. Como la confi-guración del modo se encuentra en este registro, al entrar y salir del handler deinterrupción, la ejecución del CPU quedaría siempre frenada en osekpause().

La única manera de hacer que al retornar el CPU no este frenado es modificandoel valor del SR almacenado en stack.

Para realizar esto, se usa __bic_SR_register_on_exit(), función intrínseca del gcc,al final de la ejecución del handler del tick, del SWI, y de cada interrupción decategoría 2.

3.1.5. Driver UART (Posix)

La implementación del driver UART con interfaz posix, se basó en la actual im-plementación para cortex. Se implementaron todas las funciones de bajo nivel, lasinterrupciones sin mayores problemáticas. La implementación se puede consultaren la ruta: modules\drivers\msp430

3.2. Implementación de driver HIS Para GPIO

La implementación del driver HIS para MSP430 se basó en el trabajo realizado enel branch feature/hisio[13] del repositorio del firmware de la CIAA. Estaimplementación no está completa, pero definió en gran parte el marco de trabajo.Una observación respecto la implementación de referencia es que en este trabajoalgunos puntos del estándar se interpretaron de otra forma.

Por otro lado, el driver para GPIO se basó en la sección 5.2 del estándar [14],implementándose todas sus funcionalidades.

Además, se vio la necesidad de extender definiciones del este estándar, para abar-car algunas configuraciones de GPIOs que no estaban contempladas.

3.2.1. Configuracion

Aquí se mencionarán los aportes de este trabajo respecto de la configuración deldriver.

3.2. Implementación de driver HIS Para GPIO 25

La configuración de los drivers, definida en los archivos escritos en lenguaje DIL,permite establecer canales.

Cada canal, está identificado como un PIN o un PORT.

PIN: Un canal de tipo pin identifica, valga la redundancia, a un PIN físicodel microcontrolador. Se lo puede configurar como:

• IO_UNUSED: Es la condición por defecto. Esta configuración podríaser interesante si se desea tener un canal asignado, pero sin utilidad.

• IO_INPUT: PIN como entrada.

• IO_OUTPUT_INIT_LOW: PIN como salida, inicializado en un valorbajo.

• IO_OUTPUT_INIT_HIGH: PIN como salida, inicializado en un valoralto.

Se notó que esa cantidad de configuraciones era escasa, con respecto a losperiféricos que se pueden encontrar actualmente en muchos microcontro-ladores. Puntualmente para el MSP430 fue necesario agregar las configura-ciones 10 11.

• IO_INPUT_PULLEDUP: PIN como entrada, con pull up.

• IO_INPUT_PULLEDDOWN: PIN como entrada, con pull down.

PORT: Es un canal que corresponde a todo un puerto, agrupando los pinesdeclarados en todos los canales de tipo PIN. Permite operaciones generali-zadas a todo el grupo. Ejemplo: Si tengo configurados como PIN a P1.0 yP1.2 como salida, y definido un PORT como P1, entonces una operación deSet del canal PORT va a hacer que todo el grupo de pines se pongan en unnivel alto.

3.2.2. Archivos OIL, DIL y Generador

En esta subsección se explicará cómo se resolvió el vínculo entre los archivos OIL,DIL y el generador. Una parte, ya resuelta en el módulo hisio de [13], es la decómo se definió al lenguaje DIL.

En el estándar, el lenguaje DIL es un lenguaje de texto, similar al OIL pero noigual. Por lo tanto, la implementación de dicho lenguaje se realizó siguiendo loslineamientos de un OIL, para aprovechar el generador que ya estaba disponible.Otro aporte del módulo hisio original fue incluir una extensión nueva: POIL.

En la implementación de este trabajo, se separó aún más la definición del pro-yecto, y junto a los archivos mencionados, el esquema de archivos quedó de lasiguiente forma:

10Para otros microcontroladores, posiblemente haya que extender aún más las posibilidades deconfiguración. Por ejemplo, configurar una salida como Open Drain o PushPull. En estos casosdonde se necesitan otras opciones, habrá que implementarlas.

11Esta funcionalidad agregada podría haberse implementado mediante la funciónDio_IoctlSynch() que permite al driver agregar funcionalidades no contempladas en el estándar

26 Capítulo 3. Diseño e Implementación

Archivo poil: Archivo que, según la plataforma utilizada, define que otrosarchivos incluir en la generación. Al ser POIL, se corre el preprocesador deC antes de la generación, por lo tanto, se pueden seleccionar en ese archivoque otros archivos incluir. Esto es útil para separar las definiciones según laplataforma.

Archivo osconfig.oil: Archivo que define la configuración del Sistema ope-rativo (este archivo sería como cualquier OIL de un proyecto sin HIS). Estearchivo no debería modificarse para las diferentes plataformas.

Archivo NombreDeDriver.oil: Archivo con la configuración del driver encuestión, implementado en lenguaje DIL. Debe estar adecuado al tipo deconexionado que posee la placa que se va a utilizar en el proyecto.

Todo el conjunto formado por los archivos mencionados, durante la generaciónde agrupan y se genera todo el grupo de archivos fuente que se utilizará para lacompilación.

3.2.3. Plantillas

Se modificaron algunas plantillas genéricas del ejemplo y se crearon las corres-pondientes al MSP430 y puntualmente para la placa de desarrollo elegida (ver2.3.3).

El MSP430, al poseer periféricos más sencillos, no requiso de helpers12 de gene-ración, como en el caso de Cortex-M.

Dio_Cfg_Arch.h.php y Dio_Cfg_Arch.c.php son las plantillas desarrolladas paraMSP430

En estas plantillas, además de generar los objetos necesarios para que funcioneel driver, se agregó códigos de validación, con el objeto de generar warnings oerrores durante la generación.

3.2.4. Notificaciones

En este trabajo se implementó el mecanismo de notificaciones del driver IO.

Las notificaciones están relacionadas con las interrupciones del periférico y encomo informarlas al usuario.

Para darle flexibilidad, el estándar define una interfaz (para cada tipo de driver)que debería ser llamada desde un handler de interrupción (o desde otro contexto,si se quisiese).

En el caso del driver IO, la interfaz se llama Dio_Notification. Es una función quedebe ser implementada por el desarrollador.

Para vincular a HIS con OSEK, se establecieron las siguientes pautas:

12Los helpers son pequeños programas de soporte que sirven para automatizar procedimientosde la generación y, en este caso, automatizar la generación de definiciones de hardware para elCortex-M

3.3. Mejoras en el generador de FreeOSEK 27

Implementación del desarrollador: El desarrollador deberá implementarla función Dio_Notification dentro de su código de aplicación. Esa funciónposee argumentos que son: el canal y el tipo de notificación recibida (pun-tualmente para el driver HIS IO, el canal será el nombre que se le asignóa una cierta IO que generó la interrupción, y el tipo de notificación si fueun flanco ascenderte o descendente). Dentro del callback de notificación eldesarrollador podrá utilizar SystemCalls de OSEK debido a que la ISR de-finida será de categoría 2.

Definición en OIL: Para que la automatización en la generación sea posi-ble, la definición de la ISR asociada a una notificación se realizó dentro delarchivo NombreDeDriver.oil. Se definió que el tipo de ISR para la noti-ficación sea de categoría 2.13

Implepementación del handler: El handler de interrupción se genera au-tomáticamente a través del generador. En este caso, el usuario no debeintervenir. Este handler lo primero que hace es quitar el flag de pendingque generó su llamado. Se creó luego la función Dio_FindChannel_Arch()(que no es parte del estándar) para que, a través del número de puerto y depin, se obtenga el número de canal que le asignó el generador a esa com-binación puerto/pin. Se llama a otra función que no es parte del estándar;Dio_GetEdge_Arch para obtener el flanco con el cual se disparó la interrup-ción y por último se llama al callback de usuario pasándole el canal y el tipode notificación (que, en este caso, es determinado por el flanco).

LISTADO 3.4: Código fuente generado para la interrupción delpuerto 1 de los GPIO

1 ISR(PORT1)2 {3 /* clear de pending IFG flag from P1IFG register and return the pin

number that triggered the handler*/4 uint16_t interrupt_source = GetPendingIRQ_Arch( 6 );5 /* get the channel number from the port and the pin */6 uint8_t channel = Dio_FindChannel_Arch( 1 , interrupt_source );7 /* get the configured edge for that port and pin and then trigger the

user callback */8 Dio_Notification( channel , Dio_GetEdge_Arch( 1 , interrupt_source )

);9 }

3.3. Mejoras en el generador de FreeOSEK

Se incorporaron algunas mejoras en el generador de FreeOSEK originalmentepor una necesidad puntual, y posteriormente para brindarle mayor prestación.El problema que ocurrió al correr los tests de conformidad en donde se probabanmuchos eventos a la vez. Los eventos en OSEK se identifican con un número de32 bits, cuyos bits son todos cero salvo uno. Ese bit en uno, identifica al evento.Internamente el OSEK lleva, por cada tarea, un registro de los eventos que tiene

13Una mejora a futuro podría ser que antes de correr el generador, un helper cree automática-mente la definición de la interrupción en el OIL y así permita una mayor automatización. Al noexistir esta automatización, actualmente el usuario debe realizar esa definición y necesita conocerdetalles de la arquitectura. Ver5.2

28 Capítulo 3. Diseño e Implementación

asignados (en ROM) y otro registro de los eventos que ya ocurrieron (en RAM).Esos registros, para Cortex eran de 32 bits, pero para MSP430 de 16 bits. Cuandoel generador evalúa los eventos declarados en el OIL, corría un algoritmo bastan-te simple en el cual para cada evento que encontraba en el OIL, corría en un bitla bandera asignada al anterior evento, y este número era asignado al nuevo. Laspruebas en cuestión (por ejemplo, el ctest_tm_14), definen de forma global másde 32 eventos. Esto hacia que las banderas asignadas a los eventos, se repitieranluego de 32 asignaciones. Por alguna razón, los test corrieron sin problemas enCortex-M pero cuando se intentó correr esas pruebas en el nuevo port, los mis-mos no eran superados.

Para resolver esto, se decidió modificar las plantillas 14 de la siguiente forma:

Modificación del algoritmo de asignación de eventos: Esta modificaciónse plasmó en Os_Cfg.h.php. Se implementó un algoritmo que, en vez derecorrer cada evento que encuentre en el OIL y asigne una bandera a cadauna, evalúe a que tareas se le asignará el evento y se le asigne una banderade forma más inteligente, en función de ello. En la lista de eventos generales,definidos en un OIL, algunos podrían ser asignados a una tarea, a más deuna tarea o a ninguna. En ese contexto, se implementó que todos los eventoscuyo destino sean solo una tarea, arranquen desde la bandera 0x0000001 yvayan corriéndose hacia la izquierda. Para los eventos que comparten tarea,se determinó que arranque con la bandera 0x80000000 y se vayan corriendohacia la derecha. En la figura 3.2 se presenta un posible escenario en dondese ejemplifica la asignación de eventos.

FIGURA 3.2: Posible escenario de asignación de eventos.

Validaciones:

14Posiblemente los algoritmos empleados deban agregarse en otro contexto dentro de los archi-vos del generador. Se decidió incluirse en las plantillas porque era la modificación más directa.

3.4. Modificaciones para la realización de los tests cases 29

• Se agregó lógica para verificar que una tarea no posea más de la can-tidad máxima de eventos definidos para el port (32 para Cortex, y 16para MSP430).

• Se agregó lógica para verificar que las tareas que definen eventos, seande topo EXTENDED.

• Se agregó lógica para verificar que las tareas que NO definen eventos,sean de tipo BASIC.

• Se agregó lógica para verificar que los eventos definidos dentro de lastareas, estén definidos globalmente.

Posteriormente a esas modificaciones, se realizaron otras para hacer que el gene-rador brinde mayores prestaciones.

Se agregó una optimización que, antes de procesar todos los recursos, sevalide si ha alguno definido. Esto evita el procesamiento que sigue del OIL.

Se agregó una optimización que, antes de procesar todas las alarmas, sevalide si hay alguna definida. Esto evita el procesamiento que sigue delOIL.

Se agregó una optimización que, permita evitar el procesamiento de las alar-mas de tipo AUTOSTART si no las hay.

3.4. Modificaciones para la realización de los tests cases

Para correr los tests del OSEK, se tuvieron que realizar algunas modificaciones envarios aspectos.

Proxy: A diferencia de la solución adoptada para Cortex-M, la única inter-faz que se utilizó entre la PC y microcontrolador objetivo fue el softwaremspdebug. Es software permitió realizar todas las operaciones automatiza-das de depuración de manera independiente. No se usó la herramienta gdb15.

Script: Se desarrolló una plantilla de script (archivo debug.scr para mspde-bug) que permitió realizar la depuración de cada test. Al ser una plantilla,el script no quedó genérico para todos los tests, sino que programa de ge-neración de pruebas (ctest.pl), escrito en lenguaje perl, se modificó para quealterase a una plantilla del script, y generase uno por cada test.

Funciones de soporte: Al programa de generación de pruebas se le agre-garon algunas funciones de soporte que no existían, para permitir algunasoperaciones que había que realizar sobre cada archivo OIL generado.

• Extra_IRQ_Vector_Replace e ISRs: Por razones relacionadas con losnombres en los handlers de interrupción para las diferentes platafor-mas, se redefinió una nueva manera de reemplazar nombres de lasplatillas y, entre otras modificaciones, se tuvo que implementar ésta

15Esto se hizo por dos razones. La primera es que las sesiones de pruebas se interrumpían por lavinculación mspdebug<->gdb<->target. La secunda es que la solución ofreció una respuesta máságil.

30 Capítulo 3. Diseño e Implementación

función que reemplaza selectivamente a los nombres de los handlersde ISR.

• Extra_MakeFile_AddOns_Arch: Lo mismo ocurrió con los makefilesque se generaban para cada prueba. Para el caso de MSP430 se le tuvoque agregar que agregará a las banderas de compilación la definiciónde CIAA_HEAP_MEM_SIZE comentada en 3.1.2.1 .

Código fuente de los tests: Se modificaron mínimamente los tests para quepudieran correr en MSP430. Las modificaciones pueden resumirse en la si-guiente lista:

• Habilitación de la ISRs: Para los tests en donde se prueban interrup-ciones, se tuvo que implementar (e incluir en los códigos fuente delos tests) una función que habilite las interrupciones de los periféricosutilizados en los mismos. Esa función es EnableISR1() y EnableISR2()

• Archivos OIL: Algunos archivos OIL poseían tamaños de stack extre-madamente grandes (por error). Se corrigieron a 256 bytes.

3.5. Integración de las herramientas de desarrollo en CIAA-Firmware

Para vincular el firmware de la CIAA, con el nuevo juego de herramientas dedesarrollo se tuvo que:

Reorganizar la estructura de carpetas en carpeta tools:La carpeta tools\openocd se movió a tools\debugserver\openocd, y luego secreó tools\debugserver\mspdebug. Dentro de cada una se encuentran los Ma-kefiles con definiciones nuevas, en ambos casos, que permitieron las modi-ficaciones en el makefile principal, comentadas a continuación.

Modificar del makefile principal:

• Reemplazo de la regla openocd por debugserver: Esta regla se reemplazópara que, inteligentemente, el makefile use el servidor de depuraciónque requiera la plataforma elegida en el makefile.mine (basada en unanueva variable del makefile denominada DEBUG_SERVER_CMD ubi-cada en el Makefile incluido en tools).

• Modificación de la regla erase: Esta regla se modificó con el mismo ob-jetivo comentado anteriormente basándose en una nueva variable delmakefile denominada ERASE_CMD ubicada en el Makefile incluidoen tools.

• Modificación de la regla download: Esta regla se modificó con el mismoobjetivo comentado anteriormente basándose en una nueva variabledel makefile denominada DOWNLOAD_CMD ubicada en el Makefileincluido en tools.

• Modificación de la secuencia dentro de la regla rtostests: Se necesitóagregar una línea (condicional para MSP430) que le indique al progra-ma ctest.pl que utilice otra canal para depurar, que no sea el gdb.

3.5. Integración de las herramientas de desarrollo en CIAA-Firmware 31

Agregado de nueva regla dis: Se necesitó, durante el desarrollo, definir unaregla que permitiera generar un archivo de texto con todo el código compi-lado y las líneas de assembler asociadas (dissasembly).

33

Capítulo 4

Ensayos y Resultados

En este capítulo se describen las pruebas realizadas para validar el trabajo.

4.1. Pruebas de desempeño de OSEK

Se realizaron algunas mediciones con analizador lógico para validar el funcio-namiento del sistema operativo. Esto se hizo a la frecuencia de reloj de 14,7456MHz (el microcontrolador llega como máximo a 25MHz pero en el port se usóesa frecuencia para las pruebas). La prueba se realizó utilizando como ejemploel blinking, por lo tanto, las señales medidas incluyen en la ejecución la activa-ción de la tarea en donde se conmuta el LED. Se utilizaron GPIOs (no usados enlos ejemplos) para marcar instantes de tiempos bien definidos. En la figura 4.1 sepueden observar los tiempos de duración de cada intervalo:

Inicio y Fin del Handler del Tick: La duración de tick medida es de 45us.

Inicio y Fin del Handler del SWi para cambio de contexto: La duración deSWI medida es de 10us

Latencia entre la salida del tick y el SWI: En este caso, como el microcon-trolador no posee tail chaining, cuando la rutina de tick marca la banderade pending para el SWI, al terminar restablece los registros utilizados. Lue-go, se le da servicio a la interrupción de SWi, donde se realiza nuevamentela guarda de los registros, para el cambio de contexto: La duración de SWImedida es de 10us.

FIGURA 4.1: Medición de tiempos en tick y SWI.

Por otro lado, la figura 4.2 muestra solo al tick, configurado cada 5ms (se confi-guró así para los ejemplos; Podría cambiarse, mas adelante).

FIGURA 4.2: Medición de tick.

34 Capítulo 4. Ensayos y Resultados

4.2. Tests de conformidad de OSEK

Una vez superados todos los obstáculos relacionados con la nueva plataforma yel nuevo conjunto de herramientas de desarrollo se corrieron los tests de confor-midad de OSEK exitosamente.

La operación llevó 24 hs por la gran cantidad de pruebas realizadas y, mas crítico,el tiempo que tarda el debugger en descargar la imagen de firmware al target.

4.3. Pruebas de Driver HIS - GPIO

La prueba del driver de GPIO se llevó a cabo creando un nuevo ejemplo del firm-ware, en donde:

Una tarea se encarga de parpadear un LED (a través de una alarma).

Se configuraron 5 canales:

• LED0: Configurado como salida, está conectado al LED utilizado porla tarea PeriodicTask, cuya actuación de realiza de forma periódica conuna alarma.

• LED1: Configurado como salida, está conectado al LED utilizado paraser conmutado directamente dentro del callback de notificación.

• LED3: Configurado como salida, está conectado al LED utilizado paraser conmutado en la tarea TaskLed3Toggle.

• KEY1: Configurado como entrada, está conectado a un pulsador, connotificación.

• KEY2: Configurado como entrada, está conectado a un pulsador, connotificación.

Dio_Notification (Callback de Notifcaciones): El handler, dependiendo delcanal que haya generado la notificación (KEY1 o KEY2) genera accionesdiferentes. Si el canal es KEY1, conmuta directamente el LED2. Si el canal esKEY2, activa la tarea TaskLed3Toggle.

Las pruebas resultaron exitosas 1.

4.4. Pruebas de Driver POSIX - UART

La prueba del driver de la UART, se realizó ejecutando el ejemplo blinkin_echo. Elejemplo permite probar tanto la recepción como la transmisión de datos por laUSART del microcontrolador. Como se mencionó en 3.1.5 no hubieron grandesinconvenientes con la migración del driver.

1Fue durante las pruebas que se evidenció la necesidad de agregar funcionalidad al driver, conrespecto a los pullup / pulldowns mencionada en 3.2.1.

35

Capítulo 5

Conclusiones

5.1. Conclusiones generales

Los objetivos principales del proyecto fueron:

Adaptar el RTOS FreeOSEK a un microcontrolador de la familia MSP430: Selogró cumplir este objetivo, atravesando las pruebas de conformidad queindica el estándar. ([15]). Todos los alcances relacionados para llevar a caboeste objetivo fueron descritos con detalle a través de este documento.

Implementar el driver POSIX del periférico UART: Este objetivo fue cum-plido también, sin problemas algunos. Se pudo correr el ejemplo provistoen el firmware de la CIAA, sin problemas.

Implementar el driver HIS para los GPIO: Este objetivo ha sido finalizadoexitosamente. Se logró integrar el driver para que utilice recursos del siste-ma operativo.

Uno de los alcances propuestos en el trabajo era la redacción de un documentodidáctico que permitiera preparar el entorno de desarrollo para trabajar con esteporting. Este documento es el [16] y se entrega por separado a este trabajo.

5.2. Próximos pasos

Durante el desarrollo de este trabajo, se evidenciaron diversas oportunidades pa-ra la realización de otros trabajos que continúen a este.

Implementar una versión que use todo el espacio de memoria de los uCCPUX (y no limitarse a 64k): Sería recomendable tener la opción de modifi-car el trabajo hecho para que permita utilizar toda la memoria flash dispo-nible en el microcontrolador. Para eso habría que cambiar modificadores alcompilador y linker, y también modificar algunas definiciones en el códigofuente, referidas, puntualmente al cambio de tipo de dato. Respecto de lasrutinas de bajo nivel, habría que tener en cuenta la manera en que el CPUapila la parte alta del program counter al ocurrir una interrupción.

Dar soporte al uso del multiplicador por hardware: Algunos dispositivos dela familia (incluido el MSP430F5529) poseen un multiplicador por hardwareque permite realizar operaciones con operandos de 32 bits y cuyo resultadoes de 64bits. En el caso de requerir utilizarlo, debería agregarse otro modi-ficador al compilador y además tener en cuenta que los registros utilizados

36 Capítulo 5. Conclusiones

por el periférico serán parte del contexto de una tarea, y deberán salvarse yreestablecerse al ocurrir un cambio de contexto (ver capítulo 25 de [6] ).

Desarrollar una CIAA con MSP430 orientada a algún segmento de equiposportátiles o sin acceso a energía permanente: Para que este trabajo tengacontinuidad será positivo que se realice alguna plataforma de hardware pa-ra este (u otro microcontrolador de la familia) que posea valor agregado conrespecto a los kits de desarrollo que ofrece Texas Instruments. Habrá querealizar un análisis de que aplicaciones podría cubrir esta plataforma, comopara abrirle paso en un desarrollo que se integre a la familia de la CIAA.No tendría sentido intentar desarrollar una EDU-CIAA-430 por el hecho deque los kits de desarrollo que provee texas, de similares prestaciones a unaversión educativa, cuestan 13u$s, y es imposible competir con esos valores.En cambio, si el valor agregado lo justifica, sería factible (los kits de TI queposeen mayores prestaciones arrancan de los 100u$s).

Mejorar el depurador libre, que provee TI de forma integrada en la placa deevaluación, para que sea más ágil la carga y la depuración: De la mano dela propuesta anterior, se podría avanzar con el análisis de cómo hacer paramejorar la velocidad de transferencia del debugger integrado que posee elkit de desarrollo. Todos estos depuradores se basan en un protocolo (nopublicado) de TI, pero su firmware está abierto y disponible on line. Por otrolado, existen otros depuradores libres en los cuales basarse para avanzar.

37

Bibliografía

[1] Disponible: 2016-10-29. 2016. URL:https://en.wikipedia.org/wiki/Operating_system.

[2] Disponible: 2016-10-29. 2016. URL:http://www.freertos.org/a00090.html#TI.

[3] Disponible: 2016-10-29. URL: http://tinyos.stanford.edu/tinyos-wiki/index.php/FAQ#What_are_its_weaknesses.3F.

[4] Contiki: The Open Source OS for the Internet of Things. Disponible: 2016-11-1.URL: http://www.contiki-os.org/.

[5] Disponible: 2016-10-29. 2016. URL:https://sourceforge.net/projects/mspgcc.

[6] MSP430x5xx and MSP430x6xx Family Users Guide. slau208m. Rev. M. TexasInstruments. 2013.

[7] Open Source Projects - MSP430. Disponible: 2016-10-29. 2016. URL: http://processors.wiki.ti.com/index.php/Open_Source_Projects_-_MSP430.

[8] MSP-EXP430F5529 Experimenter Board Users Guide. SLAU330A. Rev. A.Texas Instruments. 2011.

[9] Pablo Ridolfi. Extensión del Sistema Operativo FreeOSEK paramultiprocesadores asimétricos. Disponible: 2016-10-30. 2015. URL:http://laboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo-Final-CESE-Pablo-Ridolfi-2015.pdf.

[10] MSP430F5529 Device Erratasheet. SLAZ314. Rev. T. Texas Instruments.2016. URL: www.ti.com/lit/pdf/slaz314.

[11] MSP430 Embedded Application Binary Interface. slaa534. Texas Instruments.2013. URL: www.ti.com/lit/pdf/slaa534.

[12] MSP430 Function Attributes. Disponible: 2016-11-09. URL:https://gcc.gnu.org/onlinedocs/gcc/MSP430-Function-Attributes.html.

[13] Disponible: 2016-11-06. URL:https://github.com/ciaa/Firmware/tree/feature/hisio.

[14] HIS. API IO DRIVER. Versión 2.1.3. Abr. de 2004.[15] OSEK. OSEK VDX - Os Test Plan. Versión: 2.0. 1999.[16] Franco Bucafusco. Instalación de herramientas de desarrollo para MSP430 en

Linux. Versión: 1.0. 2016.