Le delai peut ne pas etre le meme pour la lecture et l'ecriture? intuitivement si ca devait varier je parierais que c l'ecriture qui demanderait un delai plus long......hors l'ecriture marche nikel.....
Version imprimable
Le delai peut ne pas etre le meme pour la lecture et l'ecriture? intuitivement si ca devait varier je parierais que c l'ecriture qui demanderait un delai plus long......hors l'ecriture marche nikel.....
Exact, donc on pourrait en déduire qu'il sagit d'une erreur de protocol...
En conservant le même délai que pour l'écriture, met au point la lecture...
Ca marche pas je commence a craaaquer...... :evil:Citation:
Envoyé par Sub0
post ton code et le protocol que tu as récupéré...
Si tu attend que je potasse, j'ai pas trop le temps en réalité,
alors donne-moi toutes les infos nécessaires pour l'analyse si tu veux...
Je t'avais envoyé mon code je crois par mp...non? l'ecriture est bonne juste la lecture marche pas..pourtant je suis scrupuleusement le protocole du datasheet.....Citation:
Envoyé par Sub0
Donc ton code actuel...
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Et le protocol du datasheet...Code:data== IO_ubI2C_Read_Bytes(I2C_ARME_LC,160,1);
http://site.voila.fr/subut/data3/24LC00.png
Bon, ton code correspond à quel tableaux ci-dessus?
Tu as choisi le 8-2 j'ai l'impression, non?
Je n'ai pas compris à quoi correspond "canal"...
"& 0xFE" sert à quoi?
Tu as un stop à la place de l'accusé, c'est pas la même chose.
le NOACK est important aussi, il est différent de l'ACK...
Lit le datasheet sur ce point.
à+
salut,
oui mon code corespond a la figure 8-2.
Canal corespond a un numero d'I2C, parcequ'il y a un autre composant sur un autre I2C que je programme aussi.....ne tiens pas compte du canal....
0xFE permet de rentrer un seul parametre lors de l'appel de la fonction...
"& 0xFE" permet de mettre un 0 au bit R/W pour l'ecriture et " | 0x01" met un "1" au bit R/W......
Le NoACK corespond a Ack0()...
La fonction de lecture devrait avoir cet ordre:
Code:
2
3
4
5
6
7
8
9
10
11
Quelle est la difference entre Ack et Ack0?Citation:
Envoyé par Sub0
C bien moi qui recoit l'ACK , je dois pas acquitter, c le recepteur qui acquitte sauf pour le NoAck ou la c moi qui ne doity pas acquitter en mettant SDA_OUT a 1 pendant un clock? non?
Déjà, le fait que tu utilises un stop avant le start...
Un start suffit, et le stop n'est pas nécessaire. Ensuite:
Citation:
le NOACK est important aussi, il est différent de l'ACK...
Lit le datasheet sur ce point.
Attention, si tu adresses plusieurs composants I²C sur le même bus, il faut peut-être l'adresser à chaque commande!
Autrement dit XXX dans l'octet de commande correspond peut-être à n° du composant... faut lire le datasheet, à+
g 2 bus I2C........le pb ne se pause pas....Citation:
Envoyé par Sub0
Citation:
Envoyé par Sub0
LE stop g essaye de le rajouter parce que ca ne marchait pas.
Le NoACK je t donné le code, il est pas juste?
Ben enlève-le maintenant. Il faut suivre le protocol à la lettre!Citation:
LE stop g essaye de le rajouter parce que ca ne marchait pas.
J'en sais trop rien...Citation:
Le NoACK je t donné le code, il est pas juste?
Il faudrait que je compare avec le code d'un de mes projets...
Mais à mon avis, ton code doit-être juste.
Essaye de faire des modifs au hasard au pire! Bon courage, à+
Citation:
Envoyé par Sub0
Write(address) = write(0) : je lui demande qu'il m'envoie le mot a l'adresse 00 on est d'accord?
bonjour, Je reprend la programmation de mon eeprom apres 2mois d'abstinence, et je n'arrive toujours pas a regler mes problemes....Sub0 es tu encore la?
Merci
Salut!
Oui, je suis toujours là! J'ai trouvé du travail (webmaster), donc je suis moins dispo forcément...
Bref, je croyais que ton problème était résolu depuis l'temps... Que se passe-t-il?
Bah en fait je relis mon code que j'ai pas touche depuis 2 mois, et je comprends pas pourquoi j'arrive a ecrire dans cette eeprom mais je n'arrive pas a la lire.......un simple micro qui a 2 entrees sorties (SCL et SDA) reliées directement par bus i2c a l'eeprom.....dans la datasheet de l'eeprom y'a 3 modes de lecture, auaun ne fonctionne.....l'eeprom acquitte correctement les octets que je lui envoie mais apparement je n'arrive pas a recuperer ce qu'elle m'envoie enfin si elle me l'envoie bien.....
Please help......
Slt! Je vois 2 possibilités d'erreur:
- Soit ton eprom n'est pas en mode lecture
- Soit ton prog aquite mal la lecture en série
L'aquitement n'est peut-être pas le même en lecture qu'en écriture.
Il faut se référer à la méthode proposée dans le datasheet...
Les fonctions de bases comme la reception et l'émission d'une donnée à l'eprom doivent être fonctionnelles.
On peut tester ces fonctions avec une lecture / écriture binaire de l'eprom.
Rappel:
DataOut (du pc vers l'eprom)
DataIn(de l'eprom vers le pc)
Pour l'écriture de l'eprom, seul l'envoi de données du pc vers l'eprom est nécessaire (DataOut).
Par contre, pour lire une donnée, l'eprom doit pouvoir envoyer la donnée vers le pc via DataIn.
Sur le bus I²C, DataIn a la même ligne que DataOut, mais le pc possède une adresse différente de celle de DataOut pour y accéder.
- programmer l'eprom en mode "envoi des données",
- programmer l'adresse à lire,
- cadencer l'emission de l'eprom avec la ligne CLock et lire DataIn au front montant ou descendant (voir datasheet).
- au même moment, le pc doit attendre la reception de donnée venant de DataIn,
- puis aquiter pour valider l'octet lu...
Salut,
Meme si j'acquitte mal l'octet recu, je devrais qd meme le lire non?
as tu deja programme en C la lecture d'une eeprom telle la mienne? si oui pourrais tu me montrer ton code? merci beaucoup....
Non, je ne programme pas en C, dsl.
Je programme en Pascal, avec TP, BPW et Delphi.
J'ai programmé une unité I²C, avec les fonctions de bases, à savoir:
- Définir l'état boolean de la ligne DataOut
- Définir l'état boolean de la ligne Clock
- Fonction pour lire l'état de la ligne DataIn
En fait, j'ai testé ces fonctions sans composant, c'est-à-dire, pour l'émission, avec un voltmètre ou une Led, testé la tension de DataOut en modifiant son état avec le pc. Pour la reception, mettre la ligne DataIn sous tension, et voir si le pc reçoit bien cette information (changement d'état). Une fois ces tests réalisés, j'ai programmé les fonctions suivantes:
- Procédure d'aquitement pour la lecture
- Procédure d'aquitement pour l'écriture
- Procédure pour émettre un octet sur le bus
- Fonction pour réceptionner un octet sur le bus
J'ai réalisé le test avec un composant I²C, en me référant à son datasheet...
Il me semble que oui...Citation:
Meme si j'acquitte mal l'octet recu, je devrais qd meme le lire non?
à+
bon bah je v deprimer tout seul dans mon coin alors ..
a+
Merci qd meme
Je ne sais pas si cela pourra t'aider mais sur certaines eeprom comme celle que je suis entrain d'essayer de programmer (M29F010B) il y a differentes commandes internes. Et l'acces en lecture ou en écriture n'est pas aussi simple et direct que ca.
Par exemple pour ecrire une données voulue dans l'eeprom il faut d'avoir d'abord effectuer une serie d'ecriture a certaines adresses. et seulement une fois qu'elle est dans le bon mode ru peut envoer ta donnees a programmer
oui merci; c justement ca le truc, je vois pas pourquoi elle est pas dans le bon mode, je fais tout ce qu'ils disent dans la datasheet......
Peux tu me faire un petit topo sur ce fameux delai stp?Citation:
Envoyé par Sub0
Merci
As-tu au moins testé ta ligne DataIn? :?:
Je te rappel la procédure...
Tu programmes une boucle qui va lire l'octet à l'adresse du port. Tu simules l'envoi d'une donnée au pc en mettant cette ligne sous tension (5v), puis à la masse. Et normalement, tu vas avoir à l'écran, cet état s'afficher. Dans cette procédure de test, il n'ya pas besoin de tempo. et ton montage électronique n'est pas connecté au pc. Par exemple, si je veux lire l'état de la broche RI (broche 9) de mon port série sur COM1, en Pascal, cela donne:
Il faut absolument être sûr que ton adresse de lecture pour accéder à DataIn est bien la bonne, sinon, tu n'y arriveras jamais... De plus, comme tu passes par un µC pour obtenir l'I²C, tu dois faire attention que celui-ci est bien capable d'envoyer l'information au pc...Code:
2
3
4
5
-> C'est seulement quand tu arriveras à afficher l'état de DataIn à l'écran que tu pourras continuer...
Bon courage, à+
Ca y'est j'ai trouvé mon erreur.....!!!!!!
En fait sur la xicor il y avait un pull up integre sur le SDA, donc les concepteurs du circuit n'avait pas mis de pull up en hard. du coup avec la nouvelle eeprom microship qui elle n'a pas de pull up integré sur le SDA, qd elle me renvoyait l'octet que je lui demandais, l'eeprom mettait la pin SDA en l'air je ne captais donc rien de clair en entree de mon micro, en rajoutant une resistance de pull en hard, l'octet de lecture est nikel....
Pour les acquitements l'eeprom force le SDA a "0" donc c pour ca quej'ai toujours recu les acquitements nikel.....
Voila, un gros ouf de soulagement et merci beaucoup a Sub0 pour son aide!!!!!!!!!!!!!!
Salut! En effet, l'erreur ne pouvait se détecter qu'en testant directement ta ligne...
Il ya toujours une résistance de rappel sur les lignes Data et Clock du bus I²C...
Mais des fois, elles sont intégrées au compo, des fois pas...
D'ailleurs, tu devrais aussi en rajouter une pour Clock, non? 22k il me semble...
Allé, bon courage pour la suite, et n'oublie pas le p'tit tag résolvé! :)
oops, déjà mis, ok j'ai rien dis! :wink: bye