FAQ 8 – Quelles sont les technologies que vous utilisez ?

Quelles sont les technologies que vous utilisez ?

Nous pensons qu’il est inutile faire étalage d’un nombre incalculable de technologies pour convaincre nos clients que nous pouvons les aider à réaliser leurs projets !

Nous préférons plutôt mettre l’accent sur des technologies bien maitrisées qui nous aident à maintenir notre efficacité à son niveau maximum.

Composants CMS ou traversants ?

La majorité des cartes que nous étudions utilisent des composants montés en surface (CMS). Il y a plusieurs raisons à cela : gain de place, rationalisation des empreintes CAO, disponibilité des composants sur le marché. L’utilisation de la technologie CMS requiert presque toujours l’utilisation d’un circuit imprimé multicouche professionnel (trous métallisés et des géométries fines).

La fabrication de cet élément essentiel d’une carte électronique est confiée aux sous-traitants habituels de ce secteur, ce qui implique un coût et un délai de fabrication parfois incompatibles avec l’étude de tout petits projets (étude de faisabilité, outil de mise au point, etc…).

Dans ce cas il nous arrive également de revenir à la technologie des composants traversants, mais cela reste l’exception (surtout s’il faut ensuite produire des cartes).

Les liaisons de communication.

La majorité des projets qui nous sont confiés nécessitent une connexion avec un ordinateur de type PC. Pour cela nous utilisons principalement les liaisons suivantes:

Bus USB: Pour nous , c’est la solution de référence à l’heure actuelle. Les performances de l’USB2 nous semblent largement suffisantes pour la majorité des besoins de nos clients. Cependant, dans certains cas, nous lui préférons le bus CAN lorsque des contraintes de types ‘temps réel’ viennent s’immiscer dans le projet.

RS232 / RS422: C’est la solution la plus économique lorsque les performances demandées restent modestes. Malheureusement c’est également une solution de moins en moins supportée en standard pas les PC récents.

Ethernet: C’est une solution plus complexe à mettre en œuvre, mais elle est parfois incontournable (distance des équipements, débit élevé des données à transmettre, multiplicité des équipements à connecter ensemble). Les services que l’on peut mettre en œuvre à l’aide de ce type de liaison sont très nombreux (WEB, Mail, VOIP, P2P, Streaming, etc…). Notre expérience dans ce domaine nous a amener à rationaliser nos développements au strict nécessaire pour couvrir les besoins de nos clients : mini serveur WEB, Modbus sur TCP/IP et protocoles spécifiques pour les besoins du projet.

Bus CAN: C’est une solution parfaitement adaptée aux contraintes environnementales sévères. Ce bus est bien utile lorsqu’il est nécessaires de connecter ensembles plusieurs équipements, mais il nécessite l’adjonction d’une carte CAN sur le PC qui recevra l’application. Le bus CAN est supporté par de nombreuses industries notamment grâce au standard CANopen. Le développement d’applications compatibles avec le CANopen nous semble disproportionné par rapport aux besoins de nos clients habituels. Nous préférons donc évier d’utiliser ce standard dans nos applications tant que cela est possible, ce qui ne nuis en rien aux performances de nos solutions basées sur le bus CAN (bien au contraire). En contre partie, lorsque nos solutions doivent être intégrées dans des ensembles plus complexes, les équipes de développement de nos clients ont un travail d’intégration un peu plus long. Cependant, dans ce cas nous proposons d’intégrer les fonctionnalités de l’élément que nous avons développé dans une DLL qui offrira une API adaptée aux besoins du client.

Bus I2C et liaison SPI: Nous les utilisons pour des liaisons inter-cartes ou pour adjoindre des fonctionnalités spécifiques aux microcontrôleurs que nous utilisons.

Panel des microcontrôleurs que nous utilisons régulièrement.

Notre panel est volontairement réduit pour des questions d’efficacités et de rationalisation des outils de développement. Pour les projets complexes ou moyennement complexes nous utilisons des DSP Texas Instrument TMS320F28335/TMS320F28377D ou des microcontrôleurs Freescale sélectionnés dans les familles S12 ou S12X. A l’avenir nous envisageons également d’utiliser des microcontrôleurs basés sur les cœurs ARM. Pour des projets plus simples nous utilisons aussi régulièrement des microcontrôleurs Microchip (PIC18xxx et dsPIC33).

Nous comprenons très bien que vous risquiez fort de trouver notre panel très réducteur. Ce serait effectivement le cas si nous devions étudier des cartes électroniques destinées à être produite en moyenne ou grande série. Mais ce n’est pas notre marché ! Aussi nous trouvons plus rationnel et plus efficace de limiter notre panel à sa plus simple expression (nos modules sur étagères sont plus faciles à développer!). D’ailleurs notre expérience conforte notre point de vue à ce sujet.

Utilisation des FPGA.

Nous faisons appel aux FPGA lorsque les performances attendues le nécessite. Pour développer les fonctions qui seront intégrées dans un FPGA (ou un CPLD) nous faisons appel au langage VHDL. Cette partie de l’étude est gérée comme un développement autonome ayant pour but la création d’un composant sur mesure. Pour nous, la validation de ce composant spécifique est très importante et elle implique non seulement la simulation à l’aide d’un ‘testbench’ exhaustif mais également une campagne de vérification sur la cible finale. Il va de soi que nous réservons ce type de développement aux cas les plus complexes.

Le panel des composants logiques programmables que nous utilisons habituellement comprend les produits proposés par Actel (familles IGLOO et A3P) et Lattice (famille LFE2 et CPLD). Notre choix s’est porté sur ces familles parce qu’elles intègrent la mémoire de configuration des FPGA, ce qui simplifie leur mise en œuvre (et la disponibilité des outils de développements à un coût raisonnable).

Concernant le développement des logiciels qui accompagnent nos cartes électroniques nous vous invitons à consulter aussi la page 9 de la liste des questions qui nous sont fréquemment posées.