Dernière mise à jour : 11/07/2010
Présentation
J'ai décidé d'écrire cette page après
réception de plusieurs courriers me demandant des détails
concernant la façon dont je procédais pour créer
et / ou simuler mes circuits électroniques, que ces derniers
comportent ou non des composants programmables. Je décrit 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 bien 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 interressante 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 évidement
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 accèpte 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 eux aussi sur le schéma
et que l'on peut "presser" avec le bouton de la souris), et de voir le
résultat sur des leds 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 connais 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é suivie 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 écrit
dans le compilateur. Il peut être exécuté (et donc simulé) mais sans
savoir précisement à quelle partie du code source (écrit dans l'éditeur
de développement) telle portion de code se réfère.
- Le fichier
*.cof (ou *.coff) contient lui aussi le code exécutable du
programme, mais aussi des informations supplémentaires qui aident au
débuggage 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 obscure 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 capitale qui permet de sauter bien 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 manque les
informations de configuration du microcontrôleur.
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. Et si des données arrivent en temps
réel de l'extérieur sur le port série physique de l'ordinateur, ces
données 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, je trouve ça assez fort, tout de même ! En revanche,
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 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.
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 fort 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 ne suis pas encore
arrivé au bout de leur limite (évidement, je
débute). 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
là qui m'a fait prendre la décision 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. Après tout, s'il existait un PIC à tout
faire, Microchip ne proposerait pas des dizaines de modèles
à son catalogue...
Nouveaux développements
Je suis débutant mais j'aime bien relever les défis.
Quelques-uns de mes projets avec processeur font suite à des
questions posées sur des forums, ou à des demandes
personnelles par courriel. Mais je n'aime pas non plus perdre mon
temps, car j'ai des tas de choses à faire ou à terminer.
Aussi, je me limite pour l'instant à des projets assez "simples"
(je sais que la notion du simple est complexe à définir),
pour lesquels il m'est facile de "sentir" le temps de travail
nécessaire. Et pour sentir ça de la façon la plus
juste possible, il faut que les besoins soient clairement
exprimés. Cela peut se résumer à la phrase
suivante : "Ce système doit faire cette action et rien d'autre,
et aucune évolution ne sera à prévoir.".
Là, c'est assez facile. Mais on peut aussi se dire que le
système doit assurer cinquante fonctions différentes, et
que des évolutions sont à prévoir sur au moins
cinq d'entre elles, ou encore que d'autres fonctions seront à
ajouter plus tard. Dans ce deuxième cas évidement, il
convient de décortiquer les caractéristiques des
composants pour en connaitre très précisement les
limites, et isoler ceux qui ne permettront aucune évolution
possible (taille mémoire limite par exemple, à moins de
prévoir dès le début une mémoire annexe
plus large que nécessaire).
