Bienvenue aux nouveaux arrivants sur FantasPic !
- Pensez à lire les règles durant votre visite, il n'y en a pas beaucoup, mais encore faut-il les respecter .
- N’hésitez pas à faire des remarques et/ou suggestions sur le Forum, dans le but de l'améliorer et de rendre vos prochaines visites plus agréables.
- Vous pouvez regarder votre "panneau de l'utilisateur" afin de configurer vos préférences.
- Un passage par "l'utilisation du forum" est recommandé pour connaître les fonctionnalités du forum.
--- L’équipe FantasPic ---
- Pensez à lire les règles durant votre visite, il n'y en a pas beaucoup, mais encore faut-il les respecter .
- N’hésitez pas à faire des remarques et/ou suggestions sur le Forum, dans le but de l'améliorer et de rendre vos prochaines visites plus agréables.
- Vous pouvez regarder votre "panneau de l'utilisateur" afin de configurer vos préférences.
- Un passage par "l'utilisation du forum" est recommandé pour connaître les fonctionnalités du forum.
--- L’équipe FantasPic ---
Modérateur : mazertoc
soucis avec debugger de PicKit 3
Bonjour à tous,
Je suis sur un programme de test d'un capteur de température Maxim DS1621 qui utilise le bus I2C sur un 16F884.
Une routine se charge de l'initialisation de quelques variables.
En mode pas à pas, cette routine semble fonctionner, on passe sur toutes les instructions sans problème, même en sautant les sous-programmes appelés (step over).
Si je veux aller plus vite et sauter cette routine, ça plante. De même si j'entre dans la routine et lance un exécuter jusqu'au curseur après avoir mis le curseur sur le return, ça plante aussi.
quelqu'un a-t-il l'expérience d'un programme qui a un tel comportement ?
Sans avoir une grande expérience de ce debugger, il me semble plutôt médiocre
Je suis sur un programme de test d'un capteur de température Maxim DS1621 qui utilise le bus I2C sur un 16F884.
Une routine se charge de l'initialisation de quelques variables.
En mode pas à pas, cette routine semble fonctionner, on passe sur toutes les instructions sans problème, même en sautant les sous-programmes appelés (step over).
Si je veux aller plus vite et sauter cette routine, ça plante. De même si j'entre dans la routine et lance un exécuter jusqu'au curseur après avoir mis le curseur sur le return, ça plante aussi.
quelqu'un a-t-il l'expérience d'un programme qui a un tel comportement ?
Sans avoir une grande expérience de ce debugger, il me semble plutôt médiocre
soucis avec debugger de PicKit 3
soucis avec debugger de PicKit 3
Bonjour Temps-X, merci de t'intéresser à mes soucis
MPLAB propose Debugger/Select tool/Pickit3, c'est celui que j'active après avoir connecté mon PicKit3 (officiel) à ma platine de mise au point. Il a l'air très pauvre
Pour le code, je t'extrais les lignes pertinentes :
init est le point d'entrée du programme
ClearRam est la routine classique
InitRegSpec initialise les FSR utilisés :
avec les valeurs suivantes
DS1621_Init APP_BaudRate instancie la macro DS1621_Init qui règle la vitesse du bus I2C utlisé à APP_BaudRate. En passant, elle initialise FSR (et IRP) pour pointer sur un tampon gérant les données entre le programme principal et le module DS1621.
call InitVariables
initialise quelques variables du programme principal, en particulier obj_DS1621_1 en calculant l'@ I2C à partir de son "numéro" obj_DS1621_1_VAL câblé sur la platine d'essais. Dans le projet définitif, j'aurai plusieurs DS1621 et une variable associée à chacun qui me permettront de les interroger successivement.
call setBoundaries, c'est cette routine qui pose problème
elle initialise les deux registres du DS1621 utilisés quand on l'utilise en thermostat (TLOWER et TUPPER). en fait ce sont les appels à DS1621_SetLOWER_TEMP et DS1621_SetUPPER_TEMP opérés par la macro CALL_DS1621 pour "l'objet" obj_DS1621_1.
En pas à pas, tout se passe bien, du moins apparemment, même si sur les instanciations de CALL_DS1621, on fait un "step over".
Mais si on s'arrête en début de routine et que l'on pose le curseur sur le return et qu'on demande "run to cursor", le programme plante dans le ssp DS1621_SetLOWER_TEMP ou DS1621_SetUPPER_TEMP.
la macro CALL_DS1621
la routine DS1621_SetLOWER_TEMP
DS1621_WaitNVB attend que le DS1621 autorise l'écriture dans sa mémoire
DS1621_Write_2Bytes envoie 2 octets aux DS1621
DS1621_Write_Byte envoie une trame composée de l'@I2C du périphérique cible, l'@ où écrire dans cette cible, le premier octet de la valeur à écrire. N'émet pas d'acquittement pour pouvoir chaîner l'envoi des octets suivants éventuels.
DS1621_Write_1Byte_1 pour gagner quelques octets utilise la fin du code deWrite_1Byte qui encoie le NonAck et le stop et restaure FSR.
i2c_write envoie un octet sur le bus I2C
IWAIT SSPCON2, ACKSTAT est une instanciation de la macro IWAIT qui attend que le bit ACKSTAT du registre SSPCON2 soit clear
Quand le programme plante et que je l'arrête avec stop, c'est dans la boucle ci-dessus qu'il tourne, il semble ne pas recevoir l'acquittement qu'il attend du DS1621, mais pourquoi le reçoit-il en pas à pas ?
et si tu m'as lu jusqu'ici.
, j'en suis complètement convaincu.Temps-x a écrit :Source du message j'ai appris à mes dépends que l'ordinateur à toujours raison
MPLAB propose Debugger/Select tool/Pickit3, c'est celui que j'active après avoir connecté mon PicKit3 (officiel) à ma platine de mise au point. Il a l'air très pauvre
Pour le code, je t'extrais les lignes pertinentes :
Code : Tout sélectionner
__CONFIG _CONFIG1, _INTOSCIO & _WDTE_OFF & _PWRTE_OFF & _BOREN_OFF & _LVP_OFF & _DEBUG_ON & _CP_OFF & _CPD_OFF
__CONFIG _CONFIG2, _WRT_OFF & _BOR21V
Code : Tout sélectionner
init
call ClearRam
call InitRegSpec
DS1621_Init APP_BaudRate
call InitVariables
init est le point d'entrée du programme
ClearRam est la routine classique
InitRegSpec initialise les FSR utilisés :
► Afficher le texte
avec les valeurs suivantes
► Afficher le texte
DS1621_Init APP_BaudRate instancie la macro DS1621_Init qui règle la vitesse du bus I2C utlisé à APP_BaudRate. En passant, elle initialise FSR (et IRP) pour pointer sur un tampon gérant les données entre le programme principal et le module DS1621.
call InitVariables
► Afficher le texte
initialise quelques variables du programme principal, en particulier obj_DS1621_1 en calculant l'@ I2C à partir de son "numéro" obj_DS1621_1_VAL câblé sur la platine d'essais. Dans le projet définitif, j'aurai plusieurs DS1621 et une variable associée à chacun qui me permettront de les interroger successivement.
call setBoundaries, c'est cette routine qui pose problème
► Afficher le texte
elle initialise les deux registres du DS1621 utilisés quand on l'utilise en thermostat (TLOWER et TUPPER). en fait ce sont les appels à DS1621_SetLOWER_TEMP et DS1621_SetUPPER_TEMP opérés par la macro CALL_DS1621 pour "l'objet" obj_DS1621_1.
En pas à pas, tout se passe bien, du moins apparemment, même si sur les instanciations de CALL_DS1621, on fait un "step over".
Mais si on s'arrête en début de routine et que l'on pose le curseur sur le return et qu'on demande "run to cursor", le programme plante dans le ssp DS1621_SetLOWER_TEMP ou DS1621_SetUPPER_TEMP.
la macro CALL_DS1621
► Afficher le texte
la routine DS1621_SetLOWER_TEMP
► Afficher le texte
DS1621_WaitNVB attend que le DS1621 autorise l'écriture dans sa mémoire
► Afficher le texte
DS1621_Write_2Bytes envoie 2 octets aux DS1621
► Afficher le texte
DS1621_Write_Byte envoie une trame composée de l'@I2C du périphérique cible, l'@ où écrire dans cette cible, le premier octet de la valeur à écrire. N'émet pas d'acquittement pour pouvoir chaîner l'envoi des octets suivants éventuels.
► Afficher le texte
DS1621_Write_1Byte_1 pour gagner quelques octets utilise la fin du code deWrite_1Byte qui encoie le NonAck et le stop et restaure FSR.
► Afficher le texte
i2c_write envoie un octet sur le bus I2C
► Afficher le texte
IWAIT SSPCON2, ACKSTAT est une instanciation de la macro IWAIT qui attend que le bit ACKSTAT du registre SSPCON2 soit clear
► Afficher le texte
Quand le programme plante et que je l'arrête avec stop, c'est dans la boucle ci-dessus qu'il tourne, il semble ne pas recevoir l'acquittement qu'il attend du DS1621, mais pourquoi le reçoit-il en pas à pas ?
et si tu m'as lu jusqu'ici.
Retourner vers « Langage ASM »
Qui est en ligne
Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 69 invités