Bonjour je souhaite mettre un bootloader sur un pic18f252. ce meme pic utilise un module Zigbee comme interface avec le PC. est-il possible de mettre en place un bootloader qui fait la mise à jour au travers du zigbee sans pour autant empecher toute autre communication dans dans la liaison série
Bonsoir,
Comment ton PIC est-il connecté au module ZigBee : UART ? SPI ? autre ?
Bonjour,
J'ai réalisé la programmation d'un pic depuis un pc avec des modules XBee et le bootloader TinyBootLoader à 115200baud/s. Tout est détaillé à l'adresse mais encore non fini...je n'ai pas mis le récepteur en ligne mais j'ai le schéma et le typon si necessaire.
http://www.ac-limoges.fr/sti_ge/spip.php?article26
par l'UARTEnvoyé par microchip
Bonjour,
Si c'est par l'UART suit le conseil de ELRIX et profite de son offre.
Tu as simplement besoin d'un bootloader UART + les commandes pour gérer ton module XBee.
est-ce que c'est possible d'utiliser le zigbee pour transmettre des donnée autre que le bootloader?
Bien sur vous pouvez faire de la transmission entre le PC et votre module XBee pour transmettre toute sorte d'info. Le bootloader sert à programmer le PIC ensuite la voie série est dispo pour faire autre chose. Genre lire un capteur, le numériser et ensuite le transmettre ves le pc à l'aide du XBee.
Cordialement
si j'ai bien compris quand on reçoit la trame 0xFFFAFA par la liaison série on fait le resetet on va automatiquement à l'adresse du bootloader et si on ne reçoit rien dans les 2ms on resaute a l'adresse du main? si c'est le cas
si dans mon main j'ai une boucle du type pour gérer la liaison série:
while(1)
{
receive_msg();
traite_msg();
send_reponse();
}
est-ce que je peut lancer le bootloader en faisant dans traite_msg
if(data_in==0xFFFAFA) reset_cpu(); ?
Bonjour,
Avez-vous lu l'article sur le bootloader sur le même site indiqué plus haut ?
Si non vous aurez pas mal de réponse à vos questions.
En fait j'active l'interruption de la voie série sur le PIC. Si lors de la réception je reçois 0xFF puis 0xFA puis 0xFA c'est le bootloader qui essaye de me contacter donc je fais un reset et le bootloader intégré attend des données sur la voie série sinon il repasse la main au programme principal. Si vous faites la même chose dans un flux de données que vous ne traitez pas sous interruption çà doit fonctionner aussi.
Attention il faut bien tester les trois octets à la suite. En admettant que votre fonction receive_msg stocke les caractères qui lui arrive dans un tableau data[20]:
if (data_in[0]==0xFF && data_in[1]==0xFA && data_in[2]=0xFA) reset_cpu();
Je ne sais pas si c'est très clair, sinon faire la méthode avec les interruptions ça marche très bien !
Cordialement
si c'est très clair merci
j'ai quelque questions sur ce morceau de code :
#device adc=8 *=16
#device ICD=TRUE
// Fusibles pour PIC18F
#fuses HS,NOWDT,NOPROTECT,NOLVP,PUT,N OBROWNOUT,CCP2C1,NOSTVREN,NODE BUG
// Fusibles pour PIC16F
//#fuses HS,NOWDT,NOPROTECT,NOLVP,PUT,N OBROWNOUT
// Fréquence d'horloge à ajuster
#use delay(clock=20000000)
// Vitesse de l'interface RS232 à ajuster
#use rs232(baud=115200, parity=N, xmit=PIN_C6, rcv=PIN_C7, STOP=1, BITS=8)
// Interruption réception d'un caractère dans le buffer voie série
#int_RDA // Reset avant reprogrammation par TinyBootLoader
a quoi correspondent les fusibles?
pourquoi utiliser la commande #use pour initialiser le rs232?
que fait la commande #use delay()?
et enfin a quoi correspon le #int_RDA tout en sachant que RDA et une interruption?
ce morceau de code à été tiré du lien donné par elrix un peu plus haut
Bonsoir,
toutes tes demandes se rapportent en fait à l'utilisation des directives de compilation du compilateur C de CCS.
Les fusibles c'est pour "configurer" le fonctionnemnt du PIC, la commande #use est spécifique à ce compilateur et permet de configurer rapidement une voie série sur le PIC, #use delay permet de calibrer les boucles delay_ms() et delay_us() en fonction de la fréquence du quartz externe utilisé, le #int_RDA est le point d'entrée de la routine d'interruption de la réception voie série.
En fait il faut lire la doc du compilateur ou chaque fonction est détaillée. Si mes souvenirs sont bons, le manuel du compilateur doit être téléchargeable sur leur site
ici.
Bonne lecture
Bonjour, moi je compile avec MCC18. si je fait le lien entre les 2 compilateurs :
#fuses correspond au #pragma config;
#int_RDA à #pragma interrupt;
et pour le #use delay, il n'y a pas de correspondance, si je veux une fonction delays ou delayus, il faut que je me la crée.
est-ce que j'ai bien compris la chose?
de plus quel est le lien entre la fréquence de l'oscillateur externe et la fréquence à laquelle va tourner le µC?
Merci d'avance
Bravo vous avez tout juste
La fréquence externe du quartz sera divisé par 4 en interne et donne la durée d'execution d'une instruction basique (en assembleur un movlw par ex). Si vous avez un quartz 4MHz alors le coeur du microcontroleur tourne à 1MHz soit 1us par instruction.
Pour les pic18F attention vous pouvez utiliser la PLL interne qui multiplie par 4 la fréquence externe donc en gros le coeur tourne à la même fréquence que le quartz externe... (Ex: quartz 10MHz externe => PLLx4 => 40MHz => horloge quadriphasé => fréquence du coeur=10MHz).
Pour des explications plus complètes il faut lire la doc technique (comme d'habitude je dirais
Pour réaliser des boucles de delai, on boucle sur un instruction "nop" (no opération) qui dure un cycle...
Cordialement
bonjour, j'essaie de mettre en place le bootloader d'elrix. pour cela je programme d'abord mon pic avec le tiny bootloader comme expliquer sur le site d'elrix. j'ai un problème lors du check pic avec le logiciel tinybld : il ne trouve pas mon pic. est-ce que quelqu'un pourrait me dire à quoi peut être dû ce problème et comment y remedier svp?
j'utilise un max232 avec ces condo de 1µF pour faire le lien entre mon port seérie et mon pic.
j'utilise un pic18f252 en 40Mhz 115200 bauds
Bonjour,
J'essayerais ca ce week-end. Le bootloader sur le site est pour un quartz 20MHz, si possible faire un essai avec cette fréquence de quartz. Pour tourner à 40Mhz il faut un quartz 10MHz et la PLL activée.
Je vous tiendrais au courant...
Cordialement
merci mais vous n'avez plus besoin de le faire : le problème est résolu et il n'avait aucun lien avec le programme du bootloader mais avec mon montage du max232. comme un idiot, j'avais oublié de brancher la masse du max232 donc le signal en sortie était très très sale et c'est pourquoi ça ne fonctionnait pas. j'ai quand même mis 1,5 jour pour m'en rendre compte. quand je vérifiait le montage je regardais uniquement les condo et mon alim 5V mais pas la masse.
désolé du dérangement et encore une fois merci pour votre aide
bonjour,
est-ce que la configuration des ports entrées/sorties peut se programmer au travers du bootloader? si non, comment peut-on programmer le bootloader un cette configuration en meme temps avec un programmateur classique?
Je ne comprend pas votre question !! Les ports d'entrées sorties se programment avec l'instruction set_tris_x(valeur); en CCS ou TRISx=valeur en MCC18 (ex: TRISB=0b00001111; // 0 = Output=sortie et 1 = Input=entré)
Donc ca a pas grand chose à voir avec le bootloader...
Cordialement
Bonjour, le bootloader fonctionne correctement avec la liaison filaire, alors j'ai mis en place le zigbee pour remplacer cette liaison et le bootloader ne fonctionne plus. le pic et bien détecter mais l'ecriture est impossible, et pourtant la transmission des données fonctionne correctement. j'ai configuré un module en coordinateur(celui du PC) et l'autre en "end device". ils ont le même ID et le même numéro de canal. le débit est de 115200 bauds RO=0 et le CTS est désactivé.
est-ce que quelqu'un pourrait me dire pourquoi l'écriture est impossible? ai-je mal configurer mon PIC?
merci par avance
Bonjour,
J'ai eu les mêmes problèmes pour programmer les PICs à travers cette liaison sans fil série ca marche impec jusqu'à 38400 aprés ca devient plus délicat. J'avais cependant trouvé une solution en supprimant le coordinateur et en mettant les deux zigbees en mode router/end device à 115200 bauds/s avec les adresses de l'un et de l'autre en dur sur les modules.
Voir mon post:
http://www.planete-sciences.org/foru...=8841&p=124345
Bon courage et tenez-nous au courant
merci pour ce renseignement et c'est vrai que la doc pourrait parler de ce problème. je vais voir si ça fonctionne et je vous tiens au courant
j'ai des modules XB24 802.15.4 avec le firmware de version 1084. j'ai essayé de changer la configuration de mes modules en enlevant le coordinateur et mettant les adresse qui conviennent et le bootloader ne fonctionne tourjours pas. je vais essayer avec une autre version (10C8) pour voir si ça marche. j'ai vu que dans votre utilisation les modules sont configuré en "end device AT", c bien la même chose que "end device" sauf que vous ce sont des modules ZNET? si ça ne fonctionne toujours pas avec la nouvelle version je vais abandonner le 115200 bauds et je passerai au 38400. le temps de programmation du PIC sera plus long c'est tout
j'ai du nouveau : finalement j'ai mis la version 10CD du firmware. le bootloader ne fonctionne toujours pas a 115200 bauds alors j'ai essayé a 38400 et ça fonctionne. cependant pendant la programmation, la LED indicatrice de reception de données de mon module du PC m'indique que l'on reçoit des info en permanence. est-ce normal? il ne me semble pas que le PIC envoi une reponse au fur et a mesure de sa programmation. si ce n'est pas normal c'est que le xbee envoi un flag de reception mais je ne sais pas quoi changer dans la config. j'ai relu plusieurs fois la doc et je trouve pas.
C'est le bootloader implanté dans le PIC qui renvoie un acquitement à chaque fois qu'il a reçu un paquet correct (la lettre K voir dans la doc de tinybootloader) donc c'est normal qu'il y ait un retour d'info.
Il faudrait que je refasse la manip de A à Z pour voir si' j'arrive toujours à programmer des pics à 115200. Je suis sur autre projet en ce moment je testerais ca quand j'aurais fini.
Bonne continuation en tout cas !
Cordialement
