Archive

Posts Tagged ‘Arduino’

Pico puter : de la théorie à la pratique

septembre 19, 2017 Laisser un commentaire

Mon mini cluster est cassé. Noeud 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 y « caser » :

  • 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 mais en pratique…

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, c’est beaucoup 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 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, Arduino, à la base, ça se programme en 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.

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 « switch » 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 avec la réservation d’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

Publicités
Catégories :Arduino Étiquettes :

Pico puter, les specs

septembre 12, 2017 Laisser un commentaire

Dans un billet précédent, j’ai abordé mon projet de créer un (tout) petit ordinateur, limité, mais simple à comprendre. Les projets, c’est bien. Créer, c’est bien mieux.

Je n’ai rien imaginé qui soit révolutionnaire. Au contraire, je vais m’appuyer sur des composants existants, assez récents pour éviter les problèmes d’approvisionnement, mais pas trop pour limiter les coûts, mais surtout simples à utiliser tant côté connectique que côté logiciel.

La cible

Les premières machines de découverte et d’expérimentation des années 70, comme le KIM-1 comportaient quelques centaines d’octets de mémoire vive, une ROM à peine plus grande contenant le programme de base (un simple moniteur), un clavier numérique et un petit afficheur, quand ce n’étaient pas de simples leds.

Les routines d’accès aux périphériques pourront occuper toute la mémoire programme (Flash) inutilisée par le système, et il faudra limiter l’usage de variables globales et, si possible, de pile. Je pense à une petite abstraction de type Chip8 largement downsizé ou encore à un Forth minimaliste. Je sais, limiter l’usage de la pile alors que Forth utilise deux piles… Deux piles, certes, mais quasiment aucune variable.

Au final, les 512 octets suffiront à peine, mais si c’était simple, ce serait beaucoup moins fun, non ?

Le processeur/contrôleur

Côté processeur, je délaisse les ATmega que je réserve pour le moment à des usages plus « arduinesques ». J’ai finalement opté pour un ATtiny85. Ses capacités sont limitées, mais c’est ce qui pimente l’histoire :

  • 8 kilo-octets de mémoire flash pour les programmes et données statiques
  • 512 octets de mémoire RAM
  • 512 octets de mémoire de stockage de type EEprom.
  • Masse et VCC pour l’alimentation
  • 1 reset qui peut éventuellement être utilisé comme entrée/sortie
  • 5 entrées/sorties

Ça parait léger, et effectivement, ça l’est réellement.  Ça change des Arduino Due avec leurs centaines de kilo octets de mémoire programme et leurs dizaines de kilos de RAM. Ça change également des Arduino Uno, déjà plus limités mais suffisant pour la plupart de mes usages. Pour se faire une idée, lire ce comparatif entre ATmega et ATtiny85.

J’ai sélectionné quelques composants repêchés dans ma boîte à rabiots.

Affichage

Il s’agit d’un petit écran OLED à la résolution faramineuse de 128×64 pixels, mais que j’utiliserai en mode texte pour limiter la consommation mémoire. Au final, huit lignes de texte. Un écran LCD 4 x 20 aurait été plus simple à utiliser, mais aurait nécessité une interface I2C, et j’ai préféré aller au plus court.

Horloge et Stockage

Là encore, une petite carte est venue à ma rescousse. Elle comporte une horloge / calendrier sauvegardée par pile, ainsi qu’une mémoire EEprom de 32 kilo bits (et non bytes, comme j’avais d’abord compris ; c’était pleine lune ou un truc du genre, mais passons ! )

On passe donc de 32 ko à … 4 ko. On verra plus tard pour un upgrade.

Clavier

J’ai ressorti de mes armoires un clavier numérique au format USB. En théorie, tout va bien avec un petit adaptateur, ça peut se brancher sur un port PS/2, l’ancienne norme de connecteur pour les claviers et souris, et il existe plusieurs librairies pour utiliser les claviers PS/2. Làs, après pas mal d’essais, ça ne veut pas. Le clavier fonctionne sur un PC, mais un arduino n’en veut pas.

Tant pis, on reviens aux bases. Un clavier, c’est des boutons, quelques résistances et un petit contrôleur. Sachant parler PS/2 ou USB. Sur le principe du diviseur de tension, on peut interfacer 4 à huit boutons sur une seule entrée analogique. Edit: depuis le premier brouillon de ce billet, j’ai trouvé (merci Glouglou) un schéma sur le même principe pour 16 boutons.

Ce sera dont un clavier à base de boutons « tact-switch », du genre de ce qu’il y a dans les télécommandes de portières de voitures.

Alimentation

Pour le moment, j’utilise une alimentation 5V/3.3V pour plaquette de prototypage, alimentée par une prise USB ou une prise 9V. Deux sorties sont utilisables en même temps, avec chacune une DDP de 5 ou 3.3V, sélectionnable par cavalier.

Le « Bus »

Pas besoin de chercher loin : l’écran, l’horloge et la mémoire externe communiquent en I2C. Le format du bus est tout simple : Masse, 5V et 3.3V pour l’alimentation, et clock plus data pour l’I2C

Autres E/S

Résumons : huits pins moins le reset, la masse, l’alimentation, les deux pins pour l’I2C, celui du clavier, restent…

Une sortie et une entrée analogiques. C’est très peu, mais avec l’I2C, et sous réserve qu’il reste assez de mémoire, il y a de quoi faire.

La programmation

L’ATtiny85 ne possède ni I2C ni USB, mais une interface série programmable. L’USB et l’I2C sont donc à portée, via vUSB pour le premier, et TinyWireM pour le second. Utiliser les deux en même temps me semble un poil complexe, même si je peux changer d’avis, mais surtout, cela monopoliserait deux E/S supplémentaires sur l’ATtiny.

Exit donc l’USB ; je programmerai l’ATtiny avec un programmateur ad-hoc. Ça tombe bien, j’en ai justement un qui me fait signe de ses LEDs.

Conclusion provisoire

Voilà donc les « spécifs » pour ce projet, et ça me semble parfait pour un premier projet un peu plus complexe que ce que j’ai pu faire jusque lors.

La feuille de route qui en découle est des plus simples :

  1. Comprendre et utiliser le protocole I2C sur Arduino, et communiquer avec l’écran OLED
  2. Appliquer le tout à l’ATtiny pour l’écran OLED. Itérer en 1 si le besoin s’en fait sentir
  3. Recommencer pour l’horloge et la mémoire Flash externe
  4. Assembler, tester un clavier et en écrire les routines d’interface

A ce stade, je devrais avoir une pico-machine comportant un clavier, un écran, de la RAM et de la ROM (flash), ainsi qu’un système de stockage (EEprom).

En fonction de la RAM et de la flash restant disponible, il restera encore à écrire le « système » du pico-ordinateur. Ah oui, ça serait bien d’avoir un boîtier assez sympa pour cacher les soudures de sauvage abriter le tout.

La todo list est déjà longue, tant côté logiciel que matériel. Ca tombe bien, il fait noir de plus en plus tôt, et comme je ne regarde pas la télébidon…

Comment ça, je dois avancer sur mon mini cluster ? Et Comment ça, c’est bientôt Nanovembre ?

Creative Commons License

Catégories :Arduino Étiquettes :

Electronique, magie noire, 8bits

juin 27, 2017 Laisser un commentaire

L’électronique a toujours été pour moi un domaine mystérieux. Bien sur, je l’ai étudiée un peu au lycée, avec le peu qui figurait au programme, les circuits RLC en mode alternatif, l’effet « ampli » des transistors, les alimentations à découpage. Bien sur, j’y suis un peu revenu – de loin – quand j’ai appris l’informatique et les circuits logiques. Bien sur, je connais les principes de base, U=RI, la loi des noeuds, Ampère et son bonhomme – sacré lui ! – , Lorentz, Laplace, les circuits équivalents, etc.

Pourtant, j’ai toujours été incapable de concevoir un circuit électronique un tant soit peu utile, et vu de moi, les circuits présentés dans les revues grand public tiennent plus de la magie noire que de l’ingénierie. Chacun son domaine, c’est comme ça.

Mon « truc », sans être un génie, c’est l’informatique, et notamment la programmation, les système, le « bas » niveau, et ça ne me défrise pas plus que ça de remettre sur pieds une vieille babasse tout juste bonne pour le recyclage ou le musée, uniquement pour que ça fonctionne. Malheureusement, les vieilles machines à un prix correct se font de plus en plus rares. En passant, je trouve ignoble de vendre plusieurs centaines d’euros un « huit bits », même en bon état, même dans sa boîte uniquement parce que c’est « vintage ».

La programmation ? Les machines grand public d’aujourd’hui sont tellement rapides et dotée en mémoire et en espace de stockage, que la programmation d’une application en serait devenue presque triviale sans toutes les couches intermédiaires – API, toolkit, etc, et même créer un système d’exploitation est abordable pour l’amateur obstiné.

J’ai commencé à programmer sur calculatrices – 22 pas de programme sur la TI 57, 220 sur la casio 7000G – puis sur micro en basic, pascal, C, assembleur dans 64 puis 512 kilo octets ! Ca c’était fun. Une idée, un besoin ? Hop, un brouillon, du code, de l’optimisation et ça roulait.

C’est la faible épaisseur des couches d’abstraction qui rendait tout cela possible. Aujourd’hui , le système est si complexe et prend tellement de place qu’il est parfois difficile de voir si un programme plante à cause d’un bug ou à cause d’une classe ou d’une API un peu tatillonne ou bancale.

Pour retrouver un peu cet esprit « micro » de l’informatique, j’ai acquis et revendu ou donné plusieurs « ordinosaures », mais par manque de place je n’en conserve que deux ou trois.

J’ai ensuite découvert presque par hasard un projet d’émulation d’une machine à base de Z80 tournant sous CPM. Cette émulation fonctionne sur … Un Arduino due. On en est là ! Une simple carte à quarante boulons est capable d’émuler une machine qui coûtait un bras au début des années quatre-vingt !

Custom serial card (front)

Le Due attend sagement dans sa boîte que je prenne le temps de m’en occuper. Je l’ai déjà dit, j’adore les cartes Arduino. La Uno avec son atméga a ma préférence, de même que les ATtiny85 pour leur simplicité et leur ouverture. Comme avec les ordinateurs des années 70 et 80, on a un accès plein et entier aux fonctionnalités du micro contrôleur, la différence étant la nécessité d’utiliser un ordinateur récent pour le programmer.
Grâce à l’ATtiny ou à son grand frère l’ATmega, il ne doit pas être bien difficile de créer une pico-machine simple, extensible, et programmable simplement, une espèce de huit bits au goût du jour. Les ressources sur Internet ne manquent pas.

L’ATtiny est limité en mémoire et en « pins » d’I/O, mais ça oblige à garder des buts simples et maitrisables. Je cherche à apprendre, et non à recréer un « Coco », un IIGS ou un Speccy, alors je vais procéder par étapes, un module après l’autre. Outre une carte « CPU » des plus simples, puisque basée sur un micro-contrôleur, un fond de panier, une alimentation, un peu de « glue » et quelques entrées/sorties devraient suffire pour commencer.

D’un autre côté, l’ATtiny sait « parler » I2C, tant en maitre qu’en esclave, ce qui ouvre pas mal d’opportunités, à commencer par une horloge RTC et une petite mémoire Flash de 32ko, ainsi qu’un petit écran oled, tous trois sortis de ma boîte à rabiots.

Creative Commons License

Catégories :Arduino É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 :