UNIVERSIDAD DE BUENOS AIRES

FACULTAD DE INGENIERÍA

CARRERA DE ESPECIALIZACIÓN EN SISTEMAS

EMBEBIDOS

MEMORIA DEL TRABAJO FINAL

Registrador industrial con soporte deplacas periféricas

Autor:Ing. Rafael B. Oliva

Director:Esp.Ing. Eric Pernia (FIUBA-UNQ)

Jurados:Dr. Ing. Pablo Gomez (FIUBA)

Ing. Juan Manuel Cruz (FIUBA/UTN-FRBA/Hasar)Esp. Ing. Alejandro Permingeat (VSATMotion)

Este trabajo fue realizado en la Ciudad Autónoma de Buenos Aires, entre mayode 2018 y agosto de 2019. - Versión 2 con figuras agregadas

III

Resumen

Este trabajo presenta el desarrollo del Firmware de una placa prototipo CL3 conun microcontrolador STM de 32 bits, que mantiene el formato de una placa

existente CL2 con controlador de 8 bits, aplicada desde 2010 en relevamiento desistemas de energía renovable de baja potencia. Basado en los resultados de los

sistemas anteriores CL2 se busca con este desarrollo cubrir requerimientosmayores y abrir la posibilidad de utilizarlo en proyectos mas complejos,

manteniendo la compatibilidad con placas periféricas existentes.

Para el desarrollo se utilizó como modelo la sAPI de la CIAA basada en NXP,adoptando las bibliotecas LL (de bajo nivel) provistas por el fabricante STM,

para ofrecer al usuario una interfase intuitiva y sencilla. El proyecto se inició conpocos módulos y en modalidad bare-metal únicamente, y luego incorporó la

utilización del sistema operativo FreeRTOS. Esto facilita el desarrollo y mejorasu portabilidad. Se describe además la implementación de un sistema

demostrativo con una de las placas periféricas existentes cuya estructura yensayos se explican en la etapa final del trabajo.

V

Agradecimientos

A mis viejos, Marjorie y Ramón, desde donde estén, y a mi familia por su perma-nente apoyo. Al Ing. Leonardo Garberoglio, co-diseñador del Hardware CL3, ala gente del INTI-Neuquén y del Area Energías Alternativas de la UNPA, por susoporte para desarrollar este proyecto. Un agradecimiento especial a Eric Perniaque tuvo la paciencia para hacer de guía y director.

VII

Índice general

Resumen III

1. Introducción General 11.1. Introducción y conceptos básicos sobre controladores industriales . 1

1.1.1. Contexto y descripción básica del sistema . . . . . . . . . . . 11.1.2. Diagrama del sistema CL2 anterior . . . . . . . . . . . . . . . 21.1.3. Nuevo sistema CL3 . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3. Objetivos y Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.3.1. Objetivos del desarrollo . . . . . . . . . . . . . . . . . . . . . 71.3.2. Alcances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2. Introducción Específica 92.1. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1. La aplicación de los sistemas CL2 y migración hacia CL3 . . 92.1.2. Tipos de Display utilizados en CL2 y en CL3 . . . . . . . . . 9

2.2. Plataforma de Hardware . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.1. Descripción de Subsistemas CL3 . . . . . . . . . . . . . . . . 10

2.3. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.1. Requerimientos planteados por usuarios . . . . . . . . . . . 112.3.2. Requerimientos internos de desarrollo . . . . . . . . . . . . . 12

2.4. Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3. Diseño e Implementación 173.1. Hardware desarrollado . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.1. Detalle de los módulos - Fuente de alimentación y distribu-ción de potencia . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.2. Detalle de los módulos - Interfaz SD y Puerto USB . . . . . . 193.1.3. Detalle de los módulos - Display . . . . . . . . . . . . . . . . 203.1.4. Detalle de los módulos - RTC y Oscilador compensado TCXO 21

3.2. Descripción de los módulos del Firmware . . . . . . . . . . . . . . . 213.2.1. Modelo de programación CIAA y beneficios para el presen-

te proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.3. Implementación del Firmware . . . . . . . . . . . . . . . . . . . . . . 24

3.3.1. Configuración del Hardware - Cube MX . . . . . . . . . . . 253.3.2. Integración con System Workbench AC6 y ejemplos con sA-

PI3C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.3.3. Debug con OpenOCD / STLink . . . . . . . . . . . . . . . . 353.3.4. Selección de librerías base y criterios de calidad . . . . . . . 35

3.4. Incorporación de FreeRTOS . . . . . . . . . . . . . . . . . . . . . . . 363.4.1. Diagrama general del Trabajo Final RTOS1 con CL3 . . . . . 363.4.2. Distribución en el entorno AC6 incorporando FreeRTOS . . 37

VIII

4. Ensayos y Resultados 394.1. Plan de Pruebas - Estrategias . . . . . . . . . . . . . . . . . . . . . . 394.2. Verificación de requerimientos . . . . . . . . . . . . . . . . . . . . . 394.3. Aplicación ejemplo con módulo METEO . . . . . . . . . . . . . . . . 42

5. Conclusiones 475.1. Conclusiones generales . . . . . . . . . . . . . . . . . . . . . . . . . 475.2. Próximos pasos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Bibliografía 49

IX

Índice de figuras

1.1. Diagrama de la versión inicial CL2 de 2010 . . . . . . . . . . . . . . 31.2. Fotografía de una de las primeras placas CL2 (2010) con procesador

ATMega1284P, conectada a un periférico M4/E . . . . . . . . . . . . 31.3. Diagrama en bloques de la placa CL3 . . . . . . . . . . . . . . . . . 41.4. Primer render de la placa CL3 - 08/2017 . . . . . . . . . . . . . . . . 51.5. Placa CL3 sin componentes 04 2018 . . . . . . . . . . . . . . . . . . 51.6. Sistemas de relevamiento INTI CL2 en Plataforma de Ensayo de

Aerogeneradores, Cutral-Có (Neuquén) - 06/2012 . . . . . . . . . . 61.7. Utilización de módulos periféricos M4/E y METEO conectados a

CL2 en Plataforma de Ensayo de Aerogeneradores (INTI, Cutral-Có) 7

2.1. Placa periférica M4/E conectada a CL2 via I2C . . . . . . . . . . . . 102.2. Placa periférica METEO conectada a CL2 via RS485 - INTI Cutral Có. 102.3. Componentes de placa CL3 . . . . . . . . . . . . . . . . . . . . . . . 112.4. Primeros ensayos sobre tablero de placa CL3 (08-2018) . . . . . . . 122.5. Primer modelo de capas de sAPICL3 (2018) . . . . . . . . . . . . . . 142.6. Modelo de capas actualizado sAPI3C (2019) . . . . . . . . . . . . . . 142.7. Diagrama AON (Activity On Node)(2018) . . . . . . . . . . . . . . . 152.8. Diagrama de Gantt actualizado (05-2019) . . . . . . . . . . . . . . . 16

3.1. Fuente de alimentación de CL3 (08-2017) . . . . . . . . . . . . . . . 193.2. Distribución de potencia de CL3 (08-2017) . . . . . . . . . . . . . . . 193.3. Interfaz SD y USB de CL3 (08-2017) . . . . . . . . . . . . . . . . . . . 203.4. Interfaz Display LCD de CL3 (08-2017) . . . . . . . . . . . . . . . . . 213.5. RTC interno, TCXO y error en pin Vbat de CL3 (08-2017) . . . . . . 223.6. Soldado de diodo DD1 (BAT54 doble Schottky) a pin 1 Vbat de CL3

(07-2019) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.7. Estructura básica del Firmware sAPI 0.5.2 (E.Pernia) Diagrama:

R.Oliva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.8. Estructura del Firmware sAPI3C - Diagrama: R.Oliva . . . . . . . . 243.9. Comparación entre funciones gpioInit() y su equivalente en ST-LL . 253.10. Configuración desde STM32CubeMX v5 de CL3 . . . . . . . . . . . 263.11. Configuración de Clocks en STM32CubeMX v5 para CL3 . . . . . . 273.12. Configuración de Toolchain desde CubeMX en CL3 . . . . . . . . . 273.13. Ejemplo 01 en AC6-System Workbench, Blinky en CL3 . . . . . . . 293.14. Directorio de Proyecto Ejemplo 01, Blinky en CL3 . . . . . . . . . . 293.15. Vista de main.c de Ejemplo 02, entorno AC6 con placa CL3 . . . . . 303.16. Ejemplo 02 - Salida a terminal (Tecla F3 = ABAJO) usando la sapi3c

en CL3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.17. Estructura de /lib/sapi3c para ejemplos simples en CL3 . . . . . . 313.18. Placa CL3 conectada a circuito STLink V2 integrado en Nucleo STM32F411 353.19. Trabajo Final RTOS 1 realizado sobre placa CL3 conectada a módu-

lo METEO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

X

4.1. Ensayos UART-LL6 con FATFS, RTC y Display ILI9341 (07-2019) . . 404.2. Ensayos CL3 con Display ILI9341 (07-2019) . . . . . . . . . . . . . . 404.3. Detalle del Display CL3 (07-2019) . . . . . . . . . . . . . . . . . . . . 414.4. Testing de RTC lecturas y conexionado de display ILI9341 . . . . . 414.5. Terminal UART6 de RTC lecturas - FreeRTOS . . . . . . . . . . . . . 424.6. Veleta y METEO conectados a CL3 bajo FreeRTOS . . . . . . . . . . 434.7. Terminal UART6 lectura desde METEO, FreeRTOS . . . . . . . . . . 434.8. Conexión a CL3 de terminal y teclado en ensayos UART-5-LL . . . 444.9. Ensayos con Ej 04 y montaje CL3 en su gabinete . . . . . . . . . . . 444.10. Ensayos Finales CL3 + METEO . . . . . . . . . . . . . . . . . . . . . 454.11. Conexión a CL3 de programador, METEO y veleta . . . . . . . . . . 46

XI

Índice de Tablas

2.1. Comparación CL2 con CL3 . . . . . . . . . . . . . . . . . . . . . . . 11

XIII

Dedicado a Claudia, Juan y Florencia, por estricto orden deaparición...

1

Capítulo 1

Introducción General

1.1. Introducción y conceptos básicos sobre controladoresindustriales

Los controladores industriales, a veces denominados autómatas programables,son equipos electrónicos programables en distintos lenguajes, y diseñados paracontrolar, en tiempo real y en ambientes industriales, procesos secuenciales. Suimportancia en el mundo moderno y la cantidad y diversidad de sistemas queinvolucran ha impulsado diversas iniciativas de estandarización, por ejemplo laIEC 61131 [1]. Dentro de esta norma, se desarrollan diversos aspectos de estos sis-temas. La normativa [2] por ejemplo, involucra la funcionalidad y requerimientosde equipos de control industrial de los siguientes tipos:

Controladores lógicos programables (PLC, Programmable Logic Controllers).

Autómata programable(PAC, Programmable Automation Controller).

Herramientas de programación y depuración (PADTs, Programming and De-bugging Tools).

PCs y Panel PCs Industriales.

Displays e Interfaces de Usuario (HMIs,Human-Machine Interfaces) para usoindustrial.

Sistemas y componentes para Control Distribuido (DCSs,Distributed ControlSystems).

Cualquier producto cuyo propósito sea el control de sistemas industriales,incluyendo sus periféricos, y que se utilicen para comando de máquinas,manufactura automatizada o procesos industriales.

Por otro lado, la normativa [3] se ocupa exclusivamente de los lenguajes de pro-gramación de dichos equipos, su sintaxis y el contenido de lenguajes textuales ygráficos.

1.1.1. Contexto y descripción básica del sistema

Existe a nivel internacional una importante oferta de placas y subsistemas aplica-bles a control y medición, con grados diversos de costo, capacidad y potencia decómputo. Se trata además de un mercado en fuerte expansión. Según la consulto-ra VDC [4] el mercado global para módulos embebidos, que fue de 4200 millones

2 Capítulo 1. Introducción General

de usd en 2016, tiene un crecimiento esperado a 33600 millones de usd en 2021.Una gran demanda se da actualmente en sistemas industriales de aplicación es-pecífica, en general de diseño cerrado y alto costo. Por otro lado, hay un mercadovasto en módulos de bajo costo (en general de diseño abierto) para hobbistas conescasos requerimientos en ítems como protección eléctrica industrial, poder decómputo o capacidad de memoria.

No resulta tan amplia la oferta en sistemas de costo medio con prestaciones indus-triales o semi-industriales, para aplicaciones de registro de variables o de controlen entornos no extremos. En este tipo de sistemas, en general para series peque-ñas se percibe una demanda insatisfecha, que es viable cubrir con equipos deproducción nacional.

El objeto del presente proyecto es insertarse en ese nicho realizando el desarrollodel Firmware de una placa denominada CL3 que migra desde una versión previaCL2 de arquitectura AVR (controlador de 8 bits) a una versión ARM-Cortex M4Fde 32 bits, manteniendo características del formato físico anterior. Se busca lograruna expansión de las capacidades de cómputo y rendimiento, que dicho Firm-ware tenga características de facilidad de uso con un enfoque similar a la sAPI(simple Application Programming Interface) desarrollada para la CIAA [5], y a la vezque resuelva las limitaciones encontradas en las placas CL2 de 8 bits.

La placa CL2 fue desarrollada a través de un ANR (Aportes No Reintegrables,Programa FONTAR) en 2009, de la firma LyR Ingeniería [6] de la que el autor esintegrante, y se viene utilizando en distintos proyectos desde 2010.

Según su propia definición, la sAPI [7] es una biblioteca de funciones de códi-go abierto, que funciona como HAL (Hardware Abstraction Layer, o Capa de Abs-tracción de Hardware) y resulta portable a diferentes placas con distintos micro-controladores. Dichas funciones proporcionan acceso a periféricos internos delmicrocontrolador (GPIO, UART, ADC, etc), módulos de alto nivel como Delay(retardo), PWM, Buffer Circular o Print (impresión a través de UART), y acce-so a módulos externos específicos (por ejemplo en la EDU-CIAA: display de 7segmentos, magnetómetro, teclado, servos).

1.1.2. Diagrama del sistema CL2 anterior

La estructura de diagrama en bloques se aprecia en la Figura 1.1, y una fotografíade la placa original CL2 en la Figura 1.2.

Dado que la mayoría de las aplicaciones para las que se utilizó involucran el re-gistro de variables eléctricas y/o meteorológicas de sistemas de energía renovable(fundamentalmente generadores fotovoltaicos y eólicos de baja potencia, en sis-temas aislados) se la dotó de una interfaz para tarjetas SD industriales y de unreloj de tiempo real con oscilador compensado por temperatura (TCXO o Tempe-rature Compensated Xtal Oscilator), para reducir significativamente la variación enlos registros temporales.

1.1. Introducción y conceptos básicos sobre controladores industriales 3

ATMega644P

+B nr +5Vcc

RTC

I2C

1 2

MAX232 RS232/COM0

SD CARD

LCD CONN.

DATA PC.2:7

PB

4:7

ISP

KB

Din

ANLGIN

ANin

PA

.0:7

PD

se

lec

t

PC.0:1

PD.0:1

CL2_b Proto (AtMega32/644) Rev5F-2010(C) R.Oliva - L&R Ing. 2008/9

B 3V

CTRL PD7

I2C

5V/3.3V

SD Socket

4050

+3V3

USB USB

XTAL o TCXO

PB

.0:3

MAX232 RS232/COM1PD.2:3

RS485 RS485

EXTER.I2C

PCA9538

2

SD_PWR

5XEXP

8b I/O

AVCC

(644P)

Fuente LinealLM2937-5 / 7805

AVCC

LPF

6P/10P+5Vcc

+5Vcc

+5Vcc LCD_BL

SD_PWR

PMOS

SD_STATUS

SD_STATUS2

ATMega32

X8

7.3728E6XTAL OSC

2X8

+5Vcc

10x2 y 17x2

PD

5

JTAG

FIGURA 1.1: Diagrama de la versión inicial CL2 de 2010

FIGURA 1.2: Fotografía de una de las primeras placas CL2 (2010)con procesador ATMega1284P, conectada a un periférico M4/E

4 Capítulo 1. Introducción General

1.1.3. Nuevo sistema CL3

Las características mecánicas, el oscilador compensado por temperatura y la in-terfaz SD industrial se mantuvieron en la placa CL3 desarrollada con el Ing. Leo-nardo Garberoglio (GADIB-UTN/FRSN), cuyo diagrama en bloques se muestraen la Figura 1.3.

STM32F411RE

+B nr

+5Vcc

TPS2085D

1 2

1/2 MAX2232 RS232_1

SD CARD

LCD AL/ILI9341

PC

8,1

1:1

2

ISP

KB

Din

ANLGIN

ANin

PC

.0:3

Se

lec

t

PB.6:7

CL3 rev1 - 2018(C) R.Oliva - L.Garberoglio / L&R Ing.

B 3V

SD Socket

USB

TCXO

PC

.4:3

RS232_2

RS485RS485

I2CPCA9539

-INT1IO_CN2, IO_CN3

16b I/O

AVDD

Fuente SwitchingTPS54302

AVDD

LPF

CN1

+LCD_PWR LCD_BL (SPI_CD)

NRST

SD_STATUS2

X8

8E6XTAL OSC

2X8

VDD

10x2

PB

.2

HC595

5V/3.3VVDD (3.3V)

RS485_DE (PB.10)P

A.4

:7

JP_EXP(I2C)

EXP_PWR(+5Vcc)

+5Vcc

PB

.0:1

LCD_DATA,LCD_CLK

LCD_E (SPI_CS)SPI1 (PB3:5)

OLED

VDDRTC

DD1=BAT54(*)

PCA9306

SDIO

SPI1 I2C1

SD_WRE (SPI_RES)

VDD

VBAT

OSC32_IN

DS32KHZ

SWDIO,SWCLK,NRST

ADC1

NRST

VDD

UART1

UART6

2

3

1UART2

WI-FIESP8266

USBUSB_DM/DP

I2C3

+5Vcc

VDD

-INT1

(JK

1)

IC23_SDA/SCL

IC21_SDA/SCL

2

3

1

WR_EN1

PA9:10

PC6:7

PA2:3

1/2 MAX2232

PA0: EN_EXP_PWR

PA1: EN_LCD_PWR

PA0: EN_SER_PWR

PB8: EN_IOT_PWRPIOT_PWR/3V3

PSER_PWR/3V3

LCD_PWR/3V3

EXP_PWR/ +5V

SN65HVD75

10K

VDD BOOT0

PSER_PWR/3V3

PIOT_PWR/3V3

PSER_PWR/3V3

(OR 5V)

J1

VDD

-INT1/PA15

PF0:1

D2

L1

OVER_CURRENT

LED1-PWR

VDD

FIGURA 1.3: Diagrama en bloques de la placa CL3

El primer render (de agosto 2017) de la placa se ilustra en la Figura 1.4. La placanueva sin componentes, recibida en abril de 2018, se expone en la Figura 1.5.

1.1. Introducción y conceptos básicos sobre controladores industriales 5

FIGURA 1.4: Primer render de la placa CL3 - 08/2017

FIGURA 1.5: Placa CL3 sin componentes 04 2018

6 Capítulo 1. Introducción General

1.2. Motivación

Hasta ahora los sistemas basados en la Placa CL2 han encontrado aplicación ensistemas aislados en bombas dosificadoras de pozos petroleros, en sistemas deprueba como los instalados por el INTI-Neuquén desde 2012 para relevamientode curvas de potencia de pequeños aerogeneradores (ver Figura 1.6) y en diver-sos sistemas de ensayo en la Universidad Nacional de la Patagonia Austral, convariantes de Firmware en cada caso.

Una limitación importante ha sido la utilización de un esquema de software clá-sico de lazo infinito, rutinas de interrupción y múltiples máquinas de estado en-lazadas. El controlador (AVR ATMega1284, o modelos menores en encapsuladoDIP-40) si bien podría utilizar un sistema operativo (SO) de tiempo real (RTOS óReal Time Operating System) simplificado, tiene limitaciones importantes de velo-cidad y capacidad de memoria que dificultan este agregado.

Por otro lado, se desarrollaron desde la empresa una serie de placas periféricas(M4/E, METEO) que continúan utilizándose (Figura 1.7), por lo cual es impor-tante mantener la compatibilidad con las mismas [8].

Se espera que esta nueva placa basada en un microcontrolador de 32 bits (líneaSTM32F4) permita expandir la aplicabilidad de la línea (en general son produc-tos en cantidades reducidas y software muy específico), manteniendo el foco enla confiabilidad y control de incertidumbres en las mediciones (por ejemplo entensión, corriente, potencia) utilizando componentes y protecciones aptos paracada aplicación. La mayor capacidad del microcontrolador permite trabajar sinproblemas con sistemas operativos como FreeRTOS.

FIGURA 1.6: Sistemas de relevamiento INTI CL2 en Plataforma deEnsayo de Aerogeneradores, Cutral-Có (Neuquén) - 06/2012

La innovación consiste en la posibilidad de ofrecer un sistema que pueda ser utili-zado para proyectos llave en mano por la empresa, o reprogramado por el usuariocon herramientas abiertas, que tenga un costo intermedio entre las aplicaciones

1.3. Objetivos y Alcance 7

FIGURA 1.7: Utilización de módulos periféricos M4/E y METEOconectados a CL2 en Plataforma de Ensayo de Aerogeneradores

(INTI, Cutral-Có)

puramente para hobby y los sistemas industriales de alto costo. Las barreras paraesta innovación son la posible competencia de alternativas importadas que pue-dan ser adaptadas, y en caso de fabricarse localmente, los costos de producciónen el mercado argentino actual.

1.3. Objetivos y Alcance

1.3.1. Objetivos del desarrollo

El objetivos del proyecto es el desarrollo del Firmware de una placa CL3 basadaen ARM Cortex M4F que representa una evolución importante desde la placaexistente CL2 (arquitectura de 8 bits). Esta última se ha aplicado en un mercadode nicho de relevamiento, registro y control de sistemas de energía renovable debaja potencia, para lo cual se cuenta con placas periféricas específicas.

Dado el buen resultado de los sistemas anteriores y la posibilidad de desarrollarproyectos de mayor complejidad, se busca desarrollar el firmware para esta placaque cubra estas aplicaciones y abra la posibilidad de utilizarla en otro tipo desistemas.

1.3.2. Alcances

Este proyecto involucró el Firmware para la placa CL3, en este caso desarrollode funciones simplificadas para acceso al microcontrolador STM32F411, la cons-trucción de un BSP (Board Support Package o Software de Soporte de Placa) parael manejo de los periféricos específicos de la placa CL3, y la construcción de una

8 Capítulo 1. Introducción General

biblioteca sAPI3C, de diseño similar a la sAPI desarrollada por E.Pernia para laCIAA.

Esta biblioteca incluye el acceso de alto nivel a la configuración y funciones deuna de dichas placas. Se enfoca en la utilización de un sistema basado en FreeR-TOS, aunque inicialmente se pensó en limitarse a uno del tipo Lazo Infinito coninterrupciones sin sistema operativo (Bare-Metal), similar a lo que se utilizó enCL2, y en la documentación de la sAPI3C y los ensayos de cada módulo, ademásde la descripción de una aplicación demostrativa.

9

Capítulo 2

Introducción Específica

En esta sección se presentan características de los sistemas registradores de tipoindustrial, las características del hardware nuevo, y los requerimientos de soft-ware que se plantearon para realizar el trabajo. Se da cuenta además del impactode la utilización del sistema operativo FreeRTOS para facilitar el desarrollo denuevas aplicaciones.

2.1. Antecedentes

2.1.1. La aplicación de los sistemas CL2 y migración hacia CL3

Las placas CL2 se diseñaron durante 2009 en el marco de un Proyecto ANR-FONTAR, con el objeto de reemplazar placas de fabricación norteamericana quehabían sido discontinuadas. Desde 2010 se desarrollaron además una serie de pla-cas periféricas orientadas a la adquisición de datos y control de variables funda-mentalmente relacionadas con equipos de energía renovable, como la placa M4Eque se muestra en la Figura 2.1 y que incorpora un controlador Cypress PSoC 1con hardware y software reconfigurable.

Durante 2017 e inicios de 2018 se avanzó con el desarrollo de la placa CPU de-nominada CL3 basada en procesador de arquitectura ARM-Cortex M4F (32 bits)para el reemplazo de los sistemas actuales de 8 bits, con mayor velocidad deoperación y capacidad de memoria, y menor consumo, a la vez manteniendo lacompatibilidad mecánica y de ubicación de componentes en los tableros existen-tes.

La placa periférica METEO (Figura 2.2) tiene un controlador similar, y entradaspara lectura de variables atmosféricas como viento, (velocidad y dirección), tem-peratura y presión atmosférica. Se incluye en el presente trabajo el acceso víainterface RS485 a dicha placa, desde el nuevo modelo CL3.

2.1.2. Tipos de Display utilizados en CL2 y en CL3

El sistema CL2 se concibió para interactuar con displays LCD alfanuméricos, enel caso de las CL3 se optó por la utilización adicional de interfaces SPI (ej conLCD touch tipo ILI9341 de bajo costo) o la utilización de displays 4DSystems coninterfase serie de nivel TTL. La extensión de sAPI es por ahora solo a funcionesbásicas de acceso a cada tipo de display en el marco del presente proyecto.

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

FIGURA 2.1: Placa periférica M4/E conectada a CL2 via I2C

FIGURA 2.2: Placa periférica METEO conectada a CL2 via RS485 -INTI Cutral Có.

2.2. Plataforma de Hardware

2.2.1. Descripción de Subsistemas CL3

En la placa CL3 se mantuvieron las características mecánicas, el oscilador com-pensado por temperatura (TCXO) para el reloj de tiempo real y la interfaz SDindustrial. El desarrollo se realizó en cooperación con el Ing. Leonardo Garbe-roglio (GADIB-UTN/FRSN). En la Tabla 2.1 se muestran algunas característicascomparativas entre los modelo CL2 y CL3.

2.3. Requerimientos 11

TABLA 2.1: Comparación placas CL2 con CL3

Característica CL2 CL3

Microcontrolador Atmel ATMega1284P STM32F411REMemoria Flash interna 128 KB 512 KBMemoria RAM interna 16 KB 128 KBPuertos serie (USARTs) 2 3Puertos I2C 1 2Interfaz SD 1 via SPI 1 independienteRTC 1 externo 1TCXO (DS32kHz) 1 1

En la Figura 2.3 se muestran en forma gráfica la ubicación de los módulos incor-porados a la placa CL3.

FIGURA 2.3: Componentes de placa CL3

A partir de julio de 2018 comenzaron los ensayos, con ubicación en los tablerosoriginales utilizados para las placas CL2. En la foto de la Figura 2.4 se muestra laplaca prototipo durante las primeras pruebas realizadas.

2.3. Requerimientos

2.3.1. Requerimientos planteados por usuarios

Algunos de los aspectos planteados desde los usuarios (sobre todo operadoresdel Campo de Pruebas INTI - Plataforma de Ensayo de Aerogeneradores) paralos nuevos sistemas, que pueden ser resueltos con las placas CL3:

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

FIGURA 2.4: Primeros ensayos sobre tablero de placa CL3 (08-2018)

Mayor capacidad de procesamiento e integración directa a la red LAN, tan-to a través de los puertos seriales /convertidores existentes como a travésde un módulo WiFi integrado.

Interfase gráfica a través de un módulo HMI táctil: el sistema permite tra-bajar con interfaces SPI o serial por lo cual resulta flexible para acomodardistintas consideraciones de costo y confiabilidad.

Interfase analógica ampliada: se mantiene (en diseño aún) la incorporaciónde una interfase analógica M5/E basada en la distribución actual M4/Emanteniendo la línea de elevada resolución y bajo ruido pero en una versiónmás avanzada.

2.3.2. Requerimientos internos de desarrollo

Uno de los problemas mas importantes detectados desde el punto de vista delmantenimiento de los sistemas en la anterior arquitectura CL2 es la complejidadde realizar cambios y agregados. Esto tiene una serie de razones que pueden sin-tetizarse como sigue:

Los primeros desarrollos sobre la arquitectura AVR datan de 2005.

Arquitectura de lazo infinito con interrupciones y múltiples máquinas deestado.

Baja modularidad y alta interdependencia entre módulos.

2.4. Planificación 13

Durante el desarrollo del proyecto y los ensayos del prototipo se fueron puliendolos requerimientos originales planteados en la etapa de planificación del proyec-to, que se transcriben con sus modificaciones en lo siguiente.

Hardware

1. Utilización como hardware del microcontrolador STM32F411RE, in-cluido en la placa CL3 y sus interfases.

2. La actualización del firmware y la depuración se realiza utilizandoSTLink/v2 como interfase de programación.

Firmware

1. El firmware previsto originalmente se basó en un modelo de capas se-gún la Figura 2.5. La sAPI3C es la capa que utiliza el usuario para eldesarrollo de su programa de aplicación.

2. El firmware se desarrolló en C utilizando herramientas libres siguien-do los lineamientos y templates utilizados en la CIAA.

3. La sAPI3C presenta funciones para interactuar con los periféricos in-ternos del STM32F411RE (GPIO, UART, ADC).

4. La sAPI3C presenta módulos de alto nivel como Delay (retardo), BufferCircular o Print (impresión a través de UART).

5. Se realizó una previsión de ensayos requeridos durante la etapa dediseño de cada módulo del firmware. Los ensayos de verificación yvalidación se realizan tanto sobre la PC como sobre el hardware.

6. Se previeron funciones para acceso a placas externas de E/S (por ejem-plo placas METEO, M4/E y M5/E)

Documentación

1. La documentación de cada módulo del firmware tiene una vinculacióndirecta con los módulos de hardware indicados en la documentaciónde la placa CL3 existente.

2. Se utiliza Doxygen [9] para la documentación de la librería sAPI3C.

3. Se documenta un ejemplo de integración de cada uno de los módulosque componen el presente proyecto.

Las modificaciones a los requerimientos se relacionaron en primer lugar con elatraso de la presentación original, planteada para fines de 2018, y además porla posterior incorporación del uso de FreeRTOS en el sistema, lo cual no estabaprevisto originalmente, y la utilización en forma integrada de las herramientasMXCube y AC6, ambas provistas libremente por ST. Esto dio lugar al modelo decapas actualizado que se muestra en la Figura 2.6

2.4. Planificación

La planificación original a través del diagrama AON (Activity On Node) se mues-tra en la Figura 2.7. Algunas de las tareas, sobre todo las relativas a la secuencia

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

FIGURA 2.5: Primer modelo de capas de sAPICL3 (2018)

FIGURA 2.6: Modelo de capas actualizado sAPI3C (2019)

2.4. Planificación 15

de desarrollo y ensayos detallados sobre el hardware prototipo, cambiaron su se-cuencia.

FIGURA 2.7: Diagrama AON (Activity On Node)(2018)

Asimismo el atraso luego de agosto de 2018 obligó al replanteo del proyecto,que se refleja en el diagrama de Gantt actualizado que se ilustra en la Figura2.8, remitido en la actualización del Plan al 05-2019.

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

FIGURA 2.8: Diagrama de Gantt actualizado (05-2019)

17

Capítulo 3

Diseño e Implementación

En esta sección se describe el desarrollo previo del hardware, la implementaciónde los módulos de firmware y los problemas encontrados, que motivaron algunoscambios en lo planificado originalmente para el proyecto.

3.1. Hardware desarrollado

En las aplicaciones de ensayo descriptas en 1.2 y en otras más recientes se obser-vó de parte de los clientes hacia 2017 una demanda de interfaces gráficas, mayorcapacidad de registro de eventos y alarmas, y expansión de posibilidades de ac-ciones de control y procesamiento de datos.

Se optó entonces por iniciar el desarrollo de la placa denominada CL3 de dimen-siones similares a la CL2, pero con arquitectura ARM-Cortex M4F de 32 bits. En laetapa de diseño, se fijaron algunas características deseables del microcontroladora seleccionar para la placa CL3:

ARM Cortex M4F, debido a su amplia disponibilidad y adecuada relaciónprecio / performance.

512K Flash mínimo, cuadruplicando la memoria disponible actual.

32K RAM mínimo.

Un mínimo de 20 entradas / salidas de propósito general (GPIO).

2 Puertos Serial (1 de ellos con RS485) y 1 puerto USB.

2 puertos SPI, uno de ellos dedicado a display TFT.

2 puertos I2C, al menos 1 tolerante a 5V con conector compatible.

Conversor A/D 12 bits mínimo, 8 entradas.

Encapsulado LQFP 64 para facilitar armado.

En cuanto a los requerimientos a cumplir por la placa, se fijaron:

1. Fuente switching y manejo de periféricos por hardware (para reducción deconsumo).

2. Incorporar interfase SD industrial.

3. Incorporar reloj tiempo real con TCXO, tipo DS32khz.

4. Mantener el factor de forma de la placa predecesora CL2.

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

En base a ello se optó por un controlador STM32F411RE de arquitectura CortexM4/F de 100 MHz con FPU y MPU, 512 KB de Flash y 128 KB de SRAM, ADC de12 bits y USB, en encapsulado LQFP64 [10].

El fabricante y empresas externas ofrecen además herramientas IDE gratuitas sinlímite de código basadas en Eclipse (ej.: AC6 System Workbench [11] , Atollic TrueStudio), librerías de nivel bajo STM32F4 LL o Low Level e intermedio STM32F4HAL (Hardware Abstraction Layer).

Existe además disponibilidad de una herramienta libre de inicialización de pe-riféricos (CubeMX32) que permite de forma gráfica obtener una versión inicialdel código para configurar y activar los periféricos del uC, con un significativoahorro de tiempo de desarrollo.

Recientemente en 2019, a través de la adquisición de la empresa Atollic, ST fu-sionó CubeMX32 con la herramienta TrueStudio, para ofrecer el IDE integradoSTM32CubeIDE [12].

El desarrollo del hardware fue realizado en cooperación con el Ing. Leonardo Gar-beroglio (UTN-FRSC / GADIB) quien contaba con experiencia en desarrollos conesta línea de controladores. Por otro lado, el costo FOB de los chips ST mencio-nados era al momento de diseño del orden de 5,5 usd por 100 unidades, apenassuperior al del controlador Atmel/Microchip ATMega1284P utilizado en CL2.Asimismo, las placas de evaluación son de bajo costo, e incluyen la herramientade debug estándar STLink.

En la figura 1.3 se mostró un diagrama en bloques de la placa CL3, y en la Tabla2.1 se mostraron algunas de las diferencias entre ambas placas.

3.1.1. Detalle de los módulos - Fuente de alimentación y distribuciónde potencia

Por razones de eficiencia se ha reemplazado la fuente lineal basada en dos unida-des LDO LM2937 5 para obtener 5 V y 3,3 V por un circuito switching buck tra-dicional (Figura 3.1), basado en un TPS54302 [13] de la firma Texas Instruments.Esto permite una tensión de entrada +Bnr entre 7 y 20 VCC y salida en Vo de 5 Va 3 A máximo, que proporciona una eficiencia mayor al 85 %.

Esta unidad tiene la ventaja adicional de reemplazar internamente el habitualdiodo rápido de bloqueo por un MOSFET, y utilizar un encapsulado SOT23-6Thin muy compacto.

Finalmente para la obtención de los 3,3 V necesarios para el funcionamiento deluC y algunos periféricos se optó por un LDO (NCP1117ST33T3G) similar al uti-lizado en la CIAA-NXP, debido a que la diferencia de tensión (5 V – 3,3 V) espequeña al igual que la corriente necesaria.

Una característica deseable para el sistema propuesto, a efectos de darle mayorflexibilidad, es la capacidad de poder conmutar por software los periféricos queno se utilicen en cada aplicación, con el objetivo de maximizar la eficiencia ener-gética del equipo. Para la placa CL3 se eligió el TPS2085 de Texas Instruments,que es un circuito conmutador cuádruple (power switch) diseñado para la admi-nistración de potencia a baja tensión.

3.1. Hardware desarrollado 19

FIGURA 3.1: Fuente de alimentación de CL3 (08-2017)

Cada switch posee una entrada de habilitación independiente (Figura 3.2). Eneste diseño se han elegido los siguientes periféricos conmutables en 3,3 V: IoT(ESP8266), SER (Serial), LCD (Display) y en 5 V la sección EXP (expansión a I2Cexterno).

FIGURA 3.2: Distribución de potencia de CL3 (08-2017)

3.1.2. Detalle de los módulos - Interfaz SD y Puerto USB

La placa CL2 utiliza una interfaz SPI para manejar la escritura/lectura de unatarjeta SD tipo industrial. La librería utilizada implementa un sistema de archivosFAT propietario (2006) de la extinta compañía PRIIO de Indianápolis, EEUU. Elsistema utiliza un FAT32 convencional con tope de 2 GB y baja velocidad, y enalgunas aplicaciones resulta una limitante el acceso a la tarjeta.

Para la placa CL3 se utilizó el módulo específico SDIO del STM32F411 en modo1 bit (ver figura 1.3), y la FatFS de Elm-Chan [14], de libre disponibilidad. Estalibrería está totalmente programada en C99 estándar, y puede ser portada a casi

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

cualquier sistema embebido. En particular, las librerías ST y el generador de có-digo CubeMX implementan dicha librería como MiddleWare de forma nativa, y sepuede configurar la misma en forma gráfica. Debido a una cuestión de compa-tibilidad, se ha decidido mantener el conector SD Hirose de la línea DM1. En laFigura 3.3 se muestra la conexión al exterior del SDIO junto con la interfaz USB.

FIGURA 3.3: Interfaz SD y USB de CL3 (08-2017)

3.1.3. Detalle de los módulos - Display

Otro punto fundamental en la actualización del sistema es el agregado de unainterfaz gráfica de mejores prestaciones. El antiguo sistema contaba con una in-terfaz tradicional a display LCD alfanumérico basado en el controlador HitachiHD44780, limitado a 4 líneas de 20 caracteres. En muchas aplicaciones esto resultasuficiente, pero frecuentemente resulta inadecuada la limitación a formato textoy sistema de menús muy básicos.

Se ha decidido mantener la interfaz LCD alfanumérica pero se ha configurado elpuerto SPI1 para controlar un display tipo TFT-LCD ( Thin Film Transistor /LCD).

Este tipo de display se implementa con diversos controladores como por ejemplo:ILI9340 o ILI9341. En los ensayos se utilizó el display no táctil ILI9341, que seincluyó con una librería en sAPI3C.

Para este modelo sobre el que se realizaron las pruebas, se debieron reasignaralgunos pines respecto a la distribución original, que se muestra en la Figura 3.4 .

3.2. Descripción de los módulos del Firmware 21

FIGURA 3.4: Interfaz Display LCD de CL3 (08-2017)

3.1.4. Detalle de los módulos - RTC y Oscilador compensado TCXO

Todo sistema registrador necesita una base de tiempo precisa y estable. Esto fueuna premisa de diseño del CL2, debido al rango de aplicaciones al que apuntaba,por lo cual al tradicional chip PCF8563 RTC se acopló un TCXO DS32kHz deMaxim, a pesar de su significativo costo inicial.

El uso de este tipo de osciladores con compensación interna de temperatura se ha-ce necesario cuando se desea mantener la fecha/hora de un equipo que necesitafuncionar durante períodos largos sin acceso a GPS u otras correcciones remotas,y ante la potencial variación significativa de la temperatura de operación de laplaca.

En esta nueva versión CL3 se mantiene esta base de tiempo de buena estabilidad,aunque se utiliza el RTC interno del uC, lo cual ahorra espacio de hardware yreduce el costo de la placa pero resulta significativamente más complejo de pro-gramar, como se verá en 3.3.

Asimismo, por un error de coordinación en el diseño del PCB se omitió el diodoschottky doble BAT54 que conserva la alimentación del RTC interno en el pin 1del microcontrolador, indicado como DD1 en Figura 3.5.

Dicho componente DD1 debió ser soldado encima de la placa posteriormentepara las pruebas del firmware RTC, como se puede apreciar en la Figura 3.6.

3.2. Descripción de los módulos del Firmware

En esta sección se describe la estructura del Firmware en lenguaje C propuestopara esta placa CL3, que facilita la programación y el agregado de componenteso módulos adicionales.

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

FIGURA 3.5: RTC interno, TCXO y error en pin Vbat de CL3 (08-2017)

FIGURA 3.6: Soldado de diodo DD1 (BAT54 doble Schottky) a pin1 Vbat de CL3 (07-2019)

3.2. Descripción de los módulos del Firmware 23

El enfoque pretende asimismo una mejora del software que es el elemento máscomplejo y costoso de la cadena de desarrollo en un nuevo producto, y que a suvez suele implicar la necesidad de un constante mantenimiento.

Para esto se ha adaptado, según se indicó en el Capítulo 1 el modelo sAPI [7]utilizado en la Computadora Industrial Abierta Argentina [5], basada en micro-controladores ARM. Un esquema global de la versión más reciente (05-2019) dedicha librería se muestra en la Figura 3.7

FIGURA 3.7: Estructura básica del Firmware sAPI 0.5.2 (E.Pernia)Diagrama: R.Oliva

Para la placa CL3 se utiliza un modelo muy acotado denominado sAPI3C comose observa en la Figura 3.8, que busca permitir a un número creciente de progra-madores familiarizados con la CIAA una notación similar a la que se utiliza enentornos de desarrollo de dichas placas, sobre todo del equipo EDU-CIAA quetiene gran difusión en las universidades y escuelas técnicas del país.

3.2.1. Modelo de programación CIAA y beneficios para el presente pro-yecto

Si bien la CIAA utiliza microcontroladores ARM Cortex y es por definición dearquitectura abierta y no atada a un vendor (fabricante) específico, el modelo másdifundido y sobre el que más desarrollo tiene la sAPI es sobre uno de NXP, espe-cíficamente el LPC4337 de tipo dual-core Cortex M4/M0.

La filosofía de este desarrollo es la utilización de herramientas abiertas y libres ylas licencias tanto del hardware como del firmware son extremadamente permi-sivas. Esto resultó ser un factor clave para la difusión de la CIAA, y se consideróimportante su adopción para el presente proyecto sobre la placa CL3, que se basaen un microcontrolador Cortex M4 de capacidades un poco más reducidas.

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

FIGURA 3.8: Estructura del Firmware sAPI3C - Diagrama: R.Oliva

Como se sabe, la firma ARM no comercializa los chips sino que licencia el diseñoo IP (propiedad intelectual) del núcleo o core del procesador, y cada fabricanteagrega sus propios periféricos y características de acuerdo a las aplicaciones y almercado. Por lo tanto, aunque se trata de un sistema complejo, su gratuidad yla disponibilidad abierta del código, herramientas de programación e incluso deldesarrollo de hardware de la placa han hecho que se cuente con un importantecaudal de experiencia colectiva en aplicaciones que utilizan la CIAA.

Esta experiencia también fomenta la adopción de técnicas similares para otrasplacas que pueden plantearse como opción, como sería el caso del prototipo CL3.En caso de realizar una migración, la similitud del modelo de programación eincluso familiaridad con las notaciones son un factor importante.

3.3. Implementación del Firmware

El sistema de librerías para el firmware de las placas CL3 tiene los contenidos yaindicados en la Figura 2.6, que guardan similitud con la sAPI original desarrolla-da por el Ing. Eric Pernia de la Figura 3.7.

La capa superior se denomina de Aplicación y es la que programa el usuario. Enel extremo inferior del diagrama se encuentra el Hardware, que desde el puntode vista del programador son registros y zonas de memoria destinados al controlde los submódulos (ej SDIO, RTC, SPI1) del STM32F411 que aparece en la partecentral de la Figura 1.3.

Dada la complejidad y capacidades integradas en el microcontrolador CortexM4F de 32 bits, se vuelve muy importante el agregado de capas intermedias.

Por encima del Hardware se ubican la capa CMSIS, estándar producido por ARM,y la capa de drivers (manejadores) del fabricante del chip, en este caso la multina-cional de origen europeo STMicroelectronics[15].

3.3. Implementación del Firmware 25

Estos drivers son rutinas de software que se indican como LL (Low Level), conmanejo casi directo del Hardware, y HAL (Hardware Abstraction Layer), con unnivel superior de abstracción. Estos últimos se utilizan en forma predominanteen los periféricos más complejos como USB, aunque con restricciones puedenutilizarse en forma conjunta.

En el nivel superior siguiente se ubican en un recuadro los módulos denomina-dos middleware o de firmware intermedio, en general desarrollados por compa-ñías o programadores independientes (third parties), y que pueden utilizarse conmuchas plataformas distintas de hardware. Tal el caso del sistema operativo detiempo real FreeRTOS [16], cuya aplicación para CL3 se utiliza en los ejemplosde implementación, y el mencionado sistema de archivos FATFS [14] que permiteimplementar la interfase a tarjetas SD, y genera archivos legibles desde cualquiercomputadora moderna.

Al mismo nivel se encuentra un módulo BSP (Board Support Package, o paquetede soporte de placa) que tiene funciones específicas para la particular asignaciónde periféricos de la CL3 que indicamos en la 1.3, y que puede considerarse parteintegrante de la sAPI3C.

Este módulo contiene funciones como SystemClockConfig() que configura el com-plejo sistema de clocks o relojes que llevan adelante todas la funciones internas delprocesador, y que se corre como función inicial al arrancar el funcionamiento dela placa.

Como se ve, la sAPI3C es simplemente un auxiliar para el programador, queinteractúa con sus funciones pero también con las funciones de alto nivel delmiddleware para crear aplicaciones en forma más intuitiva, lo cual redunda enmayor confiabilidad y mantenibilidad de los sistemas.

A modo de ejemplo, se muestra en la Tabla 3.9 a la izquierda, el llamado a lafunción original gpioInit() de sAPI para inicializar una salida SPI_RES (Figura1.3 , abajo), y a la derecha la misma funcionalidad utilizando solamente la RutinasLL de ST. Es de notar que la implementación final para las salidas en sAPI3C sedenota gpioInitOutput().

FIGURA 3.9: Comparación entre funciones gpioInit() y su equiva-lente en ST-LL

3.3.1. Configuración del Hardware - Cube MX

La herramienta gratuita CubeMX permite generar en forma sencilla la inicializa-ción de los periféricos internos en los controladores de la línea STM32. Su interfaz

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

gráfica permite realizar una configuración preliminar de dichos periféricos y ge-nerar código de inicialización.

Dicha herramienta da la opción de utilizar en forma combinada las mencionadaslibrerías LL, Low Level o HAL, Hardware Abstraction Layer para los periféricos mascomplejos como USB, LWIP o SDIO, que después puede integrarse en la aplica-ción final.

En la Figura 3.10 se muestra el resultado gráfico de dicha configuración para laplaca CL3, que utiliza una combinación de librerías LL y HAL, mientras que en laFigura 3.11 se muestra la configuración de los Clocks de dicha placa. Aquí se haoptado por utilizar el oscilador externo HSE de 8 MHz, y las entradas LSE parael oscilador de precisión del módulo DS32kHz.

FIGURA 3.10: Configuración desde STM32CubeMX v5 de CL3

El software STM32CubeMX permite, a partir del hardware y la particular confi-guración de periféricos elegida, generar código fuente para configurar el sistemaen desarrollo con el toolchain seleccionado. Esto se ve en la Figura 3.12, donde seha seleccionado SW4STM32 (que es el código para el System Workbench AC6).Se permiten sin embargo varias otras opciones, entre ellas EWARM y TrueStudiode Atollic, empresa recientemente adquirida por ST.

En este software, luego de configurar el microcontrolador como se necesita per-mite, a través de un botón Generate Code producir código fuente con una particu-lar distribución, que separa múltiples secciones de user code o código de usuario,y gran cantidad de archivos. Esto habilita, en una etapa preparatoria, a hacer

3.3. Implementación del Firmware 27

FIGURA 3.11: Configuración de Clocks en STM32CubeMX v5 paraCL3

FIGURA 3.12: Configuración de Toolchain desde CubeMX en CL3

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

modificaciones a la configuración de hardware, ensayar desde el Toolchain se-leccionado y no sobreescribir el código propio generado por el usuario a travésde múltiples iteraciones. En cada caso, se guardan las opciones y configuraciónseleccionada en un archivo .ioc, que queda en el raíz del Proyecto.

Un primer problema generado por esta modalidad es que el proyecto debe impor-tarse en el Workspace de Eclipse o del IDE seleccionado. En el caso de lo utilizadoen CL3, System Workbench AC6, las configuraciones modificadas en el Eclipseno son siempre registradas en el STMCubeMX, y viceversa. Asimismo, aunquese han hecho grandes progresos, sobre todo las primeras versiones de las HALtenían múltiples errores.

El segundo gran problema es la cantidad de archivos y la multiplicidad de seccio-nes de user code que generan confusión y dificultan la mantenibilidad del sistema.Se recomienda entonces utilizar el CubeMX solamente para las etapas de desa-rrollo inicial y ensayos de hardware, para después migrar a una estructura másordenada como la sAPI3C.

Por último, desde el punto de vista del programador acostumbrado a utilizar laCIAA y en particular la sAPI, la distribución generada por el CubeMX es poco in-tuitiva y por lo tanto se buscó producir una estructura de directorios y funcionessimilar a lo desarrollado por el Ing. E. Pernia.

3.3.2. Integración con System Workbench AC6 y ejemplos con sAPI3C

Como se mencionó en 3.3.1, en el desarrollo del presente proyecto se ha trabajadocon la herramienta System Workbench [11], basada en Eclipse, producida para STpor la firma francesa AC6. Este entorno, similar a la CIAA-IDE pero configuradopara utilizarse con controladores ST, ofrece al usuario de la CIAA una interfasefamiliar como la que se muestra en la Figura 3.13.

En este caso, la estructura de directorios del ejemplo sólo presenta al usuario unarchivo main.c y un main.h dentro de los directorios /Src e /Inc respectivamente,como se muestra en la Figura 3.14.

Los detalles de la implementación de las funciones, y la función de inicializaciónde la placa boardInitCL3(), similar a la función boardConfig() de la CIAA, se en-cuentran dentro de la estructura del directorio /lib/sapi3c de la Figura 3.14.

En la Figura 3.15 se muestra un ejemplo (Ej02) que utiliza la función de iniciali-zación de la UART TER (UART6 en CL3) , similar a la de la sAPI, y consulta enforma muy sencilla el estado de la tecla F3 / KBABJ del prototipo CL3.

Si encuentra la tecla apretada, sin debounce, envía un mensaje por el puerto serie.La salida de dicho programa se muestra en la Figura 3.16

La distribución interna de dichos directorios de sapi3c para estos ejemplos mássencillos se muestran en la Figura 3.17.

3.3. Implementación del Firmware 29

FIGURA 3.13: Ejemplo 01 en AC6-System Workbench, Blinky enCL3

FIGURA 3.14: Directorio de Proyecto Ejemplo 01, Blinky en CL3

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

FIGURA 3.15: Vista de main.c de Ejemplo 02, entorno AC6 conplaca CL3

FIGURA 3.16: Ejemplo 02 - Salida a terminal (Tecla F3 = ABAJO)usando la sapi3c en CL3

3.3. Implementación del Firmware 31

FIGURA 3.17: Estructura de /lib/sapi3c para ejemplos simples enCL3

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

A modo de ejemplo, se transcribe en el Algoritmo 3.1 el header de una de lasbibliotecas, la sapi3cboard.h que define características propias de la placa CL3 eincluye los archivos necesarios HAL y LL para la inicializacion de la placa.

1

2 # include " sapi3c_data types . h"3 # include " stm32f4xx_hal . h "4 # include " stm32f4xx_hal . h "5 # include " s t m 3 2 f 4 x x _ l l _ u s a r t . h "6 # include " s t m 3 2 f 4 x x _ l l _ r c c . h"7 # include " stm32f4xx . h"8 # include " stm32f4xx_l l_system . h"9 # include " s tm32f4xx_l l_gpio . h"

10 # include " s t m 3 2 f 4 x x _ l l _ e x t i . h "11 # include " s tm32f4xx_l l_bus . h"12 # include " s t m 3 2 f 4 x x _ l l _ c o r t e x . h"13 # include " s t m 3 2 f 4 x x _ l l _ u t i l s . h "14 # include " stm32f4xx_ll_pwr . h"15 # include " stm32f4xx_ll_dma . h"16 /∗==================[macros]===================∗/17 # def ine boardConfigCL3 boardInitCL318

19 /∗ P r i v a t e def ines −−−−−−−−−−−−−−−−−−−−−−−−−−−−∗/20 # def ine SPI_RES_Pin LL_GPIO_PIN_1321 # def ine SPI_RES_GPIO_Port GPIOC22 # def ine AN10_PC0_Pin LL_GPIO_PIN_023 # def ine AN10_PC0_GPIO_Port GPIOC24 # def ine AN11_PC1_Pin LL_GPIO_PIN_125 # def ine AN11_PC1_GPIO_Port GPIOC26 # def ine AN12_PC2_Pin LL_GPIO_PIN_227 # def ine AN12_PC2_GPIO_Port GPIOC28 # def ine AN13_PC3_Pin LL_GPIO_PIN_329 # def ine AN13_PC3_GPIO_Port GPIOC30 # def ine PA0_EN_EXP_PW_Pin LL_GPIO_PIN_031 # def ine PA0_EN_EXP_PW_GPIO_Port GPIOA32 # def ine PA1_EN_LCD_PW_Pin LL_GPIO_PIN_133 # def ine PA1_EN_LCD_PW_GPIO_Port GPIOA34 # def ine AN4_PA4_Pin LL_GPIO_PIN_435 # def ine AN4_PA4_GPIO_Port GPIOA36 # def ine AN5_PA5_Pin LL_GPIO_PIN_537 # def ine AN5_PA5_GPIO_Port GPIOA38 # def ine AN6_PA6_Pin LL_GPIO_PIN_639 # def ine AN6_PA6_GPIO_Port GPIOA40 # def ine AN7_PA7_Pin LL_GPIO_PIN_741 # def ine AN7_PA7_GPIO_Port GPIOA42 # def ine K_IZQ_PC4_Pin LL_GPIO_PIN_443 # def ine K_IZQ_PC4_GPIO_Port GPIOC44 # def ine K_ARR_PC5_Pin LL_GPIO_PIN_545 # def ine K_ARR_PC5_GPIO_Port GPIOC46 # def ine K_ABJ_PB0_Pin LL_GPIO_PIN_047 # def ine K_ABJ_PB0_GPIO_Port GPIOB48 # def ine K_DER_PB1_Pin LL_GPIO_PIN_149 # def ine K_DER_PB1_GPIO_Port GPIOB50 # def ine OLED_Pin LL_GPIO_PIN_251 # def ine OLED_GPIO_Port GPIOB52 # def ine RS485_DE_Pin LL_GPIO_PIN_1053 # def ine RS485_DE_GPIO_Port GPIOB54 # def ine LCD_DATA_Pin LL_GPIO_PIN_1255 # def ine LCD_DATA_GPIO_Port GPIOB56 # def ine LCD_CLK_Pin LL_GPIO_PIN_1357 # def ine LCD_CLK_GPIO_Port GPIOB58 # def ine SPI_CS_Pin LL_GPIO_PIN_1459 # def ine SPI_CS_GPIO_Port GPIOB

3.3. Implementación del Firmware 33

60 # def ine SPI_DC_Pin LL_GPIO_PIN_1561 # def ine SPI_DC_GPIO_Port GPIOB62 # def ine INT1_N_Pin LL_GPIO_PIN_1563 # def ine INT1_N_GPIO_Port GPIOA64 # def ine SD_INS_Pin LL_GPIO_PIN_1065 # def ine SD_INS_GPIO_Port GPIOC66 # def ine SDIO_CD_Pin LL_GPIO_PIN_1167 # def ine SDIO_CD_GPIO_Port GPIOC68 # def ine SPI_CLK_Pin LL_GPIO_PIN_369 # def ine SPI_CLK_GPIO_Port GPIOB70 # def ine SPI_MISO_Pin LL_GPIO_PIN_471 # def ine SPI_MISO_GPIO_Port GPIOB72 # def ine SPI_MOSI_Pin LL_GPIO_PIN_573 # def ine SPI_MOSI_GPIO_Port GPIOB74 # def ine PB8_EN_IOT_PW_Pin LL_GPIO_PIN_875 # def ine PB8_EN_IOT_PW_GPIO_Port GPIOB76 # def ine PB9_EN_SER_PWR_Pin LL_GPIO_PIN_977 # def ine PB9_EN_SER_PWR_GPIO_Port GPIOB78

79 /∗ Defined f o r s a p i 3 c _ u a r t . h ∗/80

81 typedef enum {82 UART_TER = 0 , // Hardware UART6 ( RS232_2 connector − Terminal )83 UART_485 = 1 , // Hardware UART1 via RS_485 A, B and GND Borns84 UART_2 = 2 // Hardware UART2 ( RS232_1 connector or ESP8266 )85 } uartMap_t ;86

87 typedef enum {88 BAUD_9600 = 0 , // Lowest Baud r a t e 960089 BAUD_19200 , // Intermediate 1920090 BAUD_38400 , // For METEO91 BAUD_115200 // Highest 11520092 } uartBaudR_t ;93

94 typedef enum {95 KBD_ABJ = 0 , // K_ABJ_PB0_Pin − Pin 26 − F396 KBD_DER = 1 , // K_DER_PB1_Pin − Pin 27 − F497 KBD_IZQ = 2 , // K_IZQ_PC4_Pin − Pin 24 − F198 KBD_ARR = 3 , // K_ARR_PC5_Pin − Pin 25 − F299 SDIO_CD = 4 , // SDIO_CD_Pin_PC11 ( former CS)

100 SDIO_INS = 5 // SD_INS_Pin_PC10101 } inputMap_t ;102

103 typedef enum {104 EXP_PW_PA0 = 0 , // PA0_EN_EXP_PW_Pin105 LCD_PW_PA1 , // PA1_EN_LCD_PW_Pin106 OLED_PB2 , // PB2_OLED_Pin107 IOT_PW_PB8 , // PB8_EN_IOT_PW_Pin108 SER_PW_PB9 , // PB9_EN_SER_PWR_Pin109 RS485_DE_PB10 , // PB10_RS485_DE_Pin110 LCD_CLK_PB12 , // PB12_LCD_CLK_pin111 LCD_DATA_PB13, // PB13_LCD_DATA_pin112 SPI_CS_PB14 , // PB14_ ( exLDC_E ) _SPI_CS_Pin113 SPI_DC_PB15 , // PB15_ ( exLDC_BL ) _SPI_DC_Pin114 SPI_RES_PC13 // PC13_ (exSD_WREN) _SPI_RES_Pin115 } outputMap_t ;

ALGORITMO 3.1: El sapi3cboard header.

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

y en el Algoritmo 3.2, la función BoardInitCL3() que realiza la inicialización de laPlaca:

1 # def ine MAX_SENSOR_NUMBER 32 /∗∗3 ∗ @brief boardInitCL3 ( ) − Set up and i n i t i a l i z e CL3 board hardware4 ∗ F i r s t c a l l the system Clock conf igurat ion ,5 ∗ Then enable a l l gpio_inputs ( c l o c k s & r e s e t outputs )6 ∗ Then conf igure a l l gpio_inputs , a l l gpio_outputs7 ∗ F i n a l l y the −INT1 EXTI i n t e r r u p t8 ∗ @param None9 ∗ @retval None

10 ∗/11 void boardInitCL3 ( void )12 {13 HAL_Init ( ) ;14 SystemClock_Config ( ) ;15 gpioIn i tEnable ( ) ;16

17 /∗ Configuracion de pines de entrada de CL318 S i m i l a r to g p i o I n i t ( DI0 , GPIO_INPUT ) ; in EDUCIAA19 KBD_ABJ = 0 , // K_ABJ_PB0_Pin20 KBD_DER = 1 , // K_DER_PB1_Pin21 KBD_IZQ = 2 , // K_IZQ_PC4_Pin22 KBD_ARR = 3 , // K_ARR_PC5_Pin23 SDIO_CD = 4 , // SDIO_CD_Pin_PC11 ( former CS)24 SDIO_INS = 5 // SD_INS_Pin_PC1025 and c o n f i g _ p u l l can be LL_GPIO_PULL_UP or LL_GPIO_PULL_NO26 ∗/27

28 g p i o I n i t I n p u t ( KBD_ABJ , LL_GPIO_PULL_UP) ;29 g p i o I n i t I n p u t ( KBD_DER, LL_GPIO_PULL_UP) ;30 g p i o I n i t I n p u t ( KBD_IZQ , LL_GPIO_PULL_UP) ;31 g p i o I n i t I n p u t ( KBD_ARR, LL_GPIO_PULL_UP) ;32 g p i o I n i t I n p u t ( SDIO_CD , LL_GPIO_PULL_UP) ;33 g p i o I n i t I n p u t ( SDIO_INS , LL_GPIO_PULL_NO) ;34

35 /∗ Configuracion de pines de s a l i d a de CL336 bool_ t gpioIni tOutput ( outputMap_t output ) ;37 S i m i l a r a g p i o I n i t ( DO0, GPIO_OUTPUT ) ;38 ∗/39

40 gpioInitOutput (EXP_PW_PA0) ;41 gpioInitOutput (LCD_PW_PA1) ;42 gpioInitOutput (OLED_PB2) ;43 gpioInitOutput ( IOT_PW_PB8 ) ;44 gpioInitOutput (SER_PW_PB9) ;45 gpioInitOutput ( RS485_DE_PB10 ) ;46 gpioInitOutput (LCD_CLK_PB12) ;47 gpioInitOutput (LCD_DATA_PB13) ;48 gpioInitOutput ( SPI_CS_PB14 ) ;49 gpioInitOutput ( SPI_DC_PB15 ) ;50 gpioInitOutput ( SPI_RES_PC13 ) ;51

52 // I n t e r r u p t INT1 f o r I2C Externa l53 gpioInit_INT1 ( ) ;54

55 }

ALGORITMO 3.2: La función BoardInitCL3().

El listado completo de los ejemplos indicados se encuentra en el repositorio [17].

3.3. Implementación del Firmware 35

3.3.3. Debug con OpenOCD / STLink

El sistema AC6 cuenta con una opción de Debug similar a la utilizada en la CIAAcon OpenOCD. La conexión permite una depuración paso a paso con las herra-mientas habituales de Eclipse y resulta un auxiliar importante para el desarrollodel software.

En nuestro caso se utilizó una placa de desarrollo modelo Nucleo STM32F411REque ya contaba con un ST-Link v2 integrado y conexión USB, y la posibilidad deconfigurarlo para debug externo de otra placa, a traves de un cable de 4 conduc-tores como se muestra en la Figura 3.18.

FIGURA 3.18: Placa CL3 conectada a circuito STLink V2 integradoen Nucleo STM32F411

3.3.4. Selección de librerías base y criterios de calidad

Durante el desarrollo del presente proyecto se consultaron distintas alternativaspara desarrollar la biblioteca sAPI3C. Existen alternativas de desarrollo indepen-diente como LibOpenCM3 [18] pero se observó que la actualización de muchasde estas librerías era deficiente, sobre todo para los modelos STM32F4. Inclusodentro de bibliotecas propuestas por ST, la mayoría de las IDE permiten seguirutilizando las bibliotecas conocidas como "Standard Peripheral Library", contan-do con muchos ejemplos de desarrollo para el microcontrolador utilizado.

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

Sin embargo, ST parece haber abandonado la evolución de dicha biblioteca enfavor de las mencionadas LL y HAL. De hecho, en CubeMX para las nuevas fa-milias M7, H7 sólo hay soporte para estas últimas. Por tanto, se tomó como crite-rio trabajar todo lo posible sobre las librerías LL y dejar solo para los casos máscomplejos o desarrollos en evolución la utilización de las HAL.

En el manual de usuario UM1725 [19] se provee una descripción bastante ex-haustiva de las bibliotecas HAL y LL. Las primeras ofrecen APIs de mayor nivel,y esconden al programador muchos detalles del controlador y periféricos. Con-sumen más memoria, sobre todo si implementan un handle para el periférico encuestión, aunque ofrecen una mayor facilidad de uso y alto grado de portabili-dad entre procesadores. Las LL (del inglés Low Level) en cambio ofrecen APIs debajo nivel, prácticamente en contacto directo con los registros. Requieren menosmemoria, pero permiten una mejor optimización al costo de menor portabilidad.Requieren un mayor conocimiento del procesador y periféricos.

En el mismo manual [19] se declara que el código fuente de los drivers sigueestrictamente ANSI-C, haciéndolo independiente del toolchain elegido. El códigoes chequeado en cada release con la herramienta de análisis estático CodeSonar[20]. Asimismo, se afirma que dicho código está completamente documentado ycumple la normativa MISRA-C 2004 [21].

3.4. Incorporación de FreeRTOS

Durante la realización de la materia RTOS 1 de la Especialización, se eligió comotrabajo final la incorporación de FreeRTOS al trabajo realizado sobre la Placa CL3,con lectura de paquetes de la unidad existente METEO utilizada con los equiposCL2. Se previó lograr una decodificación del paquete remitido por el móduloMETEO vía RS485 a través de la UART1, y su envío como datos formateados através de una cola a la tarea InterfazUsuario(). Se realiza el envío de los datos auna interfase de terminal de usuario a través de una UART6 del controlador.

3.4.1. Diagrama general del Trabajo Final RTOS1 con CL3

El diagrama general del funcionamiento del sistema se muestra en la Figura 3.19.

Uno de los puntos importantes del trabajo era la detección del string o paquetede datos de entrada que llega cada 1 segundo desde la unidad METEO a 38400baud, consistente de los elementos mostrados en el Algoritmo 3.3.

1 UUU$ s t a r t i d e n t i f i e r2 t t t t t i s 00000 08191 Raw Temperature ADC reading , usual ly 0−5V3 bbbbb i s 00000 08191 Raw Baro ADC reading , usual ly 1−5V (4−20mA)4 dddd i s 0000 to 3600 , WDIR∗10 in UWORD5 s s s s s i s 00000 to 99999 from Anemometer / Thies .6 vvv was voltage , not used .7 CRCC i s simple checksum ( paso a u i n t 1 6 _ t )8 ∗QQQ end i d e n t i f i e r

ALGORITMO 3.3: Paquete de Datos de Unidad METEO

3.4. Incorporación de FreeRTOS 37

FIGURA 3.19: Trabajo Final RTOS 1 realizado sobre placa CL3 co-nectada a módulo METEO

A fin de evitar errores en la recepción, que se daban con la configuración de larutina de interrupción original a inicios del trabajo, se modificó la misma paraagregar una mini-FSM de detección del carácter de inicio y del de fin. Con esto, latasa de errores se redujo a prácticamente 0 en condiciones de ensayo. Se eliminóla lectura del primer conjunto UUU y su envío al string de decodificación por serredundante.

3.4.2. Distribución en el entorno AC6 incorporando FreeRTOS

En cuanto a la distribución general del proyecto UART1-5-LLFR, se utilizó la po-sibilidad de inclusión de FreeRTOS v10.1 en el proyecto desde CubeMX v5, y lacombinación de rutinas de librería LL para las interrupciones de UART1 (RS485)y UART6 (Terminal). Se realizaron modificaciones en FreeRTOSConfig.h, en espe-cial en lo relativo al tamaño de Heap disponible. Se mantiene la práctica habitualde incluir un directorio Middlewares que incluye a FreeRTOS y eventualmentea FATFS para la parte de archivos SD. El código fuente de dicho proyecto se en-cuentra disponible en el repositorio [22].

39

Capítulo 4

Ensayos y Resultados

En esta sección se describen ensayos preliminares y más detallados, además deuna aplicación completa integrando elementos del proyecto.

4.1. Plan de Pruebas - Estrategias

Los ensayos más simples sobre las bibliotecas sapi3c finalizadas resultaron exito-sos, según se mostró en la Figura 3.16. A partir de la incorporación de FreeRTOSen el Trabajo Final de RTOS1, se realizaron pruebas con el mismo sistema incor-porando nuevos componentes.

Se integraron a un nuevo ensayo llamado UART-LL-6 la biblioteca abierta paraILI9341 (combina HAL y LL), el RTC (solo HAL) y el módulo SDIO con la incor-poración de FATFS, cuya distribución se muestra en la Figura 4.1, y cuyos ensayoscontinuan al momento de finalizar el presente informe.

Tanto en el caso del Display como del RTC fue necesario realizar modificacionesal prototipo de hardware de CL3 que retrasaron la implementación. Aunque to-davía no ha sido posible incorporar a la sapicl3 el módulo ILI9341, el driver hasido ensayado como parte del UART-LL-6. En la Figura 4.2 se muestra un ensayopreliminar bajo FreeRTOS de dicho display ILI9341 conectado a la interfase SPI1,y en la Figura 4.3 un detalle del mismo.

En cuanto al RTC, en la Figura 4.4 se muestran los primeros ensayos y en la Fi-gura 4.5 una captura del terminal UART6 corriendo el proyecto UART-LL-6, alque se le incorporó la lectura del RTC utilizando una sencilla función preliminarbasada en la HAL, aunque todavía se registran fallas. El funcionamiento del RTCes importante ya que es necesario vincularlo al FATFS de Chan para poder incluirel timestamp en los archivos SD.

4.2. Verificación de requerimientos

Los requerimientos de los componentes más elementales de la biblioteca sapicl3se han verificado, y la mayoría de los drivers de bajo nivel también. Resta trabajarsobre los elementos faltantes como la operación correcta de la función f-mount()de la FATFS, y la persistencia del RTC a lo largo del ciclado de la alimentación,que todavía presenta falencias. Asimismo, es importante la implementación deun módulo de emulación de EEPROM en Flash (existen rutinas LL para ello) a

40 Capítulo 4. Ensayos y Resultados

FIGURA 4.1: Ensayos UART-LL6 con FATFS, RTC y DisplayILI9341 (07-2019)

FIGURA 4.2: Ensayos CL3 con Display ILI9341 (07-2019)

4.2. Verificación de requerimientos 41

FIGURA 4.3: Detalle del Display CL3 (07-2019)

FIGURA 4.4: Testing de RTC lecturas y conexionado de displayILI9341

42 Capítulo 4. Ensayos y Resultados

FIGURA 4.5: Terminal UART6 de RTC lecturas - FreeRTOS

efectos de almacenar las constantes de calibración y varios otros elementos deoperación típicos de los sistemas anteriores CL2. Algunos elementos adiciona-les como los relativos al puerto I2C1, vinculado a la expansión de GPIO, fueronensayados con éxito como trabajo final de la materia Protocolos en Sistemas Em-bebidos de la CESE, pero no se incorporaron todavía a la biblioteca sapicl3.

4.3. Aplicación ejemplo con módulo METEO

Según se refirió en el Capítulo 3, se realizó el ensayo con el módulo METEO co-nectado y una veleta indicadora de dirección de viento, utilizando el proyectoUART-LL-5 corriendo en la placa CL3. Una fotografía de dicho sistema en opera-ción puede observarse en la Figura 4.6.

Asimismo, se muestran el Terminal operando como una tarea de FreeRTOS desdela UART6 como interfase de usuario en la Figura 4.7, y el aspecto de la platafor-ma conectada en la Figura 4.8. En la presente versión de la memoria se incluyentambién vistas de los ensayos más recientes con la placa y la ultima versión delsoftware (Ej04) ya instaladas en su gabinete, como se puede apreciar las Figuras4.9, 4.10 y 4.11.

4.3. Aplicación ejemplo con módulo METEO 43

FIGURA 4.6: Veleta y METEO conectados a CL3 bajo FreeRTOS

FIGURA 4.7: Terminal UART6 lectura desde METEO, FreeRTOS

44 Capítulo 4. Ensayos y Resultados

FIGURA 4.8: Conexión a CL3 de terminal y teclado en ensayosUART-5-LL

FIGURA 4.9: Ensayos con Ej 04 y montaje CL3 en su gabinete

4.3. Aplicación ejemplo con módulo METEO 45

FIGURA 4.10: Ensayos Finales CL3 + METEO

46 Capítulo 4. Ensayos y Resultados

FIGURA 4.11: Conexión a CL3 de programador, METEO y veleta

47

Capítulo 5

Conclusiones

En este capítulo se presentan conclusiones generales sobre el proyecto, los aportesdel trabajo y los logros obtenidos. Se mencionan técnicas aprendidas que resulta-ron útiles, junto al grado de cumplimiento de los objetivos planteados. Posterior-mente, se identifican los próximos pasos y aspectos que se consideran pendientesen el desarrollo del firmware.

5.1. Conclusiones generales

El desafío más interesante del proyecto ha sido la articulación del hardware desa-rrollado con las piezas del firmware que se fueron construyendo, para adecuar elconjunto a los objetivos planteados en el plan inicial.

Como aportes pueden mencionarse la difusión de conocimiento concreto a travésdel desarrollo de una solución completa de un registrador industrial, y la facili-dad de uso de las funciones sapi3c implementadas, siguiendo el modelo sAPI dela CIAA. La familiaridad resultante para los numerosos desarrolladores que tra-bajan en la comunidad constituye un punto favorable para el emprendimiento.

El trabajo se ha llevado adelante con un grado adecuado de terminación, y elmodelo para la incorporación progresiva de módulos a la biblioteca sapi3c estácorrectamente establecido y documentado internamente, como para que sólo res-te tiempo de trabajo para completarlo. Se ha podido incorporar el uso del sistemaoperativo FreeRTOS, y se logró el funcionamiento del display gráfico y del RTC.Se logró parcialmente la incorporación del FATFS y la expansión GPIO a travésde I2C, cuyo desarrollo queda planteado como tareas inmediatas.

Durante el desarrollo de la carrera ha sido de suma importancia la vinculacióny experiencias compartidas con docentes y compañeros de la carrera. Asimismo,ha resultado de relevancia el aprendizaje adquirido en:

Técnicas de ingeniería de software

Utilización de herramientas de planificación como Gantt y AON para inten-tar corregir vicios adquiridos en el desarrollo de proyectos.

Profundización en uso de RTOS e introducción a los frameworks y modeladode sistemas reactivos.

de diseño de PCB con herramientas libres, y la actualización en tecnologíasde fabricación y protección de los mismos en ambientes rigurosos.

48 Capítulo 5. Conclusiones

Los objetivos no alcanzados tuvieron relación con los riesgos contemplados alinicio del plan, y en cierta medida con la ineficacia de los métodos de mitigaciónpropuestos. Los riesgos considerados más severos fueron:

Riesgo 1: Prototipo de hardware incompleto o no funciona correctamente.Esto ocurrió y se discutió en los puntos 3.1.3 y 3.1.4 relativos al Display y alRTC respectivamente.

Riesgo 2: Horas de trabajo insuficientes. Esto resultó estar vinculado par-cialmente con aspectos del Riesgo 1.

Por otro lado, el Riesgo 5: Problemas de índole personal, ocurrieron también yprovocaron un retraso significativo en el desarrollo del proyecto. En cuanto a lasmedidas de mitigación de riesgos, para el Riesgo 1 se planteó la corrección de laplaca con el co-diseñador (Ing. Garberoglio) en un plazo irreal de pocas semanas,y que fue complicado por la necesidad de un nuevo acuerdo económico. Para elRiesgo 2 el incremento de las horas de trabajo que se planteó como medida demitigación también resultó insuficiente.

A consecuencia de lo indicado en el párrafo anterior, se realizó una modificaciónde los requerimientos, que incluyó la incorporación de FreeRTOS como base yla interacción solamente con el periférico existente METEO. Esta modificación seplasmó en el informe de avance de mayo de 2019. De todas maneras, los objetivosaún no completados respecto del plan fueron los siguientes:

Desarrollo del módulo RTC, por problemas de persistencia ante ciclado dealimentación, según lo indicado en la subsección 3.1.4.

Desarrollo del módulo FATFS asociado al SDIO, en parte por la falta deltimestamp a generar a través del módulo RTC.

Desarrollo de los módulos Display, ADC y Timer, aunque muchas funcionesde éste último se incorporan en FreeRTOS.

Desarrollo del módulo GPIO expandido via I2C.

5.2. Próximos pasos

Además de la implementación de los módulos faltantes indicados en la sección5.1, se pretende implementar un framework elemental (usando FreeRTOS como ba-se) como el estudiado e implementado en el trabajo final de la materia RTOS2 dela CESE con la utilización de la EDU-CIAA. Dicho elemento facilita enormementeel agregado de nuevos módulos y prestaciones, y puede ser un agregado de mu-cho interés para la continuidad del proyecto. Asimismo, se buscará incorporar elmodelado de sistemas reactivos utilizando las herramientas libres existentes. Porúltimo, se buscará avanzar en los siguientes puntos:

Desarrollo de un server http elemental integrado al módulo ESP de la pla-ca, conectado a la UART2, explorando su implementación a través del IDEArduino.

Desarrollo de un módulo de emulación de EEPROM vía Flash, que se utili-zará para el almacenado de constantes de calibración y otros ítems.

Incorporación de un bootloader que facilite la actualización del firmware.

49

Bibliografía

[1] IEC. IEC 61131-1:2003 Programmable controllers - Part 1: General information.Disponible: 2019-07-02. 2003. URL:https://webstore.iec.ch/publication/4550&preview=1.

[2] IEC. IEC 61131-2: Industrial-process measurement and control – Programmablecontrollers –Part 2: Equipment requirements and tests. Disponible: 2019-07-02.2017. URL: https://webstore.iec.ch/publication/31007&preview=1.

[3] IEC. IEC 61131-3: Programmable controllers - Part 3: Programming languages.Disponible: 2019-07-04. 2013. URL:https://webstore.iec.ch/publication/4552.

[4] VDC Research. IoT Forcing Embedded Boards and Systems Vendors to Adapt toSurvive. Disponible: 2018-06-15. 2016. URL:https://blog.vdcresearch.com/embedded_hw/current-affairs/.

[5] Proyecto CIAA. Computadora Industrial Abierta Argentina. Disponible:2016-06-25. 2014. URL:http://proyecto-ciaa.com.ar/devwiki/doku.php?id=start.

[6] LyR Ingenieria. Desarrollos AVR Cypress. Disponible: 2018-06-25. 2010. URL:http://www.lyr-ing.com/Embedded/LyRAVR_CySp.htm.

[7] Eric Pernia. sAPI - simple Application Programming Interface. Disponible:2019-06-05. 2019. URL: https://github.com/epernia/sAPI.

[8] LyR Ingenieria. Placa de CPU con arquitectura Atmel AVR: características de laCL2bm1 y periferico M4/E. Disponible: 2019-06-01. 2011. URL:http://www.lyr-ing.com/DocumentosLyR/CL2bm1/CL2bm1_caracteristicas_v3.pdf.

[9] Dimitri van Heesch. Doxygen: Generate documentation from source code.Disponible: 2019-07-02. 1997. URL: http://www.doxygen.nl/.

[10] ST Microelectronics. STM32F411RE: High-performance access line, ARMCortex-M4 core with DSP and FPU, 512 Kbytes Flash, 100 MHz CPU, ARTAccelerator. Disponible: 2017-06-05. URL: https://www.st.com/en/microcontrollers-microprocessors/stm32f411re.html.

[11] AC6. AC6 System Workbench STM32 IDE. Disponible: 2019-06-30. 2016.URL: http://www.ac6-tools.com/content.php/content_SW4MCU/lang_en_GB.xphp.

[12] ST Microelectronics. STM32 Cube IDE. Disponible: 2019-06-30. 2019. URL:https://www.st.com/content/st_com/en/products/development-tools/software-development-tools/stm32-software-development-tools/stm32-ides/stm32cubeide.html.

[13] Texas Instruments. TPS54302 4.5-V to 28-V Input, 3-A Output,EMI FriendlySynchronous Step-Down Converter. Disponible: 2017-06-30. 2016. URL:http://www.ti.com/lit/gpn/TPS54302.

[14] ELM Chan. FatFs - Generic FAT Filesystem Module. Disponible: 2019-06-30.2018. URL: http://elm-chan.org/fsw/ff/00index_e.html.

[15] ST Microelectronics. ST Microelectronics. Disponible: 2019-06-05. URL:https://www.st.com/content/st_com/en.html.

50 Bibliografía

[16] Richard Barry. Free RTOS. Disponible: 2019-06-05. URL:https://www.freertos.org/.

[17] Rafael Oliva. CESE Trabajo Final R.Oliva 2019. Disponible: 2019-08-05. URL:https://github.com/rafaeloliva/CESE_TrabFinal2019.

[18] OpenLib.org. LibOpenCM3 - Open Library. Disponible: 2019-03-10. URL:https://libopencm3.org/.

[19] ST Microelectronics. ST UM1725 User Manual / Description of STM32F4HAL and LL drivers. Disponible: 2019-06-15. URL:https://www.st.com/resource/en/user_manual/dm00105879.pdf.

[20] GrammaTech. CodeSonar SAST. Disponible: 2019-03-15. URL:https://www.grammatech.com/products/codesonar.

[21] MISRA - The Motor Industry Software Reliability Association. MISRA C2004. Disponible: 2019-03-15. URL:https://es.wikipedia.org/wiki/MISRA_C.

[22] Rafael Oliva. RTOS1 Trabajo Final R.Oliva 04-2019. Disponible: 2019-05-10.URL: https://github.com/rafaeloliva/CESE_RTOS1_TPFinal.