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 :

Linux, Docker

juillet 18, 2017 Laisser un commentaire

Mon petit cluster commence à ressembler à quelque-chose :

Bien sûr, on peut améliorer les choses :

  • passer en adressage IP V6 au lieu de l’IP V4 actuelle
  • Sécuriser le cluster, par exemple en supprimant l’accès distant à internet
  • Sécuriser l’accès nfs, pour le moment ouvert à tous vents.

L’aspect sécurité est le plus important, et les solutions sont en cours d’évaluation. Par contre l’IP V6 peut encore attendre un peu.

J’ai donc un cluster presque utilisable, mais où presque tout reste à faire pour y faire tourner des applications sans trop avoir à se casser la tête.

La solution qui m’intéresse le plus est Docker, et c’est bien le but de cette série d’articles. Commençons donc par l’installer sur chacun des noeuds.

Installation de Docker

Mes machines tournent sous Debian Linux, en mode headless (sans clavier, souris ni écran), en accès ssh. L’installation se fait donc via une interface chaise-clavier à coups de commandes apt sur chacun des nœuds du cluster:

  1. Activer les backports. Ceux-ci permettent d’installer des paquets en principe non prévus pour la version actuelle de Debian (8 dans mon cas, 9 pour les courageux), mais portés depuis une version plus récente de Debian.
  2. Installer quelques paquets nécessaires
  3. Installer Docker
  4. Créer un groupe unix docker et y ajouter le compte utilisateur unix
  5. Tester l’installation

J’ai utilisé les commandes suivantes (à adapter à votre cas) sous le compte root sur chacune des machines du cluster :

# Ajouter les backports au sources.list du noeud
echo '' >> /etc/apt/sources.list
echo '# Backport needed by Docker' >> /etc/apt/sources.list
echo 'deb http://ftp.debian.org/debian jessie-backports main' >> /etc/apt/sources.list

# Mettre à jour la liste des paquets disponibles
apt-get update

# Installer quelques paquets utiles
apt-get -y install apt-transport-https ca-certificates
apt-get -y install curl software-properties-common

# Ajouter la clef et le repository des paquets de Docker
curl -fsSL https://download.docker.com/linux/debian/gpg \
| apt-key add -
add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/debian \
$(lsb_release -cs) stable"

# Mettre à nouveau à jour la liste des paquets disponibles 
apt-get update  

# Télécharger et installer docker 
apt-get -y install docker-ce 

# Démarrer le service docker 
service docker start

Création du groupe docker

Ce groupe unix évite de devoir se connecter en root pour démarrer des conteneurs. Ceci se fait à nouveau sous le compte root.

# Créer le groupe docker.
groupadd docker

# Ajouter un compte (ici user1 sur le noeud island1)
usermod -aG docker user1

Test de l’installation

Si tout se passe bien, on peut passer au test classique du « hello world! »

docker run hello-world

Le résultat devrait ressembler à ceci :

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
https://cloud.docker.com/

For more examples and ideas, visit:
https://docs.docker.com/engine/userguide/

Etat des lieux

Jusqu’ici, les nœuds étaient reliés en un cluster unix où chaque machine faisait ce que l’on voulait bien y lancer au travers d’une connexion ssh.

Après les manipulations indiquées plus haut, chaque nœud fait fonctionner son instance indépendante de Docker, et il « suffit » d’y lancer des applications dans des conteneurs au fur et à mesure des besoins.

London docks c1909

« Suffit » est entre guillemets car plusieurs limites apparaissent très vite :

  • Si une machine « meurt » (carte réseau ou disque HS par exemple), les applications qui y tournaient, ainsi que leurs données, sont perdues, le temps de remplacer le matériel fautif, et de restaurer applications et données.
  • Il faut se souvenir sur quelle machine tourne chaque application …
  • … et que la machine en question soit démarrée.

Ces limites ont plusieurs solutions, dont le mode « Swarm » de Docker.

Autres billets sur le sujet :

Creative Commons License

Catégories :linux Étiquettes :

Mégamètre!

juillet 11, 2017 Laisser un commentaire

Non, pas de remontée nostalgique de Goldorak. Pour information, je préférais Albator pour son côté épique et, toute proportion gardée, plus réaliste. Hey, j’avais neuf ou dix ans, quoi !

Non, là, je vais parler vélo, juste un peu…

Après un début de saison s’étirant en longueur, avec des arrêts dus à une météo défavorable puis une sciatique chatouilleuse, j’ai retrouvé un rythme à peu près normal. Je suis encore loin des quarante kilomètres quotidiens de l’an dernier, mais je progresse, et surtout, je travaille différemment, en alternant les sessions orientées cardio avec d’autres plus physiques.

Le physique, justement parlons-en. Pas du mien, qui se maintient façon Geebee, mais plutôt celui du vélo. Sur les cinq dernières sorties, trois crevaisons, à chaque fois dans un nid de poule qui a traversé sans regarder. Les poules vont bien, merci pour elles, leurs nids aussi. Dimanche, ça devait être celui d’un hybride de poule croisée avec un émeu. Heureusement que je roule plutôt « souple » – je sais, souple et moi, ça fait trois – sinon j’aurais cassé une jante. Le reste de la mécanique tient bien le choc, même si la chaîne sera bientôt à changer.

Rouler pour rouler, ça peut se faire sur un vélo d’appartement, mais j’aime bien prendre l’air. Sur route, pour l’échauffement ou le cardio, ou sur chemins, je tente de profiter du paysage, et des rencontres intéressantes qui ne manquent pas de se produire. Je passe pour l’instant sur les pok-pok-pok de certains troupeaux groupes de promeneurs dont les bâtons de marche et les babelles font plus de bruit qu’une sortie d’école. Je passe également sur une compagnie de coureurs plus ou moins sportifs qui occupe – dans un apparent désir obsessionnel de possession – toute la largeur du chemin.

Les personnages dont je veux parler sont tout autres. Par exemple, un Border Collie a dû me confondre avec un ovin égaré – surement la barbe ! – vu qu’il m’a coursé, et dépassé, jusqu’à ce que je m’arrête ! Je le savais déjà mais j’en suis désormais certain, il faut toujours parler aux chiens en chien ! Ils comprennent le parler humain, mais par pure amitié. Là, apparemment, un ovin qui parle humain, c’était trop suspect. Après discussion il a dû se rendre à l’évidence – je sais être convaincant – et m’a laissé partir après avoir reconnu son erreur.

Une autre rencontre intéressante était celle d’un cheval de trait, monté à la française. Le bougre avait décidé de rester là où il se trouvait : en travers du sentier. Visiblement, il a eu à choisir entre une séance de méditation impromptue et continuer sa promenade. Malheureusement, je ne parle pas cheval. C’est compliqué, parler cheval : c’est autant vocal que postural, alors face à ce « trait » bien décidé, j’ai dû me résoudre à utiliser les grands moyens et … j’ai simplement attendu qu’il ait terminé son introspection.

Au final, les vrais problèmes sont rares, à part les nids de poule imprudents depuis quelques temps, et je profite de ces sorties sportives pour faire le plein de bon air, de rencontres, d’efforts, de « Oh pétard je suis mort! », le plein de pluie parfois, et souvent d’endorphines.

J’ai un peu bifurqué là, non ? Ok, reprenons.

« Mégamètre ! « , disais-je. Il s’agit simplement du compteur kilométrique. J’ai passé les mille kilomètres, pour être exact mille et sept sur la photo, et douze cent dix à quelques pouillèmes près depuis Dimanche. Ce n’est pas une performance en soi, seulement une étape sympa.

megametre

Creative Commons License

Catégories :life Étiquettes :

Le Rubik’s Cube et la bouteille de Klein

juillet 4, 2017 Laisser un commentaire

J’aurai mis le temps, mais j’y suis enfin parvenu. Depuis le temps qu’il me narguait avec ses facettes colorées, et ses trois axes de rotation ! J’ai laissé mes doutes de côté, dansé une gigue et je me suis lancé.

J’y ai passé la journée, une journée complète de travail acharné à apprendre et comprendre les règles, comment déplacer une facette d’ici à là et inversement, et surtout j’ai longuement médité sur pourquoi, pourquoi, pourquoi six couleurs …

… et pourquoi six faces ? Après tout, une boule aurait été tout aussi bien convenu. Ou un cylindre, un cône, une ellipse de révolution ou un tore ! Ok, c’est chaud pour un tore.

Et pourquoi pas une bouteille de … Klein ? On me dit que non, ça ne sera pas possible pour la  bouteille de Klein. Petit tour sur Wiskykipedia, voyons voir… Je cite :

La bouteille de Klein possède un revêtement orientable à deux feuillets, difféomorphe au tore.

Ça doit être pour ça. Et, en plus, je lis ceci :

D’après le théorème d’Hurewicz, son premier groupe d’homologie en est l’abélianisé. C’est donc le produit direct ℤ×2.

 

Je ne suis pas sur d’avoir tout compris, mais c’est de toute apparence bel et bien foutu pour la bouteille !

De toute façon mon Rubik’s Cube est un cube. Pas besoin de tortiller de l’arrière train pour avancer droit, même en fermant les yeux et en serrant très fort ses petits poings rageurs, tout en récitant l’alphabet à l’envers une lettre sur sept trois-quarts, ça ne changera pas, ou si ça change alors le réveil-matin se chargera de remettre le cube au carré.

Reprenons. Cube, faces, facettes, couleurs. J’ai choisi la surface supérieure, examiné la configuration, évalué la stratégie le plus appropriée pour parvenir à mes fins, respiré un grand coup et …

… et bien après coup, je suis déçu. Je ne vois pas pourquoi on en fait tout un foin, car au fond, c’est très simple. Même un piou-piou de cinq ans saurait le faire. Je ne comprends pas comment on a pu écrire des bouquins et faire des programmes informatiques là dessus !

En résumé, je lui ai fait sa fête ! Et du premier coup en plus !

Ouaip les gens ! J’ai enfin réussi à mélanger un Rubik’s Cube !

rubik_s_cube_640x360

 

Creative Commons License

 

Catégories :Ca ne va pas mieux ! É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 :

Linux, réseau, ssh

juin 20, 2017 3 commentaires

Mes trois machines sont maintenant en réseau, et chacune sait être accédée depuis les autres. Idem depuis mon PC de travail.

Se connecter sur l’une ou l’autre demande d’y connaître un compte et de pouvoir en fournir le mot de passe via une interface chaise-clavier. Outre ajouter une couche de sécurité relative, ssh permet, sous certaines conditions, de se passer de mot de passe en utilisant le principe des clefs publiques et privées.

Pour le moment, l’aspect sécurité est secondaire en ce qui concerne mon cluster, mais je changerai certainement d’avis plus tard. Un pas à la fois.

Les manipulations sont faites depuis mon PC, et les paquets ssh-server et client sont déjà installés sur les nœuds du cluster ainsi que sur le PC

Création et copie des clefs

Rien de bien compliqué, il suffit de suivre l’un des nombreux tutoriaux disponibles sur le web, en adaptant les commandes si besoin.

1 – Créer un répertoire de travail et s’y placer

mkdir ~/src/islandscluster-ssh-key
cd ~/src/islandscluster-ssh-key

2 – Créer les clefs

ssh-keygen -f  id_rsa -q -N ""

3 – Créer le fichier des clef autorisées

cp id_rsa.pub authorized_keys

4 – Ajouter la clef publique du PC de travail

cat ~/.ssh/id_rsa.pub >> authorized_keys

5 – Copier les clefs sur le noeud island1 du cluster. Le mot de passe de user1 est demandé

scp -r . user1@island1:~/.ssh

6 – Tester la connexion

$ ssh user1@island1
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sat Mar 11 20:05:11 2017 from 192.168.0.41
user1@island1:~$

Voilà, le premier nœud est accessible sans mot de passe depuis le PC de travail.

Il reste à  réitérer la commande scp pour les deux autres nœuds du cluster, puis à tester les accès mutuels entre eux.

Un peu de sécurité : ssh et root

Il est généralement conseillé de désactiver l’accès à une machine via ssh sous le compte root. Il suffit, sous le compte root, de modifier dans le fichier /etc/ssh/sshd_config le paramètre PermitRootLogin à no :

PermitRootLogin no

puis de redémarrer le serveur sshd sur la machine :

/etc/init.d/sshd restart

Prochaine étape

La prochaine étape consiste à installer Docker sur chacun des nœuds, puis d’activer le mode swarm. Cela mérite bien un billet ad-hoc.

 

Autres billets sur le sujet :

Creative Commons License

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