Del traductor: Librem 5 (en render): un teléfono inteligente seguro para Linux de Purism, que se crea en el hardware y software más abierto debido al crowdfunding .

Hoy hablaremos sobre el desarrollo del Kit para desarrolladores de Librem 5 y cómo utilizamos solo software 100% gratuito en su desarrollo.

El diseño de devkit se publica bajo los términos de la licencia GNU GPLv3 +, el repositorio de hardware de Git está aquí .

KiCad: la elección obvia para EDA

Antes de comenzar el desarrollo, no estaba claro de qué manera desarrollar el proyecto. En particular, qué herramienta elegir para la automatización del diseño electrónico (EDA) . Inicialmente, la idea era cambiar la placa i.MX 6QP OpenRex de FEDEVEL para cumplir con todos los requisitos para el devkit, pero inmediatamente enfrentamos dos problemas principales: el procesador i.MX 6QP se utilizó allí, y lo que es peor, la placa se desarrolló en el sistema patentado Altium . Afortunadamente, ya tenía experiencia en el diseño de dispositivos electrónicos con EDA KiCad, por lo que logramos crear un diseño de dispositivo con software 100% gratuito.

KiCad es una opción obvia, no solo por la licencia gratuita (GNU GPLv3 +), sino también porque es un kit de diseño electrónico muy funcional que supera incluso algunas herramientas propietarias costosas.

Selección de componentes que cumplan los requisitos.

El primer paso en el desarrollo de devkit es encontrar componentes que cumplan con los requisitos identificados durante la campaña. Además de observar las especificaciones declaradas, al buscar componentes, decidimos agregar algunas campanas y silbatos adicionales; incluyendo:

• controlador de carga (BQ25896)
• Soporte de batería 18650 para batería opcional de iones de litio
• USB-C
• mini HDMI
• Controlador de tarjeta SD y ranura micro-SD (ya que el i.MX 8M solo tiene dos controladores uSDHC)
• Ethernet / RJ45
• códec de audio
• altavoz auricular
• el microfono
• Toma de auriculares CTIA / AHJ de 4 polos y 3,5 mm (con opción de micrófono incorporado y externo)
• Lector de tarjetas inteligentes GPG
• motor de vibración
• LED programable
• botones de volumen y encendido
• conmutadores de hardware y conmutador de modo de arranque
• memoria flash 16Mb SPI NOR
• reloj de tiempo real (RTC)

Según lo planeado, agregamos a través de agujeros para los contactos de depuración de UART que no están ocupados de forma predeterminada (la serie a través de USB se ejecuta en la imagen predeterminada que viene con el devkit). Sugerencia: si no le gusta soldar, entonces el encabezado admite ajuste a presión, busque el número de pieza de Autosplice 23-1063. En el tablero hay una superficie de soporte SMD 2 × 5 JTAG, y su funcionalidad ha sido probada en el prototipo; Si está interesado en jugar, busque el número de pieza GRPB052VWQS-RC.

Para el módem WWAN / baseband y WiFi + BT, estaba claro que necesita encontrar algunos módulos listos, por ejemplo, con montaje en superficie. En una etapa temprana, Nicole tuvo la brillante idea de usar los módulos mPCIe y M.2 para que los devkits se vuelvan modulares, con la posibilidad de una actualización en el futuro. Al final, nos instalamos en el módulo de módem mPCIe SIMCom SIM7100A / E y el módulo M.2 RedPine RS9116 Wi-Fi + BT.

Empezar a dibujar

Al final de la fase de investigación, debemos comenzar a implementar nuestras ideas. El procesador i.MX 8M Quad acaba de aparecer en el mercado. Para obtener un gran avance desde el comienzo en el desarrollo, así como agregar modularidad y la posibilidad de futuras actualizaciones, hemos elegido la opción de sistema en módulo (SOM) , que incluye SoC, SDRAM, eMMC y PMIC. Pero incluso en las primeras etapas de desarrollo, cuando recién comenzábamos a dibujar diagramas, la producción en serie de algunos de los SOM que nos interesaban aún no había comenzado. A mediados de abril, establecimos buenas relaciones con EmCraft, que acababa de embarcarse en el primer ciclo importante de producción de SOM y estaba cerca de lanzar una especificación de arquitectura de hardware. Decidimos que el SOM de EmCraft y sus recursos son exactamente lo que necesitamos. Tan pronto como se seleccionó un SOM específico, inmediatamente comenzamos a dibujar diagramas.

El proceso de selección de componentes específicos para devkit se llevó a cabo simultáneamente con la preparación de esquemas. Todo el trabajo se realizó en el sistema de control de versiones Git.


Fig. 1. Revisión temprana del esquema del 2 de mayo (hash del git commit 023915d5)

Al completar los esquemas, exportamos el archivo netlist , lo que nos acercó significativamente a la implementación de devkit en la vida.

Modelado de HP_DET

Además de KiCad, desde el software gratuito también utilizamos una herramienta llamada Qucs-S y una herramienta de emulación Xyce compatible con SPICE para emular un chip sensor de auriculares, que incluye un diodo zener para proteger el GPIO correspondiente del voltaje de entrada demasiado alto o demasiado bajo emitiendo HP DAC de códec de audio La combinación de Qucs-S y Xyce hizo posible utilizar el modelo MMS-SP4 del diodo MMSZ4688T1G en el chip , que representa mejor el estado físico del conector en blanco de 3,5 mm con HP DAC activo simultáneamente.


Fig. 2. Modelado del esquema HP_DET usando Qucs-S y Xyce

Esta imitación, así como una simple caja de CC, donde el interruptor interno del conector de 3.5 mm está abierto y 1MΩ solo alcanza el voltaje predeterminado de 3V3_P, esto aseguró que el método de protección específico realmente funcione.

Crear sitios

A mediados de junio, completamos la compilación de la Lista de materiales (BOM) , comenzamos a hacer pedidos de componentes y comenzamos a crear los contornos de todos los sitios en el dispositivo (chips, conectores, módulos, etc.). Tomamos las características recomendadas de la documentación y cuatro veces verificamos que todo estaba correcto.


Fig. 3. La plataforma del controlador de carga BQ25896 (U301 en la placa de desarrollo, ubicada debajo del SOM)

En el sorprendente modo de visualización 3D de KiCad, creamos contornos tridimensionales de casi todos los componentes.


Fig. 4. Modelo 3D del controlador de carga BQ25896

Planificación, cableado y actualización de KiCad nivel por nivel

En la etapa inicial, se elaboró un plan de nivel aproximado para determinar rápidamente qué área del circuito integrado se utilizaría (90 × 180 mm) y dónde colocar los componentes más grandes (conectores, enchufes, ranuras para tarjetas, enchufes mPCIe y M.2, módulos, etc. d.). Después de la colocación en el tablero, algunos detalles aún se movieron, pero rápidamente se arreglaron en lugares específicos.

A finales de junio, comenzamos a cablear, comenzando con USB-C (commit a1bfc689). Esto marcó el comienzo de la creación de prototipos.


Fig. 5. Primero confirme con el cableado


Fig. 6. ¿Cuál fue el diseño de USB-C al final?


Fig. 7. Una versión temprana del circuito antes de colocar los componentes y el cableado.

El proceso de cableado requirió un delicado equilibrio entre la velocidad de trabajo y la verificación de que todo se hizo correctamente sin errores, incluido el cableado cuidadoso de las pistas de control de resistencia y las líneas analógicas sensibles.

Inicialmente, no había certeza de cuántas capas se necesitaban y si los componentes debían colocarse en ambos lados del tablero. Sabíamos que la placa i.MX 8M tenía ocho capas y componentes en ambos lados, pero estábamos seguros de que podíamos reducir la cantidad de capas. Rápidamente nos dimos cuenta de que en el reverso de la placa definitivamente tendrá que colocar componentes, porque en el teléfono algunos módulos se encuentran en la parte "posterior" de la placa (lado de la pantalla), incluidos los conectores de pantalla, sensor de proximidad / luz, LED programable, altavoz y micrófono. La presencia de componentes en ambos lados hizo que el proceso de diseño fuera un poco más fácil, ya que liberó un poco de espacio donde puede colocar la memoria flash SPI NOR, el lector de tarjetas, RTC, LDO 2.8V, varios circuitos integrados y otros componentes. En cuanto al número de capas, decidimos reducirlo a seis. Decidimos agregar dos capas adicionales más solo si nos quedamos atrapados en un callejón sin salida y no podemos colocar ninguna cadena. Afortunadamente, esto no sucedió y hubo un diseño de seis capas.

Decidimos usar un diseño común que proporciona un equilibrio óptimo entre la facilidad de cableado y reduce las emisiones no intencionales. Como sustrato dieléctrico, utilizamos laminado con lámina de cobre NP-180TL de NAN YA, que tiene una permitividad relativa de aproximadamente 4.11 a nuestra frecuencia de operación promedio de aproximadamente 1.7 GHz. Nuestros cálculos de la línea de alimentación de RF para líneas de alimentación de placas de guía de ondas microscópicas y coplanares (CPW) que utilizan esta disposición se pueden encontrar en el repositorio de Git.


Fig. 8: Diseño de capas devkit

Antes de implementar devkit en KiCad, no sabíamos si lanzar versiones alfa o seguir las versiones clásicas más estables como 4.0.7. Aunque las "compilaciones nocturnas" tienen varias características útiles, aún así decidimos mantener versiones estables para no tener que actualizar KiCad con frecuencia y arriesgarnos a la aparición de varias versiones simultáneas.

Cuando comenzamos a trabajar, se lanzó KiCad versión 5.0.0. El 16 de julio, actualizamos el proyecto a KiCad 5.0.0 (en particular, las confirmaciones 4f70b865 y a4e3de8a) sin ningún problema. Afortunadamente, esta actualización coincidió con la transición de la mayoría de nuestros componentes pasivos de 0603 a 0402, ya que las nuevas almohadillas en KiCad son ligeramente diferentes de los valores predeterminados antiguos, y las almohadillas tienen esquinas redondeadas que son más efectivas para la soldadura sin plomo.

Después de actualizar a 5.0.0, nos enfocamos en la creación de prototipos, y en un mes (es decir, el 14 de agosto con una confirmación de 9b4dd2e0) redujo a cero el número de circuitos sin diluir.


Fig. 9: El candidato de lanzamiento del 14 de agosto con confirmación 9b4dd2e0 registró un número cero de circuitos sin diluir

Después de completar el diseño y verificar la verificación de reglas de diseño (DRC), limpiamos el diseño durante una semana.

Al crear prototipos de una placa, los recursos más útiles fueron una guía de referencia para crear prototipos de circuitos integrados a partir de documentación oficial y una guía de creación de prototipos de Toradex .


Fig. 10. Diseño final (las áreas recubiertas de cobre están ocultas)

Exportar archivos y enviar a producción

Una vez que se completó el diseño, fue necesario exportar todos los archivos necesarios para la producción y montaje de tableros. Exportar archivos Gerber a KiCad es bastante simple. Sin embargo, el contratista solicitó otro esquema y diseño para el ensamblaje, lo que requirió cierto esfuerzo.

Para exportar archivos de vista previa, usualmente usamos Gerbv de gEDA. Así es como se ve nuestro devkit en Gerblook: esta herramienta utiliza Gerbv e ImageMagick para la representación web.


Fig. 11. Archivos devkit de Gerber cuando se ven en Gerbv

Para crear el dibujo del tipo deseado, utilizamos las capas F.Fab / B.Fab. Muestran las ubicaciones, los contornos, la polaridad y los símbolos de referencia de todos los componentes en el tablero. Usando las capas F / B.Fab para cada sitio, pudimos crear el dibujo final imprimiendo F.Fab y B.Fab en archivos PDF separados, y luego combinándolos en un documento.


Fig. 12. Esquema del SOM

Aún más tuvo que trabajar en un esquema de producción. Para hacer esto, tenía que exportar notas desde la capa Cmts.User junto con la placa de circuito como un archivo DXF, y luego exportar todas las marcas para perforar agujeros como otro archivo DXF. Después de crear estos dos archivos, se combinan en el dibujo de todo el sitio (huella). Después de recibir esta "huella" especial, que combina dos archivos DXF, ocultamos casi todo en el diseño e importamos esta huella especial "para la fábrica" ​​(sin guardar el diseño temporal). Por el momento, todo lo que necesita está en la capa Dwgs.User; por lo tanto, puede imprimirlo junto con el marco en el PDF final para producción.


Fig. 13. Etiquetas para perforar agujeros

Junto con todos estos archivos y documentos, se utiliza la lista de conexiones IPC-D-356, con la cual la planta puede realizar una prueba utilizando el método de "sonda voladora" y verificar que no haya corto circuito o circuito abierto. También preparamos un archivo CSV (para que la fábrica sepa dónde colocar y cómo orientar todos los componentes) y, finalmente, un archivo GenCAD editado manualmente (para programar un robot de soldadura de fábrica).

Prueba de prototipo

Enviamos los archivos finales para producción, respondimos todas las preguntas del contratista y cambiamos todo lo que pedían. Los archivos se enviaron a fines de agosto, y estábamos ansiosos cuando nuestro diseño llegó a la línea de ensamblaje en Shenzhen. Desafortunadamente, como dijimos en el blog , se produjeron retrasos significativos en la producción de prototipos debido a circunstancias imprevistas, como el clima severo y la Semana Dorada [fiesta nacional en China - aprox. trans.]. Debido a estos retrasos, decidimos ordenar la producción de prototipos en una planta doméstica, que nos entregó tableros dos semanas más rápido que los chinos.


Fig. 14. El panel prototipo devkita v0.1.2 (antes del ensamblaje)

Después de ensamblar un pequeño lote de prototipos, se enviaron rápidamente a nuestros ingenieros para su depuración y desarrollo de software. Afortunadamente, gracias a la discusión pública y un análisis exhaustivo del diseño, hubo muy pocos errores en el hardware (tres ajustes relativamente menores en el diseño / lista de circuitos y un arreglo mecánico). Durante los siguientes dos meses, se utilizaron prototipos para pulir el software.

Producción final y entrega

A principios y mediados de noviembre, después de realizar pequeños ajustes en el diseño y verificar casi todos los subsistemas de hardware, reexportamos y volvimos a publicar los archivos para la producción y el ensamblaje final. Algunos de nuestros empleados pasaron del 10 al 22 de diciembre, ayudando con el montaje, las pruebas, el empaque y el envío de kits a nuestros panaderos (¡muchos entregados antes de Navidad!)


Fig. 15. La vista final del panel devkit v1.0.0 (antes del ensamblaje)



Fig. 16. Devkit completamente ensamblado en comparación con el modelo 3D (lado de la pantalla)




Fig. 17. Devkit completamente ensamblado en comparación con el modelo 3D (lado SOM)

Todo el proceso requirió mucho esfuerzo, pero valió la pena. Especialmente cuando vimos cuán fructífera puede la comunidad usar los resultados de nuestro trabajo. Algunos ya han comenzado a desarrollar cajas impresas en 3D para devkita. ¡Estoy ansioso por ver qué software genial y qué casos de uso se te ocurrirán para estos tableros increíbles! Siéntase libre de informar todas las cosas interesantes por correo electrónico a feedback@puri.sm . Si es realmente excelente, hablaremos sobre su desarrollo en futuras publicaciones de blog.

Ahora siempre gastamos en enviar teléfonos Librem 5. ¡Así que hasta la próxima vez, no pierdas tu ingenio!