Les interruptions avec ICD2 et CC5xfree

[invite1e8ad136]

Bonjour,

Je suis actuellement en train de programmer un PIC16F818 en esclave I²C afin de gérer un petit moteur.

J'utilise MPLAB IDE v8.00 avec CC5xfree comme compilateur, ainsi qu'un boîtier ICD2 pour debugguer mon programme.

J'ai cependant un problème avec mon interruption :
Alors qu'elle fonctionnait correctment sous MPLAB SIM, mon programme reste dans sa boucle principal avec l'ICD2.

J'ai déjà eu du mal à connecter l'ICD2 (dû au fait qu'il faille rajouter la ligne de programme #define ICD2_DEBUG et la ligne de commande -DICD2_DEBUG dans Project -> Build Options)

Ma méthode est :
Ma connection ICD2 ne pose maintenant plus de problème
Mon programme s'initialise correctement et je remets les registres adéquats au bon état (si MPLAB SIM accepte mes interruptions je pense que ca ne vient pas là).
Cependant lorsque je place PIR1 à 0x08 (interruption SSP), mon programme ne rentre pas en exécution.

J'ai cru comprendre quelque part que les interruptions en ICD2 ne passait pas avec un single-step, j'ai donc aussi essayé en Run mais rien n'y fait.

Ma question (enfin! ^^) est donc : Est ce que (une fois de plus) l'erreur peut venir de mon compilateur (CC5xfree) ?
Si un bout de mon code est nécessaire, n'hésitez pas à me le demander
-----

[invite1e8ad136]

Voici un bout du code :

#define ICD2_DEBUG
#pragma chip PIC16F818
#include<int16CXX.h>

void i2c_test(void);

#pragma origin 4

interrupt ssp_handler()
{
int_save_registers; //Save useful registers
i2c_test();
int_restore_registers; //Restore useful registers
}

void i2c_test()
{
SSPIF=0;
//Beaucoup de code ...
}

void init_pic()
{
OSCCON=0x60; //INTOSC 4 MHz
SSPADD=0x40; //Slave adress
SSPCON=0x36; //SSP ativated (SDA & SCL) & IIC slave mode (7 bits adress)
INTCON=0xC0; //Global Interruption & Peripheral Interruption enabled
PIE1=0x08; //SSP Interrupt enabled
ADCON1=0x06; //PORTA configured as digital port
TRISA=0x38; //RA0, RA1 & RA2 configured as inputs
SSPIF=0;
PORTA=0;
}

void main()
{
init_pic(); //PIC16F818 initialization
//Beaucoup de code ...
}

Si quelqu'un peut m'aider et me dire pourquoi l'interruption fonctionne en MPLAB SIM et pas en ICD2 ?
La mise à 0x08 de PIR1 ne m'envoie pas en interruption ..

Merci.

[invite1e8ad136]

Bon même si mon problème n'intéresse que moi , je place quand même son évolution.

Donc après moults tests, en fait je rentre bien en interruption, le problème serait plutôt qu'à chaque pas, l'ICD2 remet ses registres à 0.

Concrètement, je place 0x08 dans PIR1 (pour lancer l'interruption (et ça ça marche !!),0x29 dans SSPSTAT (pour indiquer une écriture I²C) et 0x30 dans SSPBUFF (qui correspond à un ordre spécifique dans mon programme), mais dès que je relance en mode Run (car ICD2 ne fait pas les interruptions en pas à pas... pratique ...), SSPSTAT se remet à 00 et SSPBUFF à FF.

Si quelqu'un a une idée ??

Cordialement !
Votre humble serviteur. ^^

[RISC]

Salut,

Jette un oeil aux liens suivants concernant l'I2C et les "PIC16".
Certains sont en assembleur mais tu pourras peut-être détecter une erreur dans ton initialisation...

* http://www.microchip.com/stellent/id...GE&nodeId=1411
* http://www.microchip.com/stellent/id...GE&nodeId=1469
* http://www.mikroe.com/en/download/ (voir projets avec E2PROM externe)
* http://www.piclist.com/techref/microchip/i2c.htm

a+

[A voir en vidéo sur Futura]

[invite1e8ad136]

Merci RISC !

Après avoir bien lu les liens, j'ai pu trouver qu'il manquait une ligne TRISB=0x12; pour définir SDA et SCL comme des entrées.

Donc c'est bon je rentre en interruption avec le sourire ^^.

Mais ... (et il y a un mais), j'ai un problème avec SSPOV qui me signale un overflow, à peine entré en interruption ...
Et SSPSTAT se met à 10 (il ne voit que le bit de STOP).

J'imagine donc un programme assez bourrin qui consisterait à mettre SSPOV à 0 au début de chaque interruption pour ne garder dans le buffer de réception que le dernier octet (soit la data à transférer) et en fonction de cet octet, deviner s'il s'agit d'une lecture ou d'une écriture ...

Quelqu'un saurait-il me dire si cela reste dans "l'art" de l'I2C ?

Amicalement vôtre