dl7nb
Anmeldungsdatum: 27. Februar 2015
Beiträge: 8
|
Hallo,
ich versuche schon einige Zeit 10 Bytes via I2C zu lesen. Mit den I2C-Tools geht das Lesen und Schreiben von Bytes oder Words ganz elegant und einfach. Nur habe ich hier eine SMBus-Geschichte, bei der 10 Bytes als Antwort anfallen. Die Python-SMBus-routinen helfen mir da auch nicht weiter. Aber vielleicht hat da jemand schon mal so etwas gelöst?!
Hier die Vorausetzungen: I2c-Bus : 2
Address : 0x40
Command : D0h Alles weitere ergibt sich aus dem beigefütem Link: http://www.dx-buddy.net/Excerpt.png Kann mir hier jemand weiterhelfen? Danke! Wolf P.S.: Google ist normalerweise mein Freund, hier habe ich nicht wirklich was gefunden!
- Bilder
|
track
Anmeldungsdatum: 26. Juni 2008
Beiträge: 7174
Wohnort: Wolfen (S-A)
|
Hi Wolf, erstmal herzlich willkommen hier auf dem Forum ! Dein Problem müsstest Du allerdings noch einmal konkreter beschreiben, denn mir fehlt noch der Kontext. Sitzt die i2c- Schnittstelle auf dem Motherboard, oder ist das was externes ? - und welche Befehle hast Du genau benutzt ? track
|
dl7nb
(Themenstarter)
Anmeldungsdatum: 27. Februar 2015
Beiträge: 8
|
Vielen Dank für die freundliche Aufnahme hier! Und Danke auch für die Antwort! Ich verwende einen BananaPi mit Lubuntu. Der Port befindet sich auf dem Rechner.
Bytes oder Words kann ich lesen und auch schreiben.
Nur geht es hier um eine Sequenz bei der eine Abfrage mehrere Bytes zur Folge hat. Das genaue Handling/Timing ist im Link meiner Nachricht oben zu finden.
Mir geht es um die Umsetzung dieser (längeren) Sequenzen. Nur Bytes oer Words zu lesen und zu schreiben ist ja nur ein winziger Teil der I2C-Übertragungsmöglichkeiten. Oder anders gesagt: ich schicke ein Byte mit CRC-Prüfsumme und erhalte eine ganze Sequenz an Daten Der I2C-Server befindet sich in einem kommerziellem Netzteil und hier wird der komplette Status übertragen.
Ich kann Steuerbefehle ausführen lassen und bekomme auch 1-Byte oder 2-Byte(=Word) Antworten. Natürlich kann ich auch Daten-Blöcke lesen und schreiben. Nur scheint es nicht möglich zu sein ein Byte zu schicken (mit CRC) und dann eine Kette von Bytes zurückzulesen(auch mit CRC). (wie im Link detailiert beschrieben) Wolf
|
track
Anmeldungsdatum: 26. Juni 2008
Beiträge: 7174
Wohnort: Wolfen (S-A)
|
Sowohl Dein Link als auch Dein Anhang zeigen nur den (gleichen) Registerplan, oder sowas. Also nix weiterführendes. Mit hardwarenahen Sachen bin ich im Prinzip vertraut, schließlich bin ich von Hause Elektronik-Entwickler. Was mir fehlt, ist der Hintergrund zu den I2C-Tools. Allerdings habe ich wenig Lust, mich hier extra von 0 an selber einzulesen, deshalb sei so lieb, und hilf mir etwas auf die Sprünge. Bitte zeig mir die ganz konkreten Befehle, die Du benutzt hast, und am besten auch einen Link auf die Doku. LG, track
|
dl7nb
(Themenstarter)
Anmeldungsdatum: 27. Februar 2015
Beiträge: 8
|
Neee, ist KEIN Registerplan:
DAS ist der zeitliche Ablauf des gesmaten Vorganges:
Ein Start bit ->8 Bit for die Address incl. Write-Befehl usw. Die I2C-Tools erlauben eben nur Byte- und Word-orientiertes Schreiben ind Lesen. Also nur 1-Byte und 2-Byte Befehle. Hier geht es aber um 9 Bytes, wie aus dem Ablaufplan ersichtlich. Ist eben doch nicht so einfach, sonst hätte Google ja schon was ausgespuckt... Jedenfalls Danke für Deine Mühe! Wolf
|
track
Anmeldungsdatum: 26. Juni 2008
Beiträge: 7174
Wohnort: Wolfen (S-A)
|
Ok, dann habe ich das jetzt verstanden. (Ich habe ja nun Deine Hardware nicht, dass ich selber testen könnte, deshalb:) Welche Befehle hast Du abgesetzt, und was hast Du jeweils zurück bekommen ? Hast Du erst einen i2cset und danach einen (oder mehrere ?) i2cget geschickt ? - oder hast Du es mit i2cdump versucht ? Ich würde schon gerne die genauen Befehle wissen, und was daraufhin zurück kommt, um es nachvollziehen zu können. (So nach Gefühl würde ich ja darauf tippen, dass i2cdump das ist, was Du suchst. Natürlich mit dem Parameter p wegen der PEC.) LG, track
|
dl7nb
(Themenstarter)
Anmeldungsdatum: 27. Februar 2015
Beiträge: 8
|
Ich habe alle denkbare Kombinationen bei den I3c-Tools ausprobiert. Und das mehrere Tage lang. Die I2C-Tools können zwar memory dumps lesen und schreiben. Aber auf einen Schreibbefehl mit diesem Code &hD0 kommt nüscht. Da wird von den I2C-Tools ein schönes "stopp" geschreiben, bevor es überhaupt losgeht. Ist am SpeicherOsci prima erkennbar.
NAch Studium der gemanten Man-files zu I2C-Tools und dem intensiven Betrachten der I2C-Tools source, sehe ich nicht, dass es damit gehen könnte. Es muss irgendetwas anderes als I2C-Tools sein um eine I2C-Sequenz abzuarbeiten. Vor längere Zeit hab ich da mal einen Code-schnipsel gesehn, aber da hab ich das nicht gebraucht und leider nicht gespeichert. Soweit ich mich erinnere war das unter raspbian auf einem RasperryPi mit Python gelöst worden... wolf
|
snafu1
Anmeldungsdatum: 5. September 2007
Beiträge: 2123
Wohnort: Gelsenkirchen
|
|
dl7nb
(Themenstarter)
Anmeldungsdatum: 27. Februar 2015
Beiträge: 8
|
Etwas ähnliches hab ich schon probiert. Das hatte zwar keinen Erfolg... aber irgendwas scheint hier anders zu sein. Werde ich morgen als Erstes noch mal schauen, ob/wie das sich bei mir verhält. Für heute: Danke für die große Geduld! Melde mich nach den nächsten Versuchen! Wolf
|
dl7nb
(Themenstarter)
Anmeldungsdatum: 27. Februar 2015
Beiträge: 8
|
Hallo Snafu1! Diverses ausprobiert –- keine Reaktion...(=Da kommt nie was zurück) i2cget und i2cset mit Bytes und Words klappt aber (wenn pec gesetzt ist). Werde wohl damit leben müssen... Wolf
|
snafu1
Anmeldungsdatum: 5. September 2007
Beiträge: 2123
Wohnort: Gelsenkirchen
|
dl7nb schrieb: i2cget und i2cset mit Bytes und Words klappt aber (wenn pec gesetzt ist).
Dann solltest du doch normalerweise mit Folgeaufrufen in einer Schleife ebenfalls zum gewünschten Ergebnis kommen können.
|
dl7nb
(Themenstarter)
Anmeldungsdatum: 27. Februar 2015
Beiträge: 8
|
Das dachte ich auch... aber leider...
Evtl. muss ich was ganz anderes versuchen... nur was 😉 Danke!! für die Mühen, aber jetzt bin ich mir schon etwas sicherer, dass es an etwas anderem liegen kann.
Möglicherweise wird diese Sequenz vom Server gar nicht - oder anders unterstützt.
VoM?? (Victim of Manual) Wolf
|
track
Anmeldungsdatum: 26. Juni 2008
Beiträge: 7174
Wohnort: Wolfen (S-A)
|
Beim Suchen habe ich gerade noch dieses gefunden. Offenbar kann man einen Block Read durch ein i2cget und ein i2cdump ... i simulieren. Ansonsten bliebe nur der direkte Zugriff auf das i2c-Device selber. (da hatte ich vorgestern ein Beispiel gesehen, aber ich finde es gerade nicht mehr) LG, track
|
snafu1
Anmeldungsdatum: 5. September 2007
Beiträge: 2123
Wohnort: Gelsenkirchen
|
dl7nb schrieb: Möglicherweise wird diese Sequenz vom Server gar nicht - oder anders unterstützt.
Eine der vielen Möglichkeiten wäre, dass deine Anfragen schneller gestellt werden als die Gegenstelle sie verarbeiten kann. Hier hilft es, kleine Pausen (in Python via time.sleep() ) einzubauen.
|
dl7nb
(Themenstarter)
Anmeldungsdatum: 27. Februar 2015
Beiträge: 8
|
Da hätte ich selbst drauf kommen müssen - bin ich aber nicht! Du hats Recht! Was so ein bisschen sleep oder delay erreichen kann. Jetzt geht's plötzlich! Auch die High-level-Compiler können plötzlich lesen. (Gambas3 kann jetzt auch) Wochenende gerettet! Danke nochmals! Wolf
|