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 : Jérémy
Fonctions I2C
Salut Satinas !
J'ai essayé le code que tu m'as passé au post 65. Il m'affiche "1:7 45". Donc en effet, comme tu me disais, pour lire le chiffre que je lui écrit, il faut bien repointer sur le registre en question car il s'est incrémenter suite à l'écriture, je le vois désormais ^^ J'ai essayé avec d'autres chiffres et en effet, il est juste maintenant :)
J'imagine que ce genre d'élément (Pointeur qui s'incrémente seul après écriture) est un élément que l'on peut retrouver dans une doc ? Vu que, si j'ai bien compris, ce n'est pas le cas avec l'eeprom que tu as, ce n'est donc pas systématique l'incrémentation
Ce que je ne saisi pas de trop par contre, c'est qu'une fois que la led s'allume et que j'ai "1:7 45", le LCD et la led s'éteint jusqu'a ce que je coupe et remette l'alim.
J'ai ensuite commencé à enlever les breaks un par un pour voir. Si je l'enlève de WriteAddr, c'est ok, j'ai toujours 1:7 45 (puis tout s'éteint) j'ai donc laissé cette fonction sans le break.
Dès que je l'enlève du WriteData(0x00), j'obtiens 1: 7 0 (puis tout s'éteint). J'ai donc remis le break
Dès que je l'enlève du WriteData(second), je récupère 1:7 45 (puis tout s'éteint) j'ai donc laissé cette fonction sans le break.
De même avec WriteAddr du second bloc
Si j'enlève le break du WriteData du second bloc, forcèment, il rate aussi mais je recupère 1:7 165, le lcd ne s'éteint plus et la led clignote, le 1 s'incrémente sur le LCD. J'ai remis le break sur cette fonction puisque j'ai perdu mon 45, j'ai eu 165 à la place
Si j'enlève le break de ReadAddr, j'obtiens 1 6 45 puis tout s'éteint. J'ai donc remis le break
Si j'enlève le tout dernier, je n'ai rien du tout, ça normalement c'est normal car du coup je ne sors jamais du while imbriquer tout simplement, le dernier break servant à en sortir
De fait, pour essayer, si j'enlève le while imbriquer, je recupère mon 1 7 45 ^^
Au final, en ayant enlever les break que je pouvais, le code ressemble à ceci :
J'ai essayé le code que tu m'as passé au post 65. Il m'affiche "1:7 45". Donc en effet, comme tu me disais, pour lire le chiffre que je lui écrit, il faut bien repointer sur le registre en question car il s'est incrémenter suite à l'écriture, je le vois désormais ^^ J'ai essayé avec d'autres chiffres et en effet, il est juste maintenant :)
J'imagine que ce genre d'élément (Pointeur qui s'incrémente seul après écriture) est un élément que l'on peut retrouver dans une doc ? Vu que, si j'ai bien compris, ce n'est pas le cas avec l'eeprom que tu as, ce n'est donc pas systématique l'incrémentation
Ce que je ne saisi pas de trop par contre, c'est qu'une fois que la led s'allume et que j'ai "1:7 45", le LCD et la led s'éteint jusqu'a ce que je coupe et remette l'alim.
J'ai ensuite commencé à enlever les breaks un par un pour voir. Si je l'enlève de WriteAddr, c'est ok, j'ai toujours 1:7 45 (puis tout s'éteint) j'ai donc laissé cette fonction sans le break.
Dès que je l'enlève du WriteData(0x00), j'obtiens 1: 7 0 (puis tout s'éteint). J'ai donc remis le break
Dès que je l'enlève du WriteData(second), je récupère 1:7 45 (puis tout s'éteint) j'ai donc laissé cette fonction sans le break.
De même avec WriteAddr du second bloc
Si j'enlève le break du WriteData du second bloc, forcèment, il rate aussi mais je recupère 1:7 165, le lcd ne s'éteint plus et la led clignote, le 1 s'incrémente sur le LCD. J'ai remis le break sur cette fonction puisque j'ai perdu mon 45, j'ai eu 165 à la place
Si j'enlève le break de ReadAddr, j'obtiens 1 6 45 puis tout s'éteint. J'ai donc remis le break
Si j'enlève le tout dernier, je n'ai rien du tout, ça normalement c'est normal car du coup je ne sors jamais du while imbriquer tout simplement, le dernier break servant à en sortir
De fait, pour essayer, si j'enlève le while imbriquer, je recupère mon 1 7 45 ^^
Au final, en ayant enlever les break que je pouvais, le code ressemble à ceci :
Vous n’avez pas les permissions nécessaires pour voir les fichiers joints à ce message.
Fonctions I2C
Bonjour,
Ne mets pas de break derrière la fonction I2C2_ReadAddr(), car le DS1307 perdra le nord et ne voudra plus rien savoir derrière.
Il faut mettre ReadData(1) car comme tu ne lis qu'un seul octet, après réception tu envoies un NAK pour indiquer que c'était le dernier octet attendu.
Je ne comprends pas comment le lcd peut s'éteindre alors que tu y fais systématiquement un effacement et une écriture dans la foulée. Essaie de debugger cela. D'ailleurs cela veut dire quoi s'éteindre, sois plus précis, le backlight s'éteind ?, moi j'ai compris il s'efface.
Si tu es perdu, mets pic + DS1307 sur breadboard avec juste la led comme témoin et regarde si cela fait pareil.
En théorie d'après la doc, on peut lire/écrire plusieurs octets, donc récupérer date et heure complètes en une seule lecture. J'ai essayé avec mes fonctions cela ne marche pas et je n'ai pas insisté, et il a dû se passer la même chose quand j'ai fait la bibliothèque il y a 4 ans. Ou alors j'ai fait au plus vite car là on parle de quelques octets, ce n'est pas gênant de les récupérer un par un, on lit surtout la seconde et si elle change on va voir le reste.
Pour l'eeprom c'est différent; on stocke beaucoup de data, il est nécessaire de lire/écrire en continu, et cela marche très bien. Regarde ce que font mes fonctions i2c, juste les quelques lignes de description en début des fonctions. Il y a 2 versions _8 et _16 car il y a des eeproms de plus grosse capacité où l'adresse des data est sur 16 bits.
Donne moi ton dernier fichier i2c.c.
Si tu utilises encore le bit BF je ne réponds plus de rien
Ne mets pas de break derrière la fonction I2C2_ReadAddr(), car le DS1307 perdra le nord et ne voudra plus rien savoir derrière.
Il faut mettre ReadData(1) car comme tu ne lis qu'un seul octet, après réception tu envoies un NAK pour indiquer que c'était le dernier octet attendu.
Je ne comprends pas comment le lcd peut s'éteindre alors que tu y fais systématiquement un effacement et une écriture dans la foulée. Essaie de debugger cela. D'ailleurs cela veut dire quoi s'éteindre, sois plus précis, le backlight s'éteind ?, moi j'ai compris il s'efface.
Si tu es perdu, mets pic + DS1307 sur breadboard avec juste la led comme témoin et regarde si cela fait pareil.
En théorie d'après la doc, on peut lire/écrire plusieurs octets, donc récupérer date et heure complètes en une seule lecture. J'ai essayé avec mes fonctions cela ne marche pas et je n'ai pas insisté, et il a dû se passer la même chose quand j'ai fait la bibliothèque il y a 4 ans. Ou alors j'ai fait au plus vite car là on parle de quelques octets, ce n'est pas gênant de les récupérer un par un, on lit surtout la seconde et si elle change on va voir le reste.
Pour l'eeprom c'est différent; on stocke beaucoup de data, il est nécessaire de lire/écrire en continu, et cela marche très bien. Regarde ce que font mes fonctions i2c, juste les quelques lignes de description en début des fonctions. Il y a 2 versions _8 et _16 car il y a des eeproms de plus grosse capacité où l'adresse des data est sur 16 bits.
Donne moi ton dernier fichier i2c.c.
Si tu utilises encore le bit BF je ne réponds plus de rien
Fonctions I2C
Alors, j'ai supprimé le break au readAddr et j'ai mis 1 pour le NACK et la tout de suite, j'ai le programme qui ne plante plus, il boucle et la led s'allume ( mais 
) Il n'arrive pas a obtenir la valeur 7. J'obtiens 1: 6 45. Le 1 s'incrémente bien
Le writeData sans le break, c'est un écran vide directement et la led éteinte si j'en enlève un des 2 (Effectivement dans mon précédent post, je me suis mal exprimé, je voulais bien entendu dire que l'écran était vide, même pas un carré blanc juste tout vide).
Je pense aussi que je ferai octet par octet, je ne vais pas trop chercher a compliquer la chose, si je parvient déjà a avoir au final un programme robuste et fiable dans le temps, je serai bien heureux, je ne dois de toute façon pas lui demander des milliers d'octet
Promis, je n'utilise plus le BF depuis la dernière fois que l'on a parlé de cela Voici mon I2C 
) Il n'arrive pas a obtenir la valeur 7. J'obtiens 1: 6 45. Le 1 s'incrémente bienLe writeData sans le break, c'est un écran vide directement et la led éteinte si j'en enlève un des 2 (Effectivement dans mon précédent post, je me suis mal exprimé, je voulais bien entendu dire que l'écran était vide, même pas un carré blanc juste tout vide).
Je pense aussi que je ferai octet par octet, je ne vais pas trop chercher a compliquer la chose, si je parvient déjà a avoir au final un programme robuste et fiable dans le temps, je serai bien heureux, je ne dois de toute façon pas lui demander des milliers d'octet
Promis, je n'utilise plus le BF depuis la dernière fois que l'on a parlé de cela
Voici mon I2C Vous n’avez pas les permissions nécessaires pour voir les fichiers joints à ce message.
Fonctions I2C
Si tu fais tourner le programme ci-dessus avec un seul break à la fin du while, le programme tourne et la led clignote ?
Si c'est le cas alors le ReadAddr() ne passe pas, c'est lui qui n'est pas acquitté par le DS1307. Il faut trouver pourquoi.
SSP2BUF = (addr << 1) | 1;
Les parenthèses ne sont pas nécessaires, mais on sait jamais et c'est plus lisible.
Pour le moment l'essentiel c'est de le faire marcher de façon continue.
Tu peux tester uniquement la partie écriture en mettant un break juste avant le premier stop. La led doit clignoter et l'afficheur compter avec value = 3.
Si c'est pas bon, la lecture attendra.
Si c'est bon, on fait l'inverse, tu commentes toute la partie écriture, value démarrera à 4, pas grave.
Si selon ce que tu as écrit même l'écriture pose problème, c'est qu'il y a un sacré loup !
Met SMP à 0 pour voir, c'est une histoire de slew rate, si Paul passe par là y connaît.
Si c'est le cas alors le ReadAddr() ne passe pas, c'est lui qui n'est pas acquitté par le DS1307. Il faut trouver pourquoi.
SSP2BUF = (addr << 1) | 1;
Les parenthèses ne sont pas nécessaires, mais on sait jamais et c'est plus lisible.
Pour le moment l'essentiel c'est de le faire marcher de façon continue.
Tu peux tester uniquement la partie écriture en mettant un break juste avant le premier stop. La led doit clignoter et l'afficheur compter avec value = 3.
Si c'est pas bon, la lecture attendra.
Si c'est bon, on fait l'inverse, tu commentes toute la partie écriture, value démarrera à 4, pas grave.
Si selon ce que tu as écrit même l'écriture pose problème, c'est qu'il y a un sacré loup !
Met SMP à 0 pour voir, c'est une histoire de slew rate, si Paul passe par là y connaît.
Fonctions I2C
Un seul break en fin du while imbriqué ne fonctionne pas. LCD vide, led éteinte. Dès que je supprime le break à au moins l’un des 2 writeData pour préciser le registre, cela survient.
Par contre, je test de temps en temps des trucs qui me vient à l’esprit en parallèle de ce que tu me propose, parfois ce que je test donne quelque chose (en pire ou en mieux
) parfois rien. J’ai eu l’idée ici de rajouter des { } après chaque if dans le main. Dans ce cas, les WriteData pour pointer le registre ne requièrent plus de break. Dans ce cas-là, je peux n’avoir qu’un seul break à la fin du while imbriqué et j’obtiens (1 : 7 45 avec le 1 qui s’incrémente).
Si je mets un break avant le premier stop afin de court-circuiter la lecture, c’est ok, « 1 : 3 0 », le 1 s’incrémente. Un seul break avant le stop et avec mes { }.
À l’inverse, en commentant l’écriture (Donc du premier start au premier stop avec /* */) C’est aussi ok, 1 : 7 1 (Les 2 « 1 » s’incrémente) toujours avec les même condition de break et mes { }.
J’ai été un peu plus loin vu que pour une fois le DS1307 ne me boudait pas de trop, je me suis dit, profitons-en, j’ai carrément enlevé tout les breaks et le while imbriqué afin de me retrouver avec le code ci-dessous. Et… ça fonctionne !! « J’ai 1 : 7 45 » avec le 1 qui s'incrémente.
Je déduis donc que l'I2C est enfin bien formé et vivant, je croise les doigts en tout cas pour ne pas avoir parlé trop vite
Il ne me reste donc plus qu'à créer les fonctions dont ont a parlé hier et gérer aussi les conflits de bus avec WCOL notamment. Vois-tu peut-être une autre remarque/suggestions a me faire afin de rendre mon code + robuste/efficace/fiable dans le temps vu que le code fera partie d'un projet qui fonctionnera 24h/24 7j/7 ? ^^ Mes idle notamment non ?
Dans tout les cas un énorme MERCI pour ta patience, ta pédagogie et ton incroyable bienveillance !!! Le monde manque cruellement de gens comme toi comme j'ai encore pu le remarquer il y a moins de 24h !
Par contre, je test de temps en temps des trucs qui me vient à l’esprit en parallèle de ce que tu me propose, parfois ce que je test donne quelque chose (en pire ou en mieux
) parfois rien. J’ai eu l’idée ici de rajouter des { } après chaque if dans le main. Dans ce cas, les WriteData pour pointer le registre ne requièrent plus de break. Dans ce cas-là, je peux n’avoir qu’un seul break à la fin du while imbriqué et j’obtiens (1 : 7 45 avec le 1 qui s’incrémente).Si je mets un break avant le premier stop afin de court-circuiter la lecture, c’est ok, « 1 : 3 0 », le 1 s’incrémente. Un seul break avant le stop et avec mes { }.
À l’inverse, en commentant l’écriture (Donc du premier start au premier stop avec /* */) C’est aussi ok, 1 : 7 1 (Les 2 « 1 » s’incrémente) toujours avec les même condition de break et mes { }.
J’ai été un peu plus loin vu que pour une fois le DS1307 ne me boudait pas de trop, je me suis dit, profitons-en, j’ai carrément enlevé tout les breaks et le while imbriqué afin de me retrouver avec le code ci-dessous. Et… ça fonctionne !! « J’ai 1 : 7 45 » avec le 1 qui s'incrémente.
Je déduis donc que l'I2C est enfin bien formé et vivant, je croise les doigts en tout cas pour ne pas avoir parlé trop vite
Il ne me reste donc plus qu'à créer les fonctions dont ont a parlé hier et gérer aussi les conflits de bus avec WCOL notamment. Vois-tu peut-être une autre remarque/suggestions a me faire afin de rendre mon code + robuste/efficace/fiable dans le temps vu que le code fera partie d'un projet qui fonctionnera 24h/24 7j/7 ? ^^ Mes idle notamment non ?
Dans tout les cas un énorme MERCI pour ta patience, ta pédagogie et ton incroyable bienveillance !!! Le monde manque cruellement de gens comme toi comme j'ai encore pu le remarquer il y a moins de 24h !
Vous n’avez pas les permissions nécessaires pour voir les fichiers joints à ce message.
Fonctions I2C
J'ai vérifié 10 fois et tes fonctions retournent bien 2 si le DS1307 acquitte.
Les breaks que tu as enlevés permettent de sortir du while si l'envoi n'est pas acquitté, ce qui est un minimum si tu veux de la robustesse. Pas la peine d'aller plus loin, il y a un problème.
Tu ne tiens plus compte des NAK reçus du DS1307, un peu facile, et la suite va pas être triste.
Avec ton programme modifié, regarde à l'analyseur logique une écriture de registre, et examine les 3 acknoledges reçus du DS1307. ils ont quelles valeurs ?
C'est comme ça les forums, j'en ai aussi pris ma part ailleurs, pas ici. De toute façon ces forums techniques vont disparaître.
Les breaks que tu as enlevés permettent de sortir du while si l'envoi n'est pas acquitté, ce qui est un minimum si tu veux de la robustesse. Pas la peine d'aller plus loin, il y a un problème.
Tu ne tiens plus compte des NAK reçus du DS1307, un peu facile, et la suite va pas être triste.
Avec ton programme modifié, regarde à l'analyseur logique une écriture de registre, et examine les 3 acknoledges reçus du DS1307. ils ont quelles valeurs ?
C'est comme ça les forums, j'en ai aussi pris ma part ailleurs, pas ici. De toute façon ces forums techniques vont disparaître.
Fonctions I2C
J'ai essayé de prendre toute la com en screen, placé mes pin, lancer le programme LOGIC puis allumer la carte
J'ai ceci en entier
Start
WriteAddrSlave
WriteReg
WriteData
WriteAddrSlave
Write Reg
ReadAddr
ReadData
En espérant ne pas mettre trompé
J'ai ceci en entier
Start
WriteAddrSlave
WriteReg
WriteData
WriteAddrSlave
Write Reg
ReadAddr
ReadData
En espérant ne pas mettre trompé
Vous n’avez pas les permissions nécessaires pour voir les fichiers joints à ce message.
Fonctions I2C
Fonctions I2C
Fonctions I2C
Qui est en ligne
Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 3 invités
Nouveaux messages