Liebes Forum,
zur Zeit hänge ich an einem Problem mit einem FTDI VA800A-spi Board und
bräuchte ein paar Tipps von Euch:
Ich möchte den Motion-Sensor ICM-20602 über eine FTDI USB-Spi Brücke mit
einem Python-Skript unter Debian-Linux auslesen. Den gleichen Sensor
kann ich bereits mit einem Labview-Programm und einer NI-Breakoutbox
über I2C und Spi gut auslesen. Es funktioniert also - ist definitiv kein
Problem des Sensors.
Als Hobbyprojekt würde ich gerne auch mit Python und über ein FTDI-SPI
Schnittstelle das gleiche bewerkstelligen.
Ich habe alle Treiber richtig installiert und kann das FTDI Board über
python ansteuern. Ich habe mit dem Osci auch kontrolliert, ob das
Clocksignal rausgeschickt wird bzw. ob auch CS beim senden auf low
gezogen wird bzw. über MOSI auch wirklich das gesendet wird, was ich
programmiert habe: ja das ist wirklich der Fall. Nur über MISO kommt
nicht das an was ich will: Es sollte beim auslesen des Registers mit der
Adresse 0x75 die ID 0xAF gesendet werden. Statt dessen kommt entweder
nichts(0x00) oder wenn ich eine willkürliche Bytereihenfolge an die
Adresse sende kommt etwas in der folgenden Form:
"\x11\x9c\x9e\xb5\x00\x00\x00\x00\x00\x00\x00a\x15\x00f\x93\x0b\x00\x00\
x06\"
Der Sensor sollte Mode 0 oder Mode 3 können. Nun sollte es nach dem
Forum hier:
https://electronics.stackexchange.com/questions/360086/make-ftdi-2232d-do-spi-mode-1-properly-data-seems-1-2-clock-cycle-off
wenn dann nur mit Mode 1 Probleme geben. Anmerkung Mode 2 kann ich zum
Beispiel gar nicht setzen mit der pyftdi.spi lib.
Das ist mein Python-Code dazu:
Hat einer eine Idee was ich noch ausprobieren könnte? Ich habe alles
versucht - Bytereihenfolge, anderer Mode, ein Versuch mit ftd2xx statt
pylibftdi, aber es scheint als würde der Controller nicht richtig die
Flanken des Signals erkennen - also das wäre meine Erklärung dazu - aber
da muss es doch ein Lösung geben. Ich wäre sehr dankbar, wenn jemand
eine Idee hätte - vielen Dank schon mal im Voraus.
andib007 schrieb:> Ich habe mit dem Osci auch kontrolliert, ob das> Clocksignal rausgeschickt wird bzw. ob auch CS beim senden auf low> gezogen wird bzw. über MOSI auch wirklich das gesendet wird, was ich> programmiert habe: ja das ist wirklich der Fall.
Dann sollte man die Verkabelung nochmals genausestens prüfen, denn wenn
die Signale korrekt gesendet werden dann muss der Chip auch antworten.
Ist das nicht der Fall, ist was grunsätzlich faul. Also Verkabelung oder
Spannungsversorgung.
Jim M. schrieb:> andib007 schrieb:>> Ich habe mit dem Osci auch kontrolliert, ob das>> Clocksignal rausgeschickt wird bzw. ob auch CS beim senden auf low>> gezogen wird bzw. über MOSI auch wirklich das gesendet wird, was ich>> programmiert habe: ja das ist wirklich der Fall.>> Dann sollte man die Verkabelung nochmals genausestens prüfen, denn wenn> die Signale korrekt gesendet werden dann muss der Chip auch antworten.>> Ist das nicht der Fall, ist was grunsätzlich faul. Also Verkabelung oder> Spannungsversorgung.
Hallo Jim,
wie gesagt: es ist alles korrekt verkabelt.
Wenn man von Mode 0 auf 1 wechselt - kommt zum Beispiel eine Antwort -
der Chip reagiert. Nur nicht so wie er soll. Die Verkabelung ist das
erste was man prüft und die stimmt ganz sicher!!!!!!
Ich habe für dieses Problem die Lösung gefunden - es handelt sich um
einen Datenblattproblem:
Die ID für den ICM-20602 ist nicht 0xAF sondern 0x12 und kann mit dem
von mir oben angegebenen Programm ausgelesen werden, wenn man pro
Datenzyklus (Schreiben/Lesen) Master-Slave-Datenaustausch als
Controllbyte die Adresse des Registers verschickt. Für das Auslesen wird
ein weiteres Byte vom Treiber verschickt, wenn man die spi.Read-Funktion
benutzt oder auch bei der spi.exchange-Funktion.
Hier habe ich den richtigen Wert entdeckt:
https://patchwork.kernel.org/patch/10784505/> #define INV_ICM20608_WHOAMI_VALUE 0xAF> +#define INV_ICM20602_WHOAMI_VALUE 0x12
Hatte anscheinend ein altes Datenblatt zu Hand :(
Hier nochmal der Code:
