Où sommes nous ?

Retour

Programmation physique du PIC

Maintenant que notre programme a été pleinement testé, il nous reste plus qu'à le graver sur le circuit.

J'utilise un PIC-01F de la société Seeit, connecté par le port série. Il est évident que ce qui suit ne concerne que ce programmateur ... pour les autres, il faudra peut être changer la configuration.

Configuration du programmateur dans PIKLab

PIC-01 n'est pas connu en temps que tel par PIKLab, mais est pris en charge comme "programmateur directe" ... c'est donc le programmateur que nous devons choisir dans le gestionnaire de projet (la valeur actuelle devrait être GPSim suite à notre simulation).

Petit tour maintenant dans le menu "Settings/Configurer les programmateurs ...".

Dans "sélection du port", on choisis "série" et on spécifie le port à utiliser. Dans mon cas, comme c'est le 1er port série, il s'agit de /dev/ttyS0 (se sera ttyS1 pour le second ou /dev/tty01 sous NetBSD ... soyez imaginatif).

Et dans l'onglet "Spécifique", on vérifie que c'est bien "JDM classique" qui est sélectionné.

On se rend compte que les icones relatifs aux programmateurs sont dégrisés ... nous n'utilisons plus un programmateur virtuel, mais nous avons accès physiquement à notre PIC !

PIC-01F

L'installation se veut simple : on lui branche une alimentation 12V continue avec le négatif à l'extérieur, une RS-232 en DB9 et voilà ... sauf que ça a vite tourné à la galère dans mon cas.

Les LED

Le programmateur contient 2 LEDs :

Comment perdre son temps avec les cables

J'ai récupéré une palanquée de câbles DB9 vers DB9 et je me suis dit facile ... oui mais non.

Premier essai, la LED verte est toujours allumée ... en fait il s'agissait d'un câble reliant un serveur et sa console ... sauf que ces %#$^@#% ont décidé de mettre une prise non standard côté serveur (bien pour rendre le client captif et l'obliger à acheter chez le constructeur, mais le câbles ne sert à rien d'autre ... merci ).

Second essai, la LED verte ne s'allume JAMAIS : ce coup-ci, c'est bien un câble RS-232, mais il est incomplet et seul RX, TX et la masse sont câblés.

Bref, j'ai arrêté les frais là et j'ai testé mes câbles restant : AUCUN NE VA ... Y'a donc fallu que j'en re-câble un, c'est dingue.

Bon, un gros déluge bien verbeux pour répéter la règle première lors de la récupération de câbles : toujours vérifier qu'ils sont bien câblés pour faire qu'on attend d'eux.

Note supplémentaire : si la question ne devrait pas se poser avec une DB9, il faut faire attention avec les câbles complets en DB25. Sur certaines machines comme les Amiga, les pins non affectés dans la norme sont utilisés pour fournir des tensions de services ; bonne initiative, car ça permet d'alimenter facilement les périphériques ...mais ça promet une belle fumée si le dit périphérique met ces pins à la masse pour améliorer la communication.

Testons ...

Retour dans PIKLab. Pour vérifier que la connexion entre le PC et le programmateur se passe bien, nous allons cliquer sur le bouton "Vérifier la virginité" matérialisé par un circuit point avec un point d'interrogation.

La LED verte devrait s'agiter un peu et le "journal de programmation" devrait afficher

Connexion de Programmateur direct[JDM classic] sur Port série (/dev/ttyS0) avec le circuit 16F88... 
Définir la cible auto-alimentée : false
Connecté.
Identifiant lu : 16F88 (rév. 8)
Vérification de virginité...
Vérification de la mémoire : Bits de configuration
La mémoire du circuit n'est pas vierge (dans Bits de configuration à l'adresse 0x2008 : 0x0000 lu et 0x0003 attendu).

On voit donc que

Si PIKLab vous dit que le PIC est absent ou mauvais (identifiant lu : 0x3FFF), vérifiez :

Il ne reste plus qu' graver

L'icône de gravage symbolisé par un circuit avec flèche entrante est-peut-être grisé : dans ce cas, il faut re-générer le projet.

Une fois ceci fait, on clique sur le dit icône, la LED verte s'excite, les différentes mémoires du PIC sont écrites puis vérifiées ... et voilà.

Comme pour tout le reste, tout c'est très bien passé : les seuls problèmes rencontrés venait du câblage ou du programmateur lui-même ... mais aucunement causé par le fait que je sois sous Linux ou de PIKLab.

Bref, une solution 100% Linux fonctionne très bien.

Si ca ne marche pas : le guide de survie.

Il y a plein de bonnes raisons qui peuvent faire que le passage au monde réel ne s'effectue pas correctement, et j'en ait expérimenté par mal  :

Pendant la programmation

Sur la platine d'essai

J'ai beaucoup galéré avec ma platine d'essai (ce qui explique en partie le manque d'activités sur cette rubrique du site pendant de longs mois) : Même si le PICs sont extrêmement permissifs au niveau du bruit ambiant, il ne faut pas exagérer non plus. En particulier, il faut s'assurer d'avoir une alimentation très stable ... ce qui n'a pas été le cas avec mon fameux transfo made in grande surface.
Alors, on programme, on met le PIC sur la platine, on alimente et ... rien. Alors, on s'énerve bien sûr, on remet en doute le PIC, la programmateur, PIKLab, on pense même à faire du voodoo ...

J'ai fini par alimenter ma platine avec une alim "de qualité" (en l'occurrence, l'alim d'un PC défunt) et magique : ça marche. Je pense que mon transfo ne lissait pas assez et donc que le PIC restait en sécurité, car n'arrivant pas à stabiliser son cristal.
QUE DE TEMPS PERDU !


Visitez :
La liste de nos voyages
Nos sorties Ski et rando
Copyright Laurent Faillie 2001-2017
N'oubliez pas d'entrer le mot de passe pour voir aussi les photos perso.
Contactez moi si vous souhaitez réutiliser ces photos et pour les obtenir avec une plus grande résolution.
Visites durant les 7 derniers jours Nombre de visites au total.

Vous pouvez laissez un commentaire sur cette page.