Archive

Posts Tagged ‘picoputer’

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

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

Pico puter, les specs

septembre 12, 2017 1 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 de RAM 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 restera 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, 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 :Pico-puter É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 y être un génie, c’est l’informatique, et notamment la programmation, les systèmes, 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 il y a … pfff … plus de trente ans maintenant, 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 ! Ça 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)

Pas grand-chose à voir avec le sujet, mais c’est ce type de montages qui m’intéresse : du simple, du compréhensible, du réutilisable.

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 « glu » et quelques entrées/sorties devraient suffire pour commencer.

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

Creative Commons License

Catégories :Pico-puter Étiquettes :
%d blogueurs aiment cette page :