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 ---
Problème de séquence I2C entre deux PIC
Problème de séquence I2C entre deux PIC
Problème de séquence I2C entre deux PIC
Problème de séquence I2C entre deux PIC
Petite info de suite....
J'ai bien avancé sur la compréhension du mode "Ecriture", mais pourtant, ça ne fonctionne pas si on force un peu la cadence.
Bien que les registres soient bien contrôlés pour envoyer les séquences d'écriture du maître, ((SSPCON2<<3)+SSPSTAT.2=0)
L'esclave, lui, fait un "OVERFLOW" SSPCON1.6 systématique dès qu'on lui envoie un rythme supérieur à "La SECONDE"
Un siècle quoi !
Pourtant le maitre surveille bien le bus libre avant d'écrire, et l'esclave ne peut pas faire plus court entre deux octets dans l'interruption
ça fonctionne si je temporise le Maaître entre les deux séquences d'une seconde.
En dessous, "OVERFLOW"
Cette erreur SSPCON1.6 est incompréhensible.
Le buffer SSPBUF est vide et pourtant !!!
Je ne trouve pas pourquoi.
J'ai bien avancé sur la compréhension du mode "Ecriture", mais pourtant, ça ne fonctionne pas si on force un peu la cadence.
Bien que les registres soient bien contrôlés pour envoyer les séquences d'écriture du maître, ((SSPCON2<<3)+SSPSTAT.2=0)
L'esclave, lui, fait un "OVERFLOW" SSPCON1.6 systématique dès qu'on lui envoie un rythme supérieur à "La SECONDE"
Un siècle quoi !
Pourtant le maitre surveille bien le bus libre avant d'écrire, et l'esclave ne peut pas faire plus court entre deux octets dans l'interruption
ça fonctionne si je temporise le Maaître entre les deux séquences d'une seconde.
En dessous, "OVERFLOW"
Cette erreur SSPCON1.6 est incompréhensible.
Le buffer SSPBUF est vide et pourtant !!!
Code : Tout sélectionner
if PIR1.3 and not SSPSTAT.5 then
adresse=SSPBUF
do
if SSPSTAT.0 then cde=SSPBUF : exit
loop
do
if SSPSTAT.0 then octet1=SSPBUF : exit
loop
do
if SSPSTAT.0 then octet2=SSPBUF : exit
loop
PIR1.3=0
endif
Je ne trouve pas pourquoi.
Problème de séquence I2C entre deux PIC
Problème de séquence I2C entre deux PIC
satinas a écrit :Bonjour,
valeur de FOSC ?
vitesse I2C ?
En admettant que FOSC = 4MHz et Fscl = 100kHz, scénario possible :
Le pic exécute 10 instructions durant 1 période SCL.
En fin de réception des 8 bits du dernier octet data, tu fais très vite PIR1.3=0, donc durant le 9ème bit.
A la fin du 9ème bit PIR1.3 repasse à 1, voir datasheet.
Comme PIR1.3 est à 1, l'interruption se relance aussitôt avec SSPSTAT.5 à 1, donc PIR1.3 reste à 1, et l'interruption se relance en permanence, alors qu'il n'y a aucune réception en cours.
Problème de séquence I2C entre deux PIC
Problème de séquence I2C entre deux PIC
Bonsoir.
J'avance un peu dans mes essais, et mon problème devient celui-ci:
Que je mette de 5 à 24 dans SSPADD du maitre, ne change rien ! ça fonctionne toujours.
Mais j'ai un échange i2c qui n'est pas synchrone sans raison apparente.
J'envoie une séquence i2c de 6 cycles d'horloge de 9 bits comme celle-ci qui dure 1,5ms au total (y compris le temps de traitement de l'esclave)
bus libre
start
"Adresse" (ecriture)
ack
"Code à traiter"
ack
"Octet1"
ack
"Octet2"
ack
re-start
"adresse" (Lecture)
ack
"code à recevoir"
No-Ack
stop
ça, ça fonctionne bien ! de 5 à 24 dans SSPADD du Maitre (j'ai pas testé plus loin)
l'esclave reçoit son adresse, et met PIR1.3 à 1
mon interruption (une seule !) traite les 5 octets reçus, et bloque CKP à 0 pour traiter les données.
Jusque là, tout va bien !
Mais mon incompréhension vient de ce que les cycles du maître (qui ne fait que ça) ne sont pas réguliers.
Toutes les 1/2 secondes, il envoie une séquence pour changer l'état d'une led sur l'esclave.
Et je reçois 5 séquences dans le timing prévu, puis la sixième séquence est décalée d'une demie seconde !!! (quelque soit la valeur mise dans SSPADD)
Voilà ce qui ne marche pas, et le "Maitre" ne fait que ça !
en fait il loupe la sixième séquence( Il attend) sans raison apparente et l'envoie à la septième
J'avance un peu dans mes essais, et mon problème devient celui-ci:
Que je mette de 5 à 24 dans SSPADD du maitre, ne change rien ! ça fonctionne toujours.
Mais j'ai un échange i2c qui n'est pas synchrone sans raison apparente.
J'envoie une séquence i2c de 6 cycles d'horloge de 9 bits comme celle-ci qui dure 1,5ms au total (y compris le temps de traitement de l'esclave)
bus libre
start
"Adresse" (ecriture)
ack
"Code à traiter"
ack
"Octet1"
ack
"Octet2"
ack
re-start
"adresse" (Lecture)
ack
"code à recevoir"
No-Ack
stop
ça, ça fonctionne bien ! de 5 à 24 dans SSPADD du Maitre (j'ai pas testé plus loin)
l'esclave reçoit son adresse, et met PIR1.3 à 1
mon interruption (une seule !) traite les 5 octets reçus, et bloque CKP à 0 pour traiter les données.
Jusque là, tout va bien !
Mais mon incompréhension vient de ce que les cycles du maître (qui ne fait que ça) ne sont pas réguliers.
Toutes les 1/2 secondes, il envoie une séquence pour changer l'état d'une led sur l'esclave.
Et je reçois 5 séquences dans le timing prévu, puis la sixième séquence est décalée d'une demie seconde !!! (quelque soit la valeur mise dans SSPADD)
Voilà ce qui ne marche pas, et le "Maitre" ne fait que ça !
en fait il loupe la sixième séquence( Il attend) sans raison apparente et l'envoie à la septième
Problème de séquence I2C entre deux PIC
Problème de séquence I2C entre deux PIC
Bonjour à tous,
Bonjour Satinas.
Si je ne bloque pas CKP pendant le traitement, je provoque un "Owerflow" SSPCON1.6=1 dès que j'envoie des séquences un peu plus soutenues...
(ce n'est pas le cas pour juste la led qui clignotte....
Mais sans bloquer CKP, c'est aussi et toujours pareil, la led clignotte synchro sur les 5 premiers changement d'état, et le sixième est décalé au temps de la 7 ème séquence.
Bonjour Satinas.
Si je ne bloque pas CKP pendant le traitement, je provoque un "Owerflow" SSPCON1.6=1 dès que j'envoie des séquences un peu plus soutenues...
(ce n'est pas le cas pour juste la led qui clignotte....
Mais sans bloquer CKP, c'est aussi et toujours pareil, la led clignotte synchro sur les 5 premiers changement d'état, et le sixième est décalé au temps de la 7 ème séquence.
Code : Tout sélectionner
disable
Int:
if PIR1.3 then
if not SSPSTAT.5 and not SSPSTAT.2 then ' si adresse et mode ecriture'
adresse=SSPBUF
do
if SSPSTAT.0 then cde=SSPBUF : exit
loop
do
if SSPSTAT.0 then octet1=SSPBUF : exit
loop
do
if SSPSTAT.0 then octet2=SSPBUF : exit
loop
do
if SSPSTAT.0 and not SSPSTAT.5 and SSPSTAT.2 then adresse=SSPBUF : exit
loop
SSPBUF=cde
'SSPCON1.4=0 ( CKP il est à "0" "de fait" après l''envoie de confirmation, il est ici en observation. Il est remis à 1 dans le Programme en fin de traitement)'
else
poubelle=SSPBUF
endif
PIR1.3=0
endif
resume
enable
End
Retourner vers « Le forum Fantas-PIC »
Qui est en ligne
Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 26 invités