I2C durée entre STOP START ?

[cubitus_54]

Bonsoir,

Que dit le protocole I2C sur la durée entre la fin d'une trame (STOP) et le début d'une nouvelle (START) ?

Merci
-----

[DAUDET78]

Ben , tu lis la doc !

[cubitus_54]

Si tu ne connais pas la réponse, ne te sent pas obligé de donner une réponse comme celle-ci

[DAUDET78]

Si tu ne connais pas la réponse, ne te sent pas obligé de donner une réponse comme celle-ci

1/ je connais la réponse
2/ elle est dans la spécification du BUS I²C

Mais je n'ai plus aucune envie de t'aider !

[A voir en vidéo sur Futura]

[cubitus_54]

Merci Daudet,

Je me suis peut-être un peu emporté, mais ce type de réponse lapidaire m'a un peu heurté.

Question complémentaire,

dans un logiciel de programmation
La fonction STOP se termine par ceci :
delay_ms(10); //Wait before reusing the I2C BUS

Pourquoi 10 ms alors que 4 µs suffit...
Bug ou autre ?

[DAUDET78]

La doc : http://www.aurel32.net/elec/i2c.pdf Je suis pas rancunier !
Qui peut le plus, peut le moins . Et si on a tout le temps devant soi , pourquoi pas :
delay_ms(1000000); //Wait before reusing the I2C BUS

[cubitus_54]

J'avais aussi trouvé une doc...
http://www.nxp.com/documents/user_manual/UM10204.pdf

74 pages quand même...

J’ai laissé un message sur le forum du logiciel, on verra s'il y a (un jour) une réponse.

En attendant A+

[invite03481543]

Le bus doit rester libre au minimum 4.7µs en mode standard, donc comme dit Daudet pourquoi pas plus et donc pourquoi pas 10ms comme l'indique ton code, peut-être pour faire quelque chose d'autre durant ce temps.
@+

[Murayama]

Bonjour!

peut-être pour faire quelque chose d'autre durant ce temps.

En principe, les fonctions dans le genre delay_ms(xxx) sont juste consommatrices de cycles d'horloge.
Dans ce cas, si on n'est pas dans un environnement avec OS qui range les registres temporairement
pour passer à autre chose, on ne gagne rien à mettre des délais plus longs. Enfin on ne gagne
pas la possibilité de faire autre chose, en tout cas. Je mettrais tout simplement delay_us(5) pour ne pas
consommer plus que nécessaire.

En plus, il n'y a peut-être tout simplement pas besoin de délai du tout. En admettant que la fonction delai soit
à la fin d'une fonction read_i2c ou write_i2c, le temps de retourner au point d'appel et de réappeler une
autre fonction i2c, il doit se passer déjà pas mal de temps (du point de vue CPU), et suivant le processeur,
son horloge, etc, le temps d'appeler une nouvelle fois la condition start, il est fort possible que les
5µs soient déjà écoulées. À vérifier sur l'oscillo.

Pascal

[cubitus_54]

Salut,

Pour le moment, j'ai mis us à la place de ms en espérant que ce n'est qu'un affreux bug (soit 10µs)

Du coup ça fonctionne très bien

[invite03481543]

Bonjour!



En principe, les fonctions dans le genre delay_ms(xxx) sont juste consommatrices de cycles d'horloge.
Dans ce cas, si on n'est pas dans un environnement avec OS qui range les registres temporairement
pour passer à autre chose, on ne gagne rien à mettre des délais plus longs. Enfin on ne gagne
pas la possibilité de faire autre chose, en tout cas. Je mettrais tout simplement delay_us(5) pour ne pas
consommer plus que nécessaire.

En plus, il n'y a peut-être tout simplement pas besoin de délai du tout. En admettant que la fonction delai soit
à la fin d'une fonction read_i2c ou write_i2c, le temps de retourner au point d'appel et de réappeler une
autre fonction i2c, il doit se passer déjà pas mal de temps (du point de vue CPU), et suivant le processeur,
son horloge, etc, le temps d'appeler une nouvelle fois la condition start, il est fort possible que les
5µs soient déjà écoulées. À vérifier sur l'oscillo.

Pascal

Désolé mais je pense que tu n'as rien compris.
Rien n'oblige à redémarrer un start après un stop, donc la notion de délai à respecter est celle qui est minimum tout simplement dans le cas de communications permanente.
Et on utilise jamais de 'delay', tout doit se gérer en interruptions.
Je pense que tu n'as jamais utilisé l'I2C

[cubitus_54]

Rien n'oblige à redémarrer un start après un stop

.

En fait j'ai été embêté avec l'acquisition d'un gyroscope.
En séparant la lecture des registres avec un RESTART, je n'avais pas de délais, mais les données ne s’actualisaient pas.
Ce n'est qu'avec un STOP - START que les registres de données s'actualisaient. mais avec 10ms

avec ma petite modification, tout est OK

[Murayama]

Bonjour!

Ce n'est qu'avec un STOP - START que les registres de données s'actualisaient. mais avec 10ms

10 ms ou 10 µs? Dans le dernier message, ça avait l'air de fonctionner avec 10 µs.

Pascal

[cubitus_54]

Oui je me suis mal exprimé désolé,

En fait dans la chronologie,
STOP START fonctionnait avec le handicape d'avoir 10ms entre deux lectures.
Il n'y avait pas d'actualisation en remplacant STOP SART par un RESTART

avec la modification de la fonction à 10µs ça fonctionne avec START STOP normalement et très bien

[invite03481543]

Il faut regarder dans la doc de ton composant le temps min à respecter pour une condition de restart pour pouvoir accéder à un registre.
C'est peut être différent que le timing de stop/start classique demandé initialement qui doit permettre à un autre périphérique de se présenter sur le bus.
Le temps de RESTART peut varier selon si c'est une EEPROM, une RTC ou un expanseur d'I/O par exemple.

[cubitus_54]

Le composant c'est un MPU 6050

Il y a 14 registres 2*8 bits par axe (XYZ) en gyro et en accéléromètre + 2 pour la température.
Il me semble avoir vu dans la doc que le composant n’actualisait pas les registres durant une lecture pour éviter de fausser les mesures d'où l'obligation d'un STOP

Après je n'ai pas été creusé plus, car le composant est quand même assez complexe.

[HAYAC]

Bonjour à tous,

Sans vouloir relancer des polémiques, la programmation c'est comme l’électronique et tous les domaines, il y à des règles strictes.
Si dans une routine de communication une temporisation minimum est donnée ce n'est pas pour rien.

Pour en prendre conscience, une bonne méthode est de faire du développement collaboratif.
Dans ce mode de développement, chacun développe la partie de sont champs de maitrise et lors de la mise en commun, toute partie mal développé pose de gros problème.

Tout ceci pour dire :
- Soigner la structure d’écriture (Ordre, Commentaires ...).
- Soigner les déclarations (Limiter l'usage de déclaration en Public...).
- Respecter les normalisations (Délais ...).
Bref écrire du code proprement afin de pouvoir réutiliser celui-ci sans perdre du temps et de ce fait en gagner.

Cordialement,