Paris-Brest…-Paris

Encore une idée de bricolage à réaliser : un atelier portable.

Les idées:

• embarque oscillo, alim régulée
• monté sur une base sur roulettes pour le déplacement (verrouillables pour travailler)
• embarque un “vieux” PC (cf portable Toshiba sous Linux) avec ports USB / serie / parallele [liaison réseau wifi ou mieux : CPL, clavier/souris déportés], écran plan horizontal sous le plan de travail transparent –> Prévoir des rallonges pour déporter les sorties du PC afin qu’elles soient accessible depuis le plan de travail lorsque l’écran est visible.
• 1 connectique électrique pour l’atelier avec multi pour alimenter tous les appareils
• rangements pour instruments, composants…
• lampes LEDs (articulées ?) ou au moins source lumineuse amovible et orientable
• plan de travail amovible (cf repose clavier PC ou encore principe table de cuisine appart Paris)
• surface de travail : verre ou plexis qui permet de voir les instruments dessous (avec éclairage a LEDs par dessous à intensité réglable)
• Lorsque tout est refermé, place minimale (doit tenir sous un bureau normal, comme un caisson) et ne doit pas être [trop] sensible à l’environnement (hermétique aux copeaux de bois, etc…)

L’idée d’origine pour l’oscillo : plaque soutenant l’oscillo qui remonte lorsqu’on bascule le plan supérieur pour servir de plan de travail… Super principe mais pas évident à réaliser… De plus pour conserver le principe de l’écran plat + suerface transparente, il faut implanter tout ça dans ce plan de travail.

written by Mathias

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

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

Pour éviter de partir dans plein de projets différents sans jamais rien finir, je me dis que le concept de “Projet de la semaine” pourrait être simpa : énoncé du projet le lundi soir, étude, implémentation/prototype dans la semaine (voire 2 semaines pour les projets un peu plus conséquents) et publication d’un résumé et mise à disposition des sources le dimanche soir…

Pour le moment, le projet DeezerNotifier n’est pas terminé donc pour cette semaine, ça restera le fil rouge.

En ce qui concerne la suite, quelques idées qui me passent par la tête :

• Interfacer un AVR avec un écran de 3310 (ce qui nécessitera je pense une semaine pour voir comment organiser les projets AVR avec X-Code, comment rendre les sources accessibles depuis le net…)
• Interfacer un AVR avec un GPS (…)
• Page récapitulative des projets tracs hébergés sur une même machine (1 dev doit pouvoir consulter rapidement tous les tickets le concernant, doit pouvoir voir tous les tickets récemment saisies mais non affectés, etc)
• Interface IR pour commander mon APN.
• Interfacer un AVR avec un moteur pas-à-pas (type lecteur de disquette)
• Interfacer un AVR avec un moteur CC via LN297 ou autre (nécessitera du matos que je n’ai pas…)
• Interfacer un AVR avec une carte mémoire (SD ? pour limiter l’investissement dans la connectique)
• Interface FM pour sortie audio d’un PC –> broadcast de mes playlist dans les pièces de l’appart
• Interface AVR pour radio traffic ?
• Mettre en place les différents modules nécessaire à la réalisation du “radio réveil” évoqué dans un post précédent.
• Notifier gmail pour Gnome (via send-notify || zenity) & Mac OS via (Growl)
• JTAG pour AVR
• Et plein d’autres encore…

written by Mathias

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

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

Suite de mes expérimentations/idées/notes autour de l’AVR…

Pour conserver les avantages de la carte de développement ExpressEval pour le PSOC (fournie avec 2 PSoC CY8C29466), je me suis dit qu’il devrait être possible de réaliser un adaptateur enfichable sur le support du PSoC avec un AVR (ATMega8 ou autre).

Les contraintes pour une telle carte sont les suivantes :

• La carte doit pouvoir être utilisée seule pour programmer un AVR (elle doit donc embarquer un header ICSP, un quartz…)
• Idéalement un jumper permettrait de choisir la source d’alimentation : alim de la carte de dev (issue d’une source 9V ou du MiniProg) ou bien alim USB issue du programmateur AVR.
• Afin de vérifier la mise sous tension de la carte, une LED serait la bienvenue.
• Router les ports vers les pins des ports du PSoC, en tenant compte des broches spéciales de l’AVR (Rx, Tx…) et des broches choisies sur le PSoC pour l’interface RS232,… Et pourquoi pas, des supports tulipe pour ces ports (pour utilisation de la carte comme carte de dev en stand alone)
• L’emprise de la carte doit permettre d’être enfichée sur la carte de dev, sans pour autant obstruer les ports d’extension disponibles sur la carte de dev. Le port utilisé pour l’afficheur LCD doit être un port sans pin spécial, ce qui, à première vue, semble difficile/impossible ?
• L’idéal, pour éviter les faux contacts dus à l’adaptateur pour le support PSoC, serait l’utilisation d’entretoises (cependant ces entretoises doivent être assez grandes pour éviter les faux contact avec tout élément conducteur trainant sur mon poste de travail et à la fois assez courtes pour ne pas gêner l’enfichage de la carte sur la carte de dev, en prenant en compte les composants qui s’y trouvent déjà)

written by Mathias

Je poursuis ma recherche d’informations en tout genre pour débuter avec les micros AVR d’ATMEL.

Parmis les ressources utiles que j’ai pu découvrir, une liste de modules écrits en C pour faciliter le développement de fonctions spéciales basées autour d’un AVR.

Concernant les programmateurs USB, pour le moment, les projets sur lesquels j’ai porté mon attention sont l’USBASP qui est une solution articulée autour d’un ATMega8 et pouvant alimenter la carte cible depuis le port USB via la présence d’un jumper, ainsi que les programmateurs basés sur l’utilisation de FT232 mais pour le moment, je ne trouve pas les schémas de ces programmateurs (et je ne sais pas non plus si les FT232BM - à vérifier - que j’ai sont compatibles avec ces programmateurs). J’avoue qu’une version de taille réduite avec des CMS me plairait bien, mais faut pas être trop gourmand non plus.
Je réfléchis aussi à une carte de dev articulée autour d’un AVR (ATMega, ATTiny…) et je vois quelques périphériques qui peuvent être utiles dans une telle carte :

• Connexion MAX232.
• Connexion USB via FT232.
• Connexion USB pour implémentation soft de l’USB (USBtiny).

1. Voir la possibilité de n’utiliser qu’un seul connecteur USB et des jumpers pour passer d’une configuration à l’autre.
2. Voir la possibilité de mutualiser le hardware entre la config MAX232 et USB-FT232.
• Leds.
• Boutons.
• 10 pins header pour programmation ISP.
• Connexion afficheur LCD ?
• Interface I2C ?
• Connexion ethernet via RJ45 ?
• Bluetooth ? Là, je rêve un peu mais bon, ca pourrait qd même être sympa de s’affranchir de cables (debug via bluetooth série, reprogrammation à distance via bootloader…) Enfin bon, hein…

written by Mathias

Bon alors j’ai vraiment envie de me replonger dans l’électronique… Surtout que maintenant j’ai un peu de place et un peu de matos aussi.

Pour rattaquer, je suis en train de bidouiller un PSoC (CY8C29466) via un mini prog 3210 mais la suite PSoC designer ne fonctionne que sous Windows… Et pour le moment j’ai encore un peu de mal à le faire fonctionner comme je voudrais (allumage LED ok mais fonctionnement du CAN obscur…). L’autre micro qui m’attire en ce moment est l’ATMEL Attiny2313, sur lequel la gestion de l’USB low-speed peut être implémentée en soft : faut que je teste ça.

Sauf que pour programmer les ATtiny des softs sont dispos mais la plupart se basent sur la présence d’un port parallèle. D’où mon soucis actuel : sur mon macbook, je n’ai ni port parallèle (pour la prog) ni port série (utile pour débugger…) Je cherche donc un convertisseur USB Parallèle qui soit utilisable sous Mac OS/Linux comme un port parallèle.

Autant un grep CONFIG_USB_SERIAL sur le fichier de config de mon noyau me donne des pistes sur les adaptateurs USB - Série supportés, autant je ne sais pas d’où partir pour trouver des infos concernant un adaptateur USB - Parallele…

Pour le moment j’ai trouvé ça pour moins de 15euros chez ldlc et dont un utilisateur confirme le bon fonctionnement sous linux, les questions : d’une part c’est un adaptateur USB -> Centronics (j’aurais préféré parallèle DB25, faut que je regarde si c’est compatible auquel cas il suffirait d’utiliser une fichie Centronics sur le programmateur), et d’autre part, reste à voir si c’est utilisable pour autre chose qu’une imprimante… [Note, à priori le matos basé sur des chips Prolific a l’air bien supporté sous Linux]
Une autre solution serait la fabrication maison d’un adaptateur (en utilisant le port parallèle d’un vieux PC pour la première programmation du chip utilisé sur le programmateur couplé à un bootloader pour mettre à jour le firmware… mais j’ai peur de ne jamais trouver le temps de bricoler ça)

En ce qui concerne les softs (j’avoue ne pas encore avoir pris le temps de regarder) :

• Kicad, Eagle ?
• Voir s’il existe un environnement de dev un peu graphique autour de AVR GCC

Les idées de réalisation :

• Interfacer un écran de Nokia 3210/3310 (j’en ai un dont quelques lignes sont mortes mais qui reste utilisable sur les autres )
• Mettre en pratique l’utilisation de LED comme émetteur mais aussi récepteur (faut que je retrouve les docs là dessus, ça m’avait paru sympa)
• Si je trouve enfin un récepteur GPS pas trop cher et filaire, voir pour l’interfacer (cf détecteur de radar)
• …

Note : à regarder : Armadeus

written by Mathias