microchip 12F1822

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From French to

Threaded View
Bonjour,

savez-vous s'il existe un bootloader pour le 12F1822. C'est un pic
récent 8 broches ressemblant au 12F683 ou 12F675, mais avec la
possibilité de se programmer par soft.

J'ai posé la question sur le forum de microchip en février mais je n'ai
pas eu de réponse.

Si quelqu'un sait comment faire pour programmer ce chip...

Merci



Re: microchip 12F1822

Quoted text here. Click to load it

discussions ici:

http://www.microchip.com/forums/m556238.aspx

http://www.microchip.com/forums/f11.aspx
Quoted text here. Click to load it

--
--
What's on Shortwave guide: choose an hour, go!
http://shortwave.tk
We've slightly trimmed the long signature. Click to see the full one.
Re: microchip 12F1822
marc a écrit le 27/06/2011 :
Quoted text here. Click to load it

Très drôle.



Re: microchip 12F1822
"val"

Quoted text here. Click to load it

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 :
http://cjoint.com/data/0FBsEuW0vqk_12Flash.gif

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 :
http://www.etc.ugal.ro/cchiculita/software/picbootloader.htm

HTH
 


Re: microchip 12F1822
Jean-Christophe a écrit le 28/06/2011 :
Quoted text here. Click to load it

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.



Re: microchip 12F1822
"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
 


Re: microchip 12F1822
Jean-Christophe a écrit le 29/06/2011 :
Quoted text here. Click to load it
Je viens - péniblement - de mettre à jour mon programmateur pour qu'il
voie les 12F1822. C'est une première étape...

Quoted text here. Click to load it

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 !



Re: microchip 12F1822
"val"

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.



Re: microchip 12F1822
Jean-Christophe a écrit le 01/07/2011 :
Quoted text here. Click to load it

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.



Re: microchip 12F1822
"val"

Quoted text here. Click to load it

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 )

Quoted text here. Click to load it

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.
 


Re: microchip 12F1822
Jean-Christophe a tapoté du bout de ses petites papattes :
Quoted text here. Click to load it

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



Re: microchip 12F1822
"LeLapin"

Quoted text here. Click to load it

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)

Quoted text here. Click to load it

Et les sorties :o)
 


Re: microchip 12F1822
Jean-Christophe avait écrit le 01/07/2011 :
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.



Re: microchip 12F1822
"val"

Quoted text here. Click to load it

Le mieux serait que tu te procures la doc complète chez µChip :
http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en544839

Quoted text here. Click to load it

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)

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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)

Quoted text here. Click to load it

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 ... ?
 


Re: microchip 12F1822
Jean-Christophe a utilisé son clavier pour écrire :
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it
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.

Quoted text here. Click to load it

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.



Re: microchip 12F1822
"val"

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it
second
Quoted text here. Click to load it

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 )

Quoted text here. Click to load it

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 : noir00% gris_foncé01%, gris_clair10%, et blanc11%,
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.
 


Re: microchip 12F1822
Jean-Christophe a présenté l'énoncé suivant :
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

Ok, c'est plus élaboré que la led mais plus puissant aussi.
Quoted text here. Click to load it

Razut, ça va diviser par deux la vitesse.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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 ...
Quoted text here. Click to load it

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 ?



Re: microchip 12F1822
"val"

|  format ASCII : un seul octet binaire est codé par deux octets ASCII
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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 ...

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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


Site Timeline