bleugafoto

Des photos, et des restes. le blog de ecaheti.

Articles taggés avec ‘embarqué’

Hop la, le retour du blog ! Dans les épisodes précédents, j’avais expliqué comment mettre en place un serveur de téléchargement. Depuis j’ai un peu changer/améliorer l’installation, d’abord d’un point de vue hardware :

  • Changement du système de fichier du disque “NAS” (ça a l’air de rien, mais ça a ses petites conséquences) sur le Raspberry Pi (que l’on appellera RpiWeb, qui contient les fonctions évoquer dans l’article précédent, à savoir serveur Web, NAS, Seedbox)
  • Installation d’un deuxième Raspberry Pi (que l’on appellera RpiAcq) contenant notamment deux sondes de températures DS18B20 et une Camera Board)
  • Suite à mon récent déménagement j’ai également changé de box Internet, et l’air de rien ça a des conséquences également.
  • Également sur RpiAcq, j’ai installé tout récemment un moteur pas-à-pas (stepper motor outre-manche)

Travaux sur la box

Bon, l’air de rien, ça fait pas mal de choses nouvelles à gérer. Déjà, la box internet. Avant, je routais sagement le port 80 du Rpi sur le port 80 de la Freebox. Mais ça, c’était avant. Maintenant j’ai une BBox (pas Sensation, mais alors pas du tout) que c’est un peu de la merde, pour 2 choses un peu essentiel. Déjà, quand je route le 80 du Pi vers le 80 de la box, ça m’affiche … le port 80 de la box. Ok, je me retrouve donc avec l’interface de config de la box accessible par le monde entier, super safe, et pas vachement pratique pour auto-héberger son p’tit site. Mais bon, j’ai changé le port externe et j’arrive à accéder à mon site sur un autre port, mais ça fait con, et en plus y a que le port 80 qui passe au boulot. Autre incommodité, impossible de se connecter “de l’intérieur” sur le site via l’adresse externe. Problème que je n’avais pas avec la Freebox. Contournement, un favori “RpiWeb interne” et un “RpiWeb externe”. Typiquement le genre de tracasserie qui en soit n’est pas grave mais qui put l’amateurisme. Mais bon, c’est le prix d’un Youtube réactif….

Travaux sur RpiWeb

Bref, concernant le RpiWeb, j’ai également changé le disque du NAS, par un modèle plus gros de récup et formater en ext au lieu de NTFS. L’installation a grandement gagné en stabilité, et si j’avais parfois le disque NTFS qui se déconnectait/démontait tout seul, plus aucun soucis maintenant… à part qu’il a faut maintenant que je gère précisément les droits d’accès, ce qui est parfois un peu pénible, gérer mon utilisateur moi-même, mon guest pour le partage réseau, et le serveur Web qui écrit des choses à droite à gauche.

J’avais également des déconnexions réseaux/wifi, et j’ai donc dégagé le dongle USB par un boitier CPL, le Netgear XAVT5602, qui a le bon gout d’être vendu par 3, et de disposer de 2 port Ethernet sur chaque boitier. Ceci me permet de simplifier la config Internet du Rpi, et de faire un p’tit hub Ethernet local.
J’ai rajouté pas mal de script shell pour automatiser pas mal de tâche propre à ce serveur, genre :

  • Faire un backup régulier du répertoire home et web
  • Scanner tout le sous réseau local pour afficher ensuite les machines présentes, et loguer les heures de présence
  • En fonction du script précédent, détecter certaines machines particulières (mon téléphone est-il connecté ? Le RpiAcq ?)
  • Vérifier l’adresse externe de la box et uploader sur un site une redirection vers cette adresse (pour ne pas avoir à me souvenir de l’IP externe de la box quand je me connecte à partir d’une machine qui n’est pas à moi). J’avais expliqué dans mon article précédent pourquoi je faisais ça et pourquoi je ne voulais pas passer par noip ou dyndns

Dernier point, depuis le passage en ext, mon script perl permettant de faire du téléchargement direct fonctionne de façon erratique. Je l’ai donc remplacé par une page en PHP de mon cru. Soit, je perds certaines fonctionnalités genre le téléchargement de plusieurs fichiers en parallèle, mais pour ce que je m’en sers ça colle très bien à mon usage.

Capteur de température sur RpiAcq

Bon, on va être honnête, c’est clairement ce qui m’a le plus amusé. Ayant déménagé d’une maison avec une chaudière à gaz avec thermostat à un appartement chauffé au grille-pain électrique, je me suis dit que faire le thermostat moi-même pourrait être chouette. Direction learn.adafruit.com, le site de la bidouille par excellence, bien documenté, avec des liens vers les différents composants dans leur boutique pour que ton côté geek compulsif puisse s’exprimer dans une réalisation électronique facile mais au combien gratifiante. Le site n’est pas le moins cher, mais il est bien foutu, et on trouve tout, tout de suite. J’ai donc acheté une plaquette d’essai, des câbles, un déport de connexion pour le port d’extension du Rpi, et une sonde DS18B20.

Pour info, cette sonde n’est pas un “bête” capteur de température, mais une sonde “intelligente” qui intègre un contrôleur OneWire, un protocole utilisé en domotique pour récupérer facilement les informations des capteurs/actionneurs d’une installation. Ce protocole n’est pas géré en tant que tel sur le Rpi, mais le noyau Linux permet de faire du bit banging imitant le codage/décodage du OneWire. Bon, en gros, une fois le câblage fini, c’est super fastoche à utiliser. Vous chargez 2 modules dans le noyau de l’OS (ça fait style je m’y connais, de dire ça, mais si vous préférez, c’est 2 commandes à recopier dans un terminal), vous faites un cat d’un certain fichier et zou c’est plié, la température du capteur s’affiche en millidegré.

Soyons honnête de suite, d’un point de vue hardware je me suis arrêté là. J’ai acheté 2 capteurs pisse que j’habite un 2 pièces, mais pour le moment ils sont montés l’un à côté de l’autre. Je voulais aussi pouvoir piloter mes radiateurs, mais ils sont alimentés directement par un câble qui sort du mur, donc comme je n’ai pas envie de tenter de détériorer l’installation, je me suis arrêté là… niveau hardware. Parce que pour le soft, c’est autre chose !
Oui, je me suis dit que j’avais un site web sur un Rpi, un relevé de température sur l’autre, il ne me manquait pas grand-chose pour lier les deux. D’un point de vue générale je me suis fixé la contrainte suivante : ne rien stocker sur RpiAcq. J’ai donc développé un bout de soft pour :

  • Faire une requête de température
  • Aller chercher les températures (les deux sondes ainsi que la température du CPU du RpiAcq
  • Stocker la température

Je suis parti sur un modèle UDP avec socket non bloquante afin d’éviter qu’une mesure de température qui part en couille ne bloque le système. Au départ je stockais le résultat dans un fichier texte toutes les heures, mais après quelques centaines de relevés, je me suis orienté vers une base de données sqlite3 pour pouvoir traiter plus facilement l’affichage des données sur le site web. Au final ça marche bien, et c’est cool, même si un peu inutile (enfin si, j’ai pu me rendre compte qu’en coupant complètement le chauffage par grand froid en mon absence, mon appart descendait sous les 12°C).
A faire : J’ai les deux sondes dans mon salon, faudrait que j’en place une dans la chambre histoire que ça serve un peu plus. En théorie en tirant un seul câble c’est jouable, le OneWire étant fait pour. Et aussi tenter de piloter les radiateurs, je ne sais pas trop comment.

CameraPi sur RpiAcq

Quel achat compulsif cette caméra ! C’est fourni comme le Raspberry, un pauvre PCB, et puis c’est tout. J’ai donc acheté en plus de la camera un petit support en plastique permettant en outre de placer la caméra sur un pied photo. L’avantage de la CameraPi, c’est qu’étant la webcam officielle de la fondation Raspberry Pi, son utilisation est super facile et documentée clairement. Le plus “dur” c’est de la brancher, et c’est pas bien compliqué. Moi mon challenge, c’est comme pour les sondes de températures, c’est de récupérer l’image sur RpiWeb !
Qu’à cela ne tienne, je me suis attelé au développement d’un outil pour transférer l’image de RpiAcq vers RpiWeb. Alors vous me direz… mais pourquoi faire un outil quand il existe déjà des trucs pour faire le taf (Samba, FTP, NFS, voir même ssh ou http). Et bien parce que je voulais un truc TRES simple d’utilisation. Et pour la beauté du dev, aussi. Hop, c’est reparti pour un client/server, mais en TCP cette fois. Principe identique à la température, avec en plus de la gestion de fichier :

  • Faire une requête de transfert de fichier
  • Faire une requête de capture d’image
  • Répondre en envoyant la taille de l’image
  • Transférer l’image p’tit bout par p’tit bout (rappel : un trame TCP c’est 1,5ko max…)
  • Reconstruire le fichier côté RpiWeb

Votre vif esprit aura remarqué que je fais d’abord une requête de transfert de fichier, puis d’image. Le client/serveur que j’ai développé permet en plus de prendre une photo de transférer n’importe quel fichier, histoire que je puisse le réutiliser pour récupérer d’autres trucs. Ça peut être utile…
Une fois l’image récupérée, elle est archivé sur le NAS. Via les crontab, la capture se fait tous les quarts d’heures. Et là vous me direz, mais… il finira par passer à poil devant la caméra ! Et bien non, car si mon téléphone est présent sur le réseau, l’archivage est automatiquement désactivé. J’ai donc une liste d’adresse MAC qui, si elles sont détectées sur le réseau, désactive la prise automatique de photos. Niveau utilité, j’ai donc pu constater que les ouvriers qui devaient venir pendant mon absence n’ont pas trop fait de la merde, et je peux prendre des photos du chat qui glande sur le canapé.

Moteur pas-à-pas sur RpiAcq

Dernier raffinement, rendre la camera orientable. Retour sur Adafruit.com pour trouver de quoi faire. J’ai trouvé des exemples de moteur CC, de servo moteur, et donc de pas-à-pas. J’ai choisi ce dernier pour une raison simple, son utilisation reste dans l’enveloppe énergétique du Rpi. En gros, l’alimentation 5v suffit. Comme d’habitude, le tutoriel sur Adafruit est simple comme tout. J’ai acheté le moteur et une plaquette de test plus grand pour pouvoir bosser proprement et garder mes sondes de températures. Au passage j’ai pris un boitier de protection.

Mon seul regret ici, c’est que je n’ai pas réussi à piloter le moteur avec un soft en C. Ah oui, j’oubliais de le dire, dans les contraintes que je me fixe, j’essaie de ne pas m’éparpiller niveau langage de développement. J’évite donc soigneusement le python parce que je n’aime pas ça, et pour le moment, je fais du C, du shell script, du html/PHP et un poil de SQL. Mais ici j’étais si près de finir que j’ai eu la flemme de chercher pourquoi mon soft en C ne fonctionnait pas. Les fonctions de base pour piloter le moteur sont donc en python.

Pour pouvoir piloter le moteur via RpiWeb, j’ai mis à jour le client TCP du transfert d’image pour qu’il soit possible de demander soit un fichier à transférer, soit la prise de photo, soit un mouvement à gauche/droite.
Dernier raffinement, un petit montage avec des Meccano pour fixer la caméra sur l’arbre. Pour que ça soit tip top moumoute faudra rajouter un axe de rotation verticale avec un deuxième moteur, un pointeur laser, une coque blanche ovoïdale et un haut-parleur qui balancerait des “Where are you ?”, “Are you still there ?” et autre “I don’t hate you” de façon aléatoire.

Et pour le fun, une petite vidéo :
YouTube Preview Image

Si un sujet vous intéresse, n’hésitez pas à poser des questions, je suis ouvert !

Retour de notre grande série, Parlons “embarqué” afin de monter dans les hautes sphères de la communication. J’ai parlé la dernière fois de communication entre mon µC (microcontrôleur) et divers composants avec un principe de base, le bus parallèle.

Mais vous l’avez constaté vous-même, ça devient vite un peu le bordel, c’est donc pour ça qu’une tétrachié de chercheur et d’ingénieur ont mis au point des bus de communication pour se faciliter un peu le câblage.
Exemple pratique récent avec vos disques durs, regardez moi dans les yeux du blog et dîtes sincèrement que vous ne regrettez absolument pas cette superbe interface qu’était l’IDE (ou Parrallel-Advanced Technology Attachment) au profit d’un Serial ATA beaucoup plus saillant.

Hummmmmiam, la bonne vieille nappe IDE qui niquait le flux d’air du PC, qui entrainait des galères de “T’es en slave ou en master sur la nappe?”, ça en fait des bons souvenirs !

Bref, rapidement on se rend compte que physiquement parlant, ça serait bien de pouvoir brancher autre chose que des machins qui font quarante fils de large pour quelque chose de plus discret.

Mais avant d’aller voir plus loin, parlons du moyen le plus simple pour “communiquer” avec un µC : le DI/O. Comme Digital Input / Output. Et oui, quoi de plus gratifiant que de faire rentrer un signal (avec un interrupteur ou un bouton poussoir) et de voir un résultat sur une sortie avec une petite LED dessus ? Et oui, ça vend toujours autant du rêve ici. Mais sans déconner, quand vous venez de finir de monter votre PC, vous faites quoi a part appuyer sur un putain de bouton en regardant la diode de la façade, attendant l’allumage de cette dernière tel un enfant qui attend fébrile le père noël ? Comme quoi, avec une diode on fait passer pas mal de message. Si vous voulez, vous pouvez même câbler 8 diodes et faire LE TP d’informatique industrielle le plus célèbre, le “chenillard”, ainsi que sa version haut de gamme dite “K2000″. Avec une Led, vous pouvez faire du morse, bon vieux protocole de communication série qui marche aussi bien avec des fils électriques qu’avec des signaux lumineux (foutez vous de ma gueule avec ma Led, mais les bateaux ont utilisé ce principe pour chatter).

Parallèle ? Série ?

Mais si rappelez-vous, je vous expliquais que le µC plaçait des niveaux électriques sur le bus de données. Dans mon exemple on utilisait un bus 8 bits, on avait donc en parallèle 8 informations sur 8 fils. Et si maintenant on disait que plutôt que d’envoyer 8 infos en même temps sur 8 fils on envoyait un série de 8 informations l’une après l’autre sur un seul fil ? Si la communication parallèle est faite avec une vitesse de 1 rafraichissement par seconde, il suffit d’aller 8 fois plus vite sur un seul fil pour obtenir le même débit.

Un bus parallèle à 1Hz (majuscule au H, je vous rappelle qu’Hertz est un éminent monsieur) offre les même performances qu’un bus série de 8Hz. Donc pour envoyer une information en série sur un seul fil, il suffira de mettre un niveau logique haut puis bas à une fréquence qui sera connu par le récepteur. Vous imaginez bien d’allumer et d’éteindre une Led à une fréquence constante pour envoyer un message est vite chiant, et c’est pour ça que des gens ont sacrifié leur vie pour créer des interfaces de communication standardisées.

Et la première interface qui me servira de support sera… la liaison RS-232 ! J’en vois deux au fond (toujours les mêmes) qui se disent que “tiens ça me rappelle un truc”. Et oui, dans les temps reculer de l’informatique cette sympathique interface méritait d’avoir son propre port sur votre PC, sous la forme d’une prise DB9 qui s’appelait glorieusement sur votre PC : COM1.

“AAAAAaaahhhh ouuuuuuuuui ! J’me rappelle, j’y branchais (enfin, papa le faisait…) mon modem US-Robotics 33,6kbauds pour aller occuper la ligne téléphonique avec les CD d’AOL gratuit trop bien”.

Exactement, cette glorieuse interface a fait son temps car elle permettait de brancher un peu un n’importe quoi pourvu qu’un dispose d’un logiciel qui gère une communication avec un périphérique externe (modem, imprimante, scanner, lance missile USB… ah non pas celui là, mais on aurait pu). Aujourd’hui elle a disparu du cul des PC grand public, et seul les professionnels en ont parfois besoin (moi en particulier) car c’est une interface très simple à utiliser pour discuter avec de l’électronique embarquée. Au passage j’en profite pour dire que si le connecteur n’est plus présent, les fils qui l’utilisent sont parfois disponibles sur les cartes-mères. Ainsi vous pouvez à peu de frais acheter le connecteur et faire un coup de tuning/soudure pour un effet rétrochic des plus charmants.

Question : Pourquoi le connecteur ayant disparu, l’interface électrique est elle toujours présente ? Et bien ce n’est que mon avis, mais c’est parce que le module du processeur qui va derrière est tellement bidon, peu cher et historique que tout les designers du puce le garde “au cas où”.

Ce module s’appelle la plupart du temps un UART (Universal Asynchronous Receiver Transmitter). L’UART est un module de µC qui se charge de transformer des signaux électriques en valeur compréhensible par le cœur du processeur, et de faire également l’inverse, transformer des informations venant du cœur en signaux électriques. Parce que manuellement changer les niveaux électriques est fatiguant, l’UART se charge d’envoyer à vitesse constante les octets qu’on lui met en entrée, déchargeant ainsi le CPU de cette tâche ingrate. L’UART est un périphérique qui utilise 3 fils :

  • Un pour la réception (Rx)
  • Un pour l’émission (Tx)
  • Une masse électrique.

D’un point de vue électrique lors d’une communication on observe ce genre de chose :

Lorsqu’on connait la vitesse et quelques autres paramètres, on peut facilement regrouper les changements d’états par paquets de 8 et ainsi recréer des octets, qui vont au final former un message qu’on décodera ensuite dans le programme. Sur l’exemple ci dessus, le programme reçoit une trame et en renvoi une identique. Si on fait le regroupement précité, on observe ça :

Si avez le temps, observez les niveaux logiques et vous pourrez trouver les valeurs binaires de chaque paquet, qui donne les valeurs hexadécimales de la première ligne. Pour indication la deuxième ligne montre les valeurs ASCII correspondantes (sauf les valeurs entre guillemets car elles ne correspondent à aucun caractère “classique”). Si cette trame est envoyée sur un PC avec un Hyperterminal, vous verrez donc quelques caractères s’afficher à l’écran.

On a donc utilisé 2 fils pour faire transiter 8 octets de 8 bits chacun, soit 64 bits. Plus pratique que 64 fils !

Limitation et contre mesure

La limite principale d’une communication série est la perte de données suite à une vitesse trop élevée. En effet si on regarde les chronogrammes ci dessus, il est facile de comprendre que si un bit est oublié, tout le message est décalé et l’information est mal comprise. Et plus on augmente la vitesse, plus le risque d’incompréhension est grand. De plus, dans le cas de la RS232, le côté “repère temporelle” est indépendant de chaque côté. C’est à dire que l’émetteur et le récepteur sont “sensé” utiliser la même vitesse de communication. Mais si ce n’était pas le cas… impossible de se comprendre.

Autre soucis, la préservation de l’intégrité des données. C’est simple, il n’y en a pas. Si une perturbation vient transformer un 1 en 0, impossible pour le récepteur de le savoir. Cependant on peut palier à ça en intégrant des checksum dans les trames, au prix d’une phase d’analyse supplémentaire à l’émission et à la réception. Et oui, rien n’est parfait en ce bas monde.

Conclusion

Une communication dans un système embarqué est soumise à un certain nombre de contraintes dont l’encombrement. On voit bien avec ces quelques paragraphes l’intérêt d’une communication série qui permet de limité les éléments à câbler. Si la RS232 répond à des besoins simples, elle sera insuffisante pour des communications rapides ou bien soumises à des contraintes de pollution électromagnétique.

Et bien ce que je peux conclure c’est que cet article et déjà assez long comme ça, alors que j’avais envie de parler d’autre type de bus de comm. Rendez un peu plus tard pour parler SPI, CAN et pourquoi pas USB et Ethernet.

Si vous avez manquez les épisodes précédents :

Pour résumer, on avait parlé des opérations de bases d’un processeur et du câblage d’un boitier mémoire ridiculement petit. Un boitier de RAM, c’est bien, plusieurs boitiers, c’est mieux!

J’ai décidé aujourd’hui, en pleine semaine de solde, d’acheter un peu de mémoire flash pour mon montage, dans le but de sauvegarder les résultats de mes calculs même une fois que mes composants seront privés d’électricité (Si je vous dis que la RAM est volatile ça va ? ça ne vous choque pas ? très bien). Et comme c’était les soldes, j’ai eu le droit avec mon boitier de Flash F4k16 (4k de flash 16bit, soit 8 kilooctets de données) à un boitier de RAM M1k (rappel, 1k de ram 8bit, soit 1 kilooctet de données) offert ! Formidable !

Câblage

Nous avions vu la dernière fois que pour câbler notre boitier, nous avions du brancher 4 “catégories” de fil : le bus d’adresse, le bus de donnée, le Read/Write et le Chip Select. Pour les bus, c’est très con, on tire les fils qui vont bien. Pour la RAM, le câblage est identique à celui réalisé précédemment (10 fils, A0 à A9). Pour la flash, la plage d’adresse du boitier de flash étant plus grande (4 est supérieur à 1), il va falloir tirer plus de fils entre le processeur et le boitier. Deux de plus pour être précis. Attention, démonstration ! 4k veut dire 4096 adresses différentes, allant de 0 à 4095. 4095 en binaire vaut 111111111111. Pas la peine de compter les 1, il y en a 12. D’où mes deux fils de plus. Les esprits fins de certains lecteurs auront remarqués que je vais tenter d’interfacer un boitier avec 16bit de data sur un microprocesseur 8 bits. Ben… les promotions Carrefour étaient sur les boitiers 16 bits, que voulez vous que j’y fasse ! Déjà, c’est quoi la différence entre un boitier 16 bits et un boitier 8 bits ?

Interlude “Mathématiques, Hexadécimal et autre décalage logique”.

Je vous ai décrit la fois précédente mon boitier de ram comme un tableau Excel de 1024 lignes dont le contenu pouvait varier entre 0 et 255. Et bien le boitier 16 bit est un tableau dont les valeurs peuvent varier entre 0 et (2^16) - 1, soit 65535. On peut également le voir comme un tableau avec 2 colonnes (au hasard, on va appeler la colonne de droite LSB pour Less Significant Byte, et celle de gauche par MSB pour Most Significant Byte. Attention, en fonction du contexte, le B peut vouloir dire Bit également), dont la valeur peut varier entre 0 et 255.

En multipliant le contenu de la case MSB par 256 et en ajoutant le LSB, on retrouve une valeur 16 bits. Pourquoi cette multiplication par 256 ? Prenons quelques exemples concrets. Et branchez votre cerveau dégourdi, on va faire des multiplications. Par deux, c’est super balèze. En binaire, 0 vaut 0 et 1 vaut 1 (si vous avez un doute, vérifiez avec la calculette de Windows, trop bien pour les conversions). 2 = 10 4 = 100 8 = 1000 Votre esprit aiguisé aura remarqué avec brio que pour passer de 2 à 4 et de 4 à 8, on dirait qu’on a juste rajouté un 0 ! Et oui, vous pouvez vérifier avec par exemple avec 3 (11) et 6 (110). La multiplication par 2 en binaire, c’est un décalage logique de 1 bit vers la gauche. Et par conséquent, une division par 2 est un décalage logique vers la droite : si on décale 14 (1110) d’un bit vers la droite, ça donne 111, soit 7. Par conséquent du conséquent, un décalage de 2 bit vers la gauche implique une multiplication par 4; 3 bit donne une multiplication par 8, etc. Alors what iz ze point avec mon boitier 16 bit ? Et bien votre MSB représente la partie 8 bit haute de votre nombre 16 bit. Elle est donc décaler de 8 bit, et donc est multiplier par 2^8 = 256. Ainsi, si votre MSB vaut 255, que votre LSB vaut 255, votre nombre 16 bit vaut 255 x 256 + 256 = 65535.

Retour à mon montage

Sur le schéma, on voit que j’ai câblé les fils D0 à D7, soit ma colonne “LSB”. Je vais donc pouvoir y accéder sans problème comme sur le boitier de RAM. Pour le MSB (fils D8-D15), je ne vais rien en faire, puisque de toute façon, j’ai un microprocesseur 8 bit (enfin en vrai je vais les câbler à la masse pour éviter les perturbations de signaux mais ce n’est pas le sujet). Vous avez donc compris que je vais gâcher la moitié de la mémoire flash car je ne pourrais en l’état pas y accéder, ni en lecture ni en écriture. Mais puisque je vous dis que c’était les soldes ! Il me reste donc 2 signaux à caser : R/W et CS. R/W peut se câble comme un bus, directement sur chaque composant. Par contre pour CS, c’est un peu plus siouxe.

La source de CS (ce titre de paragraphe n’est là que pour faire monter mes stats Google)

Si vous vous rappelez de l’article précédent (c’est le cas j’en suis sur), vous savez que le CS permet au processeur de désigner à qui il s’adresse, pour qui sont destinés les valeurs qui transitent sur les bus de donnée/adresse. Et manque de bol, je viens de regarder dans la documentation technique (datasheet) du processeur, je n’ai qu’un seul sortie CS ! OMG LOL WTF §§!! Je ne peux pas utiliser le même signal CS sur mes trois boitiers puisque dans ce cas, j’écrirais dans les trois boitiers en même temps, mais surtout la lecture va se faire également en même temps et la si un boitier veut coller 5Volts sur le bus (pour écrire un 1, je rappelle) et que l’autre veut mettre 0 Volts (pour écrire un 0) ça va faire un sacré bordel. Comment vais-je donc faire ? Et bien je vais faire du décodage d’adresse. Qu’est ce que donc ?

Définir le mapping mémoire

Dans un premier, on prend un papier et un crayon, et on organise son merdier. J’ai 2 boitiers avec 1024 adresses, et un boitier avec 4096 adresses. Mon micro, lui, avec son bus d’adresse 16 bit, peut adresse 2^16 soit 65536 adresses différentes. En gros, va falloir organiser les trois plages des boitiers dans l’espace adressable total du µC. Mon premier choix, c’est de dire : j’aligne tout. D’ailleurs c’est tellement une bonne idée que je vais la garder. On n’a qu’à dire que les 1024 premières adresses sont pour le premier boitier de RAM, les 1024 suivantes pour le deuxième boitier, et les 4096 suivantes sont pour la flash. En résumé :

J’ai maintenant une idée de ce que je veux obtenir, je peux ENFIN passer à la gestion de mon Chip Select.

Le décodage d’adresse

Ce qui va faire la différence entre les datas qui vont dans RAM1, RAM2 et Flash, c’est la plage d’adresse que j’ai attribué à chaque composant. Je vais donc me servir de mon bus d’adresse et d’un peu de porte logique pour faire la différence entre les boitiers, j’activerai alors le CS de chacun des boitiers de façon indépendante.

Rappel de logique combinatoire (oui, on en voit des choses aujourd’hui!)

Principe de base : combiner des signaux électriques pour réaliser des opérations logiques. Les briques de bases qui vont nous servir aujourd’hui (il y en a d’autre) sont la porte ET (symbole logique “.”, symbole informatique “&”), la porte OU (symbole logique “+”, symbole informatique “|”) et la porte NON (symbole logique “/”, symbole informatique “!”). Vous rentrez un ou plusieurs signaux sur les entrées, et vous obtenez un résultat de l’autre côté. On appelle “table de vérité” le principe de comportement de la porte.

Alors pourquoi je parle de ça ? Et bien simplement car grâce à plusieurs portes logiques bien placées, on va pouvoir réaliser une “équation logique” qui va permettre de diriger notre signal CS (oui, je rappelle qu’au départ on parlait de lui, avant que vous ayez eu cette idée stupide d’écrire tl;dr). Si on regarde le mapping mémoire, en particulier les bits de poids fort (les plus à gauche), on voit que les combinaisons qu’ils composent sont propres à chaque composant. Si les bits A10, A11, A12, A13, A14 et A15 sont à zéro, on est sur d’être sur la plage mémoire de RAM1. Puis avec A10 à 1 et A11-A15 à 0, on est sur d’être sur RAM2. Pour le boitier flash, c’est un peu plus tordu car il occupe un nombre plus important de combinaison de A10-A15, mais il existe tout un art concernant la simplification d’équation logique. Nous allons les écrire vite fait, présenter le câblage de notre “décodeur”. Nous cherchons à couper notre CS en trois signaux pour chacun des boitiers : CS1 pour RAM1, CS2 pour RAM2 et CS3 pour la flash.

CS1 = CS.(/A10./A11./A12./A13./A14./A15) : pour activer CS1, il faut avoir CS à 1, et tout les autres à 0

CS2 = CS.( A10./A11./A12./A13./A14./A15) : pour activer CS1, il faut avoir CS à 1, et tous les autres à 0 sauf A10

CS3 = CS.( (/A10. A11./A12./A13./A14./A15) + (A10.A11./A12./A13./A14./A15) + (/A10./A11.A12./A13./A14./A15) + (A10./A11.A12./A13./A14./A15) ) je vous laisse comprendre, comparez ça au mapping un peu plus haut.

Voici donc notre circuit logique qui va nous produire nos trois Chip Select différents. Il sera donc impossible d’adresser en même temps deux composants.

Cependant, il faut être franc, il existe en général des boitiers programmables ou ce genre de boulot, vous simplifiant clairement la tâche. D’ailleurs j’en ai trouvé un par terre, je vais tout de suite le mettre sur mon schéma final !

Voilà, on a encore amélioré notre système embarqué. Vous collez ça avec un alim au fond d’une machine à laver, et vous avez un système capable de :

  • Charger des data qui viennent de la mémoire flash
  • Faire des calculs
  • Ecrire les résultats dans une mémoire externe deux fois plus grande que la dernière fois
  • Faire plein de sauvegarde en flash

Il ne lui manque plus qu’un brin de communication, mais je me le garde pour plus tard. Vous devez déjà bien avoir la gerbe après avoir lu tout ça !

Parlons “embarqué”

Monday 20 July 2009

Je digresse un peu du thème du bleug pour parler de ce qui me fait gagner ma croûte et me permet de craquer parfois sur du matériel photo, et par la même occasion bouffer et avoir un toit. Le “système embarqué”. Sous ce terme très à la mode, se planque la plupart des choses qui font qu’au quotidien vous pouvez utiliser un programme super compliqué sur votre machine à laver (lavage à 38,12°, puis essorage un peu vif mais pas trop , séchage optimal pour le t-shirt “10 types de personnes, ceux qui connaissent le binaire et les autres” sans abimer la dentelle de la lingerie de madame), avoir des super intéressantes sur l’afficheur digital de votre autoradio, savoir combien de kilomètres vous pouvez encore parcourir avec votre voiture, ou bien configurer votre box internet pour laisser ouvert le port pour recevoir plus rapidement les films que votre cousin d’Amérique vous envoie par Internet.

Bref, yen a partout. Mais physiquement, ya quoi derrière ce merdier?

Ben la plupart du temps, le même bordel que dans votre PC. Un truc pour recevoir des stimuli de l’extérieur, un bouzin pour traiter les infos, et un bidule pour sortir des infos plus ou moins intéressante.

Question 1 : Alors ça veut dire qu’on pourrait utiliser un PC pour faire plein de truc dans ma machine à laver ?
Oui, clairement, le PC standard de Madame Michu a la capacité suffisante pour le faire. Mais…

Question 2 : mais pourquoi ya pas de prise USB sur ma machine à laver comme sur mon PC ?
Obvious : ça coûte des thunes ! et c’est inutile d’avoir un Core 2 Quad pour gérer le cycle d’essorage.

Question 3 : Il y a quoi dans ce cas dans ma machine à laver ?
Il peut y avoir plein de chose. Mais surtout, il y un chef d’orchestre, un composant qui peut être clairement omnipotent sur tout ce qui se passe dans la machine, de la présence d’une source d’énergie suffisante, à la gestion de la température de l’eau, en passant par l’usure du moteur électrique du tambour de la machine (important ça, mais pas si utiliser que l’on aimerait).

Et ce composant, c’est la plupart du temps un microcontrôleur.

Question 4 : C’est quoi un microcontrôleur?
C’est ça. Selon ma propre définition, c’est un microprocesseur avec des périphériques intégrés, parce que vous le savez déjà, bande de geek, quand on intègre plusieurs fonctions dans un même composant, c’est moins cher que de les prendre en pièce détaché. On va donc trouver plusieurs fonctions comme :

  • un cœur central qui fait des calcul (le microprocesseur, finalement)
  • une petite mémoire vive
  • parfois une mémoire morte
  • des entrées/sorties numériques
  • des entrées/sorties analogiques
  • des UART (Universal Asynchronous Receiver Transmitter) (mon dieu, en cherchant la traduction exacte du terme, je me suis rendu que j’écrivais la même chose que wikipedia…) qui sont globalement des liaisons séries (ouais, la prise DB-9 sur laquel vous branchiez votre antique modem 33k).
  • etc

Ça a l’air de rien comme ça, mais votre Core 2, il fait pas tout ça. Bon… je m’avance un peu. Mais en tout cas, les premiers microprocesseurs d’homme avait besoin de plein de merdier autour d’eux pour gérer l’ensemble des tâches qu’on leur confiait. Pourquoi à votre avis vot’ Paintiomme il a un southbrigde et un northbrigde avec lui ?

Le microcontrôleur, lui, il se suffit “presque” à lui même, et surtout, il le fait pour pas très cher. Le micro le moins balèze que j’utilise pour le moment est un PIC 18F2525, dont le pris atteint la somme faramineuse de … 5 euros ? Et encore !

Bien évidement, tout comme pour les processeurs de PC, on a le choix. Et que dis je, on a plus que le choix. En effet, là où en informatique classique, on conseille à Madame Michu de prendre le dernier cri parce que c’est trop tout neuf de la balle, dans l’industrie on regarde à deux fois avant d’acheter, parce que le prix n’est clairement pas le le seul soucis du concepteur de système embarqué de lave linge (d’ailleurs, le prix, c’est souvent le département achat qui va lui dire : “dis donc, ton Coldfire, il coûte un peu cher là (un peu plus qu’un centaine d’euros), tu veux pas un PIC ou un ARM à 5 euros plutôt?”).

Pour repartir sur les choix possibles, on a donc plusieurs critères qui rentre en compte, comme par exemple :

  • la puissance brute : alors que les processeurs 64bit commencent à être utilisé en info “domestique”, les micro, eux, existe encore en version 8, 16 ou 32bit. La vitesse joue également son rôle
  • le nombre de périphérique intégré : avoir un micro qui mouline à fond, c’est bien, mais si en plus on a plein de chose a lui faire faire (des acquisitions, de la comm série, ethernet, du calcul différentiel intégralement dérivé), c’est mieux qu’il est les bons périphériques déjà tout près (UART, liaison CAN, controlleur ethernet, etc)
  • la consommation électrique : s’il pouvait en plus être invisible sur la facture électrique (et autonome longtemps sur batterie…)
  • le prix : monde capitaliste, quand tu nous tiens.
  • le support technique: l’air de rien, un micro avec une grosse doc peut couter plus cher que son homologue russe… dont la doc n’existe qu’en russe. Sans parler des outils de développement qui vont avec.
  • la techno utilisé en interne : exemple à deux balles, un micro Intel sont en little endian, les Freescale sont en big endian, et essayer d’accorder les violons dès le départ en choisissant bien sont composants peut épargner des emmerdes (j’y reviendrais)

Bref, c’est quand même un beau bordel tout ça. Je vais préparer une suite ou je parlerais des langages, des périphériques, du jargon du coin, d’outils de dèv, et tant qu’à faire d’exemple pratique.