Da schließe ich mich an.....den sehe ich jetzt auch zum ersten mal.Zitat von peterfido
Ich habe es gerade mal getestet. Der PSoC wird mit i2cdetect erkannt aber aus irgendeinem Grund schlägt das Schreiben und Lesen immer fehl....
Bzw....ich arbeite im Moment noch mit den Befehlen i2cget und i2cset. Nur wie kann ich ein NACK senden? Weil ich habe nun am Bus einen PCF8574 und der arbeitet problemlos mit dem I2C über Konsole. Aber ein EEPROM was auch am Bus hängt will ein NACK haben und ebenso mein PSoC. Nur bisher habe ich nichts gefunden wie man ein NACK senden kann.
Dasselbe Problem habe ich anscheinend dann auch mit meinem C-Programm. Da funktioniert die Kommunikation mit meinem PCF8574 auch super aber sobald der PSoC dran hängt gibt es Probleme.
Hier ist mal das Datenblatt des I²C Moduls vom PSoC:
http://www.cypress.com/?docID=34801
Etwas unter der "ROM" Sektion am Anfang ist ein Timingdiagramm wo dann drin steht das der Chip ein NACK beim lesen erwartet.
Ich habe das auslesen mit einem Mega32 unter Bascom getestet. Da klappt es problemlos :/
Geändert von Kampi (07.10.2012 um 00:43 Uhr)
Schaut ruhig mal auf meiner Homepage vorbei:
http://kampis-elektroecke.de
Oder folge mir auf Google+:
Daniel Kampert
Es gibt 10 Arten von Menschen. Die einen können Binär, die anderen nicht.
Gruß
Daniel
Das kann mehrere Gründe haben. Wenn Du ein Oszi hast, würde ich die Signalqualität checken. Evtl. lässt sich die Geschwindigkeit "runterdrehen". Ich habe mit dem Raspi noch keinerlei I²C Erfahrungen gesammelt. Beim AVR läuft es bei längeren Kabeln langsamer besser. Zusätzlich nehme ich da immer geschirmte Leitungen (die, welche damals immer bei den CD-ROMs zur Soundkarte bei waren).
Wenn das Herz involviert ist, steht die Logik außen vor! \/
Ich denke nicht das es die Signalqualität ist, da das Schreiben und Lesen mit dem PCF funktioniert und auch beim EEPROM. Nur leider lese ich beim EEPROM was anderes aus als ich einlese. Wo ich vorhin den Test mit dem Mega32 und dem PSoC gemacht habe hatte ich dasselbe Problem und da ließ sich das Problem beheben als ich in Bascom gesagt habe das kein ACK nach der Übertragung kommt. Deswegen vermute ich da den Fehler.
Schaut ruhig mal auf meiner Homepage vorbei
http://kampis-elektroecke.de
Oder folge mir auf Google+:
Daniel Kampert
Es gibt 10 Arten von Menschen. Die einen können Binär, die anderen nicht.
Gruß
Daniel
Mit so einem Board rumspielen und keinen Schaltplan haben ??
Man kann kein NACK senden. Ein Byte wird bei I2C in 9 Bits übertragen. Das 9. Bit ist die Quittung. Wenn ein Master von einem Slave liest, taktet er 8 Bits die er liest und liefert selbst beim 9. Bit ACK oder NACK. Das NACK (resp. ACK) ist Teil des Reads. Das bedeutet, man kann entweder einen Read mit ACK oder einen Read mit NACK machen.
Für I2C gibt es bei Linux einen ganzen Zoo von Funktionen, da sollte was dabei sein. Ein wenig in den Header-Files suchen oder in den Sourcen von i2cdetect oder lmsensors. Wenn man erstmal einen Funktionsnamen hat, findet sich der Rest.
BTW die 3,6V Zehner sind witzlos. Bis die richtig leiten, werden es schon mal 4V und mehr. Wenn es denn sein muß (warum eigentlich, bei Open Collector kann es nicht höher werden, als die Spannung am Pullup) Klemmdioden nach 3,3V.
MfG Klebwax
Strom fließt auch durch krumme Drähte !
Ich bin etwas verwirrt.
Was meinst Du mit Ack NACH der Übertragung? Beim lesen sendet doch der Master als letztes ein Nack, wenn ich mich richtig erinnere.
Wenn das Herz involviert ist, steht die Logik außen vor! \
Ah ok danke für die Korrektur, hab gedacht das NACK kommt vom Slave.
Es war aber das Fehlen vom NACK welches den Fehler verursacht hat. Es lässt sich reproduzieren und verschwindet auch direkt wenn man ein NACK nach dem Lesen im Bascom angibt und daher vermute ich das es beim Pi genau so sein wird.
Dann werde ich mich morgen wohl mal auf die Suche machen müssen.....mal schauen ob sich was findet.
Schaut ruhig mal auf meiner Homepage vorbei
http://kampis-elektroecke.de
Oder folge mir auf Google+:
Daniel Kampert
Es gibt 10 Arten von Menschen. Die einen können Binär, die anderen nicht.
Gruß
Daniel
Ja sicher doch. Wozu einen Schaltplan? Pinout des für mich interessanten Header reicht doch. Habe beim PC ja auch nur die Belegung der Schnittstellen und keinen kompletten Schaltplan zur Hand.
Hauptsache, am anderen Ende sind nicht auch aus Versehen Pullups zu den 5V drin.
Der Raspi kann mit Sicherheit kurze Spannungssprünge besser ab, als ständig anliegende 5V. Man könnte auch Widerstände in Serie statt der Zenerdioden als Schutz verwenden. Mir haben die Zenerdioden schon geholfen. Zumindest lebt der Raspi noch, obwohl ich mal aus Versehen den FTDI auf 5V IO statt 3,3 stehen hatte.
Wenn das Herz involviert ist, steht die Logik außen vor! \
Servus Kampi..
Hatte eben Zeit i2c-tools zu testen.
Klappt so weit..kann die Adressen der Devices am Bus sehen.
Aber was ich noch nicht gefunden habe ist eine brauchbare Doku zu den i2c-tools.
Hast du da zufällig was auf Lager?
Gruß, Andreas
Nam et ipsa scientia potestas est..
Das sind ja auch definierte Schnittstellen, für die es geschriebene Standards gibt. Aber wie die Frage nach den I2C Pullups zeigt, ist ein Schaltplan bei einem "Bastelboard" wie dem Pi nützlich und manchmal notwendig. Ebenso ist die Schaltung bei GPIOs wichtig, dagegen kann man USB oder HDMI in den Standards nachlesen. Wenn ich eine Elektronik einsetze, für die es einen Schaltplan gibt, habe ich mir den auch angesehen.
Ob Google da helfen kann? Das ist ein Linux System, dafür gibt es bis zum Source Code alles öffentlich.
MfG Klebwax
Strom fließt auch durch krumme Drähte !
Ne hab noch keine gefunden.
Hatte gestern aber auch nicht die Zeit/Lust nach einer zu suchen
Schaut ruhig mal auf meiner Homepage vorbei
http://kampis-elektroecke.de
Oder folge mir auf Google+:
Daniel Kampert
Es gibt 10 Arten von Menschen. Die einen können Binär, die anderen nicht.
Gruß
Daniel
Berechtigungen
Zitieren
Lesezeichen