Quasiment deux ans après mon dernier "level up" relaté sur ce blog j'en ajoute un nouveau obtenu début Mai : j'ai gagné un niveau en robotique grâce à une homologation réussie à la coupe de France 2013. Si on veut aller plus loin j'ai même gagné un second niveau en robotique grâce à un match gagné en coupe de France :) ! Comme pour le dernier "level up" cet article ne contiendra rien de passionant techniquement; si il n'y a que l'informatique qui vous passionne je vous conseille donc de zaper ce billet pour vous concentrer sur le précédent.

Du 8 au 11 Mai dernier se déroulait donc la coupe de France de robotique à la Ferté-Bernard. J'y avais déjà participé à deux reprises en 2006 et 2007 mais nous n'avions malheureusement pas réussi à homologuer nos robots et, en plus, je ne comprenais rien à l'électronique mise en oeuvre à l'époque :( Depuis ces lointaines années j'ai "pas mal" progressé en électronique et il se trouve que cette année deux amis étaient motivés pour participer à la coupe de France avec moi (pour eux c'étaient leur première participation), nous avons donc tenté le coup.

Nous sommes arrivés dans la Sarthe le premier jour de la coupe avec un robot "quasiment terminé"¹. Après un rapide tour des stands nos soupçons étaient confirmés : nous avions probablement le robot dont la mécanique faisait le plus pitié² mais qu'importe, on était là pour s'amuser et homologuer. De façon prévisible nous avons rencontré pas mal de problèmes de dernières minutes et les "une ou deux heures" que nous estimions nécessaires pour rendre le robot opérationnel s'allongeaient tant et si bien que l'après-midi du deuxième jour de compétition nous n'avions toujours pas réussi à homologuer...

C'est alors que nous avons opté pour un "plan B" : le réglement de cette année autorisait l'utilisation de DEUX robots en même temps sur la table pour chaque équipe donc, pendant que notre electronicien-magicien s'acharnait à rendre notre premier (et unique) robot opérationnel, moi et le troisième larron nous sommes lancés dans la conception d'un second robot d'urgence qui pourrait nous permettre d'homologuer. En effet, pour que notre équipe soit homologuée il fallait qu'au moins un robot parvienne à quitter sa zone de départ et que l'équipe marque au moins un point. Notre robot principal n'avait aucun problème pour quitter sa zone de départ, mais il ne parvenait pas encore à marquer de points. Le cahier des charges du "robot" d'urgence a donc été réduit au strict minimum : inutile qu'il sache se déplacer, il doit juste marquer au moins un point. Là encore le réglement de cette année nous a facilité la tache puisqu'il était possible de marquer 12 points bonus juste en gonflant un ballon d'anniversaire³ au bout de 90 secondes de match. La conception du robot secondaire s'est donc imposée d'elle-même : un ventillateur de PC va gonfler un sac plastique de supermarché au bout de 90s; pour obtenir la puissance en 12V demandée par le ventillateur de PC nous avons soudé entre-elles une pile 9V et une pile 4.5V achetées au leader-price du coin; pour compter les 90s nous avons utilisé un atmega8 qui trainait dans ma boite à malices; pour convertir l'ordre de l'atmega en puissance pour le ventillo nous avons utilisé un simple transistor également en provenance de ma boite à malices; et pour fabriquer le "bouton d'arrêt d'urgence" obligatoire sur tout les robots de la coupe nous avons collé un bouchon de Coca Cola sur un bouton poussoir :) Avec un peu de cartons et quelques chutes de plexy par dessus ce bric-à-brac le robot d'urgence remplissait parfaitement sa mission : il répond à tout les critères de sécurité nécessaire pour être autorisé à participer et il gonfle bien un "ballon" (marquant 12 points) au bout des 90s réglementaires.

Nous nous sommes donc présenté une ultime fois à l'homologation et la magie a opérée : notre robot principal a, comme d'habitude, parfaitement quitté sa zone de départ puis il a échoué à toutes ses tentatives de marquer des points; mais le robot d'urgence a correctement gonflé son ballon au bout de 90s marquant 12 points pour le compte de l'équipe et scellant ainsi une homologation réussie :-D ! Champagne⁴ !

Une fois l'homologation en poche nous avons eu le droit de participer aux séries. Le premier match est sans appel : bug dans notre robot principal qui refuse de quitter sa zone de départ; aucun de nos deux robots n'ayant quitté sa zone de départ les points de gonflage de ballons ne sont pas comptabilisés et nous ne marquons donc aucun point. En face de nous un adversaire extrèmement sympathique avec un robot à la fois superbe et efficace nous colle une raclée 65 à 0. Quelques ajustements plus tard (en particulier une refonte mécanique complète du système de démarrage du robot principal et un recalibrage important de ses paramètres d'asservissements) nous participons à notre second match de série contre un adversaire tout aussi sympathique, avec un robot à la mécanique impressionante mais souffrant de gros problèmes électronico-informatique au moment de se présenter sur l'aire de jeu. Contraint par ses soucis électronico-informatique notre adversaire partait lui aussi sur une stratégie de secours consistant à uniquement sortir de sa zone de départ et gonfler un ballon; mais en n'utilisant qu'un seul et unique robot au lieu de deux. Enorme surprise de notre coté au bout de 20s de match : les ajustements faits sur le robot principal portent leur fruits et il parvient à marquer ses tout premiers 4 points⁵ ! Notre robot de secours gonfle bien son ballon au bout des 90s, tout comme notre adversaire qui empoche lui aussi les 12 points correspondants. Le score s'élève donc à 16 points contre 12 à la fin du match, nous empochons les 5 points de la victoire et notre adversaire le point de "non-forfait" ce qui porte le score final à 21 contre 13 : nous venons de remporter une victoire en coupe de France⁶ !

Cette victoire est d'autant plus savoureuse qu'en raison de contraintes diverses et variées nous devions quitter la coupe de France à l'issue de ce match, déclarant ainsi forfait pour les deux derniers matchs de série que nous aurions pu jouer. Au final nous resterons donc à la 136ème place (sur 146 possibles) ce qui dépasse notre objectif : nous avons homologué :) !

Qui sait, peut-être reviendrons nous l'an prochain avec un objectif plus ambitieux pour un nouveau level up ;) ...

1. Expression consacrée de la coupe de France qui signifie "le robot ne marche pas mais avec beaucoup de café j'ai encore l'espoir de le faire marcher avant la fin de la compétition" ↩
2. Même les robots en LEGO avaient plus la classe que notre assemblage de bois/plexy/pistocolle ↩
3. Cette année le thème de la coupe était l'anniversaire puisqu'il s'agissait de la 20ième édition de la coupe ↩
4. Enfin...champomy en l'occurence puisque l'alcool était strictement interdit dans l'ensemble des batiments de la coupe :-( ↩
5. Quatres points qui illustrent d'ailleurs ce billet : sur la photo en tête de cet article notre robot vient d'ouvrir un "cadeau" en faisant basculer sa représentation en bois hors de la table ↩
6. Match "Robot-X" contre "Planet Express" : http://www.planete-sciences.org/robot/live/coupe2013/series/s3/ ↩

J'avais déjà rapidement parlé de gEDA dans un précédent billet¹, mais pour ceux qui ne l'ont pas lu voici un rappel : gEDA est une suite de logiciels Open Source permettant de concevoir et simuler des circuits électroniques. Dans ce billet je vais tenter de résumer comment on peut utiliser gEDA pour amener la conception d'un circuit électronique à partir de rien jusqu'à l'obtention d'un véritable circuit imprimé physique. Le but de cet article est, d'une part, de me servir de pense-bête pour plus tard et, d'autre part, d'apporter quelques astuces à ceux qui, comme moi, vont découvrir de nombreuses embuches en tentant de concevoir leur premier circuit avec gEDA. Contrairement au billet précédent il n'y aura donc pas d'informatique du tout dans ce billet-ci et il risque d'être assez indigeste pour ceux qui n'ont pas envie de concevoir de circuits imprimés...Promis je me rattraperai plus tard avec d'autres billets ;) !

gschem pour créer le schéma fonctionnel

Comme rappelé en introduction, gEDA est une suite de logiciels cohérents les uns avec les autres, chacun ayant son utilité propre. L'outil de la suite gEDA par lequel nous allons commencer est gschem qui permet de dessiner le schéma logique du circuit que l'on est en train de concevoir². Il n'est pas follement intuitif d'utilisation mais après 30mn à s'habituer au maniement de l'outil on parvient à faire à peu près ce que l'on veut.

Pour dessiner votre schéma il suffit de sélectionner les composants que vous voulez dans la bibliothèque ( menu add > components ), de les placer sur l'espace de dessin, d'éditer leurs propriétés, puis de les relier entre eux avec des "nets node". Rien de bien sorcier en somme, mais voici quelques points qu'il faut penser à vérifier si vous ne voulez pas être ennuyé plus tard :

• Penser à donner un nom unique à chaque composant (via sa propriété refdes)
• Pour les composants "redondants" (c'est à dire les composants qui répètent plusieurs fois la même fonction logique, par exemple les 7404 qui contiennent 6 fonctions logiques "NON") vous ne ferez apparaitre qu'une fonction logique sur le schéma (forcément, c'est un schéma logico-fonctionnel) et pas une empreinte réaliste du composant. Pour retrouver vos petits lorsque vous concevrez le plan physique de votre circuit il faut penser à cette étape à mettre le même nom (propriété refdes) à toutes les fonctions logiques que vous voulez prendre sur le même composant, et à les différencier uniquement en fixant une valeur incrémentale³ (unique) à leur propriété slot.
• Penser à donner une valeur à l'attribut footprint de chaque composant. Cette valeur servira plus-tard à définir l'empreinte physique du composant sur le circuit imprimé. Quelques footprints utilisables peuvent être trouvés dans /usr/share/pcb/pcblib-newlib/geda sur Gentoo, mais personnellement j'ai fini par agréger ma propre librairie de composants afin d'obtenir des descriptions cohérentes utilisables sur l'ensemble des logiciels de la suite gEDA, les composants fournis d'office n'étant généralement plus utilisables dès qu'on veux passer d'un logiciel de la suite à un autre⁴.
• Faite apparaitre vos connecteurs sur le schéma logique :) ! On n'y pense pas forcément lorsqu'on a le nez dans le schéma fonctionnel mais il est essentiel de se rappeler que votre "signal IN" devra bien venir de quelque part sur votre circuit imprimé physique. Vous devez donc absolument ajouter à votre schéma gschem les composants de connectique.

pcb pour créer le plan physique

Une fois le schéma fonctionnel satisfaisant (.sch) vous pouvez lancer pcb, également inclus dans la suite gEDA. Si vous avez bien fait votre fichier ".sch" un petit clic dans le menu File > Import Schematics fera apparaitre l'ensemble des composants physique de votre schéma logique (dans un gros paté au centre de la fenêtre de pcb). Si ça ne marche pas pensez à bien vérifier les points exposés dans la partie gschem ci-dessus, et si ça ne marche toujours pas changez les noms de vos composants pour des noms plus courts et homogènes en casse. Ca a l'air tout con mais j'ai constaté que certains composants qui n'apparaissaient pas dans mon import sur PCB, ont subitement décidés d'apparaitre quand j'ai changé leur nom de quelque chose du type LED_batterie vers quelque chose du type LEDB...allez comprendre !

Une fois l'ensemble de vos composants et connexions correctement chargées dans PCB vous allez pouvoir les disposer sur l'espace qu'occupera votre futur circuit ainsi que faire le routage⁵ à proprement parler. Le routage est une étape qui peut prendre BEAUCOUP de temps, mais elle est malheureusement nécessaire pour obtenir une réalisation physique qui fonctionne. Ci-dessous je vous mets quelques astuces en vrac pour le routage :

• Penser à dé-selectionner, dans la colonne de gauche de l'interface de pcb, les "layers" que vous ne voulez pas utiliser avant de faire appel à la fonction "Auto-route" de pcb. En effet, si vous prévoyez de réaliser votre circuit imprimé sur une seule face (par exemple si vous voulez le graver vous-même par la suite) il ne faut pas que pcb utilise deux couches pour router (or en mode "Auto-route" il utilise autant de couche que possible). Pour ma part je ne garde que 2 "layers" actifs (en plus des layer "silk" et "rat lines" qui ne correspondent qu'à des indices visuels et ne sont donc pas utilisés par la fonction "Auto root") parce que j'utilise plutôt du double couche que du simple. En effet le double couche reste encore raisonnable (on peut graver soit-même des circuits en double couche) et il permet de router des cartes avec beaucoup de connexions sans avoir à ajouter des tas de ponts disgracieux jouant à saute mouton au dessus des pistes comme celà arrive rapidement quand on se restreint au simple couche.
• Penser à faire un gros plan de masse, voire un gros plan au potentiel VCC (pour ce faire vous pouvez, par exemple, utiliser les outils polygone ou rectangle puis les relier à des net via un pin grace à l'outil "therm(al)").
• Jouez avec la largeur et les marges de vos pistes. Plus ces paramètres sont petits plus le routage est facile, mais plus la réalisation physique sera compliquée et moins vous pourrez faire passer de courant.

Création physique !

Une fois votre PCB correctement créé sur le logiciel éponyme il est temps de passer à l'étape physique ! Pour ce faire il y a deux chemins possibles : soit vous fabriquez votre circuit vous-même, soit vous le faite fabriquer par une entreprise spécialisée.

Si vous décidez de fabriquer votre PCB pensez à faire un routage avec des pistes larges et bien espacées. En effet, la réalisation manuelle de PCB est une opération délicate donc moins il y aura de petits détails sur votre plan de PCB moins vous risquerez de faire d'erreur et ce n'est pas du luxe ! Plusieurs méthodes existent pour la réalisation manuelle mais sachez qu'elles impliquent toutes l'utilisation de produits chimiques et peuvent vous prendre plusieurs heures. Ne paniquez pas pour autant, de nombreux amateurs réalisent régulièrement des cartes⁶ donc je vous assure que c'est réalisable. N'ayant moi-même pas choisi cette voie je ne vais cependant pas rentrer dans les détails, mais cherchez sur le net et vous trouverez pleins de gens prêts à vous expliquer comment ils font chacune des deux étapes principales du processus :

• Mise en place d'une couche protectrice sur une plaque cuivrée vierge reprennant la forme de votre circuit à imprimer : Soit vous utilisez des PCB recouvertes d'une résine photosensible et vous détruisez sélectivement cette résine en exposant la plaque à la lumière derrière un transparent sur lequel vous avez imprimé votre circuit; soit vous imprimez une image mirroire de votre circuit avec une imprimante laser sur du papier de mauvaise qualité (en espérant ne pas tuer votre imprimante) puis vous tentez de faire un "décalcomanie" de votre impression sur une plaque de cuivre nue avec un bête fer à repasser.

• Trempage de la plaque, avec son masque protecteur, dans une solution qui va dissoudre le cuivre non-protégé et donc "graver" les contours de votre circuit : soit vous utilisez le produit chimique "standard" que vous devrez acheter pour une dizaine d'euros en magasin spécialisé (ce produit chimique est réutilisable), soit vous tentez de concocter vous-même un autre produit chimique à base d'eau oxygénée à vos risques et périls.

• Suppression du masque protecteur une fois la gravure terminée pour découvrir vos pistes de cuivres : selon les méthodes suivies aux étapes précédentes ça peut être aussi simple que de laisser la plaque au soleil, ou un poil plus compliqué type "tamponnage de disolvant à l'aide d'un coton tige".

Si, en revanche, vous décidez de faire fabriquer votre PCB par une entreprise spécialisée soyez averti : ça coute cher ! La conception de circuits imprimés amateur n'est pas encore follement répandue et les tarifs restent avant tout orientés vers des tirages en série, le mode de facturation/production n'est donc généralement pas adapté aux besoins d'amateurs souhaitant n'avoir qu'un ou deux prototypes. Vous trouverez ainsi souvent un montant forfaitaire d'une trentaine d'euros pour "préparation des outils", puis comptez une autre trentaine d'euros pour une impression sur des PCB carré double face de moins de 10cm de cotés, et ajoutez enfin à celà une dizaine d'euros de frais de livraison. Pour ma part j'ai eu énormément de chance et j'ai pu faire appel à un petit fournisseur asiatique qui m'a réalisé 10 exemplaires de mon circuit (5,50cm par 5cm en double face) pour seulement 25€, donc je n'ai pas hésité :) ! Bref, ce qu'il faut retenir si vous voulez faire fabriquer vos circuits :

• La tarification est souvent élevée et parfois obscure, mais il existe tout de même quelques fournisseurs qui mérittent le coup d'oeil.
• Les entreprises acceptent généralement le format "gerber" pour vos fichiers, c'est un format vers lequel pcb sait exporter donc tout va bien⁷; mais parfois ils n'acceptent que le format du logiciel Eagle qui est un logiciel non-libre...à moins de tout recommencer sous ce logiciel vous ne pourrez donc pas faire appel à ces entreprises.

Une fois votre PCB nu en main⁸ vous n'avez plus qu'à vérifier qu'il n'y a pas de court-circuit apparent sur les contacts accessibles, puis à souder les composants en place (cf la photo du paragraphe précédent) et à faire vos tests unitaires en croisant les doigts !

Conclusion sur le combo gschem/pcb

Le message essentiel à retenir sur la conception c'est qu'il est vraiment important d'avoir des librairies de composants cohérents à utiliser sous gschem et pcb. Il n'y a rien de plus rageant que de faire son circuit logique sous gschem pour se rendre compte ensuite que le "footprint" que l'on a mis à toutes ses résistances est inconnu de pcb (et donc inutilisable) ou encore que le "footprint" de vos diodes d'électronicien correspond en fait à un composant de puissance d'un mètre de diamètre pour pcb -_- ... Pour ma part j'ai honteusement pioché/tranché dans les composants fourni avec gEDA sous ma gentoo ainsi que dans les nombreux éléments téléchargeables sur internet grâce aux explications de ce site de référence. Ayant tranché comme un goret dans des parties de code (et de commentaires, dont certains contenaient le descriptif de la version de license utilisée) pour rassembler ma petite librairie de composants je ne vais pas la rendre téléchargeable avec ce billet; mais si vous la voulez envoyez moi un mail et je pourrai vous passer une copie "en privée".

Enfin, quelques dernières remarques en vrac qui pourront vous aider si vous rencontrez des problèmes de composants incompatibles entre gschem et pcb⁹ :

• Favorisez les composants dont les PIN sont numérotées (plutôt que "lettrées") dans gschem. Par exemple préférez le modèle "capacitor" dont les pins sont labélisées "1" et "2" plutôt que "P" et "N". En effet les symboles dans pcb utilisent plutôt des numérotations que des lettres donc si vous voulez que pcb parvienne à retrouver les connexions rentrées dans gschem il faut que les références des pins des symboles pcb soient les même que celles des symboles gschem.

• Quelques associations "composant <==> footprint" qui marchaient pas trop mal dans pcb et qui étaient fournis dans ma Gentoo :

capacitor-2.sym <==> RCY100P 
lm7805-1.sym <==> TO126W
connector2-1.sym <==> JUMPER2
resistor-1.sym <==> ACY800
led-3.sym <==> RCY100

• Les connecteurs sont parmi les composants les plus pénibles à traiter. En effet leurs formes sont souvent assez spécifique et il est essentiel qu'ils aient la bonne représentation dans pcb sous peine de vous retrouver avec un circuit imprimé inutilisable parce que vous n'avez pas la place de souder vos connecteurs. Pour ma part j'ai été obligé de créer mes modèles de connecteurs de toute pièce afin d'en avoir qui marchent¹⁰. Parmi les problèmes que j'ai cru identifier : les "connectors" fourni avec mon gschem ont des pin de type pas(siv) qui, visiblement, ne plaisent pas à pcb; du coup j'ai refait les connecteurs avec des pins de type io. Ah et mes connecteurs étaient également particulièrement sensibles aux blagues de nommage dont je vous parlais plus haut : quasiment tout ceux dont le nom dépassait 5 caractères n'étaient pas importés dans pcb...

En guise de conclusion : concevoir ses circuits imprimés ex nihilo jusqu'à obtenir un circuit physique qui fonctionne c'est une grande satisfaction (surtout pour moi qui ne pigeait rien à l'électronique il y a 4 ans); et même si le "motor shield" compatible arduino que j'ai réalisé et qui illustre intégralement cet article est bourré de maladresse de conception¹¹ j'en suis très content et j'aurai peut-être l'occasion d'en faire bon usage :D !

1. Billet qui a déjà presque 2 ans...le temps passe vite :) ↩
2. Dessiner/Relire des schémas logique à peine plus haut niveau que ceux dont nous parlons ici semble justement amuser follement beaucoup de monde en France ces temps-ci ;-) ↩
3. En commençant à compter à 1, donc 1,2,3,4,5 et 6 pour un 7404...Bah ouais c'est de l'électronique, pas de l'informatique donc on commence à "1". ↩
4. Douce ironie: les logiciels qui comptent plusieurs dizaines de miliers de ligne de code sont compatibles entre eux, mais les composants comptant à peine 20 lignes de texte, eux, ne sont pas prévu pour fournir des informatios à tout les logiciels... ↩
5. C'est à dire tracer les connexions physiques entre les différentes pates de vos composants. ↩
6. J'en connais plusieurs, et pourtant ils ne sont pas masochistes. ↩
7. Vous pouvez ensuite utiliser le logiciel gerbv pour visualiser les fichiers gerber générés par pcb avant de les envoyer à votre fabricant ↩
8. PCB nu tel que celui qui illustre ce billet, tout juste sorti de sa boite de livraison. ↩
9. Remarques qui vont surtout me servir de pense-bête personnel pour le jour où je voudrait rajouter des composants à ma bibliothèque et que j'aurai tout oublié :D ↩
10. Et encore...Je m'étais trompé dans l'espacement entre les deux pates de mon connecteurs, si bien que j'ai du les tordres à la pince pour les espacer afin qu'ils puissent s'enfiler correctement dans les trous prévus à cet effet dans mes circuits imprimés reçus d'Asie. Trous qui, celà dit en passant, étaient largement surdimensionnés pour mes connecteurs, j'aurai du modifier mes empreintes pcb pour utiliser des trous de la même taille que ceux destinés à accueillir les pates de mes autres composants. ↩
11. Pas de plan de masse, pas de condensateurs filtrant les parasites, pas de résistance de pull-up, etc... Mais les fichiers sont quand même disponibles si vous me les demandez par mail ;-) ↩

Après plusieurs billets assez pauvre en contenu je me suis dit que résumer un micro-projet mettant en oeuvre plusieurs techniques différentes serait une bonne idée. Voici donc le résumé de la création d'un petit jouet qui m'a couté environ 7€ ¹ ! Je vous laisse découvrir un à un les différents domaines que j'ai associés et essayer de deviner au fil de l'eau ce que j'obtient à la fin et qui constitue le but de ce projet (ainsi que le titre du billet...j'aurai d'ailleurs du y mettre des balises SPOIL ^^ ). Bonne lecture !

Un peu de vision

J'ai déjà expliqué sur ce blog comment on peut facilement programmer un micro-controlleur², et nous avons également déjà vu comment utiliser ces micro-controlleurs pour faire tourner des moteurs, ce qui permet (par exemple) de faire bouger un robot. Nous savons donc à présent comment fabriquer un robot qui agit sur le monde (en s'y déplaçant) mais nous n'avons pas encore vu de méthode pour que le robot prenne connaissance du monde (or d'aucun diront qu'il est intéressant de comprendre son environnement avant d'agir). La première connaissance nouvelle que nous allons aborder dans ce billet c'est justement comment mesurer la distance qui sépare notre robot d'un obstacle situé devant lui.

Beaucoup de méthodes existent pour mesurer des distances sans contact. On peut par exemple citer les mesures de déphasages entre un rayon laser émis et son reflet renvoyé par l'obstacle, les mesures de focalisation d'un signal lumineux (généralement infra-rouge) émis puis réfléchi par l'obstacle, ou encore la mesure de temps entre l'émission d'un signal acoustique (généralement ultra-son) et la réception de son écho produit par l'obstacle.

Dans ce mini-projet j'ai opté pour la mesure par ultra-son, pour deux raisons :

• c'est la méthode la moins chère (on trouve des modules tout fait à moins de 1.50€ sur eBay, à moins de 6$ sur amazon, à moins de 10€ sur robotshop, ou à 15€ chez gotronic pour la classe au dessus).
• Ces modèles peu onéreux permettent pourtant déjà de mesurer des distances allant, classiquement, de quelques centimètres à environ 4m, ce qui est parfait pour un usage en intérieur.

Plus précisément j'ai opté pour un HC-SR04, qui semble être l'un des modèles les plus répandus (mais pas l'un des plus fiables).

Le fonctionnement de ce module est simplissime : on branche la PIN "GND" du module à la masse de notre circuit, la PIN "VCC" à une alimentation 5V, et les PIN "trig(ger)" et "echo" chacune à une I/O de notre microcontrolleur. Pour mesurer la distance qui sépare ce module d'un obstacle situé devant lui on envoie simplement une impulsion positive d'environ 10us sur la PIN "trigger" du module, puis on mesure la longueur de l'impulsion positive que nous envoie le module en réponse sur sa PIN "echo". La longueur de l'impulsion de réponse (sur la PIN "echo") est proportionnelle au temps mis par le son pour faire l'aller-retour entre le module et le premier obstacle rencontré (la vitesse du son étant à peu près constante on en déduit alors la distance qui sépare le module du premier obstacle situé devant lui). Pour être précis on considère que 1cm se traduit en environ 58uS d'impulsion "echo"; si je reçois une impulsion retour qui dure 580uS j'en déduis donc qu'il y a un obstacle à environ 10cm devant mon module. Trivial³ !

Un peu d'action (controllée)

La denière fois que nous avons parlé d'agir sur le monde depuis un microcontrolleur nous avions fait tourner des moteurs, dans un sens ou dans l'autre, à une vitesse arbitraire. C'est déjà très pratique, mais pas vraiment adapté à des mouvements finements controllés; en effet nous ignorons tout de la vitesse réelle de rotation du moteur (en fonction de la résistance qu'il rencontrera lors de sa rotation il tournera plus ou moins vite pour une même commande donnée). Pour palier ce manque de précision nous avons, là encore, de nombreuses options qui s'offrent à nous. Nous pouvons par exemple asservir la commande du moteur à la lecture de capteurs qui nous renseigneront sur la rotation réellement effectuée, ou nous pouvons opter pour des moteurs "pas à pas" plus compliqués à commander mais qui offrent une bien meilleure précision de commande, ou encore nous pouvons utiliser des servomoteurs qui permettent d'obtenir directement un déplacement asservi.

Pour ce petit projet nous allons opter pour un servomoteur. J'aurai pu avantageusement partir sur un moteur pas à pas mais j'avais besoin de jouer avec des servomoteurs pour un autre projet donc j'ai décidé de faire d'un pierre deux coups et de mettre également un servomoteur dans ce micro-projet. En plus, comme les capteurs ultrason hc-sr04, les servomoteurs ont le bon gout d'être simple à utiliser et peu cher (on en trouve à moins de 2€ sur eBay, à 3$ sur amazon, à un peu plus de 4€ chez gotronic, ou encore à une quinzaine d'euros chez selectronic pour la gamme au dessus).

Généralement les servomoteurs se connectent via 3 fils. Les couleurs varient selon les constructeurs mais vous pourrez trouver facilement les équivalences en cherchant sur internet. Les servomoteurs que j'ai (les même que celui de la photo ci-dessus) suivent les couleurs traditionnelles du constructeur Graupner :

• un fil marron que je dois brancher à la masse
• un fil rouge que je dois brancher à mon "VCC" (alimentation 5V);
• un fil orange sur lequel je dois envoyer la commande. Comme je vous l'ai déjà dit la commande d'un servomoteur est simple : on doit envoyer sur le fil de commande, à intervalle régulier (environ toutes les 20ms au plus), une impulsion positive dont la largeur est notre commande⁴. L'impulsion doit avoir une largeur comprise, environ, entre 0,5ms et 2,5ms. Lorsque la commande est correctement envoyée l'axe du servomoteur s'aligne sur un angle compris entre 0° et 180°, proportionnellement à la commande envoyée⁵. Donc si j'envoie, toutes les 20ms, des impulsions de 0,5ms sur la commande de mon servomoteur celui-ci va s'aligner sur -90° et ne plus en bouger. Si j'allonge mes impulsions jusqu'à 1,5ms l'axe du servomoteur va tourner environ jusqu'à 0° et ne plus bouger. Enfin si je rallonge mon impulsion jusqu'à 2,5ms l'axe va sagement s'aligner sur +90°. L'avantage d'avoir un asservissement directement dans le servomoteur c'est que son axe va s'aligner à un angle correspondant à ma commande quelque soit la résistance à son mouvement, je n'ai pas à me préoccuper d'asservir le bouzin, c'est prévu dans le forfait de base.

Un peu de dialogue

Les amateurs d'arduino sont habitués à communiquer avec leur joujou préféré depuis leur PC en le branchant simplement en USB, seulement voilà : les atmega8 n'ont pas de port USB et donc pas de méthodes native pour discutter avec un PC. Pour palier ce "problème" nous avons, encore une fois, plusieurs solutions :

• Nous pouvons opter pour un autre microcontroleur qui supporte l'USB nativement comme les atmega8u2 ou les AT90USB
• Nous pouvons implémenter le protocole USB directement en logiciel sur notre atmega8
• Nous pouvons faire appel à un chip externe qui va dialoguer en USB d'un coté et en "autre chose compréhensible par un atmega8" de l'autre.

Les microcontrolleurs incluant directement le support de l'USB ont l'inconvénient d'être plus cher que nos composants "low cost" (atmega8, atmega328, attinyX5, etc.), mais surtout ils sont plutôt disponible au format TQFP qu'au format DIP⁶, donc j'exclus cette solution pour ce mini projet.

Implémenter la pile USB sur un atmega8 c'est sympa, mais comme je ne maitrise pas encore toutes les subtilités du débugage sur microcontrolleurs et que, de toute façon, la gestion USB pomperait quasiment toutes les resources du microcontrolleur, j'exclus aussi cette solution.

Il nous reste donc le passage par un "interprète". Ca tombe bien, sur internet on peut trouver des petits montages tout fait autour du chipset cp2102 pour moins de 2€ sur eBay ou moins de 9$ sur DX.

Ces petits montages discutent en USB avec l'ordinateur, et en UART avec notre microcontrolleur. Avantage certain : les chipsets cp2102 sont pris en charge directement par le noyau linux depuis la version 2.6.12, il suffit donc de le brancher pour se retrouver avec un /dev/ttyUSBX fonctionnel qui fait le pont jusqu'à notre microcontrolleur :) Coté microcontrolleur l'UART est un protocole de communication série "universel" intégré en hardware dans les atmega8 et supérieurs⁷ ce qui permet de ne consommer quasiment aucune ressource de calcul !

Une fois le montage branché il nous suffit donc de coder la communication. Coté microcontrolleur c'est supporté en hardware, donc après la routine d'initialisation le code d'envoi d'un octet se résume à vérifier que le flag "REady" est positionné, puis à inscrire l'octet à envoyer dans le registre dédié "UDR" (on fait difficilement plus simple...) :

/* Wait for empty transmit buffer */
while ( !( UCSRA & (1<<UDRE)) ) {};
/* Put data into buffer, sends the data */ 
UDR = data;

Coté PC c'est de la communication série standard, vous pouvez donc utiliser des softs "tout fait" comme minicom, ou dénicher une librairie de communication série pour dialoguer à partir de votre language de script préféré :

import serial
ser = serial.Serial('/dev/ttyUSB0', 4800, stopbits = serial.STOPBITS_TWO, parity = serial.PARITY_ODD)
while True:
    print ord(ser.read(1))

Bien entendu la communication peut être bi-directionnelle sans aucune modification matérielle et sans vraiment plus d'effort de code (il faut remplacer ser.read par ser.write en python et lire un registre au lieu d'en écrire un du coté de l'atmega...dur n'est ce pas ?).

Un peu de superficiel

Je suppose maintenant que vous voyez où on va avec ces différentes briquettes et le titre de ce billet : nous montons une "tourelle de surveillance" (visible sur la photo tout en haut de ce billet). Cette "tourelle" va être constituée d'un capteur de distance à ultra-son, monté sur un servomoteur, controllé par un atmega8, communiquant avec un PC via UART/USB. L'idée c'est que nous allons mesurer la distance qui nous sépare d'un obstacle "devant nous", puis nous allons faire tourner le servomoteur de quelques degrés et nous allons à nouveau faire une mesure de distance. En itérant ainsi le procédé nous pouvons obtenir une cartographie à 180° de la distance qui nous sépare du premier obstacle; obtenant ainsi une vision partielle de la pièce dans laquelle nous sommes. Grace à la communication avec le PC nous pouvons, en prime, obtenir une jolie visualisation de ces informations à la façon "radar".

Pour ne pas changer les bonnes habitudes j'ai codé tout le bouzin en python :

• Pour réaliser la communication j'utilise la librairie "pyserial"
• Pour faire une "jolie visualisation" j'utilise pygame.

Avec ces deux éléments, un peu d'huile de coude, et 93 lignes de python (commentaires inclus), j'obtiens un joli écran "radar" ^^ Grace à la fonction pygame.image.save c'est un jeu d'enfant de sauvegarder chaque frame affichée, et grace à la toute puissance de la ligne de commande linux je peux vous faire partager le résultat facilement :

Pour ceux qui ne connaissent pas la pièce ça ne ressemble sans doute pas à grand chose, mais moi je vois bien les deux murs de ma pièce, la porte (ouverte) entre les deux murs, et mon armoire tout à droite (quand au gros obstacle collé tout à gauche du capteur...c'est moi -_-)

Conclusion

Et c'est tout pour ce résumé de la création d'un micro jouet conçu et bidouillé en quelques heures seulements :) Vous noterez que j'ai jeté un voile pudique sur la partie mécanique du projet, mais j'ai bien l'intention de revenir dessus dans un article ultérieur puisque c'est un domaine sur lequel j'ai également réalisé pas mal de recherches et progrès récemment, notamment grace à l'excellent "Guerrilla guide to CNC machining, mold making, and resin casting"⁸ et à ce produit miracle que l'on appelle "polymorph plastic".

En guise d'ultime conclusion un petit rappel des couts de construction (hors mécanique; comptez moins de 5€ de mécanique) :

Atmega8     1.50
UART-USB    1.80
servo       2
HC-SR04     1.50
============
TOTAL       6.80 €

1. Sans compter la main d'oeuvre, évidemment ;-) ↩
2. Vous pouvez également utiliser un arduino, c'est juste un peu plus cher ↩
3. Attention, le fonctionnement de ce module HC-SR04 vu "de l'extérieur" est trivial mais je vous rassure : son fonctionnement complet est un poil plus complexe. En effet, afin d'éviter d'être perturbé par des bruits parasites, le module se charge d'envoyer en réalité plusieurs trains d'ondes séparés pour fiabiliser sa mesure. C'est l'intérêt d'un module "tout fait" par rapport à un système bricolé à la main à partir des éléments d'émission et de réception ultra-son uniquement. ↩
4. Une méthode simple de faire ça sans consommer de temps de calcul de notre microcontrolleur c'est d'utiliser une PWM dont la fréquence avoisinne les 50/60Hz ↩
5. je ne parierai pas sur la linéarité de la relation entre l'angle du servomoteur et la largeur de l'impulsion ceci-dit... ↩
6. Petite parenthèse : le format "DIP" c'est le format standard du prototypage, c'est facilement manipulable et soudable à la main, les pattes des composants sont espacés de 2.54mm. Le format "TQFP" en revanche est nettement plus petit et, bien qu'il soit soudable à la main, vous allez galérer pour le manipuler et le mettre en place correctement puisque les pates peuvent s'y trouver espacées de seulement 0.4mm. ↩
7. Les attiny n'embarquent qu'une version "light" de l'UART que je n'ai pas testé, mais j'ose espérer que ça marche quand même ↩
8. Guide rédigé par Michal Zalewski alias lcamtuf qui ne se contente pas d'être un expert reconnu en sécurité informatique mais qui réalise aussi de bien jolis robots. Bref : un gars certainement très bien :-D ! ↩

Ce qu'il y a de bien avec l'état d'esprit du "hack" c'est qu'on peut l'employer dans de nombreux domaines. Et ce qu'il y a de très bien c'est qu'on peut faire des combinaisons de plusieurs domaines ! Par exemple on peut faire un combo programmation/électronique/biologie et obtenir des petites expériences amusantes comme celle que je vais retranscrire ici.

L'idée de départ c'est qu'habitant en ville je ne peux planter aucun végétal "naturellement". A la rigueur je dispose de deux rebords de fenêtre pour poser des petits pots ou des jardinières mais c'est quand même super limité. Du coup comment faire pour améliorer autant que possible la pouse de jolies plantes carnivores ? La solution simple c'est d'abandonner la méthode "naturelle" (i.e. : fabriquer une tourbière de quelques mètres carrés avec écoulement d'eau permanent pour recréer des conditions marécageuses) et passer à de l'artificiel.

"Artificiel" ça peut recouper beaucoup de choses et du coup je me suis renseigné. J'ai ainsi découvert et approfondi les méthodes de cultures allant de la simple serre, à la culture aéroponique/ultraponique, en passant par l'hydroponique et l'aquaponique. Toutes ces méthodes semblent intéressantes mais il y a un point que j'ai trouvé systématiquement mal traité : l'éclairage. En effet on comprend vite que les méthodes en ultraponie, en hydroponie, ou en aquaponie, adressent principalement des problématiques d'arrosage; mais le problème de l'éclairage, lui, est souvent traité d'une façon qui m'a laissé sur ma faim. Bien souvent en effet les seuls remarques que l'on peut trouver sur l'éclairage se résument à quelque chose du genre : "une lampe au sodium super puissante, puisque c'est ce qui s'approche le plus de la vrai lumière du soleil et que ça chauffera super bien ta culture en placard où tu pourra planter plein d'herbe de provence¹"

Ce genre de réponse ne me satisfait pas du tout puisqu'elle vise une problématique qui n'est pas la mienne. En effet ce type de réponse vise le problème de recréer des conditions naturelles dans un espace à l'abri des regards (à savoir un placard -_-); ma problématique à moi c'est de faire pousser des plantes carnivores (et des tomates cerises²). Ayant quelques bases en optique je me disais que les plantes n'avaient pas besoin de tout le spectre lumineux du soleil pour bien pousser, et du coup j'ai été faire un petit tour sur wikipédia pour obtenir le spectre d'absorbtion de la chlorophyle :

En regardant ça je me suis dit qu'il était probablement superflus de vouloir recréer un spectre lumineux continu, et je me suis dit qu'il était certainement énergétiquement plus intéressant de faire un éclairage par LED à des fréquences de couleur bien choisies :) ! J'ai farfouillé sur le net pour savoir si quelqu'un avait déjà fait ce genre d'expérience mais ce ne fut pas très fructueux. J'ai bien trouvé quelques personnes qui disaient qu'il fallait faire pousser sous du rouge, d'autre sous du rouge et du bleue, mais aucune référence sérieuse pour étayer le propos. Devant ce manque d'information pour me guider dans le choix (dois-je prendre des LED bleues ? Rouge ? Un mélange des deux ?) j'ai pris la décision le plus "simple" : faire un test³.

Le protocole de test est simple : je vais réaliser en même temps 5 cultures de graines issus d'un même lot et semées dans un même terreau. L'une de ces cultures sera laissée à la lumière naturelle, l'une sera plongée dans le noir total, et les trois autres seront respectivement éclairés exclusivement par une diode rouge, bleue, et UV⁴.

Pour cette expérience je vais donc utiliser 4 pots en plastique noir. L'un sera directement retourné sur la culture qui ne doit pas avoir de lumière, et les trois autres seront préparés pour éclairer au mieux d'une unique couleur les cultures qu'ils recouvreront. La préparation est simple : j'ai recouvert les bords intérieurs de papier aluminium afin que le maximum de lumière atteigne les plants, j'ai planté une diode sur le fond du pot pour que ses connections soient accessible de "l'extérieur", et j'ai calibré une résistance série pour que chaque diode consomme autant de puissance électrique malgré la différence de chute de tension à leur bornes :

Pour garder les diodes allumées 12h par jour, et éteintes 12h par jour j'avais deux solutions : les allumer moi-même à heure fixe tout les matins et les éteindre tout les soirs; ou opter pour une méthode de feignasse et utiliser un microcontrolleur pour qu'il fasse ça à ma place. Bien évidemment j'ai opté pour la solution micro-controlleur (ce qui m'a permit de m'entrainer à la gestion des timers et des interruptions, ainsi que de constater que si je veux faire une "vrai" horloge un jour il faudra que j'utilise un chip RTC pour compenser la dérive de l'oscillateur interne du micro-controlleur⁵). Si vous êtes curieux vous pouvez aller jeter un oeil au code que j'ai mis en pièce jointe de ce billet, m'enfin il n'est pas très intéressant puisque 70% du code porte sur l'affichage et le réglage de l'heure (affichage réalisé par un afficheur 7 segment, et réglé par un unique bouton permettant d'avancer le temps).

Il ne reste donc plus qu'à mettre le terreau dans un grand bac en plastique, à y semer des lentilles vertes (parce que, de mémoire de classe de CP, ça pousse super facilement et rapidement ces trucs là) et à lancer l'expérience. Voilà donc à quoi ressemble le montage expérimental :

Après une dizaine de jours les résultats sont surprenants :) !

Pendant la germination nous avons deux cultures qui ont nettement pris la tête : la culture obscure (!!), et la culture rouge. Ces deux cultures étant suivi de prêt par les cultures bleue et UV, elles-même tallonnées par la culture au soleil.

Une fois la germination effectuée et les premières feuilles sorties on assiste à un équilibrage des 5 cultures en termes de longueur de pousse (y compris de l'obscure donc !). La seule culture qui se détache nettement des 4 autres reste néanmoins l'obscure puisqu'au lieu d'avoir de jolis plants verts elle a des plants blanchatre qui ont un peu de mal à tenir vertical.

Si vous voulez plus de détails sur le déroulement précis de la pousse de chaque échantillon vous pouvez télécharger le fichier ZIP joint à cet article, il contient quasiment une photo pour chaque jour d'expérience.

A partir de cette expérience super simpliste les questions ouvertes sont pourtant nombreuses :

• Pourquoi le pot obscur germe-t-il aussi vite ? Est-ce grace à l'effet "serre" du pot opaque qui augmente l'humidité ?
• J'ai visé du bleue, du rouge, et de l'UV, qui sont tout les trois normalement assez bien exploités par la chlorophyle; cependant le relatif "match nul" au bout de l'expérience me fait penser que j'aurai pu tenter une culture sous lumière verte pour vérifier si, comme la théorie l'indique, j'aurai obtenu les même résultats que dans l'obscurité (ou pas ?!)
• Mes cultures sous lumière artificielle ont poussé quasiment à la même vitesse que celle exposée à la lumière du jour; que se passe-t-il si je double la puissance lumineuse artificielle ? Et si je la divise par deux ?
• J'ai imposé des cycles jours/nuit de 12h/12h à mes cultures sous lumière artificielle. Que se passe-t-il si j'accélère ou si je ralenti ce cycle ?
• Enfin une question évidente : que se passe-t-il sur une durée de vie plus longue de la plante (là j'ai abandonné l'expérience avant la maturation complète des lentilles faute de parvenir à bricoler des serres opaques assez grandes) ? De même que se passe-t-il sur d'autres plantes (par exemple sur les tomates cerises et les drosera/nepenthes que je vise) ?

Enfin, en guise de conclusion, je constaterait la chose suivante : Chaque LED utilisait environ 54mW de puissance électrique (51.5mW pour le rouge, 54.4mW pour le bleue, et 57.8mW pour l'UV), les pots faisant 7x7cm à la base (mesure intérieure) on est donc sur une consommation de 11W/m² pour l'éclairage, c'est à dire une énergie consommée de 48kWh pour un an d'éclairage. Si on recoupe avec les infos de Wikipédia sur les panneaux solaires (à savoir qu'un m² de panneau solaire a une puissance d'environ 150Watt Crete et qu'en Europe 1Watt Crete permet de produire environ 1kWh/an⁶) on obtient qu'un panneau solaire de 1m² pourrait, sur une année, fournir assez de puissance (150kWh) pour éclairer environ 3m² de culture :) Intéressant, non ?

1. J'ai mis "herbe de provence" mais en réalité internet est submergé de conseils pour faire pousser un tout autre type de plante (dont, perso, la méthode de pousse m'intéresse encore moins que celle des herbes de provence). ↩
2. j'ai été obligé par ma copine ↩
3. On peut également dire "expérience" pour faire plus scientifique. ↩
4. Référez-vous à la courbe d'absorbtion de la chlorophyle, vos verrez que le rouge vise un pic important sur la chlorophyle A, la bleue vise un pic important de chlorophyle B, et l'UV tape un plateau correcte pour la A et un peu la B ↩
5. Sur la durée de l'expérience, à savoir un peu plus de 10 jours, l'horloge de l'Atmega8 avait pris un peu plus d'une heure de décalage. ↩
6. Avec une forte variance, en gros entre 0.5 et 1.4 ↩

Le 9 mars 2011 dernier (merci Twitter pour la date exacte) j'ai acheté un arduino. Depuis j'ai pas mal joué avec et j'en arrive aujourd'hui à vouloir utiliser au jour le jour certains de mes bricolages. Le problème c'est que si je dois acheter un arduino pour chaque bricolage que je veux garder et utiliser quotidiennement ça risque de taper sérieusement dans mon budget. Heureusement il y a pleins de solutions à ce problème.

La première solution c'est de ne tout simplement jamais utiliser d'arduino et d'oublier carrément les micro-controlleurs Atmega. L'un de mes amis, qui fait de l'électronique depuis des années, a ainsi toujours utilisé des PIC. L'avantage des PIC, par rapport aux Arduino, c'est leur prix ridicule (comptez quelques dizaines de centimes d'euros pour les plus petits alors qu'un arduino coutera minimum une quinzaine d'euros). Mais l'inconvénient majeur des PIC c'est qu'il vous faudra un programmeur matériel dédié pour uploader vos programmes dessus, et que ce programmeur dédié coute cher (comptez une trentaine ou une cinquantaine d'euros).

La seconde solution c'est d'utiliser des Atmega nu. Les Atmega c'est la famille des micro-controlleurs qui sont au coeur des Arduino. En fait un Arduino c'est un atmega avec un peu d'électronique autour pour uploader les instructions sans programmeur externe, et pas mal de logiciel pour rendre ultra simple le codage, la compilation, et l'upload sur l'Atmega. Donc quand on utilise un Arduino en fait on utilise un Atmega :) L'avantage des Atmega (et leur petits frêres les Attiny) c'est le prix du programmeur externe, en effet vous pouvez utiliser votre Arduino comme programmeur pour Atmega (via le sketch ArduinoISP, donc aucun investissement supplémentaire si vous arrivez à le faire marcher) ou bien en acheter un tout fait et dédié à cet usage (ce qui est beaucoup plus simple à mon gout) pour la modique somme de 3€ sur eBay. L'inconvénient c'est que les Atmega (et les Attiny) sont plus chers que les PIC (et qu'il existe également moins de modèles différents); mais ne vous affolez pas ça reste quand même largement moins cher qu'un arduino complet et vous n'aurez donc aucun scrupule à "investir" 1 ou 2 euros dans un Atmega destiné à rester à perpétuité dans votre bricolage numéro 3454464béta :D

Dans l'idée de fabriquer des bricolages "définitifs" je me suis donc orienté vers la seconde option : programmeur matériel dédié à acheter une fois et atmega (ou attiny) indépendant à acheter pour chaque montage "définitif". Le prix de cette migration a donc été pour mon cas de :

• 3€ pour un programmeur dédié USBASP (acheté sur eBay)
• 1,30€ pièce pour des Atmega8 (également achetés sur eBay)
• ou 3,5€ pièce pour des ATtiny85 (encore et toujours achetés sur eBay) à la place des Atmega8 si je veux un tout petit montage.

Par contre en basculant sur du micro-controlleur indépendant on perd un avantage énorme de l'arduino : l'IDE et ses bibliothèques simplifiant monstrueusement la tache du codeur. A titre d'exemple voilà le code Arduino qui fait clignoter une LED (l'équivaleur électronique de "Hello World") :

void setup() {                
  // initialize the digital pin 13 as an output.
  pinMode(13, OUTPUT);     
}

void loop() {
  digitalWrite(13, HIGH);   // set the LED on
  delay(1000);              // wait for a second
  digitalWrite(13, LOW);    // set the LED off
  delay(1000);              // wait for a second
}

Et, pour comparer, le même code pour ATtiny85 sans utiliser les librairies Arduino :

#include<avr/io.h>
#include<util/delay.h>

void sleep(int millisec) {
    while(millisec)
    {
        _delay_ms(1);/* 1 ms delay */
        millisec--;
    }
}

main() {
    DDRB |= 1<<PB3; /*PB3 is now an output*/
    while(1) {
        PORTB &= ~(1<<PB3); /* PB3 low */
        sleep(1500); /* 1.5s delay */

        PORTB |= (1<<PB3); /* PB3 high */
        sleep(3000); /* 3s delay */
    }
}

Tout de suite c'est quand même moins user-friendly. Et encore, là on fait juste clignoter une LED. Soyez assurés que quand on joue avec les interruptions c'est encore plus moche. M'enfin bon, ça reste quand même compréhensible, donc poursuivons. Quand on utilise l'IDE Arduino on branche son arduino en USB, on écrit son code, puis on clique sur le bouton "compile and upload" et c'est fini, l'Arduino se comporte comme on l'a programmé. Quand on utilise un micro-controlleur indépendant c'est "un poil" plus compliqué.

D'abord il faut brancher l'USBASP (notre programmeur matériel dédié) : Coté USB c'est trivial, coté Micro-controlleur il faut ressortir la doc des branchements. Une fois la doc sous les yeux le branchement est simple puisqu'il suffit de se débrouiller pour que les fils MOSI/MISO/SCK/RST du programmeur correspondent aux pates MOSI/MISO/SCK/RST du micro-controlleur. Ca n'a rien de sorcier mais on est obligé de ressortir le schéma à chaque fois (parce que, franchement, l'apprendre par coeur...). Branchement coté programmeur :

Et branchement coté micro-controlleur (ci-dessous pour les attiny) :

Une fois correctement branché il faut coder (pour ça on peut être certain que vim ne nous laissera pas tomber :)). Ensuite on compile avec avr-gcc en faisant attention de bien choisir la plateforme cible :

avr-gcc -mmcu=attiny85 ledblink.c -Os -o ledblink_tiny85.o

Une fois compilé on extrait le code intéressant au format ihex :

avr-objcopy -j .text -j .data -O ihex ledblink_tiny85.o ledblink_tiny85.hex

Il ne reste plus qu'à uploader le code sur notre micro-controlleur à 3€ :

avrdude -p /dev/ttyS3 -c usbasp -p t85 -v -U flash:w:ledblink_tiny85.hex

Et "voilà" la LED qu'on a branché sur la pate PB3 de l'attiny (via une résistance de plus de 300 ohms pour ne pas la cramer) clignote gentiment. Maintenant plus rien ne s'oppose à la réalisation de montages permanents coutant moins de 10€ :) !

EDIT 14/04/2012 : chez moi par défaut avr-gcc ne trouve par le fichier "crtm8.o" et du coup il ne parvient pas à linker correctement quand je lui spécifie une cible "atmega8" à la place de "attiny85". Pour régler le problème il suffit de lui rappeler où trouver "crtm8.o" avec son option -B:

avr-gcc -mmcu=atmega8 ledblink.c -Os -o ledblink_atmega8.o -B /usr/avr/lib/avr4/

La suite reste similaire à l'exemple donné pour l'attiny85:

avr-objcopy -j .text -j .data  -O ihex ledblink_atmega8.o ledblink_atmega8.hex

Et pour l'upload on change juste l'option "-p" en mettant "m8" (= atmega8) à la place de "t85" (=attiny85) :

avrdude -p /dev/ttyS1 -c usbasp -p m8 -v -U flash:w:ledblink_atmega8.hex

EDIT2 14/04/2012 : Rajout en fichier joint d'un exemple de code réalisant deux Fast PWM sur atmega8 (typiquement pour diriger un robot)