jan 05
Suite à mes tests avec les AVR d’ATMEL et l’implémentation logicielle USB, j’ai testé l’interface avec la plateforme hardware via un script python s’appuyant sur le module python usbtiny fourni avec l’implémentation logicielle USB.
Un problème qui me bloque actuellement est l’utilisation de cette interface de communication sous Mac OS X.
J’ai installé la libusb (téléchargée depuis un projet développé pour utiliser des scanners sous Mac OS X). Les fichiers installés semblent se trouver dans /usr/local/lib, /usr/local/include. Dans la version linux, le wrapper utilisé pour communiquer entre le module python et la libusb avait été généré automatiquement par Swig. Le fichier libusb.py généré contient la ligne “import _libusb” qui doit faire référence au fichier _libusb.so dont le type ne correspond pas à une librairie sous Mac OS X :
ImportError: dlopen(./_libusb.so, 2): no suitable image found. Did find:
./_libusb.so: unknown file type, first eight bytes: 0×7F 0×45 0×4C 0×46
Une piste qui explique comment générer un wrapper avec Swig sous Mac OS X (et les différences avec la génération du wrapper sous Linux).
Suite au prochain épisode…
written by Mathias
août 20
Juste une idée d’un petit projet qui pourrait prendre quelques soirs dans la semaine (ou plus si affinité) : à la suite de la lecture d’un article sur l’organisation de la fuite d’informations depuis un poste distant dans le MISC n°44 de cet été (juillet/aout 2009), je me dis que pour tester, il pourrait être intéressant d’utiliser une broche d’un AVR typiquement reliée à une led pour lui permettre de communiquer avec le monde qui l’entoure. En résumé utiliser les 2 états (éteint/allumé) et/ou le temps d’allumage (…) pour transmettre des bits à l’environnement extérieur.
Cette petite expérience ne nécessite pas beaucoup de matos (voire même aucune modification matériel sur du matos existant) mais nécessite néanmoins quelques tests pratiques pour définir des valeurs correctes.
L’autre partie intéressante de cette expérience serait d’utiliser un capteur (iSight, photodiode/photorésistance voire pourquoi pas LED…) pour pouvoir décoder en temps réel les informations transmises par le montage.
Ce principe serait/devrait aussi être applicable en utilisant le son comme media de communication…
Le dévéloppement d’une petite bibliothèque AVR et de petits utilitaires côté hôte pourrait être très pédagogique.
written by Mathias
mai 09
L’idée : faire un radio réveil avancé à partir d’un PC.
Bios : wake up automatique à 6h00 tous les matins.
Lancer la tache “réveil” avec un crontab.
La tach réveil:
- Détecter présence sur place (mode local/distant) via bluetooth du tel en attendant de trouver mieux.
- Syncronisation du calendrier interne avec calendrier publié sur le net (Google Calendar) qui doit etre à jour (ou avec calendrier téléphone via bt ?)
- Récupération heure de réveil pour le jour de la semaine (fichier de configuration par défaut)
- Recherche d’événement spécifique pour la journée d’aujourd’hui (chaque jour de la semaine, vacances scolaires, jour férié…)
- A partir du calendrier + hre par défaut (+ jour férié ?) –> détermination de l’hre du réveil
- Réveil :
- Si mode distant : mise à jour calendrier google pour etre prévenu par sms du réveil (avec récapitulatif événements de la journée ?… pas forcément utiles car un sms envoyé par google X minutes avant chq événement)
- Si mode local : allumage de la chaine (envoi signal IR via un boitier USB ?) mesure du bruit local, lancement lecteur musique au volume le plus bas, puis augmentation du volume progressive (rapide au départ jusqu’à ce que la valeur mesurée atteigne un seuil fixé (fichier de propriétés), ensuite augmentation progressive. Lors de la réception d’un signal IR (de la télécommande) ou clavier () interruption de la lecture (voire, si aucune autre action prévue, arret du PC / mode veille prolongée pour réveil plus rapide).
Reste à faire : tout.
Problèmes potentiels :
- lancement de taches alors qu’aucun user n’est loggé (sauf peut etre en cas de wake up suite à une veille prolongée…)
- Sécurité : hébergement chez hébergeurs gratuits (eg free) => http… voir possibilité hébergement https ou autres options pour sécuriser les transactions
A lire :
written by Mathias
avr 11
Bon ça y est… Je suis passé à l’étape après la LED : l’afficheur LCD (celui de ma carte de dev AVRée).
Après avoir un peu galéré pour récupérer une doc correspondant à mon afficheur, j’ai finalement réussi à écrire un driver (basique, sans optimisation aucune… Mais qui avait le mérite de fonctionner!). 
Suite à une mauvaise manip (attention aux fichiers dont seul la casse du nom change sous XCode !), j’ai fini par reprendre le driver LCD d’une suite de librairies dédiées aux AVR et à la tunner pour ma config (lecture du LCD physiquement impossible : RW forcé à W).
En ce qui concerne la prog du 2313, je me suis bricolé un USBTinyISP pour pouvoir le programmer depuis mon Mac. J’ai eu quelques soucis au début : mon programmateur était bien reconnu par ma tour mais il ne l’était par aucun des portables qui trainent ici… Après quelques prises de tête et ré-étude du schéma, je me suis rendu compte que les diodes Zener assurant la limitation de tension sur les broches de données du bus usb sont nécessaires pour que les signaux soient interprétés sur tous les ordis (la tour tolère le +5V mais à priori les portables non… je n’ai heureusement pas grillé de port USB 
)
J’ai utilisé la breadboard de la carte de dev PSoC pour mon USBTinyISP (en laissant la connectique DB25 au cas où) et ça fonctionne plutôt pas mal. Donc dès que je trouve un peu de temps, je pense que je vais migrer tout ça vers une plaque pré-percée. Sinon l’autre “bonne nouvelle” c’est que ma carte de dev AVR était prévue pour être programmée via un port série (un switch permet de passer du mode programmation en mode tri-state pendant l’exécution normale, offrant ainsi la possibilité de laisser le programmateur branché sans danger pendant la phase de “run” normale). Un petit bémol là dessus : le USBTinyISP ne fonctionnait pas de base, j’ai été obligé de court-circuiter un trigger de Schmidt, mais l’inconvénient, c’est qu’en passant en mode Programmation, la broche reset du programmateur est alimentée par le montage… D’où un moment de surprise et de panique lorsque j’ai vu la LED d’alimentation de mon programmateur s’allumer alors que ce dernier n’était pas alimenté par l’USB…
Prochaine étape : connecter un GPS ?
written by Mathias
mar 20
Youpi : ça clignotte !
Apres avoir acheté sur eBay une carte de dev à la base orientée ancienne génération AT90S2313 (AVRée de Elektor), et quelques ATTiny2313 ainsi que des ATMega8, j’ai enfin de quoi tester les AVR…
Le souci : la programmation… Heureusement qu’il me reste une tour avec une prise lpt. Via un ssh dessus et par AVRDUDE (faudra que je re-teste UISP) j’ai réussi à programmer mon premier 2313 pour faire clignoter une LED ! Magique ! (Merci la carte de dev PSoC avec sa mini breadboard qui m’a permis de me servir de cette breadboard pour programmer le 2313 en utilisant l’alimentation “stabilisée” de la carte). J’en ai profité, après quelques mauvaises manips, pour re-tester le port parallèle du PC, ça faisait longtemps et ça m’a rappelé quelques bons souvenirs : faire clignoter des LEDs branchées sur le port //, lire les changements d’états… le tout sous Ubuntu (quelques galères avec les IOPerm et la librairie io à inclure, qui ne se trouve pas dans asm mais dans sys sur mon Ubuntu).
Il me reste quand même pas mal de progrès à faire mais je pense que je vais pouvoir pas mal m’amuser avec la carte de dev (LEDS, boutons poussoir, LCD 2×16, baie d’extension…), le tiny2313 étant compatible pin à pin avec l’AT90S2313, ça permet d’utiliser la carte sans aucune modification matérielle.
L’inconvénient pour le moment est la nécessité de retirer le tiny2313 pour le replacer sur la carte de prog., de déplacer la tour pour pouvoir accéder au port parallèle puis de la replacer à chaque nouvelle programmation du micro… Ca risque de ne pas être drôle longtemps, d’où l’urgence “relative” de me fabriquer un USBtinyISP ou USBASP : après quelques recherches dans le fond de mes tiroirs j’ai trouvé pas mal de trucs utiles mais il me manque les résistances 68 ohms qui permettent à l’host de détecter la présence d’un périphérique USB.
To be continued soon.
written by Mathias
