Robots @ Loamok

Concept de programmateur multi-ports ICSP pour pics

symio — Tue, 03 Jul 2007 09:57:00 +0200

Pendant une séance de réflexion à la conception de mon Robot, il m'est venu une idée que je pourrais presque qualifier de géniale :

Le "Concept de programmateur multi-ports ICSP pour pics". Je m'explique :

Premières contatations :

- Il est convenu que l'électronique nécessaire à la programmation d'un micro-controleur est coûteuse pour l'autonomie d'un robot.
- La technique du "Boot-loader" (technique permettant de charger du code dans la mémoire au démarrage du pic) est également coûteuse en termes de réservation d'une partie des ports d'entrée-sortie du micro-controleur pour les dédier à une communication série ainsi qu'en consommation de la mémoire de programme, puisque le fragment de code "Boot-loader" doit être inscrit de manière "résidente" dans la mémoire de programme du micro-controleur. (Cela fait des octets libres en moins et puis il faut quand même un programmateur pour placer le "Boot-loader" en mémoire ...).
- La technique du programmateur externe nécessite d'avoir un accès physique au micro-controleur en permanence. Il faut << arracher >> le micro-controleur de son support, le placer sur le programmateur, le remettre sur le support de sa carte mère ..... Bref c'est loin d'être idéal comme concept.

Secondes constatations :

- Il semble peu pratique de devoir s'équiper d'un programmateur par type de port exploité sur un PC. En effet si l'on souhaite pouvoir faire preuve de mobilité il faut :
-A) : trouver un port pc suffisament générique pour être disponible en toutes circonstances.
-B) : s'équiper d'autant de programmateurs que de ports de programmation possibles.
-C) : se prommener partout avec une tour pc dédié à la programmation du robot.

Analyse :

Un programmateur c'est quoi ? Ce sont quelques composants dédiés à la programmation d'un micro-controleur faisant le lien entre un port (Série, Parallèlle, Usb) et les pattes dédiées à la programmation d'un micro-controleur.

L'ICSP c'est quoi ? C'est l'extériorisation des composants de programmation sur une plaquette séparée de la carte de support du micro-controleur, les deux plaquettes "dialoguant" au travers d'un connecteur.

Un Port (Série, Parallèlle, Usb) c'est quoi ? C'est une interface Machine-Machine. C'est une série de broches permettant des entrées - sorties d'un ordinateur vers un autre équipement au travers d'un protocole commun.

Conclusion :

Un programmateur multi-ports ICSP peut être conçu selon le croquis suivant :

Le "PC" est relié au programmateur via un "module" (Série, Parallèlle, Usb). Le programmateur est relié au support du micro-controleur via une liaison ICSP.

De cette façon il suffit de disposer du module adéquat pour reprogrammer le micro-controleur du robot depuis n'importe quelle plate-forme (PC, portable, Apple, Palm, .....).

Les outils du Geek

symio — Mon, 02 Jul 2007 12:14:00 +0200

J'ai faillit oublier l'essentiel !!!
Quels outils pour la robotique sous Linux ? :

Outils de conception :

Tout d'abord pour faire de jolis schémas, dessiner des plaques électroniques (PCB), obtenir un aperçu en 3 dimensions de la plaque résultante, imprimer Typons et autre liste de composants :
L'excellent Kicad

Pour les PICS :

Ensuite pour compiler de l'assembleur pour les pics, simuler le fonctionnement d'un programme (le premier qui réussi à faire clignoter une led pour pic16f84 dans un simulateur sous ubuntu-gnome, .... je lui offre une barquette de fraises (NDLR)), ... et bien plus :
GpUtils

Et enfin histoire d'envoyer le code compilé directement entre les pattes de notre puce :
PKP extrait du projet PikDev (pour les Kde'istes).

Carte de commande "Monty" et adaptations diverses

symio — Mon, 02 Jul 2007 07:48:00 +0200

Comme vous pouvez le voir sur le site dédié au robot Monty, la carte de commande principale sert à la fois de carte mère et de carte de programmation pour un pic 16f84.
Voici le schema de cette carte :

Cette carte a le désavantage d'intégrer toute l'électronique nécessaire à la programmation des pics.
Je dis désavantage car cette électronique n'est indispensable que pour les "séances" de programmation du pic. En mode "fonctionnement" cette électronique représente une pompe à courant et un surpoids inutile.
De plus cette partie de la carte a été particulièrement mal étudiée en termes de choix des valeurs des composants. Il n'est en effet pas possible, sans la modifier, d'utiliser d'autres logiciels de programmation que celui fournit. Et enfin de graves perturbations électro-magnétiques surviennent systèmatiquement lors des séquences de programmation rendant temporairement inutilisable le pic embarqué.

Modifications notoires :
- Inversion des sorties de r12 et r13 respectivement vers les pattes 5 et 9 du buffer U3.
Cette modification permet d'apporter à la partie "programmateur" la compatibilité "Tait Programmer".
Après tout, s'adapter à un standard reconnu est une forme d'ouverture et ça ne peut pas faire de mal à une plateforme mal conçue. (NDLR)
- Remplacement des résistances de "Pull-up" R2, R3, R4 de 10K par des résistances de 1K.
Cette modification notoire des composants est censée supprimer les problèmes de programmation dus aux perturbations électro-magnetiques induites par la fréquence (élevée) présente sur les signaux "datas" et "clock" lors du transfert du code.
Je n'ai pas encore éffectué cette modification et subit toujours des erreurs quasi-systèmatiques lors de mes essais de programmation d'un pic 16f84.
Le plus comique lors de mes tests est que l'orsque je place un multimètre mesureur de tension entre la patte 6 du buffer (Data) et la masse du montage, la programmation s'effectue sans problème !!!
Ma conclusion est donc que mon multimètre (résistance interne de 10 MOhms) une fois placé en sortie du buffer data crée une sorte de pont diviseur de tension entre la résistance R4, la sortie du buffer et la masse stabilisant ainsi la sortie de données et permettant le bon déroulement de la programmation.
Je ne sais si le terme est "électroniquement correct" mais j'en conclut que mon multimétre ainsi placé se comporte en résistance "Pull-down".
Voici le schéma résultant :

Et les calculs en loi d'Ohms décrivant la tension présente en "Data" une fois le montage en place :

Sachant que la broche RB7 (Data in) reçoit un "1" logique avec une tension de +5V et un "0" logique par une tension de 0V, le buffer avec sa résistance de pull-up est censé délivrer soit 5V soit rien (0V).
Un appareil de mesure placé entre la sortie du buffer et donc la masse indique bien des oscillations de 5V et 0V.
/!\ Oui mais voila le multimètre n'est pas neutre et contient sa propre résistance interne ! /!\
L'orsque l'on enlève le multimètre on ne peut être certain de bien revenir à 0V quand c'est nécessaire. Le +5V est, quand à lui, assuré par la résistance de pull-up.
J'en déduit que l'orsque je place mon multimètre mon montage change pour de venir un "Pont diviseur de tension". Dont les valeurs de sorties sont :

Formule : RB7 = BO + (5V*(10000000/(10000+10000000)))
A°) : pour Buffer-Out = 5V : RB7 = ~10V
B°) : pour Buffer-Out = 0V : RB7 = ~5V

Ces résultats êtant parfaitement faux car ils ne tiennent pas compte de la résistance interne du pic entre RB7 et la masse du montage.
Ce qui transforme notre pont simple en "Pont diviseur de tension chargé".
L'ajout de cette résistance "enlevant" ~5V au montage (étant donné que mes mesures au multimètre me donnent une oscillation entre 0 et 5V j'en déduit que la réduction voltaïque du pic est d'environ 5V) nous obtenons donc :

Formule : RB7 = (BO + (5V*(10000000/(10000+10000000)))) - 5V
A°) : pour Buffer-out = 5V : RB7 = ~5V
B°) : pour Buffer-out = 0V : RB7 = ~0V

Pour conclure sur les modification de la platine de "Monty".
Je ne remplacerais sûrement pas les résistances de 10k par des 1K mais placerais, de préférence, une résistance de 10MOhms entre la sortie du buffer et la masse. Afin de stabiliser proprement et définitivement le signal de programmation.

J'attends bien évidemment vos commentaires car je n'ai aucune confirmation ou infirmation de mes théories si ce ne sont les expérimentations que j'ai moi-même conduit. (en tout cas si mon montage explose une fois la résistance de pull-down en place je ne comprendrais pas pourquoi).

Je placerais bientôt, ici-même, une vidéo démontrant ce bug étrange.

Le(s) cerveau(x) d'un Robot : un micro-controleur

symio — Sun, 01 Jul 2007 18:14:00 +0200

Tout robot digne de ce nom ce doit d'être doté d'un ou plusieurs cerveau(x).

Ces cerveaux sont matérialisés sous la forme de micro-controleurs (pic 16fxxx, Atmel, ...etc etc...).

Je commence donc mon étude des micro-controleurs avec l'ultra classique PIC 16F84A.

Ayant tenté, par le passé, de réaliser un robot "Monty", je dispose de presque tout le matériel nécessaire pour démarrer une longue période d'aprentissage, de ratages et de bugs divers . Bref le lot quotidien de tout geek convaincu. Pour le reste je le fabriquerais au fur et à mesure et ferais en sorte que chaque "module" soit suffisamment générique pour servir aussi bien mon robot qu'un autre.

Ce que j'ai appris lors de ma tentative de "Monty" :

- un micro-controleur est programmable à souhait (limité toutefois à sa structure physique),
- ces petites bestioles à multiples pattes ont besoin d'un programmateur pour ingérer le code compilé,
- ces mêmes bestioles ont besoin d'un support électronique pour fonctionner,
<< ce support pouvant se confondre avec le précédent (cas du robot "Monty" dont la platine principale sert aussi à la programmation ce qui n'est pas sans poser quelques problèmes à nombre de Montyliens) >>

Ce que j'ai appris bien plus tard :

- Le fabricant des PICS (Microchip) a breveté une technique de programmation nommée ICSP (In Circuit Sérial Programming).

Au sommaire donc :

- Carte de commande "Monty" et adaptations diverses,
- Concept de programmateur multi-ports ICSP pour pics,
- Carte mère minimale pour pic.

Création, un nouveau blog est né ..

symio — Sun, 01 Jul 2007 17:48:00 +0200

Il existe beaucoup de ressources sur le thème de la robotique de par le web.

Un constat tout de même sur ce florilège de ressources :

- la plupart sont totalement désorganisés,

- beaucoup "piquent franchement les yeux",

- la grande majorité s'adressent à des utilisateurs de plate-formes propriétaires.

Et le Libre dans tout ca ?

Quelle est la place du Linuxien passionné désireux de créer son petit robot ?

Malheureusement, elle est faible et rarement francophone.

Alors si comme moi vous avez jeté Gill Bates aux horties ... Que vous ne concevez plus l'informatique autrement que sous Linux ...

Bienvenue, ce site s'adresse tout d'abord à vous.

J'ai entamé la construction d'un Robot, et ce blog est un recueil de mes explorations dans ce domaine appliqué aux Logiciels Libres.

Tout les thèmes nécessaires à la construction de ce robot seront explorés, fouillés, traduit en Libre. Vous trouverez ici mes réflexions, des schémas électroniques adaptés aux besoins de mon robot (et donc peut-être du votre).

Vous pourrez y poser des questions, ou répondre aux miennes qui seront très nombreuses.