jueves, septiembre 02, 2021

Herramientas: Fuente de Laboratorio (I)

Las fuentes de alimentación es uno de los elementos más importantes de un laboratorio: hay quien dicen que nunca se tienen suficientes fuentes... y es posible que tenga razón. Quien ha trabajado diseñando o probando circuitos muchas veces se encuentra con la necesidad de probar varias partes simulando señales con la propia fuente.

Para mi pequeño laboratorio que tengo en casa empecé con una fuente de alimentación realizada a partir de una fuente AT (salidas +-5V y +-12V), sin embargo me encontraba, en muchas ocasiones, que era insuficiente, ya que en muchas ocasiones no tenía controlada la corriente de salida (tenía que utilizar un multímetro para verla) y no tenía características básicas tales como limitar corriente o tener una tensión regulable.

Para tener una fuente regulada en tensión y limitada en corriente mi segunda opción fue utilizar un transformador de tensión comercial (una fuente de PC con salida de 12V 5A) y un módulo DP3003 que me ha hecho el trabajo hasta el día de hoy, sin embargo, uno nunca sabe cuando va a necesitar más... 

Por eso me he propuesto crear una fuente de laboratorio, regulable, con limitación de corriente y (muy importante) programable desde un PC.

Hoy en día es sencillo realizar esto con los convertidores de tensión que nos llegan desde china, así que como tenía una fuente ATX de mi ultimo ordenador decidí aprovechar todas las capacidades de la misma.

Al final ha quedado de la siguiente forma:
- Salida +12V con visualizador de tensión y corriente
- Salida +5V con visualizador de tensión y corriente
- Salida de +3.3V
- Salida de -12V
- Salida de -5V
- Salida regulada de 0 a 50V y corriente 0 a 5A con control manual y por puerto USB 


sábado, noviembre 07, 2020

Documentando (II): Control de versiones del código

Para el control de versiones de código se utiliza sistema basado en GIT (https://git-scm.com/).

Flujo de trabajo

La base del flujo de trabajo aquí expuesto es el sistema GITFLOW WORKFLOW. Este sistema define un modelo de ramificación estricto diseñado entorno al lanzamiento del proyecto y proporciona un marco robusto para la gestión de proyectos.



Visión general

La disposición de las ramas son las siguientes

  • master”: Una única rama donde se colocarán las versiones de producción (es decir, públicas).
    • Todos los “commits” en esta rama deben estar numerados con su versión correspondiente.
    • No se permite desarrollo, ni corrección de errores en esta rama.
    • Todos los “commits” de esta rama deben ser funcionales:
      • Su compilación no debe contener ni errores ni advertencias (“warning”).
      • Debe haber pasado el sistema de prueba sin ningún problema.
    • En esta rama no se desarrolla código, únicamente se puede hacer un “merge” con la rama máster desde las ramas de las carpetas “hotfix/” o “release/”.
  • develop”: Una única rama de desarrollo donde se colocarán las versiones de desarrollo.
    • Todos los “commits” de esta rama deben ser compilables:
      • Su compilación no debe contener ni errores ni advertencias “warning”).
      • Es recomendable que pasen un test funcional.
    • Todas las ramas deben hacer un “merge” a esta rama una vez que e ha terminado el desarrollo o solucionado el problema (“hotfix”).
    • Esta rama es de desarrollo y pueden contener errores, nunca entregar una versión de producción desde esta rama.
    • En esta rama no se desarrolla per se, sino que es donde van se juntan los desarrollos y corrección de errores realizados en el resto de ramas.
  • hotfix/”: Una carpeta donde se colocarán las ramas de corrección de errores de producción. Esta carpeta sirve para crear ramas donde se solucionan los errores no detectados por el sistema de prueba que han llegado a la rama “master”.
    • En estas ramas sólo se solucionan problemas que han aparecido en la rama “master”. No se añaden nuevas características.
    • Una rama nueva en esta carpeta debe implicar también un cambio en el sistema de prueba para detectar el error que no se había detectado antes.
    • Antes de realizar un “merge” a la rama “master” se debe asegurar que el firmware resultante sea funcional:
      • Su compilación no debe contener ni errores ni advertencias (“warning”).
      • Debe haber pasado el sistema de prueba (corregido) sin ningún problema.
    • Se realiza un “merge” adicional con la rama de “develop”, el “commits” resultante debe ser compilable:
      • Su compilación no debe contener ni errores ni advertencias (“warning”).
      • Es recomendable que se pase un test funcional
  • release/”: Una carpeta donde se colocarán as ramas de comprobación para generar una nueva versión de producción. Esta carpeta sirve para crear ramas donde se buscarán y solucionarán los errores del código antes de pasar a producción.
    • En estas ramas sólo se solucionan problemas que han aparecido en la rama “develop” antes de realizar un “merge” con la rama “master”. No se añaden nuevas características.
    • Antes de realizar un “merge” a la rama “master” se debe asegurar que el firmware resultante sea funcional:
      • Su compilación no debe contener ni errores ni advertencias (“warning”).
      • Debe haber pasado el sistema de prueba sin ningún problema.
    • Se realiza un “merge” adicional con la rama de “develop”, el “commits” resultante debe ser compilable:
      • Su compilación no debe contener ni errores ni advertencias (“warning”).
      • Es recomendable que se pase un test funcional.
  • feature/”: Una carpeta donde se colocarán las ramas de desarrollo para añadir una nueva característica o solucionar un problema encontrado durante el desarrollo.
    • En estas ramas se desarrolla o se solucionan problemas.
    • Las ramas dentro de esta carpeta son de desarrollo y pueden contener errores, nunca generar una versión de producción desde estas ramas.
    • Antes de realizar un “merge” a la rama “develop” se debe asegurar que el firmware resultante sea compilable:
      • Su compilación no debe contener ni errores ni advertencias (“warning”).
      • Es recomendable que se pase un test funcional.

Rama “master” y rama “develop”

Este flujo de trabajo usa dos ramas para registrar el historial del proyecto. La rama “master” almacena el historial de lanzamientos oficiales (firmware que ha pasado a producción), y la rama “develop” sirve como una rama de integración de características. 

La rama “develop” contendrá el historial completo del proyecto, mientras que la rama “master” contendrá una versión resumida. Es decir, las dos ramas se crean al inicio del proyecto y son paralelas.

Carpeta “features/”

Cada nueva característica debe residir en su propia rama, dentro de la carpeta “feature/”. Cada nueva rama de característica tiene siempre la rama “develop” como su rama principal. Cuando se completa el desarrollo de una característica se fusiona nuevamente en el desarrollo (rama “develop”).

Merge de “features/” en “develop”

Para añadir una nueva característica ya desarrollada en la rama “develop” se siguen los siguientes pasos:

  1. Comprobar que el nuevo código desarrollado compila sin errores ni advertencias (“warning”). A ser posible pasar un test automático en el código.
  2. Realizar un “merge” de la rama “develop” a la rama de desarrollo (“feature/…”).
  3. Corregir los conflictos surgidos en el “merge
  4. Comprobar que el código fusionado compila sin errores ni advertencias (“warning”). A ser posible pasar un test automático en el código.
  5. Realizar un “merge” de la rama de desarrollo (“feature/…”) a la rama “develop”.

Carpeta “release/”

Una vez que la rama “develop” ha adquirido suficientes funciones para un lanzamiento se bifurca una

La creación de esta rama inicia el siguiente ciclo de lanzamiento, por lo que no se pueden agregar nuevas características después de este punto, solo las correcciones de errores, la generación de documentación y otras tareas orientadas a la versión deben ir en esta rama. Una vez que está listo para enviar, la rama “release/…” se fusiona con “master” y se etiqueta con un número de versión. Además, debe fusionarse nuevamente con “develop”, lo que puede haber progresado desde que se inició el lanzamiento.

Merge de “release/” en “master”

Para generar una nueva versión de producción se sigue los siguientes pasos:

  1. Comprobar que el nuevo código desarrollado compila sin errores ni advertencias (“warning”).
  2. Realizar un test completo del código, incluyendo las funciones de actualización del firmware.
  3. Realizar un “merge” de la rama “release/…” a la rama de producción (“master”). No debería generar conflictos y si los genera todo se debe substituir con la rama de “release/…
  4. Cambiar el nombre del archivo .bin al número de versión (ej.: 1.1.1a.bin)
  5. Actualizar el firmware del producto y leer el código .hex
  6. Copiar los dos archivos (.bin y .hex) a la carpeta correspondiente dentro del árbol de carpetas.
  7. Realizar la fusión de la rama “release/…” con la rama “develop” y corregir los conflictos.

Merge de “release/” en “develop”

Hay que tener en cuenta que la rama “develop” puede haber progresado mientras se preparaba una nueva versión, por lo que para realizar la fusión de estas dos ramas habrá que seguir los siguientes pasos:

  1. Realizar un “merge” de la rama “develop” a la rama de preparación de la versión (“release/…”).
  2. Corregir los conflictos surgidos en el “merge
  3. Comprobar que el código fusionado compila sin errores ni advertencias (“warning”). A ser posible pasar un test automático en el código.
  4. Realizar un “merge” de la rama de desarrollo (“release/…”) a la rama “develop”.

Carpeta “hotfix/”

Esta carpeta se utiliza para el mantenimiento (corrección de errores) de la rama “master” y se utiliza para parchear de forma rápida las versiones de producción.

Todas las ramas de esta carpeta parten de una versión estable (versión de producción), es decir, de la rama “master”, y terminan en una segunda versión estable (con el número de versión actualizado) en la rama “master”, además se realizará un segundo “merge” con la rama de desarrollo (“develop”).

Etiquetado de la versión

Tanto la rama “master” como la rama “develop” deben seguir el mismo etiquetado de versiones, que será del tipo:

XX.YY.ZZaa

Donde:

  • XX corresponde al número de versión. Esta versión aumentará cuando haya un cambio de hardware o firmware suficientemente importante.
  • YY corresponde al número de subversión. Esta versión aumentará cada vez que haya un nuevo “commits” en la rama “master” desde la rama “release/…”.
  • ZZ corresponde al número de corrección.
  • aa corresponde al número de compilación. Este número aumentará cada vez que haya un nuevo “commits” en la rama “develop”.