Les systèmes embarqués sont omniprésents dans le monde technologique d'aujourd'hui. Que ce soit un rasoir connecté à Internet ou un véhicule complexe, les dispositifs embarqués sont au cœur de la plupart des appareils électroniques que nous utilisons aujourd'hui. Composés d'un ou de plusieurs microprocesseurs, les systèmes embarqués peuvent simplifier l'électronique en déléguant la complexité à être gérée par le logiciel. À mesure que les dispositifs embarqués deviennent plus grands et plus complexes, il en va de même pour les cartes de circuits imprimés (PCB). Assez souvent, ces dispositifs se transforment en plusieurs cartes et deviennent des assemblages plus importants que prévu initialement.
Dans cet article, nous allons examiner les compromis et considérations architecturales pour les systèmes embarqués composés de plusieurs PCB. Nous aborderons les avantages, les considérations de conception et les défis associés aux systèmes multi-PCB.
Bien que garder votre dispositif sur une seule PCB soit l'option idéale (à la fois pour la simplicité et le coût), nous devons parfois nous résoudre à diviser notre conception en deux ou même plusieurs PCB afin d'atteindre nos objectifs de conception. Voici quelques raisons pour lesquelles nous voudrions séparer notre produit en plusieurs cartes :
Pour ces raisons (et d'autres), nous envisageons de concevoir un assemblage composé de plusieurs PCB, mais les défis du côté du firmware embarqué ne sont pas sans leurs complexités.
Maintenant que nous avons établi le cas d'utilisation de plusieurs PCB (le cas échéant), il est important de comprendre les considérations de conception lors de l'architecture du système embarqué. Tant du point de vue matériel que logiciel, il y a des nuances que nous ne tendons pas à peser aussi soigneusement lorsque tout est mis sur une seule carte.
La première considération qui devrait nous venir à l'esprit est la communication entre cartes. Comment chaque carte va-t-elle communiquer avec les autres ? Quel type de puissance de traitement (le cas échéant) réside sur chaque carte ? Peut-être qu'une carte consiste en le cerveau tandis que les autres comportent les capteurs ? Alors que nous choisissons soigneusement nos protocoles de transmission, que ce soit I2C, SPI, UART, Ethernet, etc., nous devons également tenir compte des lignes de transmission, de l'intégrité du signal et, plus important encore, du transfert de signal à travers les connecteurs inter-cartes. La pire chose qui puisse arriver à un concepteur (et croyez-moi, j'y ai été confronté) est de concevoir le système complet et de recevoir vos PCBs du fabricant seulement pour réaliser que vous avez manqué un signal d'horloge ou deux. Nous avons également tendance à oublier de garder des broches de réserve sur nos connecteurs inter-cartes, tentant de maximiser le nombre de broches au maximum. C'est quelque chose qui peut vraiment nous causer des problèmes à la fin. Concevoir en gardant à l'esprit un projet multi-cartes, comme la fonctionnalité Assemblage Multi-Cartes dans Altium Designer, est indispensable lors du routage de tant de lignes de communication entre PCBs.
Nous devons également réfléchir à la manière dont nous prévoyons de distribuer l'alimentation, surtout si nous allons surveiller les bus d'alimentation avec notre microprocesseur. Nous voulons un accès au "cerveau" pour lui permettre de surveiller tout événement catastrophique, mais nous devons aussi considérer le bruit de l'alimentation à découpage, la distribution d'énergie pour les charges lourdes, et si nos broches de connecteur inter-cartes sont évaluées pour ce type de puissance.
Enfin, bien que cela ne soit pas directement lié au logiciel lui-même du système embarqué, la conception mécanique joue également un rôle important. Les boutons-poussoirs, écrans tactiles et autres interfaces physiques avec l'utilisateur sont toujours connectés au microprocesseur et doivent être pris en considération. Le câblage peut-il être routé de manière à ce que le microprocesseur puisse accéder à ses entrées ? Avons-nous considéré l'intégrité du signal des sorties numériques à haute vitesse lorsque nous les faisons passer d'une carte à l'autre ? Ce sont des choses auxquelles nous devons penser lors de l'architecture de notre dispositif embarqué.
Un des défis les plus sous-estimés que j'ai vu encore et encore dans les startups en croissance (et même dans les grandes entreprises) a été le fléau des schémas de versionnement entre logiciel et matériel. Gérer les sorties de logiciels contre les révisions de PCB est devenu la bataille sans fin qui conduit souvent à la confusion, aux retards et même aux échecs de produits.
Par exemple, dans une startup avec laquelle j'ai travaillé, une légère modification dans le PCB nécessitait une nouvelle version et, donc, une mise à jour du firmware (bien que minimale). En raison d'un mauvais contrôle de version, l'équipe d'ingénierie a déployé le nouveau firmware sur d'anciennes versions de PCB provoquant des baisses de tension inattendues et un nuage de fumée périodique. Heureusement, nous l'avons découvert avant que le produit ne soit expédié mais cela a été un cauchemar absolu pendant des jours.
Pour éviter ces pièges, il est crucial d'établir un schéma de versionnement solide et d'assurer une communication claire entre les équipes matériel et logiciel. Même un schéma de versionnement simple comme un hash Git (ou version sémantique) pour le firmware, à côté d'une table de recherche basique pour les révisions matérielles, peut suffire pour commencer. Au fil du temps, des mécanismes plus sophistiqués comme la détection de révision matériel dans le firmware (vérifiant ainsi la compatibilité) réduisent également grandement les confusions.
En plus de la gestion des versions logicielles, il est également important de penser à la modularité du code. Avec un code spaghetti, remplacer une carte de capteurs par de nouveaux puces ou capteurs pourrait devenir un cauchemar de refactoring. Modulariser vos pilotes de périphériques et créer des couches d'abstraction matérielles permet de remplacer facilement les composants pendant de nombreuses années. C'est quelque chose qui est devenu beaucoup plus populaire au fur et à mesure que les systèmes embarqués se sont complexifiés avec le temps.
Lorsque nous pensons à l'architecture des systèmes embarqués, nous n'avons pas toujours à penser petit. Les engins spatiaux et les automobiles sont des systèmes embarqués extrêmement complexes, tout comme le sont les smartphones. Que nous concevions une cuillère connectée à Internet ou le prochain satellite, comprendre les compromis de l'architecture des systèmes embarqués est extrêmement important lors de la conception pour plusieurs PCBs. Nous avons exploré de nombreux concepts dans cet article mais il y en a encore beaucoup d'autres que, sans aucun doute, vous découvrirez tout au long de votre parcours.