[ad_1]
En la Parte 1 de esta serie, presentamos el proyecto Anthill Controller y analizamos los beneficios de hacer que su hardware sea de código abierto. En la Parte 2 veremos más de cerca lo que implica la certificación de código abierto. El objetivo es doble: aclarar el proceso de certificación para los diseñadores y explicar qué hace que un proyecto sea certificable de código abierto. Empezaremos por este último.
¿Qué hace que un proyecto sea de código abierto?
La Open Source Hardware Association (OSHWA) define «hardware de código abierto» en detalle en su sitio web. Sin embargo, esencialmente un proyecto de hardware necesita dos cosas para ser considerado de código abierto:
- Documentación disponible públicamente.
- Una licencia de código abierto correspondiente.
Independientemente de la definición de hardware de código abierto, OSHWA recomienda que los proyectos incluyan cuatro elementos básicos:
- Hardware.
- Software.
- Documentación.
- Marca.
De estos, sólo el hardware y la documentación son obligatorios para obtener la certificación de hardware de código abierto (Figura 1). Si no se incluye ningún software, «Documentación» se refiere únicamente a la documentación del hardware. En cualquier caso, la documentación deberá tener una licencia de código abierto tal y como se define anteriormente. Cubriremos las licencias más adelante en este artículo.
Ilustración 1. Placa controladora Anthilla con certificación de hardware de código abierto (abajo a la derecha).
Para Anthill Controller, decidimos renunciar a incluir software en el repositorio de archivos o en la licencia. AnthC es una plataforma de hardware de IoT flexible, por lo que el código de software difiere según la aplicación; proporcionar y mantener un código específico no ayudaría a la mayoría de los usuarios. Sin embargo, es posible que en el futuro se cargue código para probar funciones básicas y verificar el ensamblaje de una nueva placa.
Lo que queda es la documentación del hardware, que se puede dividir en tres categorías:
- El diagrama del circuito.
- Archivos de fabricación.
- Archivos de montaje.
Juntos, estos permiten que una nueva persona replique o mantenga el proyecto. Analizaremos cada una de estas categorías individualmente, junto con la importancia de la documentación en general, en la siguiente sección.
documentación
Es una trampa común creer que una vez que el producto comienza a funcionar, no es necesario hacer nada. La documentación es tan importante como la fase de diseño, y una documentación bien organizada hace que un proyecto sea accesible y popular.
Compartir la documentación del proyecto es uno de los principales requisitos para certificar un proyecto como código abierto. Una vez compartidos los archivos, otra persona puede usarlos para replicar el proyecto, reparar el producto o simplemente como herramienta de aprendizaje. Es importante que esta transferencia de información se produzca sin la intervención del creador del proyecto.
Como se mencionó anteriormente, la documentación de hardware de código abierto debe incluir archivos de fabricación, archivos de ensamblaje y un esquema.
El diagrama del circuito
El diagrama del circuito electrónico describe las conexiones lógicas entre los elementos de la placa. Es útil tanto para comprender el objetivo de un sistema como para aprender partes específicas del diseño electrónico. Dado que es posible que los lectores no tengan la herramienta de diseño adecuada, se recomienda crear un PDF con todas las hojas esquemáticas.
El esquema debe ser legible para los recién llegados al proyecto, por lo que debe estar bien organizado y ser claro. La Figura 2 muestra los diagramas esquemáticos del controlador Anthill. Tenga en cuenta que las diferentes áreas funcionales están divididas en bloques para que sean fáciles de encontrar.
Figura 2. Diagrama de cableado del controlador Anthill M2-R3.
Archivos de fabricación
Los archivos de fabricación se utilizan para replicar la placa de circuito. Los fabricantes no necesitan los archivos CAD nativos que generamos con KiCAD. En cambio, utilizan un conjunto específico de archivos generados a partir de archivos nativos. Estos pueden ser:
Los archivos de fabricación del controlador Anthill están formateados como archivos Gerber y Bohr. Son fáciles de crear con KiCAD y, por lo tanto, son una opción común.
Archivos de ensamblaje
Los archivos de ensamblaje se utilizan para completar la construcción del proyecto especificando qué componentes exactos deben montarse en el tablero. En las primeras etapas de desarrollo, también ayudan a estimar el precio y el tiempo de entrega. Estos archivos incluyen:
- La lista de piezas: enumera todos los componentes.
- El archivo de escoger y colocar: muestra dónde y en qué componentes de orientación deben colocarse.
Ahora que hemos cubierto la documentación, hablemos de licencias.
Licencia
Los proyectos de código abierto son para compartir. Una licencia de código abierto define los parámetros de este intercambio al decirles a otros cómo se puede utilizar su propiedad intelectual (IP). Elija su licencia con cuidado: un error en este caso puede tener un impacto significativo en el proyecto, especialmente si es necesario proteger intereses comerciales específicos.
No es necesario utilizar una única licencia para todo el proyecto: es posible utilizar una licencia para el hardware, otra licencia para la documentación y una tercera para el software (si corresponde). La AnthC ha decidido las siguientes licencias:
Nuestro objetivo principal al obtener la licencia del controlador Anthill fue garantizar que el controlador pueda ser utilizado por la mayor cantidad de personas posible. También queríamos que los productos futuros que incluyeran el controlador fueran accesibles. Finalmente, asumimos que el software cambiaría a medida que el controlador se personalizara para cada aplicación. Con estos objetivos y expectativas en mente, seleccionamos las licencias de AnthC.
La licencia de hardware abierto (OHL) del CERN se utiliza ampliamente en la comunidad de código abierto. Como sugiere el nombre, está diseñado específicamente para proyectos de hardware. Hay tres subclases de esta Licencia:
- Fuertemente recíproco (CERN-OHL-S): Alguien que utilice su producto debe distribuir productos posteriores bajo el mismo tipo de licencia.
- Débilmente recíproco (CERN-OHL-W): Alguien que utilice su producto no está obligado a distribuir los componentes restantes (no incluidos en su proyecto original) bajo el mismo tipo de licencia.
- Recíproco permisivo (CERN-OHL-P): No existe obligación de revelar fuentes al enviar su producto.
Como se mencionó anteriormente, elegimos la versión débilmente recíproca de la licencia. Esta es una licencia copyleft, lo que significa que los proyectos derivados (basados en el proyecto licenciado) deben publicarse bajo la misma licencia que el proyecto original. porque es solo débil Por el contrario, esto sólo se aplica si el nuevo proyecto cambia directamente el AnthC. El AnthC se puede utilizar como parte de proyectos nuevos que no sean de código abierto.
Para nuestra documentación, elegimos una licencia Creative Commons permisiva, que pone nuestros archivos en el dominio público. Aunque no hemos licenciado ningún software para AnthC, también se suelen utilizar licencias Creative Commons para este fin.
Próximos pasos
En esta etapa el proyecto es estable: la documentación está versionada y todos los archivos de hardware están congelados. En la Parte 3 analizamos las pruebas de productos y el proceso de fabricación. También hablaremos de algunos desafíos relacionados con la obsolescencia de componentes que han surgido en este punto.
Nota editorial: El desarrollo inicial, las pruebas y la fabricación del controlador Anthill fueron posibles gracias a la financiación de Anthill, pero la empresa no participa actualmente en el proyecto. Ni All About Circuits ni el autor de este artículo reciben ningún beneficio financiero de Anthill por publicar el artículo.
Todas las imágenes utilizadas son cortesía de Ignacio de Mendizábal.
[ad_2]