Probleme beim Auslesen von einem Motionsensor per spi über FTDI USB Brücke mit pyftdi

[andib007 (Gast)]

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:

from pyftdi.spi import SpiController, SpiIOError
from struct import *





ctrl= SpiController()#spi
ctrl.configure('ftdi://ftdi:232h/0')  
spi = ctrl.get_port(cs=0, freq=1E6, mode=0)
#spi.set_frequency(1000000)
#spi.configure('ftdi://0x403:0x6014/1')
#slave = spi.get_port(cs=0, freq=1E6, mode=1)
write_buf = b'\x75\0x10'
#write_buf = b'\x75\0xdf'
#write_buf = b'\xD0\0xff'


spi.write(write_buf,True,False)

read_1= spi.read(200, start=False, stop=True).tobytes()

#id = spi.exchange([0x43,0x11,0x00,0x00,0x00],8).tobytes()
id = spi.exchange([0x75,0x00],200).tobytes()
#ctrl.get_port(cs=1, freq=1E6, mode=1)
print(read_1)
print(id)

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.

[Jim M. (turboj)]

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.

[Andreas K. (andib007)]

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!!!!!!

[Andreas K. (andib007)]

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:

from pyftdi.spi import SpiController, SpiIOError
from struct import *

ctrl= SpiController()#spi
ctrl.configure('ftdi://ftdi:232h/0')  
spi = ctrl.get_port(cs=0, freq=1E6, mode=0)

write_buf = b'\x75'

spi.write(write_buf,True,False)

read_1= spi.read(1, start=False, stop=True).tobytes()

id = spi.exchange([0x75],1).tobytes()
print(read_1)
print(id)