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 : Gérard
Communication entre deux PICs en I²C
Bonjour.
Et bien, je viens de tester sans les PIC les circuits "C3" et "C4" des lignes SCL et SDA, et finalement, cela ne vient pas des circuits.
Les 2 lignes aboutissent bien en 5V Niveau d'attente Haut.
Si je force au 0V l'une d'entre elles, l'autre passe bien à 0V, et cela sur les 4 possibilités.
Donc j'en déduit de façon sûr que cela ne vient pas du circuit.
J'ai remplacé les 2 PIC 18F2520 par acquis de conscience, et c'est toujours pareil !
C'est donc bien un problème soft.
Sachant que si je ne raccorde pas les deux pic ensemble, la séquence "Start"+"Adresse" s'exécute correctement, alors que si je les connecte, je n'ai plus que le "Start" qui s'exécute. et laisse SCL niveau bas.
C'est cornélien.... je ne trouve pas.
Et bien, je viens de tester sans les PIC les circuits "C3" et "C4" des lignes SCL et SDA, et finalement, cela ne vient pas des circuits.
Les 2 lignes aboutissent bien en 5V Niveau d'attente Haut.
Si je force au 0V l'une d'entre elles, l'autre passe bien à 0V, et cela sur les 4 possibilités.
Donc j'en déduit de façon sûr que cela ne vient pas du circuit.
J'ai remplacé les 2 PIC 18F2520 par acquis de conscience, et c'est toujours pareil !
C'est donc bien un problème soft.
Sachant que si je ne raccorde pas les deux pic ensemble, la séquence "Start"+"Adresse" s'exécute correctement, alors que si je les connecte, je n'ai plus que le "Start" qui s'exécute. et laisse SCL niveau bas.
C'est cornélien.... je ne trouve pas.
Communication entre deux PICs en I²C
Re..
Je pense que c'est le PIC esclave qui , dès qu'il reçois une condition "Start", prend la main sur SCL et la garde basse.
Sans aucune ligne de code, le MSSP réagit comme ça !
Et comme il garde la main sur SCL, le PIC maitre ne peut pas envoyer l'adresse.
Il me semble donc que ce soit de la config ?...
Mais laquelle ? car tout semble en ordre sur SSPSTAT, SSPCON1 et SSPCON2.
Je pense que c'est le PIC esclave qui , dès qu'il reçois une condition "Start", prend la main sur SCL et la garde basse.
Sans aucune ligne de code, le MSSP réagit comme ça !
Et comme il garde la main sur SCL, le PIC maitre ne peut pas envoyer l'adresse.
Il me semble donc que ce soit de la config ?...
Mais laquelle ? car tout semble en ordre sur SSPSTAT, SSPCON1 et SSPCON2.
Code : Tout sélectionner
SSPADD = $40 ' si Esclave, contient l'adresse de l'esclave
SSPSTAT.7 = 1 ' SMP: Controle de la vitesse du bus: 1=vitesse standard 100 Khz 0=vitesse haute 400 Khz
SSPSTAT.6 = 0 ' CKE: SMBus Select 1=enable SMBus 0=desable SMBus
SSPSTAT.5 = 0 ' D/A: Data/Address en mode Maitre: (réservé). en esclave: 1=dernier byte reçu ou transmis=DATA si non 0= Adresse
SSPSTAT.4 = 0 ' P: Stop bit si=1 StopBit à été détecté si=0 n'as pas été détecté
SSPSTAT.3 = 0 ' S: Start bit(1) si=1 StartBit à été détecté si=0 n'as pas été détecté
SSPSTAT.2 = 0 ' R/W: Read/Write Information bit (I2C mode only) en mode Esclave 1=Read 0=Write en mode Maitre 1= Transmission en cours 0= pas de transmission en cours
SSPSTAT.1 = 0 ' UA: Update Address bit (10-Bit Slave mode only) 1=Indique que l'utilisateur doit mettre à jour l'adresse dans le registre de SSPADD
' 0=L'adresse ne doit pas être mise à jour
SSPSTAT.0 = 0 ' BF si BF=0: Buffer Full Status bit en mode Transmission 1= SSPBUF est plein 0=Vide
'en mode Réception 1= SSPBUF est plein (sans inclure l'ACK et le StB) 0=vide
'Config I2c
SSPCON1.7 = 0 'WCOL Maitre: 1= Ecriture dans SSPBUF en transmission non valide (erreur) effacer le bit par soft
' Esclave: 1= le registre SSPBUF est écrit en transmission non finie (erreur) effacer le bit par soft
SSPCON1.6 = 0 'SSPOV Réception: 1= SSPBUF contient toujours un octet tandis qu'il en reçois un autre. (erreur) effacer le bit par soft
' Transmission: 1= Sans importance.
SSPCON1.5 = 1 'SSPEN 1= I2c Enable et configure les pins SDA et SCL
SSPCON1.4 = 0 'CKP Esclave: 1= Horloge de sortie 0= temps bas utilisé pour monter les données
' Maitre: 1= Non utilisé
SSPCON1.3 = 1 'SSPM 1111 = I2C Slave mode, 10-bit address with Start and Stop bit interrupts enabled
SSPCON1.2 = 1 '1110 = I2C Slave mode, 7-bit address with Start and Stop bit interrupts enabled
SSPCON1.1 = 1 '1011 = I2C Firmware Controlled Master mode (Esclave Inocupé)
SSPCON1.0 = 0 '1000 = I2C Master mode, clock = FOSC/(4 * (SSPADD + 1))
'0111 = I2C Slave mode, 10-bit address
'0110 = I2C Slave mode, 7-bit address
'Bit combinations not specifically listed here are either reserved or implemented in SPI mode only.
'Gestion I2c
SSPCON2.7 = 1 'GCEN en mode Esclave seulement si =1 Enable Interruption si appel général à l'adresse(0000h) réception dans le SSPSR si=0 Desable l'appel générale
SSPCON2.6 = 0 'ACKSTAT Transmission Maitre seulement 1= pas d'acknowledge reçu de l'esclave 0= acknowledge reçu
SSPCON2.5 = 0 'ACKDT En Réception Maitre seulement 1= Pas d'acknowledge 0= acknowledge
SSPCON2.4 = 0 'ACKEN En Réception Maitre seulement 1= acknowledge sur SDA et SCL et transmission ACKDT Automatiquement (clear Hardwaire) 0= bus inocupé
SSPCON2.3 = 0 'RCEN Mode Maitre seulement 1= Enable mode réception I2c
SSPCON2.2 = 0 'PEN Mode Maitre seulement 1= Condition STOP sur SDA et SCL 0= libre (clear hardwaire)
SSPCON2.1 = 0 'RSEN Mode Maitre seulement 1= Condition Repeated START sur SDA et SCL 0= libre (clear hardwaire)
SSPCON2.0 = 0 'SEN Maitre: 1= Condition START sur SDA et SCL Esclave: 1= maintient l'horloge tant que l'esclave transmet
Communication entre deux PICs en I²C
Communication entre deux PICs en I²C
Bonjour.
Pour éliminer un maximum de pannes possibles dues aux éléments additionnels du réseau SCL/SDA, j'ai connecté directement les sorties des pic avec résistances sur le +5V sans autre connexion.
SCL-SCL
SDA-SDA
J'obtient exactement le même phénomène.
START Ok ! et l'Esclave garde SCL niveau bas. Le maître n'envoie pas l'Adresse.
Pour éliminer un maximum de pannes possibles dues aux éléments additionnels du réseau SCL/SDA, j'ai connecté directement les sorties des pic avec résistances sur le +5V sans autre connexion.
SCL-SCL
SDA-SDA
J'obtient exactement le même phénomène.
START Ok ! et l'Esclave garde SCL niveau bas. Le maître n'envoie pas l'Adresse.
Communication entre deux PICs en I²C
Communication entre deux PICs en I²C
Bonjour,
qu'est-ce que tu ne comprends pas dans le programme du post 44 d'il y a 2 pages ?
Il marche chez moi avec 2 18F, envoi et réceptions de données.
Je te conseille de faire tes premiers essais avec une connexion de 10 cm entre les 2 pics, et 4 résistance pull-up. Quand ce sera au point, tu pourras passer à la liaison longue distante.
Mettre les 2 variables i et read en globales, pas dans le main, et dans le commentaire final, c'est pas clock checking mais clock stretching.
qu'est-ce que tu ne comprends pas dans le programme du post 44 d'il y a 2 pages ?
Il marche chez moi avec 2 18F, envoi et réceptions de données.
Je te conseille de faire tes premiers essais avec une connexion de 10 cm entre les 2 pics, et 4 résistance pull-up. Quand ce sera au point, tu pourras passer à la liaison longue distante.
Mettre les 2 variables i et read en globales, pas dans le main, et dans le commentaire final, c'est pas clock checking mais clock stretching.
Communication entre deux PICs en I²C
Bonjour Satinas.
Ce que je ne comprend pas, c'est que l'adresse du Slave ne soit pas envoyée derrière le Start du Master si je déclare mon Slave avec SSPEN=1
Dès que mon slave est en I2C avec toutes les configues possibles il bloque l'envoie de l'adresse du Maitre. Je reçois que le Start.
Par contre, si je remet les IO du Slave en entrées, le maitre envoie tout comme il faut.
On dirait que la configue du Slave n'est pas en "Drain Ouvert" quand SSPEN=1
J'ai actuellement remis une connexion de 10 Cm comme je l'expliquais précédemment.
je ne suis pas en connexion longue.
Et comme je le disais au départ, je n'utilise pas les fonctions I2cWrite ou autres des fonctions basique.
Mon but étant d'utiliser le MSSP uniquement dans sa version Hard sur les ports dédiés C3-C4
Ce que je ne comprend pas, c'est que l'adresse du Slave ne soit pas envoyée derrière le Start du Master si je déclare mon Slave avec SSPEN=1
Dès que mon slave est en I2C avec toutes les configues possibles il bloque l'envoie de l'adresse du Maitre. Je reçois que le Start.
Par contre, si je remet les IO du Slave en entrées, le maitre envoie tout comme il faut.
On dirait que la configue du Slave n'est pas en "Drain Ouvert" quand SSPEN=1
J'ai actuellement remis une connexion de 10 Cm comme je l'expliquais précédemment.
je ne suis pas en connexion longue.
Et comme je le disais au départ, je n'utilise pas les fonctions I2cWrite ou autres des fonctions basique.
Mon but étant d'utiliser le MSSP uniquement dans sa version Hard sur les ports dédiés C3-C4
Communication entre deux PICs en I²C
Moi aussi, j'ai eu ce problème de slave qui met à 0 les 2 lignes SCL et SDA, mème si le clock stretching n'est pas activé. C'est en analysant au debugger les flags dans SSPSTAT en début d'interruption, que je m'en suis sorti. C'est difficile de mettre au point ce truc en cogitant, il n'y a que l'expérimentation qui marche.
Communication entre deux PICs en I²C
En fait, ce que je ne sais pas, c'est si on peut faire fonctionner le MSSP uniquement à partir de ses registres, ou si on est obligé d'utiliser les fonctions i2cRead et i2cWrite.
Je croyais que ces fonctions étaient destinées à "émuler" n'importe quelle Pine du Pic pour un I2C plus soft que hard, et qu'on peut les utiliser sur la famille 16F qui n'est pas pourvue de module MSSP
Je croyais que ces fonctions étaient destinées à "émuler" n'importe quelle Pine du Pic pour un I2C plus soft que hard, et qu'on peut les utiliser sur la famille 16F qui n'est pas pourvue de module MSSP
Communication entre deux PICs en I²C
Quelle que soit la façon dont tu programmes le MSSP : asm, c, basic, ... cela se termine en lecture et écriture de registres. J'ai mis un pseudo-code pour s'affranchir du langage.
Ne connaissant pas les bibliothèques I2C, je ne sais pas si elles s'adaptent aux pics, pour faire de l'i2c soft ou hard.
Commence par envoyer un seul octet. Et désactive l'int sur start/stop, simplifier, toujours simplifier ...
le master envoie -> start, $40, data, stop
le slave reçoit avec ça ->
Ne connaissant pas les bibliothèques I2C, je ne sais pas si elles s'adaptent aux pics, pour faire de l'i2c soft ou hard.
Commence par envoyer un seul octet. Et désactive l'int sur start/stop, simplifier, toujours simplifier ...
le master envoie -> start, $40, data, stop
le slave reçoit avec ça ->
Code : Tout sélectionner
interrupt i2c (si PIR1.SSPIF = 1)
PIR1.SSPIF = 0
if SSPSTAT.BF = 1
data = SSPBUF
endif
SSPCON1.CKP = 1
Retourner vers « Langage BASIC & PASCAL »
Qui est en ligne
Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 1 invité