Archive

Posts Tagged ‘arduino’

Éclairage à leds : Réalisation

novembre 6, 2018 Laisser un commentaire

Mon contrôleur de leds RGB en est resté à… l’état de prototype. Un prototype fonctionnel et presque autonome avec son alimentation euh… intégrée. Il fait appel à des composants pour ainsi dire standard :

  • Bloc d’alimentation secteur, 12V en sortie, et assez d’ampères.
  • Convertisseur 12 volts vers 5 et 3.3 volts
  • Un clône d’Arduino Mini (5V, 16 MHz)
  • Un circuit UNL pour contrôler de petits moteurs ou des leds en PWM

ctrl_rgb_led_prptotype.jpg

Le circuit final est réalisé sur une plaquette type stripboard, et comprend plusieurs parties.

De gauche à droite :

  • Connecteur pour le convertisseur 12V vers 5V (je n’utilise pas le 3.3V sur ce projet)
  • Connecteur pour l’Arduino Mini
  • Connecteur pour le circuit UNL
  • Trois connecteurs pour trois bandes de leds …

En haut, un « rail » d’alimentation en 12 volts pour les bandes de leds.

En bas, une ligne de masse (0V) et une ligne d’alimentation en 5V

Chaque zone est reliée soit par les bandes conductrices du stripboard, soit par des fils en point à point.

Les connecteurs

Il s’agit essentiellement de barettes HE10 femelles. Le circuit UNL a, lui, droit à un connecteur du commerce, et trois barettes HE10 mâle serviront à connecteur des bandes de LEDs RGB. L’interrupteur (en bleu) n’a finalement pas été soudé sur la plaquette.

ctrl_rgb_led_connecteurs.jpg

Les fils de jonction

La majeure partie des bandes conductrices du stripboard ont été « coupées » pour isoler les différentes zones, et surtout isoler pour l’Arduino et l’UNL les pins droites et gauches.

Par convenance, les alimentations – 12 et 5V – sont câblées en rouge, et les masses en noir. Les signaux entre l’arduino et l’UNL et entre l’Arduino et le récepteur infra-rouge utilisent d’autres couleurs.

Esthétiquement, j’ai déjà fait mieux, mais les connections sont correctes… à part un défaut que je ne verrai que plus tard.

ctrl_rgb_led_fils.jpg

Le résultat

Les différents circuits sont fixés sur leurs connecteurs :

  • L’alimentation à gauche. Son fil 12 volts, en rouge, est connecté sur le rail 12 volts en haut de la carte.
  • L’Arduino mini au centre à gauche.
  • L’UNL au centre à droite
  • Le récepteur infra-rouge sous l’UNL
  • La bande de leds sur le premier connecteur en haut à droite.

Un pont à peine visible entre les pins 2 et 15 de l’UNL m’a donné une suée. Même en forçant les niveaux à 0, le bleu des RGB restait allumé. Après avoir identifié le pont avec un testeur de continuité, j’ai dû utiliser une loupe pour l’avoir en visuel. Un coup de mèche plus tard, tout rentrait dans l’ordre

ctrl_rgb_led_résultat.jpg

Les prochaines étapes

Plusieurs choses sont à voir, ou à revoir sur ce circuit.

  • Esthétiquement, on peut faire mieux, mais cette carte doit prendre place dans un boîtier. On ne verra à terme que l’interrupteur et la LED de l’alimentation, celles de l’Arduino, le récepteur infra-rouge et les trois connecteurs pour les bandes de LEDs.
  • Une fois l’alimentation branchée, le rail 12 volts est alimenté. Apparemment, c’est sans conséquence, mais par acquis de conscience, je vais lui ajouter un interrupteur.
  • Sur le dernier connecteur, seules deux couleurs pourront être utilisées, car la pin 9 du circuit UNL sert pour l’anti-retour nécessaire si on contrôle des moteurs à courant continu. Plutôt que d’utiliser une bande RGB sur ce connecteur, je pourrais me contenter de deux bandes de leds blanches. A étudier…
  • La programmation actuelle ne prévoit que l’utilisation d’une seule bande RGB. L’évolution du code est prévue, mais reste à valider.
  • Le contrôleur à l’origine de ce projet était sensé produire des animations, comme des effets de « pulse », des flashes, etc. Les sous programmes correspondants sont en place, mais sont vides pour le moment et restent à coder.
  • En cas de panne de la télécommande – pile épuisée ou autre – le contrôleur devient inutilisable. Une interface physique (boutons, variateurs, etc) pourrait prendre le relai, mais cela fera l’objet d’un autre projet.

En attendant la suite…

Novembre, c’est Nanovembre, et le NaNoWriMo prend tout mon temps libre. Ca laisse un bon mois pour laisser percoler de nouvelles idées pour améliorer ce qui peut l’être.

Creative Commons License

Publicités
Catégories :arduino Étiquettes :

Éclairage à leds : le prototype

juin 19, 2018 2 commentaires

Une impression 3D ne se passe pas toujours bien. La buse peut se boucher, le filament casser avant d’entrer dans le tube d’alimentation, le spool peut jammer, et il arrive même que ça flambe.

Je n’ai jamais eu à affronter le troisième cas, mais si cela arrivait, je préférerais m’en rendre compte dès le début du problème. Il vaut mieux avoir à changer quelques pièces que toute l’imprimante, ou même de maison pour cause d’incendie. Du coup, je garde un oeil sur l’impression en cours. Les petites impressions prennent vingt ou trente minutes, mais se déplacer pour vérifier la progression et l’absence de problème toutes les quelques minutes devient vite gênant, pour ne pas dire plus, parfois au point de ne pas pouvoir rester concentré sur autre-chose.

L’ajout d’une webcam a été une première avancée, mais sa résolution ainsi que son débit sont tous deux limités, et elle ne dispose pas d’un éclairage intégré. Sans demander du 4K, je préférerais avoir de bonnes images et pour obtenir de bonnes images, il faut un bon éclairage. En attendant de récupérer une meilleure webcam, commençons par l’éclairage du plateau.

Fiat lux !

Un ruban de leds RGB acheté pour quelques pièces dans un marché aux puces fera l’affaire.

rgb_led_strip_640

Ce ne sont pas des NeoPixels pilotables individuellement, mais de « simples » leds RGB montées en parallèle, avec tout de même leurs résistances protection. Le boîtier de commande et sa télécommande infra-rouge, sans oublier le bloc d’alimentation 12V sont un bonus bienvenu. Pourtant…

Et lux non fit.

La connexion du ruban de LEDs au boîtier de commande se fait par un connecteur qui ne fonctionne pas, malgré une apparence plus que convenable. Le boîtier ouvert, un test de continuité montre que le fil d’alimentation est rompu. On coupe, on remplace, on strappe, on teste et… toujours rien.

Sans alimentation, pas de lumière. Il existe d’autres points d’alimentation utilisables sur la carte électronique du boîtier. Tant qu’à faire, j’ai décidé de remplacer le connecteur « fancy » du boîtier par un bornier à vis. Mon multimètre a rendu l’âme, et son remplaçant n’a pas encore été livré, mais j’ai tout de même pu vérifier que le courant passe en pointant directement depuis le bornier vers le ruban de leds.

L’intensité est malheureusement insuffisante, malgré les tests et réglages à l’aide de la télécommande. Au lieu d’avoir des couleurs éclatantes, je n’ai qu’une très légère activation des leds. Apparemment le boîtier de commande hors service. Heureusement que le reste fonctionne !

Une solution, vite ! Un petit projet, on a dit.

Je pourrais passer des heures à tenter de comprendre ce qui ne fonctionne pas, mais je réserve l’exercice pour plus tard. Je vais « simplement » remplacer le boîtier par un équivalent.

Le ruban de leds mesure plusieurs mètres, largement trop pour mon projet, qui devrait en consommer une soixantaine de centimètres au plus. Il en restera assez pour d’autres usages. La télécommande fonctionne, ainsi que le bloc d’alimentation.

Le cahier des charges

Le nouveau boîtier de commande doit :

  • être utilisable avec une bande de 10 cm à 1 m
  • réutiliser la télécommande infra-rouge et le bloc d’alimentation
  • être facilement clôné
  • être facilement connectable et dé-connectable d’une bande de leds

Je me suis inspiré de plusieurs projets présentés sur youtube, instructables, et d’autres blogs pour développer ma petite solution à base d’Arduino :

  • Arduino Uno pour le prototype, un clone pour la cible
  • Récepteur infra-rouge
  • Commande de la bande de leds RGB via une puce UNL2803 commandée en PWM ( pseudo analogique)
  • Alimentation unique pour l’Arduino et la bande de leds

Première étape : piloter la bande de leds

L’UNL2803 est un petit circuit intégré à 20 18 pins permettant de piloter aussi bien des leds que de petits moteurs électriques. Il suffit de lui connecter une masse, les signaux d’entrée et les moteurs ou leds en sortie. Dans le cas d’un moteur, une pin supplémentaire doit être utilisée, pour éviter les « retours » de courant lors d’un arrêt de moteur.

Les pins 0 à 8 reçoivent les signaux PWM en provenance de l’arduino, les pins 10 à 17, juste en face, sont reliés aux leds ou moteurs à contrôler. Le pin 8 doit être relié à la masse, et le 9 ne sera pas utilisé.

La vitesse des moteurs ou l’intensité des LEDS peuvent être commandées finement en PWM – Pulse Width Modulation ou Modulation de longueur d’impulsion – et non en tout-ou-rien.

Dans mon cas, les connections sont les suivantes :

  • pin 0, 1 et 2 de l’UNL sur les pins 9, 10 et 11 de l’arduino
  • pin 9 de l’UNL sur la masse de l’arduino
  • pins 16, 17 et 18 de l’UNL sur les lignes Bleu, Vert, et Rouge de la bande de leds
  • ligne 12V de la bande de leds sur le 12V de l’alimentation
  • Masse de l’Arduino sur la masse de l’alimentation

Un petit programme trouvé ici permet de vérifier que tout fonctionne correctement. Les différentes couleurs devraient s’éclairer suivant une animation simple.

Seconde étape : identifier le type de télécommande infra-rouge

Là aussi, je me suis inspiré d’un travail existant. J’ai flashé sur l’Arduino un programme permettant de décoder ce qu’envoie chaque touche de la télécommande infra-rouge.

La librairie InfraRed pour l’Arduino offre largement assez de possibilité, et de multiples exemples permettent de s’y retrouver. Malheureusement, elle n’est pas directement utilisable dans mon cas. La classe (le module) sensée gérer le codage « NEC1 » se contente d’afficher des valeurs sur le port série de l’Arduino. Je pourrais lui ajouter ce qui manque (une simple routine de lecture en lieu et place d’un affichage), mais j’ai suivi une autre piste, celle de la librairie IRLib2, que j’ai découverte via un tutorial chez Adafruit.

L’exemple « comboDump » affiche le détail du signal reçu par l’Arduino et identifie le codage utilisé :

Decoded NEC(1): Value:F7E817 Adrs:0 (32 bits)
Raw samples(68): Gap:9364
Head: m9300 s4400
[ . . . ]
Space min:550 max:1750

C’est peu lisible, et j’ai abrégé, mais l’essentiel se trouve sur la première ligne : ma télécommande générique utilise le codage NEC, un classique du genre.

Troisième étape : décoder les touches de la télécommande

J’ai modifié la fonction loop() de l’exemple comboDump fourni avec la librairie IRLib2 pour afficher les codes des touches de la télécommande.

Une fois le programme flashé sur l’Arduino, le moniteur série de l’IDE Arduino affiche effectivement les codes envoyés par la télécommande, qu’il « suffit » de noter pour les utiliser dans le programme final :

Code : F730CF
Code : FFFFFFFF
Code : F708F7
Code : FFFFFFFF
Code : F700FF
Code : FFFFFFFF
Code : FFFFFFFF
Code : FFFFFFFF

Le code FFFFFFFF est un code de répétition, lorsque l’on appuie longuement sur une touche sans la relâcher.

Quatrième étape : choisir et programmer le comportement des LEDS

La télécommande doit permettre de :

  • allumer et éteindre les leds
  • augmenter et diminuer l’intensité des leds
  • allumer toutes les leds en blanc
  • sélectionner l’intensité d’une des trois couleurs
  • si possible sélectionner une animation des couleurs (flash, fading, etc)

Rien n’empêche de l’utiliser autrement, mais je vais tenter de copier le comportement d’origine. Le but premier est de produire de la lumière, pas de créer de nouveaux effets façon boîte de nuit

Toutes les fonctions, à part les quatre animations, devraient être assez simples à développer, en jouant sur le niveau des signaux en entrée de l’ULN.

Les animations demandent de jouer avec des temporisations, mais rien de vraiment compliqué à la base. Pour limiter les manipulations sur la télécommande pendant les tests, on pourra éventuellement flasher l’Arduino pour démarrer directement sur l’animation testée.

Le programme

Le programme final n’est pas très compliqué. A chaque exécution, la fonction principale effectue les actions suivantes :

  1. Si un signal infra-rouge valide est détecté, agir en conséquence :
    • changement d’animation
    • ou changement d’intensité d’une couleur
    • ou passage en mode « blanc » continu
    • ou allumer ou éteindre toutes les leds
  2. Mettre à jour l’intensité des leds suivant l’animation en cours

Le code sera disponible librement.

Bilan d’étape

Le montage et le programme fonctionnent correctement. Il me reste encore à coder les animations (flash, etc), mais pour l’instant cela peut attendre. Il suffira de reflasher l’Arduino.

Pour le moment le montage consiste en :

  • une carte arduino uno
  • une petite alimentation 12, 5 et 3.3V. Seul le 12V est utilisé pour le moment car l’Arduino est alimenté par sa prise USB
  • un breadboard supportant l’unl2803 et le récepteur infra-rouge
  • une bande de douze leds RGB
  • de la filasse pour relier le tout.
  • le bloc d’alimentation 12V
  • un petit transformateur 12V vers 5 et 3.3 V, pour le moment utilisé en 12V uniquement

unl2803_640

breadboard_640

led_strip_controler_640

Le programme comprend quatre modules :

  • affichage de messages sur un terminal série (xterm, putty, etc), pour suivre la progression du programme
  • lecture des signaux infra-rouge et décodage/transformation en numéro de touches
  • gestion des leds RGB
  • programme principal

Quelques liens utilisés

Les prochaines étapes

Ce projet n’aurait dû durer qu’une petite semaine, si le boîtier de contrôle d’origine avait fonctionné. J’y ai gagné au change, en découvrant le décodage de commandes infra-rouge, ainsi que le composant unl2803, qui permettent de contrôler de petits moteurs ou des leds RGB .

Pour termine complètement ce projet, il me reste à :

  • Améliorer et documenter le code
  • Rendre les sorties terminal série désactivables
  • Remplacer l’Arduino Uno par un Arduino Mini ou une Menta
  • Réaliser un boîtier et le câble de connexion d’une bande de leds

Pour le remplacement de l’Arduino Uno, la première option est d’utiliser une carte Menta dont la partie prototypage recevrait les composants du montage. La seconde est d’utiliser un clone d’Arduino mini. Vu l’encombrement, celle-ci a ma préférence.

 

arduino_menta_640

L’Arduino mini est posée sur la zone de prototypage de la carte Menta.

Encore quelques petites heures de travail en vue. Je documenterai cette seconde partie dans un prochain article en incluant le programme de l’Arduino.

Creative Commons License

Catégories :arduino Étiquettes :

Pico puter : de la théorie à la pratique

septembre 19, 2017 Laisser un commentaire

Mon mini cluster est cassé. Nœud principal HS. Diagnostic à venir. Du coup, je n’ai toujours pas de « vrai » serveur Mercurial…

En attendant, j’ai relu et (re-)*dé-coquillé mon premier NaNoWriMo (merci encore Titi !) , et j’ai un peu avancé sur mon projet de « Pico ordinateur« .

Yeps ! Les premiers écueils apparaissent à l’horizon.

Pour rappel, un ATtiny85 vu du programmeur, c’est :

  • 8 kilo-octets de mémoire flash pour les programmes et données statiques
  • 512 octets de mémoire RAM

Côté pratique, l’électronique est à l’avenant :

  • une masse et une alimentation
  • 1 reset qui peut éventuellement être utilisé comme entrée/sortie
  • 5 entrées/sorties, dont deux que je réserve pour le « bus » I2C
  • 512 octets de mémoire de stockage de type EEprom.
  • un capteur de température (si-si)
  • des timers
  • des interruptions

Bref, de quoi s’amuser, surtout vu ce que je compte lui adjoindre :

  • un petit écran OLED
  • un clavier 4 x 4 touches
  • une horloge/calendrier, sa ram intégrée sauvegardée par pile, ainsi que la mémoire EEProm qui l’accompagne
  • une entrée et une sortie « analogiques » dont l’usage reste à déterminer
  • d’autres petites choses connectées en I2C.

Ça parait léger.

De la théorie …

En principe, tout ça devrait se programmer sans trop de problèmes. I2C ici, I2C là, un clavier « lu » comme une entrée analogique, etc.

Eh bien, non !

… à la pratique

L’I2C n’est pas implémenté en matériel sur l’ATTiny85, et j’utilise une librairie ad-hoc. Et hop, quelques centaines d’octets consommés dans la mémoire flash du contrôleur, plus une quarantaine en RAM.

L’écran OLED a son petit protocole bien à lui, et il faut lui fournir le bitmap (5 octets) de chaque caractère à afficher. Un écran LCD 4×20 aurait été plus simple à programmer mais, je l’ai déjà dit, moins fun. Ce sera une solution de repli au cas où…

L’horloge RTC stocke l’heure et la date au format BCD dans sa RAM « non volatile » – comprendre, « sauvegardée par pile ». Elle propose au total dans cette RAM 64 octets de RAM dont l’usage d’une bonne partie est, à priori, laissé libre pour le programmeur. Hop, on ajoute un mini-protocole supplémentaire, et deux routines de conversion BCD <-> binaire.

L’EEPROM de trente deux kilo-bits  – 4 kilo octets – qui squatte la carte de l’horloge a, devinez quoi, son petit dialecte propre, mais c’est peut-être le composant le plus simple à utiliser dans ce projet.

J’oubliais l’EEPROM de l’ATtiny, utilisable librement, lui aussi. Heureusement, la librairie standard de l’Arduino suffit. Ouf !

Un peu d’unification

L’EEPROM de l’Attiny – 512 octets – , celle de la carte horloge – 4 kilo octets – , la RAM de l’horloge – 64 octets – ont des besoins assez simples. On peut les considérer comme des périphériques de stockage, mais à la base il faudra y lire et y écrire des valeurs, généralement un octet à la fois. Lent mais simple, et inversement.

Vu la mémoire RAM totale de l’ATtiny85 – 512 octets – ne pourrai pas je n’aurai pas à y manipuler de grosses structures. Partant de là, stocker ou récupérer des informations pourra se faire par paquets de huit, seize, trente-deux octets ou plus à la fois. Je ne suis pas encore fixé là dessus, mais un stockage « de masse » – tout est relatif – par blocs de 32 octets devrait suffire.

On sort son cahier, ses stylos, on dessine l’organisation générale du bousin, les classes, leurs héritages, bref, on fait ses plans, et on se retrouve avec plusieurs « périphériques » de stockage présentant les mêmes routines d’accès. Merci la POO ! Classe de base : I2C, classe abstraite stockage, une classe par périphérique, une pour le clavier, une pour l’écran. Ça a … de la classe !

** /me court se planquer comme un bourrin des Flandres **

Mise en oeuvre

L’écriture du code se passe bien. On joue un peu avec le C++. Et oui, l’IDE Arduino, à la base, c’est du C++ !

Les tests se déroulent bien, l’écran affiche, l’horloge donne la date et l’heure, sa RAM est lue et écrite sans soucis, idem pour sa colocataire l’EEPROM I2C, et le clavier attend sagement qu’on passe à l’étape du fer à souder, même si son code est presque terminé.

Bilan d’étape

La compilation donne :

Le croquis utilise 6862 octets (83%) de l’espace de stockage de programmes. Le maximum est de 8192 octets.
Les variables globales utilisent 439 octets (85%) de mémoire dynamique, ce qui laisse 73 octets pour les variables locales. Le maximum est de 512 octets.

6862 octets de flash utilisée, avec uniquement quelques tests, sans aucun logiciel de mon système cible (qu’il reste d’ailleurs à définir). Je suis encore confiant là-dessus : les tests prennent de la place qui sera à terme libérée pour autre-chose.

Mais 73 octets de RAM disponible ! SOIXANTE TREIZE ! Même si j’ai réservé 256 octets de RAM pour le futur système, clairement, ça va coincer. Un stack overflow sur PC, ça éclabousse un peu, mais là, ça va frotter sévère !

J’ai choisi la bonne méthode…

… pour un Arduino Mega (256 ko de flash, 8 Ko de RAM) , ou un Arduino Due (512 ko de flash, 96 ko de RAM). Pour un micro contrôleur beaucoup plus petit comme l’ATTiny85, il faut revoir sa copie car la programmation objet, pour sexy élégante qu’elle soit, n’est pas vraiment indiquée vu le peu d’espace disponible.

  • L’héritage, et en particulier la surcharge de méthodes couplée au polymorphisme consomment énormément de RAM.
  • Il vaut mieux utiliser la composition et la délégation. Les classes de bases fournissent les fonctions simples et se fichent éperdument de ce qu’on en fera. La classe auparavant héritée devient une classe chargée de les coordonner et leur déléguer les fonctions de base. On utilise plus de mémoire programme en flash, mais beaucoup moins de RAM. Si j’étais « jusqu’au bout-iste », je n’utiliserais que des fonctions (au sens C), mais la programmation orientée objet en mode light a quelques petits avantages.
  • Les attributs (variables internes) des classes consomment de la RAM. Il faut donc en limiter le nombre et la taille.
  • Les paramètres passés aux méthodes (fonctions) consomment de la pile, donc de la RAM. Même punition.
  • Les appels de méthodes consomment également de la pile pour les variables locales, mais uniquement lors de l’exécution de la méthode. A la sortie, de la pile est libérée, mais les appels de méthodes en cascade (et encore plus la récursion) multiplient d’autant l’utilisation de la pile. Il faut donc limiter les profondeurs d’appels. Un maximum de trois ou quatre fonctions/méthodes en cascade est une bonne règle. Pour les fonctions très simples (une ligne ou deux), préférer utiliser des macros (#define)
  • Même si ça reste à confirmer, les « switch » occupent apparemment moins de mémoire programme si les valeurs recherchées dans les clauses « case » sont triés par ordre croissant.
  • Les variables, attributs, fonctions et méthodes inutilisés n’occupent pas de mémoire de programme, mais complexifient le projet. Il faut rester simple.

Résumé simple de ce qui précède :

  • éviter l’héritage
  • utiliser la composition et la délégation
  • limiter au strict nécessaire l’utilisation de variables globales et de variables internes aux classes
  • limiter le nombre de paramètres passés aux fonctions/méthodes
  • limiter la profondeur d’appel des fonctions/méthodes
  • ordonner les valeurs testées dans les clauses « switch »
  • diminuer la complexité tant matérielle que logicielle – le fameux « KISS principle »

Après mise en pratique, la compilation de mon programme enrichi d’une foultitude de tests donne :

Le croquis utilise 7434 octets (90%) de l’espace de stockage de programmes. Le maximum est de 8192 octets.
Les variables globales utilisent 383 octets (74%) de mémoire dynamique, ce qui laisse 129 octets pour les variables locales. Le maximum est de 512 octets.

La RAM disponible pour la pile est maintenant de 129 octets sur les 512 que contient l’ATTiny85, toujours en réservant un bloc de 256 octets. Cela devrait suffire, même s’il faudra veiller au grain…

Les prochaines étapes

  • Décider du système qui animera le bousin. J’hésite toujours entre un Forth et un Chip-8 fortement dégraissé. Si j’étais cintré du chapeau, BrainF*, pourrait coller. Le Forth a ma préférence, mais avec un clavier 4×4, ça risque de ne pas être pratique.
  • Assembler et tester le clavier 4×4
  • Donner une fonction aux deux entrées/sorties encore libres

Mais d’abord

Un grand merci à Alex Wulff dont la « Business Card/Game Console » m’a donné plusieurs pistes pour mon projet, notamment le code de gestion de l’I2C et de l’écran OLED.

Creative Commons License

Catégories :arduino, Pico-puter Étiquettes : ,

Mon premier shield Arduino

mai 30, 2017 Laisser un commentaire

J’ai acheté ma premiere carte Arduino il y a … longtemps maintenant. Je l’utilise surtout pour des petits montages rapides et recyclables : voltmètre ou ohm-mètre basse résolution, bruiteurs, lucioles. L’AT-Mega est un peu surdimensionné alors qu’un « simple » ATtiny85 suffirait bien souvent, avec ses 8 petites pattes, à comparer aux 28 de son grand frère.

Vient alors le premier soucis : une carte arduino Uno permet de programmer son propre microcontrôleur, et d’y faire tourner une application. Un ATtiny85 sans moyen de le programmer, c’est un micro-presse-papier ou encore une agrafe high-tech.

Évidemment, les solutions existent :

  • boîtier de programmation du commerce
  • arduino comme programmateur à l’aide d’une plaque d’essais
  • arduino et shield de programmation pour ATtiny

La troisième solution a ma préférence, et des sites comme Make, Dangerous Prototypes, Hack-a-day, ou encore instructables donnent toutes les informations nécessaires.

Just do it !

Ok, juste faisons-le ! Y’a qu’à. En théorie, du moins.

En réalité, ça n’est pas allé sans mal.

Prototype #1 : le premier prototype fonctionnait quand il voulait, et l’ATtiny était reconnu… une fois sur trois ou quatre. Plutôt que de galérer plus longtemps, je suis passé au second prototype.

Prototype #2 : quelques corrections d’erreurs plus tard, ça ne fonctionnait toujours pas. J’ai ajouté les leds d’affichage après coup. Visuellement, la vérue est dégueu, mais au moins je suis certain que le shield est reconnu par l’arduino au vu de l’activité des leds . J’ai appris une bonne leçon à cette occasion :

Leçon #1 : un microcontrôleur DIL (ici un ATtiny85 avec ses 2 fois 4 pattes) s’installe sur un connecteur DIL. Un connecteur à base de barrette femelle sécable n’est pas prévu pour ça ! Obtenir un contact fiable dans ces conditions tient presque du miracle.

Après avoir adapté ledit connecteur DIL, ça se passe beaucoup mieux, même si l’ensemble ressemble très fortement à un bricolage fait sur un coin de table (c’est le cas).

Prototype #3 :  j’ai tout de suite intégré les trois leds d’état, une zone de tests, et deux boutons reset – un pour l’arduino vu que le sien était hors d’atteinte, l’autre pour l’ATtiny.

Leçon #2 : au plus simple, au mieux. Le fameux KISS. Euh, le fameux principe KISS, disais-je. Un shield, une fonction. Les deux boutons reset sont de trop, la barrette de tests itou.

Leçon #3 : utiliser des repères physiques pour connecter le shield sur l’arduino. J’ai voulu économiser un pin et une soudure, et ça m’a mis dedans : une masse connectée sur une alim, le reset du shield sur le 3.3V de l’arduino… bref, seules les leds fonctionnaient, et décaler les pins se faisait plus vite que de compter jusque trois. Pas de fumée, pas d’odeur de plastique fondu, je suis passé assez près.

Prototype #4 : Ce n’est pas que ça coûte cher, mais ça commence à y ressembler. On ressort le calepin et on recommence de zéro.

Le cahier des charges est simple :

  • tenir sur une carte de type stripboard (ou veroboard, suivant les fournisseurs) de  20 points de large (la largeur de la carte arduino) par 20 points de long, pour laisser un accès au bouton reset de l’arduino
  • utiliser un minimum de composants, et réduire le nombre de ponts/straps
  • la connexion à l’ATtiny, ou à la carte qui l’utilise, passe par une barrette sécable de 8 points. Je sais, c’est contraire à ce que j’ai écrit plus haut. J’y reviens bientôt.
  • permettre une utilisation en 5V comme en 3.3V
  • afficher le bon fonctionnement du bidule, via trois leds
  • simplifier la connectique
  • utiliser des repères physiques pour éliminer les erreur de connexion
  • connexion standard : Arduino 13, 12, 11 sur ATtiny 7, 6, 5 ; arduino 10 sur ATtiny 1 ; masse arduino sur masse ATtiny 4; Arduino 5V (ou 3.3V) sur ATtiny 8, arduino 9, 8, 7 chacun vers sa led précédée de sa résistance 330 Ohm, les leds dirigées vers la masse de l’arduino. Ah, oui, ne pas oublier le condo polarisé entre la masse et le reset de l’arduino. Je crois que c’est tout.

Le résultat final est presque conforme. En tout cas, c’est presque propre. Ne manque que l’étiquette sur la barrette centrale ainsi que celle sur le sélecteur de tension.

Côté soudures

shield_verso

Les ruptures de pistes ont été exécutées en tournant doucement un forêt pour métaux de diamètre 2.5mm. Pas besoin d’y aller comme un brutos, la couche métallique est très fine. Les soudures ont été faite au fil de diamètre 0.5mm. Je remercie au passage mon ophtalmo et mon opticien.

Côté composants

attiny_shield

Un strap (pont) aurait pu être évité, mais c’est très bien comme ça. Vu leur diamètre, les leds verte et rouge sont légèrement inclinées.

Repères physiques

Les pins analogiques de l’arduino (à droite) ne sont pas utilisés. Côté alimentation, l’alignement se fait sur le pin de droite (non utilisé et non routé sur le shield).

shield_reperes.jpg

Côté signaux, le pin 7 (à gauche) doit être plié d’une demi-piste pour respecter l’alignement côté arduino. Les pins 8 à 13 peuvent rester d’équerre.

shield_reperes_2.jpg

Petit bonus

Les prototypes 2, 3 et 4. Attention,  on peut rire, mais on ne se moque pas !

shield_prototypes.jpg

De haut en bas et de droite à gauche :

  • Prototype #2 avec son adaptateur DIL. Moche mais fonctionnel. Le tube plastique blanc empêche de déformer les leds ajoutées après coup lors des manipulations.
  • Prototype #3. Complètement buggé. Le mieux qu’on puisse en tirer est un feu tricolore et un bouton reset !
  • Prototype #4. Simple et presque clair. On touche bientôt au Zen.
  • Un proto d’adaptateur, maintenant sans utilité.
  • Un porte-clefs FOSDEM. C’est une monocarte à base d’ATtiny85. Peu pratique mais sympa.

Connecter un attiny sur le shield

La barrete du shield ne sert qu’à connecter la carte qui utilise l’ATtiny. Ce dernier est soit directement soudé, soit fixé sur un connecteur DIL.

Attention, pour simplifier le « routage », l’ordre des pins est inversé sur le connecteur du shield : le #1 est à droite, et le 8 à gauche.

Et maintenant ?

J’ai une petite poignée d’ATtiny85 d’avance, de quoi me fabriquer quelques amusements. Le prochain comprendra :

  • une alimentation par jack et USB
  • un affichage sur I2C
  • une horloge RTC sur I2C
  • quelques entrées sorties encore à décider (buzzer, microphone, boutons, …)

 

Creative Commons License

Catégories :arduino Étiquettes :
%d blogueurs aiment cette page :