[satinas]

Bon là t'es le boss je m'éclipse. C'est le moment de faire les fameuses fonctions en amont et le reste. Si c'est industriel, mets de la gestion d'erreurs partout. Je vois pas pourquoi il y aurait des collisions s'il n'y a qu'un host.
A+

[Stefox]

Merciiiii !!

Il n'y a qu'un esclave pour le moment ^^ Le DS est une partie du projet, il va y avoir d'autres copain et d'autres copain en SPI ^^

Juste petite question de comphréension sur ce que l'on a fait. On a mis des break, si une fonction foire, on sort du while, mais c'est pas un souci ? Genre on a un souci dans la fonction on force à sortir avec le break au lieu de traiter l'erreur ? Je veux dire normalement je dois pas en faire quelque chose pour régler l'echec de la fonction ?

Tout à l'heure du parlais de SMP = 0, c'est quoi au juste l'histoire la dessus, mettre 0 va faire quoi ? Je vois dans la doc que c'est une question d'échantillonage mais... voila.. Visiblement Paul a dû le mettre a 0 que tu m'as dit

Et donc ici je garde les break, le while imbriqué, je vais regarder pour faire les collisions, je rajoute les idle. Tu vois un truc pour que ce soit davantage fiable dans le temps et robuste pour un truc qui ne doit surtout pas planter ? Ou tu penses qu'ici avec tout ça on est franchement pas mal ?

[satinas]

L'idle ne sert à rien. Il n' y a qu'un host, les slaves répondent quand on les adressent, donc pas de risque de collision. Je suis pas un grand spécialiste I2C.

Mon programme était fait pour mettre au point la communication I2C. Bien sûr qu'il faut traiter les erreurs, mais il ne devrait pas y en avoir. Disons que si cela se passe mal dans une transaction, tu envoies un message d'erreur et à part réitérer la transaction, je vois pas ce que tu peux faire d'autre.
De ce que j'ai vu du DS1307, quand il perd la boule il n'y a plus rien à faire.

Pour le bit SMP, demande à ChatGepetto, lui il sait tout
Ouille ChatGepetto existe déjà, encore une blague ratée.
=> "A quoi sert le bit SMP dans la configuration i2c du 18F46K22 ?"

C'est à toi de voir, si tu n'es pas assez à l'aise avec le C, tu vas galérer.
Dans tes fonctions, ce sera soit des break soit des if soit autre chose, la programmation c'est vaste, et chacun a ses habitudes.
My God mets mon programme à la cave, il n'a rien à voir avec ton code appli. Il a juste servi à valider la communication I2C.
Essaie de déchiffrer mon appli. Elle affiche date et heure sur un lcd textuel. Tu regardes comment cela se passe. Elle fait plein de choses, remplit une grosse eeprom I2C, affiche sur un oled I2C, et tout se passe bien. Quand l'I2C est au point, il n'y a aucune raison que cela passe mal, après il y a les aléas, interférences, parasites ...

[paulfjujo]

bonsoir,

j'ai essayé aussi d'utiliser l'I2C2 sur un 18F46K22 ... que je n'ai pas utilisé depuis longtemps, le 18F26K22 etant suffisant
pour piloter beaucouo de devices sur un meme port I2C1..
j'avais deja testé avec C18 ... ou MikroC ...beaucoup plus facile à manier que XC8
j'ai trouvé de l'aide sur le web , où les fonctions sont relativement simples , sans utiliser MCC ..

Resultat OK avec I2C1 (RC3 RC4) ou I2C2 ( RD0 RD1)
voila le pack ci joint..

18F46K22_I2C2_OLED_DS1307_2025.zip

je vais y rajouter un mini OLED SSD1306 .....

(18:40:37.493) Init UART1 115200bds
(18:40:37.493) 18F46K22 sur FOSC interne 64Mhz (XC8)
(18:40:37.543) Init I2C2 RD0=SCL1 RD1=SDA2
(18:40:37.543) InitSQW output 1Hz RTC
(18:40:37.543)
(18:40:37.543) Init RTC 27/07/2025 18H58
(18:40:37.543) sec > 00 min > 58 heu > 18 Js > 06 jou > 27 moi > 07 Ann > 25
(18:40:38.523) sec > 01 min > 58 heu > 18 Js > 06 jou > 27 moi > 07 Ann > 25
(18:40:39.579) sec > 02 min > 58 heu > 18 Js > 06 jou > 27 moi > 07 Ann > 25
(18:40:40.598) sec > 03 min > 58 heu > 18 Js > 06 jou > 27 moi > 07 Ann > 25

je n'ai pas synchronié avec le terminal...

[satinas]

Ah ah Paul écrit tous les registres dans une seule transaction I2C, comme quoi c'est possible
Par contre il ne teste aucun code retour, tu vois tout existe, mais lui il expérimente, donc pas grave.
Paul tu as bien un avis sur le bit SMP de la config I2C ?

Stefox, quand je te dis que cela n'a rien à voir avec mon programme, c'est faux bien sûr, cela fera la même chose mais ce seront des fonctions appli, alors que ce programme était un truc de test pour vérifier la qualité de la liaison I2C.

J'ai regardé une bibliothèque DS1307 Arduino, qui s'appuie sur la bibliothèque I2C Wire, d'après ce que je comprends dans Wire on remplit un buffer, d'abord l'adresse de l'esclave puis les data à envoyer, puis elle envoie le tout, et si un envoi n'est pas acquitté elle interrompt la transmission et fait un stop. Pour la lecture la fonction requestFrom(addr_chip, n) permet de lire n octets.

Wire retourne des codes erreur, la bibliothèque DS1307 ne les exploite pas. la fonction de mise à l'heure void RTC_DS1307::adjust(const DateTime& dt) devrait retourner un code indiquant si le DS1307 était présent et a bien reçu.

[paulfjujo]

Ah ah Paul écrit tous les registres dans une seule transaction I2C, comme quoi c'est possible
Par contre il ne teste aucun code retour, tu vois tout existe, mais lui il expérimente, donc pas grave.

Dans un 1er temps ,il vaut mieux verifier individuellement chaque device I2C ... et l' essayer SANS traitement d'erreur
car en fait , on fait quoi si il y a des erreurs ?
si on perd son temps à debloquer des situations inextricables .. probleme hard ou erreur de programmation ..


MikroC utilise un timer pour sortir de situation en erreur ...
mais encore faut-il la traiter correctement
le traitement des erreurs ne doit pas conduire à un gaspillage de temps MCU, suivant les contraintes de l'application
devant gerer d'autres devices (UART,SPI,...) et interruptions

XC8 avec le 18F27K42 gere aussi les erreurs via un timer

si le DS1307 genere des erreurs (I2C) ,on fait quoi, on signale une anomalie et on oublie la date et heure ?
et on est dans un cas simple ...on compte le nb d'erreur cummulées
dans un temps imparti ..

Mesure de courant moteur via INA226 .. erreur I2C ? => arret moteur
ou on oublie l'erreur et teste si la mesure suivante reste plausible et coherente
pour poursuivre l'acquisition INA.

le traitement complet des erreurs possibles peut mener à une programmation inextricable..

Je conçois quand meme aisément que le programme d'un Vehicule ..doit verifier TOUTES les erreurs..
ou avoir des situations de repli.

Paul tu as bien un avis sur le bit SMP de la config I2C ?

mis à 0, pour I2C 400Khz
en réalité SCL2 mesuré à 373Khz car usage de fosc interne et alim =3,3V

REGISTER 15-1: SSPxSTAT: SSPx STATUS REGISTER
In I2 C Master or Slave mode:
1 = Slew rate control disabled for standard speed mode (100 kHz and 1 MHz)
0 = Slew rate control enabled for high speed mode (400 kHz)

https://electronics.stackexchange.com/q ... te-for-i2c

I'm not sure what I should do with slew. I can choose from two options, defined in i2c.h:
SLEW_OFF: Slew rate disabled for 100 kHz mode
SLEW_ON: Slew rate enabled for 400 kHz mode
Slew rate is how fast the signal changes from low to high, or vice versa. By limiting this abrupt transition,
you can reduce ringing from signal reflections, and limit crosstalk between signal lines.
The way it works out, though, is that at 100kHz, the signal rates are so slow that the slew rate doesn't
really matter; at 400kHz you may be able to fix an otherwise problematic circuit by limiting it; but then
when you get to 1MHz you really need all the transition speed you can get, and so you just have to do good
signal matching and route your lines more carefully.

[gwion]

On pourrait imaginer de mettre les périphériques I2C sur une ligne d'alimentation spécifique commutée par le PIC. En cas d'erreurs successives on aurait la possibilité de faire un reset sélectif avec un OFF/ON de cette branche d'alim.

[satinas]

Merci Paul, je n'avais pas le courage d'essayer à nouveau de replancher sur le slew rate.

Ce qui m'a surpris c'est que le module DS1307 en carafe, même avec une mise hors tension, ne repartait pas, il fallait le débrancher.

Juste le fait de savoir qu'une transmission I2C s'est mal passé me semble important et cela ne ralentit en rien l'appli puisque les fonctions bas niveau retournent l'erreur. On peut mettre un simple compteur qui indique le nombre de transactions à problème. On le regarde tous les soirs avant de s'endormir pour passer une nuit tranquille. De toute façon il restera à 0 si la liaison I2C est correcte.

Sur Arduino avec Wire on a l'info adresse slave non acquittée ou data non acquittée. Pour une appli un peu sérieuse, un petit message "La mise à l'heure s'est mal terminée", cela coûterait pas grand chose de retourner un bool, et surtout il ne transmet pas en amont un code erreur. Mais bon c'est une bibliothèque Arduino, et peut-on mettre un DS1307 dans une appli industrielle ?

[Stefox]

Boujour tout le monde ! ^^

Beaucoup d'info très interessante et je vous lis avec beaucoup d'attention !

J'ai regardé un peu ton code, je n'avais jamais pensé à mettre un while a while(SSP2CON2bits.SEN == 1); (Comme tout les autres) Que cela va t-il apporter ? Ce sera j'imagine plus robuste mais si tu fais cela, c'est peut-être car cela ta posé souci par le passé sans le while ?

Il est vrai que je me suis fait aussi la remarque de "Et si j'ai pas le bon retour de ma com... Que vais-je faire ?" Hormis relancer, peut -être couper et reessayer, au bout de x fois avec echec peut-être juste couper et renvoyer une alerte à l'opérateur.. C'est vrai que je n'ai pas beaucoup de pouvoir la dessus. Si la com à décidé de foutre le camp.... voila hein Je verrai mais je pense en effet faire ce que je viens de dire pour la gestion d'erreur, je ne vois pas trop quoi faire d'autres non plus ^^

Qu'entends tu par "Il vaut mieux vérifier individuellement chaque device I2C ?" Voir s'il réponde avant de démarrer le vrai programme ? Si tout le monde répond correctement mettre un flag a 1 par exemple et si = 0 le main partiellement accessible ou autre, sinon gestion de l'erreur comme j'ai dit juste avant ?

J'aime beaucoup l'idée de Gwion, je vais garder cela bien précieusement en tête

Je compte bien entendu passer sur un DS3231, j'ai mis le DS1307 car ma carte est conçue comme cela mais c'est pas défintif ^^ Surtout que le DS3231 serait beaucoup plus stable en I2C et précis

Merci encore pour vos retour très intéressant, je suis toujours preneur d'informations, je vois d'autres manière de faire, d'autres réflexion, d'autres logique, c'est très enrichissant je trouve, surtout pour moi qui apprend beaucoup tout seul de base

[gwion]

Comme tu as une RTC tu peux envisager de faire un journal horodaté des erreurs à sauvegarder en eprom/SD pour avoir une idée de l'ampleur des dégâts. Ce journal pourrait être téléchargé/vidé via la liaison série. Et tu peux allumer une LED quand il y a quelque chose dedans. L'erreur peut être codée sur 1 caractère, ce qui laisse largement de quoi faire.