Interruption et I2C

[Gérard]

Bonjour à tous,

Le contexte :
- un PIC (ça coule de source)
- une interruption TMR2 pour générer un signal PWM
- une liaison I2C : RTC, EEPROM, MCP23016 ...

Question :
Que se passe-t-il quand l'interruption va interrompre un échange I2C?

Merci d'avance pour toutes vos expériences.

[Claudius]

Bonsoir,

Et bien je dirais, aucune conséquence particulière si ce n'est l'état figé des 2 lignes SCL et SDA durant la durée de ladite interruption qui doit, par principe, ne durer qu'un très court instant...

[paulfjujo]

bonjour,

Bonsoir,
Et bien je dirais, aucune conséquence particulière si ce n'est l'état figé des 2 lignes SCL et SDA durant la durée de ladite interruption qui doit, par principe, ne durer qu'un très court instant...

je ne pense pas que le Timer2 utilisé par le PWM genere une interruption ...
il doit etre utilisé seulement au niveau hardware pour le reglage du " duty_cycle"
sauf peut etre si TMR2IE_bit est armé (et avec GIE_bit=1),
dans le bloc diagramme du module PWM , on ne voit aucun lien (tel que TMR2IF) vers la logique d'interruptions.

à verifier ..
en mettant un TXREG='*' dans l'entree du vecteur de traitement des IT ?

Le PMW est relativement autonome ... meme une IT RX UART ne devrait pas le perturber
sinon je ne vois pas comment on pourrait piloter des moteurs ..

Par contre au niveau I2C .. si c'est de I2C Hardware
une bonne partie de l'echange est autonome .. en hardware
il n'y a donc que les phases intermediaires entre l'envoi du Start et de Data ou attente d'un ACK
ou il pourrait y avoir une durée de traitement intempestif
ex: du au traitement d'une Reception UART par exemple qui serait à 115200 bds !

avec un FOSC à 64MHz , on peut faire pas mal de chose ..par rapport à la durée d' un bit I2C
Cycle=0.0625µS => 40 instructions @ 400Khz , ou 160 à 100Khz )

En I2C Software ou bit bang .. là, à mon avis, c'est problematique,
ou alors on cale le timming justement avec une interruption Timer2 et machine d'etat ?.

L'autre methode serait d'utilier les interruptions liées à l' I2C Hardware et de les mettre en prioritaire .
le protocole I2C n'est pas non plus tres rapide 400KHz (sauf mode High speed 1,7Mhz)

Les nouveaux MCU ont toute une panoplie pour gerer les cas difficiles .
et un jeu d'interruptions specifiques à l'I2C , grace au rajout de bits d'interruption
( sur le Start, sur le ACK ..etc ..) voir 18F27Q10 .. destiné à remplacer le bon vieux 18F26K22
voir MPLABX IDE XC8 et ressources associées à l'I2C

----------------------------

par rapport à ce genre de probleme ( puissance de traitement et interference)
j'ai pris la solution d'utiliser 2 MCU 18F26K22
1 MCU esclave , pour gerer une horloge (version 2020) avec 6 afficheurs 7 segm multiplexés à 40Hz + 1 ruban 60 leds RGB (SPI bit bang)
et 1 autre MCU , en Maitre ,pour gerer 12 affciheurs matrices8x8 en mode defilant (SPI ) + RTC (I2C) + UART + 2x OWS DS18B20
liaison UART maitre-esclave pour retransmettre l'heure , reception UART pour MAJ RTC et envoi de messages
Faire le tout avec un seul PIC ,en DIP40 me parait trop capilotracté.. pour imbriquer et gerer tous les timings.
Qu'en pensez-vous ?

[Gérard]

Bonjour à tous,

Je vais me replonger dans la doc. Je compte utiliser l'interface hard pour l'I2C.
Claudius : tu dis que l'interruption TMR2 ne devrait pas gêner l'I2C?
Paul : TMR2 peut fonctionner sans interruption?

[paulfjujo]

Paul : TMR2 peut fonctionner sans interruption?

le TMR2 , quand il est utilisé pour une sortie PWM, ne genere pas d'interruption

d'une façon generale, un timer peut etre utilisé avec ou sans interruption ...
mode pooling .. on surveille le TMRxIF bit
mode interrupt on autorise l'IT TMRxIE _bit
et on traite l'interruption generée par le TMRXIF bit..
si GIE=1

[Claudius]

Bonsoir,

Gérard a écrit:
...
Claudius : tu dis que l'interruption TMR2 ne devrait pas gêner l'I2C?

Je confirme avec le projet sur pic16f628a interfaçant le coprocesseur flottant - uM-FPU V3.1 dont le code assembleur est téléchargeable ici: uM-FPU-V3.1 et qui utilise en autre et sans problème :

- l'interruption T0IF (timer TMR0) pour un cadencement toutes les 1 mS
- l'interruption RCIF pour la réception en UART de 1200 à 19200 bauds
- l'interruption TXIF pour la transmission en UART de 1200 à 19200 bauds
- une gestion 100% logicielle de l'I2C qui est donc le plus mauvais cas d'utilisation de cette interface qui est interrompue sans problème puisque le protocole s'appuie sur l'acquisition / transmission de données SDA synchrone de l'horloge SCL (lire et relire l’excellente présentation: Le bus I²C ;-)

NB1: L'i2C est dans ce projet utilisée pour interfacer:
- le coprocesseur flottant uM-FPU V3.1
- une eeprom AT24C256 (en cours de développement sur pic16f648a car le pic16f628a est plein ;-)
- un afficheur 4-digit 7-segment (en cours de développement sur pic16f648a car le pic16f628a est plein ;-)

NB2: L'utilisation d'un si "petit" PIC est un exercice de style dont je raffole...

[Gérard]

...

le TMR2 , quand il est utilisé pour une sortie PWM, ne genere pas d'interruption

d'une façon generale, un timer peut etre utilisé avec ou sans interruption ...
mode pooling .. on surveille le TMRxIF bit
mode interrupt on autorise l'IT TMRxIE _bit
et on traite l'interruption generée par le TMRXIF bit..
si GIE=1

Je comprends bien que l'interruption n'est générée que si les bit prévus sont placés. En pooling, il faut tout le temps surveiller le bit xxIF. N'est ce pas gênant pour du PWM?

[Gérard]

Claudius, je vais jeter un oeil à ton programme asm mais ce n'est pas gagné pour moi.

[Temps-x]

Bonsoir tout le forum,

Source du message j'ai pris la solution d'utiliser 2 MCU 18F26K22

Source du message 1 MCU esclave , pour gerer une horloge (version 2020) avec 6 afficheurs 7 segm multiplexés à 40Hz + 1 ruban 60 leds RGB (SPI bit bang)

Ok

Source du message et 1 autre MCU , en Maitre ,pour gerer 12 affciheurs matrices8x8 en mode defilant (SPI ) + RTC (I2C) + UART + 2x OWS DS18B20 liaison UART maitre-esclave pour retransmettre l'heure , reception UART pour MAJ RTC et envoi de messages

OK

Source du message Qu'en pensez-vous ?

Vu la vitesse ou tourne ton microcontrôleur(64Mhz) tu peux sans aucun problème lui faire tout faire, il faut juste les faire dans un bon ordre.

Source du message Claudius, je vais jeter un oeil à ton programme asm

Gérard... j'ai regardé le code de Claudius, ca te fait 4489 lignes d'assembleurs à lire (une banalité pour toi)

A+

[paulfjujo]

Je comprends bien que l'interruption n'est générée que si les bit prévus sont placés. En pooling, il faut tout le temps surveiller le bit xxIF. N'est ce pas gênant pour du PWM?

par contre je ne comprends pas bien tes besoins ( pas ceux naturels !) et ou tu veux en venir

L'association TMR2 et PWM est NATURELLE, et interne en HARDWARE .
on met dans PR2 la valeur du Duty cycle PWM ..et ça roule tout seul ..
pas besoin de gerer un flag ou interrupt

par contre si par ailleur tu as besoin d'un timer, prend en un autre (TMR4,TMR6) qui sont en 8 bits Auto-Relaod
ou un 16 bits ; Timer1,3, 5 qui ont un bit de start (TMR1ON_bit par exemple)
et utilise les interrupts pour faire des tempos ou autre traitement

car utiliser Timer2 ,déja pris par le PWM => Problemo

un timer utilisé en mode pooling , bloque quelque part le programme, puisqu'il faut surveiller le flag TMRxIF
mais il peut etre utilisé comme TimeOut ..pour ne pas rester bloqué dans une boucle sans fin , si il manque
une autre condition.