microchip 12F1822

discussions ici:

--
--
What's on Shortwave guide: choose an hour, go!
http://shortwave.tk
700+ Radio Stations on SW http://swstations.tk
300+ languages on SW http://radiolanguages.tk

Très drôle.

"val"

Pas vu de bootloader tout fait pour le 12F1822.

Consultes la data sheet, pages 110 à 115 tu y trouveras le code ASM qui permet de déverouiller et programmer la flash interne :

Ensuite tu implémentes une com minimale via l'USART du pic pour loader le code machine HEX via un soft depuis le PC. (ca tient en une centaine de lignes ASM)

Tu peux t'inspirer du principe général décrit ici :

HTH

Jean-Christophe a écrit le 28/06/2011 :

Merci Jean-Christophe. C'est une solution en effet mais ça risque de prendre du temps... Je suis pas sûr d'en avoir le courage.

"val"

| Merci Jean-Christophe. C'est une solution en effet mais ça risque | de prendre du temps... Je suis pas sûr d'en avoir le courage.

Mais c'est un bon entrainement ... :o) surtout qu'il n'y a pas (à ma connaissance) de bootloader déja tout fait pour ce PIC-là.

Pour te faciliter la vie, tu peux partir du source d'un bootloader déja écrit pour un autre PIC, et adapter le code au 12F1822. Côté PC (dans un premier temps, sans hand-shake) tu peux envoyer le HEX au PIC via RS232 avec un terminal. C'est même faisable sous DOS :

C:\> mode COM1 9600,N,8,1 C:\> copy code.hex COM1

"val"

Ok.

| tu peux envoyer le HEX au PIC via RS232 avec un terminal. | C'est même faisable sous DOS : | C:\> mode COM1 9600,N,8,1 | C:\> copy code.hex COM1

Oui enfin ca reste TRES rudimentaire, c'est juste si tu n'as pas encore de soft PC pour envoyer le HEX vers le PIC et que tu débugges la COM série de ton uC.

Hum, je ne dirais quand même pas cela ... Tu peux tester séparément l'écriture interne de la Ram Flash et la com série du PIC.

Jean-Christophe a écrit le 29/06/2011 :

Je viens - péniblement - de mettre à jour mon programmateur pour qu'il voie les 12F1822. C'est une première étape...

Mmmh, ainsi la partie PC est déja réglée sans que j'aie à lever le petit doigt. Déja la moitié du travail de fait !

Jean-Christophe a écrit le 01/07/2011 :

Oui, d'autant que l'écriture en zone flash se faisant par blocs je risque de louper des octets lors du passage des données de la RAM du µC vers la zone flash programme... Il faudra peut-être écrire un prog (PC) de transfert avec test du µC pour voir s'il peut accepter le bloc suivant.

"val"

Qu'est-ce qui te fait dire cela ? Dans ce genre de procédure, le transfert Ram vers Flash se passe toujours bien, sinon c'est que le chip est défectueux ou que la routine de transfert n'est pas écrite correctement. Les routines bas niveau données dans les data-sheets sont OK. ( sauf éventuellement publication d'un erratum par MicroChip )

En général on met en place un handshake entre le PC et le uC pour que le PC s'assure que les données émises ont été bien recues. ( donc avec une communication dans les deux sens au lieu d'un seul sens ) Par exemple, le uC vérifie le checksum du bloc recu et retourne au PC un code d'erreur en cas de défaut : le PC renvoie alors le bloc courant au lieu de passer au suivant. ( je suppose que le câble de liaison entre PC et uC sera assez court, donc - en principe - pas grand-chose à craindre de ce côté-là )

Pour chaque bloc recu, le uC le transfère de la Ram vers la Flash, puis relit le bloc Flash pour le comparer avec le bloc Ram : en cas de différence le uC retourne au PC un code d'erreur. Dans ce dernier cas le PC ne peut rien faire, mais il indiquera au moins à l'utilisateur qu'il y a un problème avec le uC.

Jean-Christophe a tapoté du bout de ses petites papattes :

A 9600 bps, même si c'est pas de la RS232 mais de la TTL, on a quand même de la marge sur la longueur et la qualité du câble. Au pire, charger un peu les entrées.

--
LeLapin

"LeLapin"

Yep. J'avais mis 9600 à titre d'exemple; le câble étant souvent assez court le RS232 ca tourne bien à 115,2 Kbps. (en général on se passe de bit de parité et on ajoute un checksum ou un CRC)

Et les sorties :o)

Jean-Christophe avait écrit le 01/07/2011 :

D'après la page du DS que tu m'as donnée l'écriture en zone flash se fait par bloc de 16 octets. Donc le µC reçoit les octets et les transfère en RAM, et une fois le compte de 16 atteint il les écrit en zone programme. Combien de temps ça prend d'écrire un bloc de 16 octets en zone flash ? Le buffer de l'USART étant de 2 octets (aargh!) cela veut dire que l'on a ~ 2 ms max (soit 2 octets à 96000 bds) pour écrire le bloc avant que le buffer ne soit en overrun. Est-ce que ça suffit, 2 ms, pour écrire un bloc de 16 octets, c'était la question que je me posait.

Oui, mais en fait les erreurs sur les ports séries sont tellement rares (une fois le truc stabilisé, hein) que ça vaut pas le coup de s'emm... avec de la gestion d'erreur. Si je le fais ce bootloader une approche Quick & Dirty me convient tout à fait.

Voila, mais pendant que le µC transfère vers la flash il faut pas qu'il loupe les octets entrants. Ou alors il faut découper le hex entrant en bloc de 16 et mettre un délai entre chaque bloc, mais ça serait dommage car je trouve ton idée du 'copy code.hex COM1' d'une simplicité très séduisante.

Bon, je vais essayer de trouver des infos de timing dans le datasheet.

"val"

Le mieux serait que tu te procures la doc complète chez µChip :

Je ne vois pas ca comme ca : ton µC a 128 octets de RAM, donc le PC peut envoyer au µC un bloc de 7 * 16 = 112 octets, puis attendre un code de retour de la part du µC. ( tu gardes 16 octets de RAM restants pour tes pointeurs, etc ) En cours de réception sérielle, le µC stocke les octets recus en RAM : lorsqu'il en a 112, il commence l'écriture en Flash par blocs de 16, puis retourne ensuite au PC un code signifiant « ok, je suis prêt, envoie-moi le bloc suivant ». De cette façon, ton algo est indépendant du temps d'écriture en Flash. (et ca l'immunise contre les dispersions éventuelles entre différents chips)

Oui, pour une première version ... mais c'est au début d'un développement qu'on a tous les problèmes à résoudre, alors ce n'est pas plus mal si le ?C peut retourner au soft PC des codes d'erreurs pour aider à la mise au point. ( si ton firmware ne tourne pas, tu ne sauras pas s'il a un bug ou si c'est le transfert en Flash qui s'est planté : dans ce cas tu es aveugle ) Et je t'assure qu'une fois que la com série µC/PC est fonctionnelle, ce n'est pas vraiment pas difficile à mettre en place.

D'où l'intérêt de bufferiser avec la RAM interne de 128 octets, et d'implémenter un minimum de hand-shake entre le ?C et le PC. Si tu ne comptes que sur la vitesse de la com série pour temporiser le temps d'écriture en Flash je crains que tu n'ajoutes plus de risques d'erreurs qu'en implémentant un hand-shake ... même rudimentaire.

Oui, mais dans ce cas tu n'as plus du tout de hand-shake ! Mais si tu tiens vraiment à procéder ainsi : pour augmenter le timming tu peux baisser la vitesse d'émission du port série. Par exemple, à 1200 bps tu recois (environ) 120 octets/seconde donc le ?C aura (environ) 8 ms pour écrire 16 octets en Flash. Et si ce n'est pas suffisant tu peux baisser encore la vitesse d'émission. Je vois que ce ?C a une mémoire programme de 3,5 Ko : à 1200 bps ca fait quand même 30 secondes pour tout up-loader en Flash ...

Je pense vraiment que ca vaut le coup de faire un petit soft PC pour gérer le hand-shake. De plus tu pourrais dans un premier temps envoyer des blocs de seulement 16 octets au ?C pour qu'il passe directement en écriture Flash ... et monter la vitesse à 115,2 Kbps tout en ayant un timming toujours correct grâce au hand-shake :o)

J'ai une question : avec un boitier 8 broches, en comptant 2 pour l'alim,

2 pour le Tx/Rx série il reste 4 broches de libres pour ton appli : je suis curieux de savoir ce que c'est ... ?

Jean-Christophe a utilisé son clavier pour écrire :

Je l'ai. Quand je m'intéresse à un nouveau pic je commence même par imprimer la doc, c'est incontournable. Ce qui bientôt ne sera pas plus possible vu l'inflation du nombre de pages dans le cas des nouveaux µC. Là ça fait quand même 400 pages imprimées sur 50 feuilles en 4p/f.

Ah oui il est indispensable de pouvoir débugger mais on peut le faire aussi avec le couteau suisse du développement sur micro : la LED. Genre un petit flash de led une fois le bloc de 16 octets écrit en mémoire programme. Cela dit débugger avec un TX/RX complet est beaucoup plus agréable car on peut envoyer les valeurs des registres vers le PC.

Bien vu. D'après la doc (DS41413B, page 353, paramètre Tiw) l'écriture en mémoire flash prend 2 ms. Si c'est l'écriture d'un bloc entier ça parait jouable de transférer en aveugle l'intégralité du fichier hex en

9600 N 8 1.

Ce que j'aime dans ce pic - qui est une sorte de super 12F683 en fait - c'est justement la possibilité d'assigner plusieurs fonctions à chaque broche. Mon appli est un simple timer qui tient dans une boîte 40x18x28 avec sa pile 11A. Ça se compose de : un bouton pour régler les minutes (avec flash d'une led bleue à chaque pression) ; un bouton pour démarrer le décompte (avec flash rouge) ; une led verte qui clignote une fois le décompte terminé ; un petit vibreur récupéré sur un téléphone portable comme second signal d'alerte. Enfin, une broche TX ayant servie pour le debuggage. Une fois tout ça correctement multiplexé il me reste même un port de libre. Ça sert juste à ne pas louper la cuisson du riz mais le développement était fun !

Maintenant je voudrais utiliser la led rouge comme RX pour le bootloader et utiliser l'écran du PC comme émetteur de bits (noir=0, blanc=1, par ex). Mais je ne sais pas si c'est vraiment possible car je n'ai pas encore testé le rapport signal sur bruit de cette méthode.

"val"

Oui, personnellement c'est pour cela que je n'imprime plus ces docs. En général on ne s'intéresse qu'à une partie à la fois : c'est dommage de dégommer des arbres pour imprimer du papier qui reste dans un tiroir.

Quand je n'ai pas d'interface, mon couteau Suisse est le port série : juste deux broches avec un minimum d'interface soft côté uC, et côté PC un soft maison pour dumper les adresses du PIC en lecture, mais aussi en écriture. Ca permet pas mal de modifs et de débuggage sans avoir à recharger le code à chaque fois.

Hé, Val, n'oublie pas que le HEX est un format ASCII : un seul octet binaire est codé par deux octets ASCII (par exemple 0x69 sera codé par 0x3639 ) Donc il faut transmettre deux fois plus d'octets que la taille rééle du code. Les compilos fournissent en sortie d'autres formats en binaire mais il faut connaitre leur structure. Dans tous les cas le fichier transmis nécéssite un minimum de parsing : s'agit-il de fusibles de config, ou de code ... et si c'est du code il faut transmettre aussi l'adresse. C'est plus simple si c'est le soft PC qui se charge de ce boulot en amont.

Ne m'en parle pas ! J'ai bossé sur un PIC à 80 pins dont pratiquement toutes les broches sont remappables : ca facilite le circuit imprimé mais il faut se taper l'init d'après la table de mapping ... bon. Il faut surtout garder sous le coude les fonctions assignées à chaque broche. ( là ca vaut le coup d'imprimer une page avec le chip et ses broches ) D'un autre côté ca rend plus difficile le reverse engineering.

second

J'imagine. Mais alors pourquoi tu veux un bootloader sur ce truc ? Si tu veux juste modifier sa configuration et son fonctionnement, tu peux le faire en chargeant des valeurs en EEPROM via le port série. ( ou avec un mini afficheur LCD sériel et quelques boutons poussoirs )

Et tu récupères les données de l'écran de PC avec une photodiode ? Si tu affiches un gros carré noir ou blanc et que tu transmets bit par bit, ca risque d'être plus long qu'avec un port série à 115,2 Kbps ...

Si le uC a une entrée analogique, tu peux utiliser plus de deux niveaux, par exemple quatre : noir=00 gris_foncé=01, gris_clair=10, et blanc=11, comme ca tu transmets deux bits avec une seule "couleur" et tu doubles la vitesse de transfert. Suivant la qualité de l'ADC du uC, tu peux augmenter le nombre de niveaux de gris tout en restant en-dessous du niveau de bruit.

Jean-Christophe a présenté l'énoncé suivant :

En 6 ans j'ai imprimé le 16F876, le 12F683, et maintenant le 12F1822. Les zentils zarbres n'ont pas grand chose à craindre de moi.

Ok, c'est plus élaboré que la led mais plus puissant aussi.

Razut, ça va diviser par deux la vitesse.

Oui, c'est l'esprit du bootloader du roumain, si je me souviens bien. Toute la complexité est gérée par le soft PC ce qui lui permet d'avoir un code asm très court pour le pic. Je crois bien qu'il parle même d'un code minimal d'une trentaine d'octets (ou une trentaine de mots, je sais plus) pour le bootloader, c'est bluffant. A propos de la config on ne peut malheureusement pas changer celle du

12F1822, on ne peut que la lire, c'est dommage.

En fait j'amerais pouvoir reprogrammer le truc sans ouvrir, et donc utiliser une des leds en capteur d'entrée RX. Il y a plein de choses que je pourrais améliorer, comme une gestion du temps en heures minutes ; ajouter une fonction thermomètre (le 1822 en a un en interne) ; utiliser la led bleue comme capteur UV ...

Excellent l'idée des niveaux de gris, je retiens ! Ce matin j'ai fait un test tout simple avec la led rouge (c'est sûrement la plus sensible) montée en inverse (5V sur la cathode) directement sur un multimètre et ça m'a donné écran noir = < 1mV, écran blanc = 26 mV +/-1mV. C'est largement suffisant pour faire un RX décent.

Bon maintenant il faudrait que je trouve un autre truc pour améliorer la vitesse de transfert, vu que le rafraichissement de l'écran n'est que de 60 Hz. Peut-être un système un peu comme des codes barres et balader la led sur l'écran ?

"val"

| format ASCII : un seul octet binaire est codé par deux octets ASCII

Oui, d'où l'intérêt de faire le parsing du HEX en amont par le soft du PC qui ne transmettra que du binaire pur.

Pour gérer juste les Rx et Tx de l'UART, pas même besoin d'interruption, et l'écriture (et le check) de la Flash, c'est compact.

Alors pourquoi pas carrément un autre PIC pour avoir les deux pins dispo pour Tx et Rx ? Sinon il y a toujours la possibilité (si c'est faisable sur ce uC) d'utiliser une seule broche pour Rx lors de la réception, puis de la reprogrammer en Tx pour l'émission, vu que tu n'as pas besoin de recevoir et d'émettre en même temps ...

Donc tu vas ajouter un peu d'électronique pour mettre ce signal en forme : avoue que ce serait plus simple d'utiliser un pic à 10 ou 12 broches pour avoir un port série full-duplex décent et digne de ce nom :o) Le tout tiendra bien dans une petite boite d'allumettes.

Hum, je trouve ca un peu compliqué par rapport à un simple port série.