Sommaire | Services Pro | Musiques | Publications | Connectique | Electronique | Logiciels | Divers | Contacts | Liens | Glossaire | Historique

Electronique > Développements

Dernière mise à jour : 03/03/2013

Présentation

Cette page est née suite à plusieurs demandes d'internautes curieux de connaître mes habitudes "électronique et informatique". Quels logiciels j'utilise pour dessiner mes schémas, simuler, dessiner les circuits imprimé, écrire mes logiciels pour PIC, etc. Je décris ainsi les étapes par lesquelles je passe pour passer d'un schéma électronique à sa réalisation finale.

Saisie de schéma

C'est l'étape la plus simple et la plus rapide de toutes... une fois le logiciel de saisie de schéma en main. Pour ma part, j'utilise la suite Proteus de Labcenter (distribuée en France par Multipower) qui inclue en un seul package les deux logiciels Isis et Ares. Isis est le module qui permet la saisie du schéma électronique, avec un module de simulation intégré dont les possibilités dépendent des options achetées (les simulations avancées par graphe telles que analyse FFT ou réponse amplitude / fréquence sont optionnelles).

Ares est le module qui permet de dessiner le circuit imprimé (appelé aussi typon ou PCB) : placement des composants et routage avec pistes. Pour celui qui n'a pour souhait que de réaliser des schémas propres, point besoin de prendre le niveau de logiciel le plus élevé avec toutes ses options. La version freeware (bien allégée) peut même surement lui suffire ! Je dessine tous mes circuits électronique sous Isis depuis 1994.

Simulation des circuits analogiques et / ou numériques

La simulation d'un circuit est très intéressante car elle permet de voir comment le circuit dessiné pourrait se comporter dans la réalité.

Simulation d'un circuit analogique orienté "logique"


Simulation d'un circuit purement analogique

Certes avec plus ou moins de fidélité, mais de nos jours la simulation est en général très proche de la réalité. Elle reste même fiable pour des circuits très rapides si on sait "placer" le circuit dans un contexte plausible (tenant compte de l'environnement). En cas de mauvais fonctionnement révélé par la simulation, il suffit de modifier la valeur d'un ou de plusieurs composants et de voir ce que donne la simulation avec les nouvelles valeurs. Ce qui évidemment est beaucoup plus rapide à faire à l'écran que sur l'établi, et conduit à un gain de temps considérable, surtout lors du développement d'un nouveau circuit - cas dans lequel je me trouve souvent. Vu que ma passion de l'électronique m'accapare beaucoup de temps, j'ai décidé de travailler avec la version de proteus niveau 2 (il existe 3 niveaux), avec les options de simulation avancées par graphe.

Remarque : il arrive parfois que la simulation d'un circuit analogique dans Isis ne veuille pas démarrer du tout, avec un message d'erreur de type "Trop d'itérations sans convergence". La simulation dans Isis s'appuie sur le moteur Spice, qui a besoin qu'on lui modifie parfois quelques paramètres pour qu'il accepte de démarrer. Moi-même ne suis pas du tout expert dans les principes avancés de la simulation, et quand ce genre de problème survient (c'est assez rare tout de même), je découpe le circuit en plusieurs parties et les simule séparement.

Simulation des microcontrôleurs

Quand j'ai découvert qu'il était possible de simuler des microcontrôleurs au sein même d'un schéma dessiné dans Isis, je n'en revenais pas ! Il était ainsi possible de simuler en temps réel l'action d'évenements externes sur un programme compilé (par exemple avec des boutons poussoirs présents sur le schéma que l'on peut "presser" avec le bouton de la souris), et voir le résultat sur des LED ou sur un afficheur LCD (eux aussi modélisés).

Tout ça me semblait bien beau mais j'avais du mal à voir comment s'organisait l'ensemble, et il a fallu que je me documente un bon moment avant de comprendre. Car si les vendeurs de logiciels et de matériels n'hésitent pas à mettre en avant les multiples fonctions de leurs produits, il n'en reste pas moins difficile d'établir un lien entre les parties logicielle et matérielle (quand on n'y connait rien du tout, ce qui était bien mon cas dans ce domaine précis). Voilà en gros les points que je devais retenir et que vous aussi devez retenir si vous voulez procéder de la même façon :

1 - Pour pouvoir faire quelque chose, un microcontrôleur doit être "chargé" (on emploie aussi le terme "flashé") avec un programme que vous (ou quelqu'un d'autre) avez écrit, et ce programme doit se trouver dans un format compilé (fichier binaire hexadécimal *.hex). Au moment où vous écrivez le code du programme, vous pouvez choisir un language de programmation parmi plusieurs : Basic, Pascal, C, ou assembleur, le logiciel dans lequel vous l'écrivez se charge ensuite de le compiler dans le format de sortie *.hex requis. Sachant cela, autant choisir le langage que vous préférez. Pour ma part, j'ai choisi le compilateur MikroPascal car j'avais déjà de l'expérience avec le développement en langage Pascal, au travers de mes développements informatiques pour Windows avec Delphi (Borland / Inprise / CodeGear). La prise en main du logiciel a donc été assez rapide pour moi.

2 - Dans Isis, vous devez indiquer le fichier *.hex (ou *.coff si vous souhaitez effectuer un debugage avec suivi ligne par ligne du code source dans Isis même) qui doit être utilisé par le composant microcontrôleur de votre montage. Là, rien de compliqué, il s'agit d'une des propriétés du composant qu'il faut juste renseigner. Une fois fait, la simulation peut être lancée.

3 - Dans le monde réel, le microcontrôleur n'est pas sur l'écran d'un PC mais sur un circuit imprimé. Il y a donc lieu de procéder à la programmation du composant que vous avez acheté, et cela doit se faire avec un programmateur. Il en existe de plusieurs sortes, des tous petits pas chers qui permettent juste de programmer un composant de taille physique donnée (nombre de pattes fixe), et des platines de développement complètes capables d'assurer la programmation de plusieurs "tailles" de composants, mais aussi des contrôles avancés de débugage et le test immédiat du circuit avec des périphériques inclus sur la platine même (leds, poussoirs, afficheur, interfaces USB et RS232). De mon côté, j'ai opté pour la platine de développement EasyPic4 (distributeur français Lextronic, mais on peut aussi l'acheter directement chez le fabricant MikroElektronika), car elle m'a tout de suite parue adaptée à mes besoins : je trouvais bien pratique de ne pas faire faire plusieurs allers-retours aux microcontroleurs entre programmateur et circuit imprimé final, quand ça ne fonctionne pas du premier coup. Et, point non négligeable, le fabricant de cette carte est l'éditeur du logiciel MikroPascal, ce qui me semblait présenter moins de risque d'incompatibilité entre les deux.

Au final, rien de bien compliqué, mais il fallait le savoir pour donner envie de se lancer pour de bon ! Il m'aurait manqué un seul élément que les choses n'auraient pas été assez claires, et peut-être ne me serais-je pas lancé dans l'aventure. Le synoptique qui suit montre comment je pratique quand j'inclue un microcontrôleur dans un montage (uC = microcontrôleur) :

1 - Je dessine le schéma dans Isis, en incluant bien sûr le microcontrôleur.

2 - J'écris et je compile le programme du microcontrôleur avec MikroPascal, ce dernier fournit le fameux fichier *.hex.

3 - Dans Isis, je spécifie au microcontrôleur quel fichier *.hex (ou *.coff) tout fraichement compilé il doit utiliser, et je lance la simulation. Si les résultats obtenus ne sont pas bons :
- j'arrête la simulation dans Isis,
- je modifie le programme dans MikroPascal et je recompile,
- je retourne dans Isis et relance la compilation.
Jusqu'à ce que la simulation dans Isis donne les résultats attendus.

4 - Quand ça fonctionne bien dans Isis, je transfert le dernier fichier *.hex dans le vrai microcontrôleur, directement depuis le logiciel MikroPascal qui pilote la carte EasyPic4. Puis directement sur cette carte (parfois avec quelques "déports" sur plaques sans soudure pour faciliter les tests), j'effectue les derniers tests matériels qui s'imposent.

En pratique, j'ai donc deux programmes qui tournent simultanement sur le PC pendant la phase de développement : Isis et MikroPascal. A une ou deux exceptions près, toutes les simulations réussies sous Isis ont été suivies d'un parfait fonctionnement dans le monde réel.

Différences entre HEX et COFF...

Lequel de ces deux fichiers utiliser dans Isis ? Les deux permettent en effet de simuler le programme compilé du microcontrôleur, mais avec les subtilités que voici :

• Le fichier *.hex ne comporte que le code exécutable (format binaire) du programme. Ce code peut être exécuté (simulé) mais on ne peut pas, dans le simulateur, s'arrêter sur telle ou telle portion de code pour rechercher d'éventuel défauts de fonctionnement (mode débogage).
• Le fichier *.cof (ou *.coff) contient lui aussi le code exécutable du programme, mais en plus de cela il contient des informations qui aident au débogage dans l'outil de simulation (Isis dans le cas présent). Ces informations supplémentaires portent sur les noms des variables et des fonctions ainsi que sur leur emplacement mémoire. Et cerise sur le gateau, le fichier comporte aussi des informations qui permettent de faire la correspondance entre le code exécutable (*.hex) et le code source (*.mpas pour MikroPascal). Cela peut paraitre un peu obscur pour celui qui n'est pas habitué à lire des valeurs de variable durant le processus même de simulation, et qui se contente de regarder l'effet du programme dans sa globalité. Mais pour le développeur averti, c'est une aide sérieuse qui permet de repérer plus vite la source d'un problème.

Remarque : la simulation sous Isis avec les fichiers *hex ne pose pas de problème, mais j'ai rencontré plusieurs problèmes de simulation avec utilisation des fichiers *.cof générés par MikroPascal. Le problème semble venir du fichier *.cof lui-même, à qui il semble manquer certaines informations de configuration du microcontrôleur.

Simulation USB

Certains microcontrôleurs tels que les 18F2550 et 18F4550 comportent un module USB, que Proteus prend en charge. En clair, on peut simuler le circuit avec son microcontrôleur et grâce à un driver USB virtuel (fourni avec Proteus) on peut faire comme si le circuit en cours de simulation était réellement relié au PC ! J'ai utilisé cette fonction, par exemple, pour simuler le fonctionnement de mon interface USB 004USB-HID-TEST-256.

 

MikroPascal et programmateur...

Le compilateur MikroPascal et le driver du programmateur sont en fait deux modules séparés, qui peuvent être exécutés de façon individuelle : on peut utiliser le compilateur MikroPascal juste pour disposer du fichier binaire compilé *.hex (ou *.cof), et utiliser un programmateur d'un autre fabricant, qui saura dans tous les cas lire le fichier *.hex (c'est un standard). Tout comme on peut utiliser un compilateur autre (Proton ou MPLab par exemple) et avec le fichier *.hex créée avec celui-ci, programmer le microcontrôleur avec la platine EasyPic4, dont le logiciel de programmation attaché PicFlash peut bien sûr lire lui aussi tout fichier binaire compilé *.hex.

MikroPascal pour la compilation...


... et PicFlash pour la programmation.

Simulation des "stimulis"

Les signaux de commande externes (stimulis) peuvent se résumer à l'action manuelle sur de simples boutons poussoir, à la mise en oeuvre de générateurs de tous types (carré, triangle, sinus, signal audio, etc). Mais on peut aussi vouloir voir ce que donne un circuit lorsqu'il reçoit des données provenant pour de vrai de l'extérieur, par le biais d'une liaison série RS232 par exemple. Et là, proteus montre une fois de plus sa puissance : on place un composant de type Port Com sur le circuit, et on connecte ses "pattes" sur le circuit à simuler. Quand des données arrivent en temps réel de l'extérieur sur le port série physique de l'ordinateur, elles sont aussitôt transmises dans le schéma et le circuit réagit en conséquence ! Le même type de fonction est également permis pour le bus USB ! Les ports MIDI ne sont pas pris en charge, mais il existe un outil dans Proteus fort pratique qui permet de contourner ce manque : il s'agit du générateur EasyHDL, qui permet, grâce à quelques lignes de code, de produire n'importe quelle type de signal, analogique ou numérique.

C'est ce type de générateur EasyHDL que j'ai utilisé, par exemple, pour mettre au point mon interface MIDI 005b et vous trouverez quelques exemples pratiques d'utilisation (RS232, MIDI et codage RC5) de ce générateur à la page Générateur EasyHDL.

Placement et routage

C'est en temps normal la dernière étape. Comme je le disais au début, j'utilise Ares pour l'implantation (le placement) des composants et pour leur raccordement (routage).

L'étroite collaboration de Ares avec Isis limite au maximum les risques d'erreurs : Isis fabrique un fichier spécial appelé Netlist, qui comporte sous forme de texte la liste des composants utilisés dans le schéma, ainsi que leur interconnexions. Ce fichier est chargé par Ares, qui sait donc tout de suite quels composants doivent être placés sur le circuit, et affiche un chevelu des connexions à réaliser sous forme de lignes rectilignes. Les lignes du chevelu disparaissent au fur et à mesure que les pistes de cuivre (et éventuellement les straps) sont dessinées, que ce soit de manière automatique (autoroutage) ou manuel. Sur la copie d'écran qui précède, une partie du circuit est routée, les lignes vertes droites indiquent les liaisons qu'il reste à tracer. Bien entendu, chaque piste et pastille peut se voir attribuer la taille désirée, et des règles de conceptions ajustables par l'utilisateur permettent de spécifier les espaces inter-pastilles, inter-pistes ou entre pistes et pastilles minimum, au-dessous desquels on ne veut pas descendre. Je trouve qu'il s'agit d'un logiciel souple à l'usage.

Prototypage

Tout ce qui précède parle d'étapes qui restent dans le monde du virtuel. Vient forcément le moment où il faut mettre la main à la pâte. Il m'arrive parfois d'utiliser des plaques prépercées à bandes ou à pastille, quand je suis assez sûr de moi.

 

Sinon, et dans la majorité des cas, je préfère les plaques d'expérimentation sans soudure, tellement pratiques pour les narines sensibles !
 


Pour me faciliter la tâche, j'ai composé quelques "périphériques" réutilisables pour mes expérimentations sur plaque sans soudure : une interface MIDI, une interface RS485, des modules d'affichage multiplexés, et même un petit support pour connecteur USB, dont je me sers de plus en plus pour mes essais avec mes PIC 18F2550 ou 18F4550.

 

On n'en fini jamais, vous le savez bien...

Définition des besoins

Qu'est-ce que la définition des besoins ? C'est simplement la liste de tout ce que l'on attend d'un système, exprimée de façon claire et précise. Elle permet d'être sûr de savoir ce que l'on veut et de ne pas se tromper sur ses choix, et porte aussi bien sur le projet que l'on veut démarrer, que sur les outils que l'on utilise pour le mener à bien.

Choix du système d'assistance au développement électronique (CAO)

Quand j'ai débuté avec la CAO électronique dans le début des années 90, je n'avais pas vraiment de notion sur le sujet, et j'ai simplement essayé plusieurs produits auquels j'avais accès via licence d'entreprise ou disquette de démo (Orcad, MultiBoard, puis Proteus). J'ai fait un choix et je ne le regrette pas. Il va de soi que le choix d'un système réclame du temps pour analyses et essais, afin d'être sûr qu'il nous conviendra bien, car on ne peut pas foncer tête baissée sur un produit qui coûte cher. Cela reste bien sûr limité aux besoins du moment, car l'analyse se fait évidement sur ceux-ci, on n'imagine pas forcement toujours ce dont on aura besoin demain. Pour ma part, je souhaitais disposer d'un logiciel qui me permettrait de dessiner mes schémas et de faire mes circuits imprimés. Liste close. Je n'étais pas bien difficile, n'est-ce pas ? 

Aujourd'hui, je n'ai aucune idée de ce que valent les autres systèmes, mais je sais - par lecture dans les forums de sujets portant sur la comparaison des produits concurrents - que le nombre de composants inclus dans les bibliothèques livrées avec le produit n'est pas toujours un facteur de choix prioritaire. Et que la définition des besoins n'est pas forcement la même pour une entreprise et pour le particulier, même si parfois certains croisements s'opèrent.

Choix du type de microcontrôleur et du compilateur

A l'époque, il n'était pas question pour moi de programmer des composants autres que des PROMs (j'avais la chance de disposer d'un programmateur de PROM à mon boulot), aussi n'ai-je pas cherché à disposer de cette fonction dans mon outil de CAO. Finalement, les choses vont bon train, et le logiciel que j'ai choisi à l'époque permet à ce jour l'ajout de modules complémentaires dédiés composants programmables, sous forme de "familles". Il existe même des "petites familles" comportant seulement quelques composants (appelées starter kit), vendues moins cher et principalement destinées à attirer ceux dont les besoins ne vont pas trop loin. C'est ce que j'ai fait : j'ai acheté un module d'extension permettant de simuler les PIC 16F84 et 16F877, les deux types de circuits livrés avec ma platine EasyPic... Quelle coïncidence, n'est-ce pas ? Bien évidement, j'ai mordu à l'hameçon et ai par la suite acheté les modules complémentaires pour l'ensemble des familles de PIC 8 bits (10Fxxx à 18Fxxx). Tout allait donc bien en ce qui concernait le choix des microcontrôleurs.

Remarque : je dois avouer que tout ce que je dis ici fait référence à mon expérience personnelle, de débutant et non de professionnel. Pour ce qui est du choix du type de microcontrôleur, je suis vraiment parti au hasard en choisissant les PIC et en laissant de côté les ARM, AVR et autre HC11 ou 8051. Une chose m'a cependant conforté dans ce choix : la présence sur Internet, d'un grand nombre de projets qui utilisaient des PICs et qui s'approchaient de ce que je voulais faire. Si d'autres avaient pu faire ceci ou cela avec tel type de PIC, je me suis dit qu'il n'y avait pas de raison que je n'y arrive pas. Et j'ai parfaitement compris que pour certains projets ambitieux, je ne pourrais pas compter sur les "PIC de base".

Choix du microcontrôleur

Pour moi, les fondations sont posées, mais si je devais construire une deuxième tour, je le ferai. Pour le moment, je reste sur la famille des PIC de Microchip car je suis loin d'être arrivé au bout. J'ai commencé avec les 16F84 et 16F877, qui permettent un peu de voir les deux bouts d'une longue ficelle sur laquelle se trouvent plein de noeuds (plus du côté du 16F877) que l'on doit dénouer l'un après l'autre. Le 16F84 m'a permis de voir comment gérer les entrées / sorties, et le 16F877 m'a permis de m'initier avec les convertisseurs analogique / numérique. Mais le jour où j'ai voulu faire un indicateur de niveau batterie simple et petit, j'étais coincé : le 16F84 ne dispose pas de convertisseur A/N et impose d'en ajouter un, et le 16F877 fait un peu luxe pour un tel usage, en plus de tenir difficilement dans une prise allume-cigare. Il me fallait trouver un PIC de petites dimensions et disposant d'un CAN, et si possible pas cher. Je l'ai vite trouvé, après quelque recherches sur internet : le 12F675. C'est ce que je découvrais à ce moment-là qui m'a décidé d'acheter la licence pour plusieurs variantes de processeurs PIC : je savais que je coincerai encore un peu plus tard sur le même genre de problème. Puis ensuite vinrent se loger dans ma main les 16F88, 18F2420, 18F2550, 18F4550, 18F45K22... Après tout, s'il existait un PIC à tout faire, Microchip ne proposerait pas des dizaines de modèles à son catalogue... Avec le temps et de manière naturelle, j'ai fini par explorer les PIC24, les dsPIC30/33 et les PIC32.

Historique

03/03/2013
- Ajout infos côté matériel / prototypage.
11/07/2010
- Première mise à disposition.