Du traducteur: Librem 5 (sur le rendu) - un smartphone sécurisé pour Linux de Purism, qui est créé sur le matériel et les logiciels les plus ouverts grâce au crowdfunding .

Aujourd'hui, nous allons parler du développement du kit de développement Librem 5 et de la façon dont nous n'avons utilisé que 100% de logiciels libres dans son développement.

La conception de devkit est publiée sous les termes de la licence GNU GPLv3 +, le référentiel matériel Git est ici .

KiCad - le choix évident pour EDA

Avant de commencer le développement, il n'était pas clair de quelle manière développer le projet. En particulier, quel outil choisir pour l' automatisation de la conception électronique (EDA) . Initialement, l'idée était de changer la carte i.MX 6QP OpenRex de FEDEVEL pour répondre à toutes les exigences du devkit, mais nous avons immédiatement rencontré deux problèmes principaux: il utilisait le processeur archaïque i.MX 6QP, et pire encore, la carte a été développée dans le système propriétaire Altium . Heureusement, j'avais déjà de l'expérience en conception d'électronique à l'aide d'EDA KiCad, nous avons donc réussi à créer une conception de devkit en utilisant un logiciel 100% gratuit.

KiCad est un choix évident, non seulement à cause de la licence gratuite (GNU GPLv3 +), mais aussi parce que c'est un kit de conception électronique très fonctionnel qui surpasse même certains outils propriétaires coûteux.

Sélection de composants répondant aux exigences

La première étape du développement de devkit consiste à trouver des composants qui répondent aux exigences identifiées pendant la campagne. En plus de respecter les spécifications déclarées, lors de la recherche de composants, nous avons décidé d'ajouter quelques cloches et sifflets supplémentaires; dont:

• contrôleur de charge (BQ25896)
• Support de batterie 18650 pour batterie lithium-ion en option
• USB-C
• mini HDMI
• Contrôleur de carte SD et fente micro-SD (comme le i.MX 8M n'a que deux contrôleurs uSDHC)
• Ethernet / RJ45
• codec audio
• écouteur haut-parleur
• le microphone
• Prise casque CTIA / AHJ 3,5 mm 4 pôles (avec choix entre microphone intégré et microphone externe)
• Lecteur de carte à puce GPG
• moteur de vibration
• LED programmable
• boutons de volume et d'alimentation
• commutateurs matériels et commutateur de mode de démarrage
• mémoire flash 16 Mo SPI NOR
• horloge en temps réel (RTC)

Comme prévu, nous avons ajouté des trous de passage pour les contacts de débogage UART qui ne sont pas occupés par défaut (série sur USB s'exécute sur l'image par défaut fournie avec le devkit). Astuce: si vous n'aimez pas la soudure, l'en-tête prend en charge l'ajustement à la presse, recherchez le numéro de pièce Autosplice 23-1063. Sur la carte il y a une surface de support SMD 2 × 5 JTAG, et sa fonctionnalité a été testée sur le prototype; Si vous êtes intéressé à jouer, recherchez le numéro de pièce GRPB052VWQS-RC.

Pour le modem WWAN / bande de base et WiFi + BT, il était clair que vous devez trouver des modules prêts à l'emploi, par exemple, avec montage en surface. À un stade précoce, Nicole a eu la brillante idée d'utiliser les modules mPCIe et M.2 pour que les devkits deviennent modulaires, avec la possibilité d'une mise à niveau à l'avenir. Au final, nous nous sommes installés sur le module modem mPCIe SIMCom SIM7100A / E et le module Wi-Fi + BT M.2 RedPine RS9116.

Commencez à dessiner

À la fin de la phase de recherche, nous devrions commencer à mettre en œuvre nos idées. Le processeur i.MX 8M Quad vient d'apparaître sur le marché. Pour obtenir une percée dès le début du développement, ainsi que pour ajouter de la modularité et la possibilité de futures mises à jour, nous avons choisi l'option système sur module (SOM) , y compris SoC, SDRAM, eMMC et PMIC. Mais même aux premiers stades de développement, alors que nous commencions à peine à dessiner des diagrammes, la production en série de certaines des SOM qui nous intéressaient n'avait pas encore commencé. Vers la mi-avril, nous avons établi de bonnes relations avec EmCraft, qui venait de se lancer dans le premier grand cycle de production SOM et était sur le point de publier une spécification d'architecture matérielle. Nous avons décidé que le SOM d'EmCraft et ses ressources sont exactement ce dont nous avons besoin. Dès qu'un SOM spécifique a été sélectionné, nous avons immédiatement commencé à dessiner des diagrammes.

Le processus de sélection des composants spécifiques pour devkit a été effectué simultanément avec la préparation des schémas. Tous les travaux ont été effectués dans le système de contrôle de version Git.


Fig. 1. Révision précoce du schéma du 2 mai (hachage du git commit 023915d5)

Une fois les programmes terminés, nous avons exporté le fichier netlist , ce qui nous a considérablement rapprochés de la mise en œuvre de devkit dans la vie.

Modélisation HP_DET

En plus de KiCad, à partir d'un logiciel gratuit, nous avons également utilisé un outil appelé Qucs-S et un outil d' émulation Xyce compatible SPICE pour émuler une puce de capteur de casque, qui comprend une diode zener pour protéger le GPIO correspondant contre une tension d'entrée trop élevée ou trop faible lors de l'émission de HP DAC depuis codec audio. La combinaison de Qucs-S et Xyce a permis d'utiliser le modèle MMS-SP4 de la diode MMSZ4688T1G dans la puce , qui représente le mieux l'état physique du connecteur vide de 3,5 mm avec HP DAC simultanément actif.


Fig. 2. Modélisation du schéma HP_DET à l'aide de Qucs-S et Xyce

Cette imitation, ainsi qu'un simple boîtier CC, où l'interrupteur interne du connecteur 3,5 mm est ouvert et 1MΩ n'atteint que la tension par défaut de 3V3_P, cela a fait en sorte que la méthode de protection spécifique fonctionne vraiment.

Créer des sites

Vers la mi-juin, nous avons terminé la compilation de la liste des matériaux (BOM) , commencé à passer des commandes de composants et commencé à créer les contours de tous les sites de l'appareil (puces, connecteurs, modules, etc.). Nous avons pris les caractéristiques recommandées de la documentation et vérifié quatre fois que tout était correct.


Fig. 3. La plate-forme du contrôleur de charge BQ25896 (U301 sur la carte de développement, située sous le SOM)

Dans le superbe mode de visualisation 3D de KiCad, nous avons créé des contours tridimensionnels de presque tous les composants.


Fig. 4. Modèle 3D du contrôleur de charge BQ25896

Planification, câblage et mise à jour niveau par niveau de KiCad

Au début, un plan de niveau approximatif a été élaboré pour déterminer rapidement quelle zone du circuit intégré serait utilisée (90 × 180 mm) et où placer les composants les plus grands (connecteurs, prises, emplacements pour cartes, prises mPCIe et M.2, modules, etc.). . d.). Après le placement sur la planche à pain, certains détails ont toujours bougé, mais se sont rapidement fixés à des endroits spécifiques.

Fin juin, nous avons commencé le câblage, à commencer par USB-C (commit a1bfc689). Cela a marqué le début du prototypage.


Fig. 5. Commettez d'abord avec le câblage


Fig. 6. Quelle était finalement la disposition USB-C?


Fig. 7. Une première version du circuit avant de placer les composants et le câblage

Le processus de câblage a nécessité un équilibre délicat entre la vitesse de travail et la vérification que tout a été fait correctement sans erreurs, y compris un câblage soigné des pistes de contrôle de la résistance et des lignes analogiques sensibles.

Au départ, il n'y avait aucune certitude sur le nombre de couches nécessaires et si les composants devaient être placés des deux côtés de la carte. Nous savions que la carte i.MX 8M avait huit couches et composants des deux côtés, mais nous étions sûrs que nous pouvions réduire le nombre de couches. Nous avons rapidement réalisé que sur le côté arrière de la carte, vous devrez certainement placer des composants, car sur le téléphone, certains modules sont situés à l'arrière de la carte (côté écran), y compris les connecteurs d'affichage, le capteur de proximité / lumière, la LED programmable, le haut-parleur et le microphone. La présence de composants des deux côtés a rendu le processus de mise en page un peu plus facile, car il a libéré un peu d'espace où vous pouvez placer la mémoire flash SPI NOR, le lecteur de cartes, le RTC, le LDO 2.8V, divers circuits intégrés et d'autres composants. Quant au nombre de couches, nous avons décidé de le réduire à six. Nous avons décidé d'ajouter deux autres couches supplémentaires uniquement si nous sommes coincés dans une impasse et que nous ne pouvons pas poser de chaînes. Heureusement, cela ne s'est pas produit et il y avait une conception à six couches.

Nous avons décidé d'utiliser une disposition commune qui offre un équilibre optimal entre la facilité de câblage et réduit les émissions involontaires. En tant que substrat diélectrique, nous avons utilisé un stratifié de feuille de cuivre NP-180TL de NAN YA, qui a une permittivité relative d'environ 4,11 à notre fréquence de fonctionnement moyenne d'environ 1,7 GHz. Nos calculs de la ligne d'alimentation RF pour les lignes d'alimentation de carte à guide d'ondes microruban et coplanaire (CPW) utilisant cet arrangement peuvent être trouvés dans le référentiel Git.


Fig. 8: Disposition des couches devkit

Avant d'implémenter devkit dans KiCad, nous ne savions pas s'il fallait publier des versions alpha ou s'en tenir aux versions classiques plus stables comme 4.0.7. Bien que les "builds nocturnes" aient plusieurs fonctionnalités utiles, nous avons tout de même décidé de conserver des versions stables afin de ne pas avoir à mettre à jour KiCad souvent et risquer l'apparition de plusieurs versions simultanées.

Lorsque nous avons commencé à travailler, la version 5.0.0 de KiCad est sortie! Le 16 juillet, nous avons mis à niveau le projet vers KiCad 5.0.0 (en particulier, les commits 4f70b865 et a4e3de8a) sans aucun problème. Heureusement, cette mise à jour a coïncidé avec la transition de la plupart de nos composants passifs de 0603 à 0402, car les nouveaux pads de KiCad sont légèrement différents des anciennes valeurs par défaut et les pads ont des coins arrondis qui sont plus efficaces pour la soudure sans plomb.

Après la mise à jour vers 5.0.0, nous nous sommes concentrés sur le prototypage - et en un mois (à savoir le 14 août avec un commit de 9b4dd2e0), le nombre de circuits non dilués a été réduit à zéro.


Fig. 9: le candidat à la libération du 14 août avec la validation 9b4dd2e0 a enregistré un nombre nul de circuits non dilués

Après avoir terminé la mise en page et vérifié la vérification des règles de conception (DRC), nous avons nettoyé la mise en page pendant une semaine.

Lors du prototypage d'une carte, les ressources les plus utiles étaient un guide de référence pour le prototypage de circuits intégrés à partir de la documentation officielle et un guide de prototypage Toradex .


Fig. 10. Disposition finale (les zones recouvertes de cuivre sont cachées)

Exporter des fichiers et envoyer en production

Une fois la mise en page terminée, il a fallu exporter tous les fichiers nécessaires à la production et à l'assemblage des planches. L'exportation de fichiers Gerber vers KiCad est assez simple. Cependant, l'entrepreneur a demandé un autre schéma et une autre disposition pour l'assemblage, ce qui a nécessité un certain effort.

Pour exporter des fichiers de prévisualisation, nous avons généralement utilisé Gerbv de gEDA. Voici à quoi ressemble notre devkit dans Gerblook - cet outil utilise Gerbv et ImageMagick pour le rendu Web.


Fig. 11. Fichiers devkit de Gerber vus dans Gerbv

Pour créer le dessin du type souhaité, nous avons utilisé les couches F.Fab / B.Fab. Ils affichent les emplacements, les contours, la polarité et les symboles de référence de tous les composants de la carte. En utilisant les couches F / B.Fab pour chaque site, nous avons pu créer le dessin final en imprimant F.Fab et B.Fab dans des fichiers PDF séparés, puis en les combinant en un seul document.


Fig. 12. Régime du SOM

Encore plus ont dû travailler sur un schéma de production. Pour ce faire, vous avez dû exporter les notes de la couche Cmts.User avec la carte de circuit imprimé sous la forme d'une archive DXF, puis exporter toutes les marques de perçage des trous sous la forme d'une autre archive DXF. Après avoir créé ces deux fichiers, ils sont combinés dans le dessin de l'ensemble du site (encombrement). Après avoir reçu cette «empreinte» spéciale, qui combine deux fichiers DXF, nous cachons presque tout dans la mise en page - et importons cette empreinte spéciale «pour l'usine» (sans enregistrer la mise en page temporaire). Pour le moment, tout ce dont vous avez besoin se trouve sur la couche Dwgs.User; par conséquent, vous pouvez l'imprimer avec le cadre dans le PDF final pour la production.


Fig. 13. Tags pour percer des trous

Avec tous ces fichiers et documents, la liste de connexion IPC-D-356 est utilisée, avec laquelle l'usine peut effectuer un test en utilisant la méthode de la "sonde volante" et vérifier qu'il n'y a pas de court-circuit ou de circuit ouvert. Nous avons également préparé un fichier CSV (pour que l'usine sache où placer et comment orienter tous les composants), et, enfin, un fichier GenCAD édité manuellement (pour la programmation d'un robot de soudage en usine).

Test de prototype

Nous avons envoyé les fichiers finaux pour la production, répondu à toutes les questions de l'entrepreneur et changé tout ce qu'ils demandaient. Les fichiers ont été envoyés vers la fin du mois d'août - et nous attendions avec impatience le moment où notre conception a frappé la chaîne de montage à Shenzhen. Malheureusement, comme nous l'avons dit sur le blog , des retards importants dans la production de prototypes se sont produits en raison de circonstances imprévues, telles que les intempéries et la Golden Week [fête nationale en Chine - env. trans.]. En raison de ces retards, nous avons décidé de commander la production de prototypes dans une usine nationale, qui nous a livré des planches deux semaines plus vite que les Chinois.


Fig. 14. Le panneau prototype devkita v0.1.2 (avant assemblage)

Après avoir assemblé un petit lot de prototypes, ils ont été rapidement envoyés à nos ingénieurs pour le débogage et le développement logiciel. Heureusement, grâce aux discussions publiques et à une analyse complète de la conception, il y a eu très peu d'erreurs dans le matériel (trois ajustements relativement mineurs à la disposition / liste des circuits et un correctif mécanique). Au cours des deux mois suivants, des prototypes ont été utilisés pour peaufiner le logiciel.

Production finale et livraison

Vers le début et la mi-novembre, après avoir apporté des modifications mineures à la conception et vérifié presque tous les sous-systèmes matériels, nous avons réexporté et réédité les fichiers pour la production et l'assemblage final. Certains de nos employés ont passé du 10 au 22 décembre pour aider à l'assemblage, aux tests, à l'emballage et à l'envoi des kits à nos boulangers (beaucoup livrés avant Noël!)


Fig. 15. La vue finale du panneau devkit v1.0.0 (avant assemblage)



Fig. 16. Kit de développement entièrement assemblé par rapport au modèle 3D (côté affichage)




Fig. 17. Kit de développement entièrement assemblé par rapport au modèle 3D (côté SOM)

L'ensemble du processus a demandé beaucoup d'efforts, mais en valait la peine. Surtout quand nous avons vu à quel point la communauté peut utiliser avec fruit les résultats de notre travail. Certains ont déjà commencé à développer des étuis imprimés en 3D pour devkita. J'ai hâte de voir quels logiciels sympas et quels cas d'utilisation vous proposerez pour ces superbes cartes! N'hésitez pas à signaler toutes les choses intéressantes par e-mail à feedback@puri.sm . Si c'est vraiment super, nous parlerons de votre développement dans les prochains articles de blog.

Maintenant, nous dépensons toujours pour envoyer des téléphones Librem 5. Alors jusqu'à la prochaine fois, ne perdez pas votre inventivité!