DC Load New Brain

Este proyecto consiste en un cambio de microcontrolador para la carga electrónica hecha anteriormente. Se pasa de un Atmega 328p (8bits a 16 Mhz) a un Cortex-M0+ (32bits a 48 Mhz). Con él se pretende mejorar y añadir algunas características a la carga electrónica a la vez que se aprenden cosas nuevas.

De hecho, bastantes cosas, ya que se ha decidido cambia a NXP, por lo que se usa un IDE diferente y el SDK del fabricante. También se se pasa de un firmware basado en Arduino con multitud de librerías en C++, a un RTOS nuevo (FreeRTOS, en el proyecto del panel de control ya se utilizó otro RTOS, ChibiOS), donde no hay ninguna librería aparte de las necesarias para utilizar los periféricos del microcontrolador, y se programa todo desde cero en C.

También se han añadido herramientas para la mejorar la calidad del firmware, como un analizador estático de código, un visor en tiempo real para ver el comportamiento del sistema, y se intenta seguir con algunas directrices del estándar MISRA C de 2012. De todo esto se hablará con un poco más de detalle a lo largo de este artículo.

Frontal de la PCB principal.

Características añadidas a la carga electrónica:

• Se reescribe todo en C usando FreeRTOS.
• El algoritmo de compensación de corriente es mucho más rápido y eficiente.
• Se utilizan múltiples rangos a la hora de calibrar la carga con lo que se consigue más precisión. (Se pasa de ± 5 mV de error en tensión a ± 2 mV)
• Mejora de tiempo entre transiciones en el modo transient. (10-99.999ms)
• Se añade un zumbador con posibilidad de desconexión.
• En el menú de Set-Up se comprueba si se superan los límites de la carga.
• Se desactiva la carga al cambiar de modo de operación.
• Se añade capacidad de definir tiempos de subida y bajada para la corriente. (En mA/ms).
• Se añade soporte para tarjeta SD, permitiendo guardar logs.
• Se usa el RTC del micro para añadir fecha y hora a los logs.
• Se añade batería para poder terminar la escritura en la SD en caso de fallo de alimentación, y evitar que el sistema de archivos FAT32 se corrompa.
• Se añade posibilidad de cargar el firmware por USB.
• No permite conectar la carga si se detecta conexión USB. (Para evitar referenciar a tierra y posibles fugas).
• Se añade capacidad de detener la descarga de un batería al llegar a unos mAh indicados.
• La lectura de resistencia interna permanece en pantalla hasta la pulsación de un botón.
• Se añade protección contra sobrecorriente.
• Se añade un watchdog para reiniciar el micro en caso de bloqueo del mismo.
• Se añade protección de offset. (Si existe un voltaje o corriente superior a 1mV o 2mA al arrancar, no deja continuar. Ya que la diferencia puede ocasionar que el ADC no llegue al final de escala y las protecciones de máxima corriente y máximo voltaje no funcionarían.)

 Especificaciones anteriores de la carga:

• Potencia máxima: 300 W.
• Amperaje máximo: 15 A.
• Voltaje máximo: 100V.
• Modo de corriente constante.
• Modo de potencia constante.
• Modo de resistencia constante.
• Modo de transición. (Cambio entre dos valores de carga cada cierto tiempo).
• Medición de la resistencia interna de una batería.
• Medición de la capacidad de una batería en Ah.
• Error de lectura en tensión de ± 5 mV aprox.
• Error de lectura en corriente de ± 4 mA aprox.
• Protección por límite de corriente.
• Protección por límite de potencia.
• Protección por límite de voltaje.
• Protección por límite de temperatura.
• Control automático de los ventiladores.
• Control de temperatura y circuito de control de corriente independiente para cada mosfet.
• Capacidad de desconectar la carga físicamente (relés), para protección contra polaridad inversa y cuando se rebasa cualquier límite (temperatura, voltaje, potencia o intensidad).
• Fusibles en la salida en caso de fallo en la electrónica.
• Lectura de voltaje independiente (4 Wire). 

Al igual que los proyectos anteriores, todos los programas y librerías utilizados son gratuitos y en su mayoría opensource. Dejo una relación de los mismos junto con su página web.

• Diseño PCB: KiCad. 
• IDE de programación: MCUXpresso.
• Visor de sucesos en el sistema: SystemView.
• Visor de logs: Glogg.
• Creación de gráficas: LibreOffice Calc.
• Análisis estático: Cppcheck.
• Software para analizador lógico: Sigrok.

Todos los ficheros utilizados: esquemáticos, firmware, PCB, etc..., se encuentran disponibles en el siguiente repositorio: DC Load NewBrain. Pertenecen a la versión 1.1, donde se han corregido los errores detectados en la versión 1.0.

 

Esquema y PCB

El esquema del circuito se encuentra dividido en tres partes, cada una correspondiente a una pcb distinta. Una es la placa principal con el microcontrolador, otra con el USB y tarjeta SD, y la última tiene la misma forma que el Arduino Nano utilizado anteriormente y sirve para conectar el hardware antiguo con la nueva placa. También hay una pequeña placa para situarla en frontal e incluye varios botones y las ranuras para la SD y el puerto USB.

Esquema principal de la PCB

 El esquema completo se encuentra en PDF en el repositorio.

Frontal PCB principal v1.0

Parte trasera PCB principal v1.0 (con zumbador y relé)

PCB para SD y USB v1.0

PCB que sustituye al Arduino Nano y PCB para frontal.

Durante la soldadura de los componentes se ha probado una punta para soldadura por arrastre (tiene forma de cuchara y permite que una gota de estaño permanezca en ella), que emula la soldadura por ola que se realiza en los hornos de soldadura. Con el fin de eliminar lo máximo posible el uso de la malla de desoldar, al quedar puentes entre los pines de integrados con poco espaciado entre pines.
Y con un poco de práctica se consigue soldar de una sola pasada sin un solo puente.

Conector SMD con 0.5mm de "pitch".

Microcontrolador con 0.5 mm de "pitch".

 

Desarrollo del firmware

Como se ha dicho al inicio de este artículo, se ha reescrito desde cero en C usando FreeRTOS. Con ello, aparte de aprender otro RTOS y otras herramientas de desarrollo, se consigue una separación de las distintas tareas que realiza el firmware, y es más sencillo modificar una sin que afecte a los tiempos de ejecución de otras, si lo comparamos con la versión anterior.

En el firmare de la placa anterior basada en Arduino Nano, si una tarea se modifica y necesita más tiempo de ejecución, hace que las tareas o funciones que se ejecutan después no tengan la misma periodicidad.

Tareas e interrupciones

Aunque como todo, también tiene inconvenientes, como la mayor dificultad a la hora de diseñar y depurar el firmware. Se ha pasado de un único hilo en la versión anterior, ha tener seis hilos de ejecución como se ve en la imagen superior.

El sistema utiliza cinco interrupciones externas, que se ven junto a un símbolo de un rayo.

• La primera detecta la introducción o retirada de una tarjeta SD o un cable USB.
• La segunda se utiliza para crear un pulso PWM que genera el sonido del zumbador.
• La tercera se encarga de marcar el tiempo para el RTOS y la genera FreeRTOS.
• La cuarta detecta el movimiento del encoder.
• La quinta detecta cambios en los pines del micro, donde están conectados botones e interruptores de la SD, como el bloqueo de escritura.

A continuación se encuentra el "scheduler", que organiza las tareas se van a ejecutar y controla el tiempo asignado a ellas. Ya que utiliza un algoritmo "pre-emptive" (por derecho preferente). En el cual las tareas tienen una prioridad asignada, y si una tarea de mayor prioridad está lista para ejecutarse se interrumpe otra tarea de menos prioridad, continuando su ejecución una vez que las tareas con mayor prioridad hayan terminado. Para una descripción detallada mirar la documentación de FreeRTOS.

El resto de entradas de la imagen son las tareas o hilos de ejecución:

• La primera que se ve tiene prioridad 5, es la más importante, y es creada por FreeRTOS. Se encarga de controlar los temporizadores por software.
• La segunda tiene prioridad 4 y se encarga de leer el teclado de 16 teclas.
• La tercera tiene prioridad 3 y realiza la comprobación de las teclas pulsadas y su visualización en pantalla si fuera necesario. Básicamente, si se quiere introducir un dato, se le hace una petición a esta tarea y cuando se haya terminado de introducir esta devuelve el resultado, a la vez que lo puede ir mostrando en pantalla en la posición que se quiera.
• La cuarta  tiene prioridad 2 y se encarga de controlar la pantalla lcd. El resto de tareas le mandan comandos y el texto a mostrar mediante una cola, y esta tarea se encarga de ir mostrándolo en pantalla, ya que es la única con acceso al hardware.
• La quinta también tienen prioridad 2 y se encarga de la mayoría de la lógica del sistema.
• La última tarea tienen la mínima prioridad y es creada por FreeRTOS. Esta se ejecuta cuando ninguna otra tarea este lista para ejecución. En este firmware sirve principalmente para medir el tiempo en reposo de la CPU del microcontrolador.

Análisis estático

Casi al final del desarrollo se descubrió el programa Cppcheck. Que es una herramienta de análisis de código fuente capaz de encontrar problemas como comportamiento no definido (punteros muertos, división por cero, desbordamiento de enteros, ...) , construcciones de estructuras de código peligrosas, y en definitiva, encontrar errores en el código. Este tipo de herramientas ayudan a aumentar la calidad y seguridad del firmware, y si se incluyen addons, se pueden comprobar además determinadas normas o estándares.

Se han utilizado entre otros: cert.py que comprueba si se sigue el estándar de seguridad en programación CERT, misra.py que comprueba si se sigue el estándar MISRA C, de seguridad en sistemas críticos en tiempo real, y threadsafety.py que comprueba problemas relacionados con la programación multi-hilos.

De ellos, quizás el más importante para el desarrollo embebido es misra.py, ya que el estándar se utiliza como referente de seguridad en la industria del automóvil. Y adaptando las normas a seguir (es imposible cumplir con todas las normas, ya que son muy restrictivas en conjunto) según lo peligroso que pueda ser un fallo en una parte del código, se usan unas normas u otras.
El SDK de NXP también intenta cumplir con ciertas normas del estándar MISRA C 2012.

En el firmware del proyecto se encuentran las excepciones hechas en un archivo llamado suppressions.txt.

Hay que añadir que el programa informa de la norma (MISRA C) que se incumple, pero no da un mensaje descriptivo. Para ello hay que adquirir el libro desde la página oficial de la industria automovilística del Reino Unido, y pasando un script se extraen los mensajes. A parte, en el libro se explica el porqué de cada norma y se muestran ejemplos de código que cumple y que no cumple con cada norma. El precio del libro es de unos 15€ al cambio aproximadamente.

Analizador lógico

Otra herramienta, quizás la más importante a mi parecer, durante el desarrollo de sistemas digitales es el analizador lógico. Con él se pueden ver las señales digitales y decodificar los protocolos de comunicaciones en busca de errores.

Sirok PulseView descodificando protocolo SD SPI.

En la imagen superior se puede ver como se descodifica el protocolo SPI usado en la SD. Se pueden ver los comandos que se envían y reciben y averiguar cual es el que origina el fallo.

La captura fue tomada durante un problema con la inicialización de la tarjeta, en concreto fallaba al ejecutar el comando 16. Tras horas de depuración y búsqueda por internet se vio que el protocolo SPI, al no ser el principal utilizado por las SD, no recibe mucha atención por parte de los fabricantes y muchos no cumplen con las especificaciones. Se recomendaban las tarjetas SandDisk, y efectivamente, fue cambiar la marca del fabricante y la tarjeta se inicializó correctamente.

Inicialización a 400 Khz

Otro error que surgió fue el cambio de frecuencia del bus SPI una vez inicializada la tarjeta. Normalmente se utiliza una frecuencia de 400 Khz para la inicialización, y posteriormente se aumenta para alcanzar una mayor velocidad durante las operaciones con los archivos.
Gracias al analizador se pudo diagnosticar el problema y arreglar la función que lo originaba.

SPI en "fast mode"

Una vez corregido el problema, la tarjeta funciona correctamente a unos 8 Mhz como se ve en la imagen superior.

IDE de programación

Otra herramienta muy importante es el IDE utilizado para realizar el firmware, en este caso MCUXpresso de NXP, el cual tiene soporte para depurar firmwares que usan FreeRTOS.

Usos de las pilas en reposo.

En la imagen superior se puede ver como durante la depuración, al pausar la ejecución del microcontrolador, se muestra la utilización de las pilas (stacks) de cada tarea, el nombre de las tareas, el estado de las mismas (en ejecución, suspendidas, bloqueadas, etc), si esperan algún evento y el tiempo de ejecución. En este caso la tarea Idle se ejecuta casi el 98% del tiempo, lo que indica el procesador solo está usando el 2% de su capacidad aproximadamente.

Uso de las pilas en prueba de estrés.

En la imagen anterior se muestra el uso bajo condiciones de estrés. En ella se ve como algunas tareas aumentan el uso de la pila, pero no llegan a agotarla. Y se ve como el procesador utiliza un 9% de su capacidad.

Hay que destacar que para obtener toda esta información hay que compilar sin ninguna optimización, lo que conlleva ha aumentar considerablemente el espacio usado en memoria flash. Como recomendación, durante el desarrollo utilizaría un microcontrolador con el doble de la memoria flash prevista.

Uso de memoria dinámica.

Como se ve en la imagen, también se puede comprobar el uso de la memoria dinámica utilizada en el sistema.

Flash usada en modo "debug" sin SD.

En la imagen se ve como se utiliza el 96% de la memoria flash y el 87% de la RAM. Sin estar habilitado el código relacionado con la tarjeta SD, y usando optimización compatible con el modo debug. Ya que de lo contrario no cabría, aunque se pierden ciertas funcionalidades, como no poder ver los diferentes hilos de ejecución al pausar la CPU durante la depuración, o no poder ver los temporizadores de FreeRTOS.

Insuficiente flash en modo "debug" sin optimización y sin SD.

En la imagen anterior se puede ver el mensaje de error al tratar de quitar las optimizaciones. Se necesita casi un 22% más de memoria flash, y sin tener habitado ningún código de la SD. Con lo que se ha tenido que comentar y compilar partes del código para poder obtener la información necesaria durante la depuración. Un verdadero incordio, de hay la recomendación de adquirir el doble de flash de la necesaria.

También es necesario tener más memoria RAM por si se quieren utilizar otras herramientas como SystemView, o poder usar MTB (Micro Trace Buffer), que permite en los Cortex M0+ poder guardar información de la traza de ejecución en tiempo real en un buffer en la RAM.

Configurando MTB.

Se puede ver en la imagen superior como se puede configurar esta herramienta. Se pueden establecer direcciones de memoria que originan la recolecta de información, y otras que causan la terminación de la recolecta. También se puede configurar en modo circular, de modo que al llegar al límite del buffer se sobrescribe el principio, teniendo en caso de parada por un error, las últimas instrucciones ejecutadas.

Datos capturados (MTB)

En la imagen anterior se pueden ver las instrucciones en ensamblador descargadas del buffer del microcontrolador. Como se puede apreciar, se indica la función a la que pertenecen las instrucciones y al pinchar en una nos muestra la línea de código C a la que pertenece. Muy útil cuando ocurre un "hardfault", ya que es mucho más difícil saber la causa sin la ayuda de esta herramienta.

Uso de la flash y RAM con SystemView

Se pude observar el uso de la flash y RAM del código final optimizado en tamaño y con el código para usar SystemView. Se está muy cerca del límite del microcontrolador y no es aconsejable tener tan poco margen.

Una vez terminado el uso de SystemView, se puede desactivar y se obtiene el uso final de memoria en el microcontrolador.

Uso de flash y RAM final.

Como se puede ver, si no hubiera espacio no se podría haber utilizado la herramienta SystemView, que se comentará más adelante.

Al final tenemos en torno a un 10% de margen en ambas memorias. La estimación original de RAM y flash fue bastante acertada para la versión final del firmware, pero dio problemas durante la fase de desarrollo. La actualización del firmware por USB se realiza mediante el código en ROM que proporciona el fabricante, si se quisiera hacer algo más aparte con el USB no habría espacio.
Por lo que se vuelve a recomendar tener más memoria durante el desarrollo, de hecho, no se sabe muchas veces si las especificaciones van a cambiar durante el mismo. Por ello, recomendaría una vez elegido el microcontrolador, comprar el que tenga más memoria y posteriormente cuando esté terminado el firmware, optimizarlo en la medida de lo posible y adquirir la versión con la flash y RAM más cercana a la usada finalmente.

SystemView

Anteriormente se ha hablado del uso de este sistema durante el desarrollo del firmware. Ahora se va a mostrar en que consiste.

SystemView es un sistema desarrollado por SEGGER para poder visualizar lo que está sucediendo dentro de un sistema embebido en tiempo real. Para ello se utilizan unos archivos de código fuente que permiten sacar información del sistema y un programa de ordenador que decodifica y representa esos datos.

Esta herramienta es gratuita con ciertas limitaciones, solo puede grabar un millón de eventos y los mensajes que se obtienen no se pueden filtrar. Aunque se pueden paliar en cierto modo como se verá más adelante.

Para utilizar SystemView es necesario tener una herramienta de depuración por hardware con firmware Jlink. En este caso se utiliza una muy barata de NXP, el LPC-Link2 que ronda los 20€ y al tener un acuerdo de colaboración con SEGGER, permite carga un firmware Jlink.

Pantalla de SystemView

En la parte superior se tiene la ventana de eventos y la de terminal. En la de eventos se muestran las interrupciones, las tareas que se suspenden, las que están listas para ejecutar, cuando se escribe en una cola, cuando se lee, cuando se crea..., un montón de eventos relacionados con FreeRTOS en este caso. Y en la de terminal se muestran los mensajes enviados desde el microcontrolador, con distintos colores dependiendo de si son de información, advertencia o error. Estos mensajes son mucho más rápidos y eficientes que los mandados usando printf.

Debajo se encuentra la ventana de linea de tiempo, que permite ver las tareas y el tiempo en el que se ejecutan. Por ejemplo, de izquierda a derecha se ve en rojo que se ha ejecutado la interrupción Systick, a continuación se ve debajo como la tarea Tmr Svc está lista para ejecutar (todas las tareas listas para ejecutar se representan con el color gris), pero está en espera de que termine la rutina de interrupción.

Más abajo la tarea keypad_Reader también está lista. Y una vez se termina la ejecución de la interrupción, se ejecuta en negro el scheduler, que pone la tarea con más prioridad (Tmr Svc) en ejecución, en color morado. Cuando esta tarea termina se ejecuta la tarea keypad_Reader en color verde, y al terminar esta se ejecuta la tarea lcd_control. De esta manera se puede ver exactamente que se esta ejecutando en cada momento.

La siguiente ventana es la de carga de la CPU, en ella se ve el tiempo de procesamiento usado por las diferentes tareas e interrupciones en un espacio de tiempo configurable. En este caso se ven 50 unidades o bins de 40 us cada una, y durante este tiempo si miramos al principio, se ha ejecutado la rutina de interrupción Systick, más adelante durante todo el periodo de 40 us se han ejecutado: la tarea Tmr Svc, el scheduler y la interrupción Systick nuevamente. Con lo que el espacio en blanco representa el tiempo en el que no se ha hecho nada.

A continuación se encuentra la ventana de contextos, donde se ven todas las interrupciones y tareas que se están ejecutando, junto con estadísticas asociadas a las mismas. A su derecha la ventana de información del sistema, con el microcontrolador utilizado, el tiempo que está encendido, el tiempo de grabación, etc.

Para terminar se encuentra la ventana de log, y la barra de estado con el número de eventos capturados y el tiempo de grabación.

Forma de mitigar los límites de SystemView

Dado la limitada tasa de transferencia del LPC-Link2 y del firmware Jlink que incorpora, es imposible obtener los datos mostrados en su configuración por defecto, ya que el buffer se desborda constantemente y se pierden datos. Por ello, lo que se ha hecho es modificar los ficheros de SystemView relacionados con FreeRTOS y desactivar la captura de eventos que suceden con mucha frecuencia y no son necesarios en ese momento, como las escrituras y lecturas en las colas.

Utilizando selectivamente lo que se quiere capturar junto con el hecho de poder iniciar la captura y pararla cuando se quiera mediante código, permite capturar los datos vistos anteriormente y recudir el número de eventos, con lo que se puede grabar durante más tiempo.

En cuanto a no poder realizar búsquedas en la ventana de terminal, lo que se ha echo es modificar el código de SystemView para añadir "Err:" al comienzo de los mensajes de error y "Warn:" en los de advertencia. Después se han exportado los mensajes a un archivo de texto.

Capturando solo los mensajes.

En la imagen superior se puede ver como se han desactivado la captura de interrupciones y de las tareas, para proporcionar la mayor tasa de transferencia posible a los mensajes.
Una vez exportados los mensajes se utiliza un programa para visualización de logs.

Glogg

Mediante este programa se pueden asignar colores al texto y al fondo si cumplen ciertas expresiones regulares. De esta manera se consigue que los mensajes con el texto "Err:" tengan un fondo rojo y los que contienen "Warn:" un fondo amarillo. También se han asignado colores diferentes a cada tarea, ya que al exportar los datos nos muestra la tarea que originó cada mensaje. Además podemos ver el tiempo en que se originó el mensaje y podemos realizar búsquedas. Como se ve en la imagen, al buscar "SD" podemos ver el mensaje de error relacionado con la tarjeta SD. 

Uso de la CPU

Con la herramienta SystemView se puede ver el uso real de la CPU con el firmware compilado con optimizaciones, ya que SystemView está diseñado para tener un impacto mínimo en el rendimiento del sistema. Ahora si se puede sacar la información referente al impacto en la utilización del la CPU al estar la SD grabando datos continuamente .

En reposo (Idle)

Como se puede apreciar, en reposo se está utilizando el 3.5% de la CPU aproximadamente.

En estrés sin TT ni "slew rate"

En la imagen superior el sistema con el "logging" a la tarjeta SD funcionando a la máxima velocidad. Se está utilizado el 7.7% de la CPU.

En estrés con TT y sin "slew rate"

Ahora aparte de lo anterior,  el sistema está en un modo de transitorios (TT), cambiando continuamente entre dos corrientes cada 500ms, que es el tiempo mínimo en el que se refresca la pantalla, con lo que aumenta el uso del bus I2C.
El uso de la CPU es de un 7% aproximadamente, por lo que el modo TT no tiene prácticamente impacto en el uso de la CPU.

En estrés con TT y "slew rate"

Como última prueba de estrés, aparte de lo anterior se activa el modo "slew rate", el cual incrementa y decrementa los cambios de corriente de forma escalonada. Se configura a la velocidad más lenta, lo que implica el mayor número de comunicaciones hacia el DAC, una cada 4mA. Si lo sumamos a que sube y baja cada 500ms, se está en el caso de máximo estrés al que se le puede someter al sistema. El uso de la CPU es de un 29% aproximadamente.

Como se ha podido observar, apenas estamos utilizando la CPU durante un uso normal, siendo el microcontrolador más bajo de la gama ARM Cortex-M. Esto también es gracias al RTOS, ya que partes de la lógica del sistema están implementadas en temporizadores por software de FreeRTOS, que no hacen uso de la CPU hasta que llega la hora de ejecutarse.

Pruebas

Durante el proceso de pruebas y depuración

El proceso de pruebas ha sido bastante largo, ya que al implementarse todo desde cero, se han tenido que comprobar todas las funcionalidades anteriores además de las nuevas. A continuación se muestran algunas de las imágenes tomadas durante este proceso, al probar las nuevas funcionalidades. Para ver más imágenes de las pruebas de las funcionalidades anteriores, ver el último artículo de la construcción de la carga electrónica.

Con el programador y el analizador lógico conectados.

Interior una vez terminado el desarrollo.

En la imagen superior se puede ver como la nueva PCB principal va conectada a la electrónica anterior y a la placa con SD y USB mediante cable plano.

Midiendo la velocidad del aire con relación a la frecuencia PWM.

Se puede ver como se hicieron pruebas de diferentes frecuencias para la señal PWM, hasta dar con la frecuencia en la que se producía mayor flujo de aire. También se midieron las velocidades de aire a diferentes anchos de pulso.

Se seleccionó 100Hz como frecuencia para el PWM, y como puede verse, a partir de 1Khz la velocidad se reduce casi 3 veces.

Logging en la SD

Probando la desconexión de alimentación mientras se escribía en la SD.

En la imagen superior se ve como se detecta la pérdida de alimentación y se pasa a usar la pila de la placa, escribiendo el mensaje en la SD y poniendo el microcontrolador en modo de ahorro de energía.

Exportando datos de la SD a LibreOffice Calc.

En la imagen se ven los datos registrados mientras se usa una fuente de alimentación variable a modo de emulación de una batería. En el gráfico se muestra la descarga en mAh y la variación del voltaje. La carga se configuró para cortar al llegar a 50 mAh de descarga.

Añadida gráfica de potencia y corriente

En la imagen se ve añadida otra gráfica para mostrar los otros datos exportados, la corriente y la potencia. La carga se configuró para cortar a los 3V, para simular una batería de litio 1S.

Carga del firmware por USB

Carga conectada al PC por USB.

Adaptador para realizar un cable USB-A a USB-A

Cargando firmware con KinetisFlashTool.

 

Capturas de osciloscopio

Tiempo en fijar la salida (rutina que manda el valor al DAC).

Tiempo en mandar el mensaje por I2C.

Tiempo desde que se recibe la señal hasta que la salida alcanza el valor indicado.

Tiempo desde que se fija hasta que la salida llega a 1A.

Modo TT operando normalmente.

Modo TT con "slew rate" activado.

Detalle en modo TT con "slew rate". Tiempo de subida.

Detalle en modo TT con "slew rate". Tiempo de bajada.

En las dos imágenes anteriores, el canal 1 en amarillo representa la entrada y salida de la función encargada de hacer el "slew rate".

Caída de voltaje al cambiar de la alimentación principal a la batería.

Nuevos menús de la LCD.

A continuación se muestran los nuevos menús o pantallas añadidas al firmware. Para ver las anteriores, mirar el artículo sobre firmware de la carga electrónica.

Pantalla de inicio.

Menú para selección de modo.

Para configurar el corte por descarga en mAh.

Menú para activar el modo "fast mode".

El modo "FastMode" permite conmutar mucho más rápido en los modos de transitorios a cambio de no actualizar la pantalla.

En el menú de Setup se puede activar o desactivar el sonido.

Configuración del modo "slew rate".

Menú para el "logging" en la SD.

Vista del reloj y calendario.

Menú con las nuevas funciones de las teclas.

Estableciendo el tiempo entre escritura en la SD.

Activando/desactivando la SD.

Mensaje de advertencia al introducir una SD bloqueada.

Mensaje de error al tener voltaje en la entrada al arrancar el sistema.

Mensaje de advertencia de USB conectado.

 

Conclusiones

Una vez terminado el proyecto, y revisado el funcionamiento, se necesitarían hacer algunos cambios en torno a la circuitería de la batería. El firmware funciona correctamente y se ha probado que el cambio de alimentación funciona, pero consume bastante más de lo esperado. Sobre todo por las dos resistencias de pullup de los botones reset y boot que no tuve en cuenta durante el diseño inicial, y las pullups utilizadas en la circuitería de la SD. De volver a diseñar la PCB, seguramente elegiría unas resistencias mayores para los botones, pondría un mosfet para cortar toda alimentación a la circuitería de la SD una vez desmontada la tarjeta, y cambiaría la batería CR2032 por una pequeña de litio de una celda, junto con un circuito que la recargara mientras esté la alimentación principal conectada.

En cuanto a las herramientas, las voy a usar en todos mis proyectos futuros ya que ayudan enormemente durante el proceso de depuración, y ayudan a visualizar posibles problemas en el diseño del firmware.

La mayor pega durante el desarrollo ha sido la falta de librerías, sobre todo a la hora trabajar con la pantalla LCD, la interfaz de usurario básicamente. Hay librerías muy profesionales para ayudar a desarrollar interfaces (menús de forma jerárquica, por ejemplo) para pantallas gráficas, pero no para las basadas en caracteres (en lenguaje C). Por lo que para futuros proyectos intentaré utilizar una gráfica y seguramente la interfaz gustará más, tendrá más posibilidades y se tardará menos en desarrollar gracias a esas librerías.

Otro hecho de escribir todo el código en C, es que se incrementa considerablemente el código fuente a escribir, con lo que ello conlleva. Para un futuro también pienso en usar C++ para la lógica de la aplicación y ayudar a abstraerse más del hardware, a la vez que se usa C para el bajo nivel y poder utilizar el SDK de NXP para los periféricos y funciones que proporciona. Esto también ayuda a la hora de incorporar fácilmente librerías escritas en C++ para Arduino, y permite utilizar las bibliotecas estándar del lenguaje, que son muchos más extensas que las de C.

Como siempre, dar las gracias a quienes se han tomado el tiempo de leer este artículo, y recordar que el código fuente y los archivos de la PCB se encuentran en el repositorio.