Forum: Mikrocontroller und Digitale Elektronik FT2232-SPI: SS funktioniert nur mit ADBUS3


von dschenzen (Gast)


Angehängte Dateien:

Lesenswert?

Guten Tag.

Ich habe da ein derbes Problem mit dem FT2232D-USB-Controller von FTDI. 
Wir benutzen ein DLP-2232M-Board mit dem besagten Controller. Unser Ziel 
ist es, zwei oder mehr Drucksensoren (Sensortechnics HCEB002GUH9P5) über 
SPI abzufragen. Zur Steuerung der SPI-Kommunikation benutzen wir das 
Beispielprojekt FTCSPI.dll von FTDI, das einen Wrapper für die 
MPSSE-Programmierung über FTD2xx.dll darstellt.

Nachdem wir es geschafft haben, den 1. Sensor mit ADBUS3 als Slave 
Select korrekt abzufragen, schaffen wir es einfach nicht, einen weiteren 
Sensor mit /SS auf einem der GPIOL-Pins (konkret ADBUS4/GPIOL1) 
anzusprechen. D.h., wir kriegen schon was raus: wenn kein Sensor am 
entsprechenden /SS hängt, kriegen wir kontinuierlich 0xff-Bytes zurück. 
Der über ADBUS4 aktivierte Sensor liefert dann auch meist 0xff, aber 
eben nicht immer. Ich habe schon versucht, ein Muster zu erkennen, wg. 
evtl. Timing-Probleme und deswegen verschobener Bits. Ich kann da aber 
kein sinnvolles Muster erkennen. (Wir haben übrigens auch den Sensor 
schon ausgetauscht, weil wir den Verdacht hatten, dass er nicht richtig 
funktioniert).

Wir hatten auch schon mal vermutet, dass es am FTDI-Beispielprojekt 
liegen könnte. Wir haben nämlich bei Experimenten mit I2C-Sensoren einen 
entsprechenden Fehler in der FTDI2C.dll gefunden und behoben. Ich bin 
aber bisher auf nichts gestoßen.

Ich habe den Verdacht, das Problem hat mit der Konfiguration der 
GPIOL-pins über SPI_SetGPIOs(...) zu tun, denn mit ADBUS3 klappt es ja.

Der Sensor schickt im Idealfall jeweils zwei Byte für den Druck und 2 
Bytes für die Temperature. Solange /SS nicht auf High gesetzt wird, 
schreibt der Sensor immer weiter Daten auf MISO, wobei der Druckwert 
sich nur alle 250µsec ändert. Das erste Datenpaket enthält normalerweise 
noch ein Dummy-Byte vor den gültigen Daten. Die SPI_Read()-Funktion 
zeigt dieses Byte aber nicht an. Da man bei SPI_Read mindestens ein Byte 
auf MOSI schreiben muss, wird das vom Slave geschickte Dummy-Byte 
offenbar "verdeckt". So wie beschrieben funktioniert es bei /SS auf 
ADBUS3 (unser sogenannter Channel 1).

Ich habe mal die C-Quellcode-Datei angehängt. Die relevante Funktion ist 
RDK_GetDruck(); sie enthält u.a. zwei Aufrufe von RDK_InitializeDevice() 
und InitializeSpiReadStructures(), in denen die entsprechenden GPIO-Pins 
sowie die Datenstrukturen für den Aufruf der SPI_Read()-Funktion gesetzt 
werden. Zur Ausgabe der Rohdaten gibt es einen Codeblock, der mit 
"TEST-CODE" markiert ist. Ich schicke bei Bedarf auch gerne das 
komplette VC++ 2008-Projekt, aber vielleicht fällt jemandem was auf.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.