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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.