FTDI libMPSSE SPI-Problem

[Ralf G. (dl5eu)]

Moin zusammen,

ich möchte in einem PC-Programm (Qt 6.8.3 und GCC) mit der von FTDI zur 
Verfügung gestellten libMPSSE die MPSSE eines FT232H (UM232H-Modul) 
nutzen, um einen über SPI angeschlossenen MCP3008 auszulesen. Hat jemand 
von Euch so etwas schon einmal erfolgreich gemacht? Es geht mir 
wohlgemerkt um genau diese Hardware und die libMPSSE.

Grundsätzlich funktioniert das Programm. Allerdings habe ich das 
Problem, dass beim Aufruf der Funktion SPI_ReadWrite() Daten zum ADC 
geschickt werden, die nicht aus meinem TX-Puffer stammen und dadurch die 
Funktion stören.

Wenn ich 3 Bytes mit 0x00 im Puffer habe erwarte ich, dass während der 
24 Takte die MOSI-Leitung auf 0 bleibt. Das ist jedoch nicht der Fall. 
Wie ich mit meinem MSO sehen kann wird während der ersten 8 Bits z.B. 
0x79 oder etwas anderes anstatt 0x00 gesendet. Der Aufruf von 
SPI_Write() (und SPI_Read()) funktioniert hingegen korrekt; hier bleibt 
die MOSI Leitung wie erwartet auf 0.

Hat jemand eine Idee, wo diese (für mich willkürlich aussehenden) Daten 
herkommen? Vielleicht ein Bug in der Funktion SPI_ReadWrite()? Falsche 
Initialisierung? Oder muss ich in dem UM232H mit FT_PROG etwas 
umprogrammieren?

Ich habe jetzt schon mehrere Tage damit verbracht den Fehler zu suchen, 
bisher leider ohne Erfolg und die Informationen aus dem Netz haben mir 
dabei leider auch nicht geholfen.

Vielen Dank für Eure Hilfe!

Freundliche Güße,

Ralf

[Oliver S. (oliverso)]

Ralf G. schrieb:
> Hat jemand eine Idee, wo diese (für mich willkürlich aussehenden) Daten
> herkommen?

Die lib kommt ja nun mit source Code. Man könnte nachschauen…

Oliver

[Frank O. (frank_o)]

Aktuelle Treiber verwendet?

[Ralf G. (dl5eu)]

Die Bibkiothek kommt zwar mit Sourcecode, aber leider ist es mir bisher 
nicht gelungen, sie als statisch gelinkte Bibliothek in mein Projekt 
einzubinden und zu kompilieren um sie debuggen zu können. Alles wird 
ohne Fehlermeldungen kompiliert aber kein Code erzeugt. Wahrscheinlich 
habe ich da irgendwo ein #define vergessen oder falsch gesetzt. Auch 
damit habe ich bereits viele Stunden verbracht und das letztendlich auf 
später verschoben.

Die aktuellen Treiber sind installiert.

Grüße,

Ralf

[Harald K. (kirnbichler)]

Ralf G. schrieb:
> Allerdings habe ich das
> Problem, dass beim Aufruf der Funktion SPI_ReadWrite() Daten zum ADC
> geschickt werden, die nicht aus meinem TX-Puffer stammen und dadurch die
> Funktion stören.

Dann zeig' doch mal Deinen eigenen Quelltext. Daß die Library selbst 
einen so eklatanten Fehler hat, wie Du beschreibst, halte ich für wenig 
wahrscheinlich, dafür gibt es die schon zu lange und zu viele Leute 
nutzen die.

[Ralf G. (dl5eu)]

Bitteschön. Den relevanten Teil meines Testcodes habe ich angehängt.

Im Hauptprogramm wird noch das hier gemacht:

quint32 index;
int value;

SpiDevice::getIndexByDescription(ID_STR, index);
m_device = new SpiDevice(index, this);
m_adc0 = MCP300X::create(*m_device, 8);
m_adc0->init();
m_adc0->readChannel(0, value);

Falls Du den Fehler findest kläre mich bitte auf.

Grüße,

Ralf

[Harald K. (kirnbichler)]

Ralf G. schrieb:
> Bitteschön. Den relevanten Teil meines Testcodes habe ich angehängt.

OK, danke. (Einfacher wäre es gewesen, das Ding einfach *.cpp zu nennen 
und nicht als Zip anzuhängen, dann hätte die Forensoftware das selbst 
anzeigen können, aber egal, ich hab's auch so ansehen können)


Tja, das sieht auf den ersten Blick unverdächtig aus.

[Jens B. (dasjens)]

Ralf G. schrieb:

> Grundsätzlich funktioniert das Programm. Allerdings habe ich das
> Problem, dass beim Aufruf der Funktion SPI_ReadWrite() Daten zum ADC
> geschickt werden, die nicht aus meinem TX-Puffer stammen und dadurch die
> Funktion stören.
>

Und wie hast Du das festgestellt?

[Harald K. (kirnbichler)]

Jens B. schrieb:
> Und wie hast Du das festgestellt?

Hat er doch geschrieben:

Ralf G. schrieb:
> Wie ich mit meinem MSO sehen kann

[Ralf G. (dl5eu)]

Harald K. schrieb:
> Einfacher wäre es gewesen, das Ding einfach *.cpp zu nennen
> und nicht als Zip anzuhängen, dann hätte die Forensoftware das selbst
> anzeigen können, aber egal, ich hab's auch so ansehen können

Beim nächsten Mal kann ich das ja machen. Ich wollte das Posting nicht 
mit aufgeblähtem Code unleserlich machen. Die Forensoftware und wie sie 
arbeitet kenne ich ja nicht.

Jens B. schrieb:
> Und wie hast Du das festgestellt?

Wie bereits früher geschrieben mit meinem MSO (Mixed Signal 
Oscilloscope), das auch Digitaleingänge hat. Die habe ich an CS, SCK, 
MOSI und MISO geklemmt und mit CS getriggert. Wenn ich RX- und TX-Puffer 
vollständig mit 0 initialisiere sollte an MOSI auch nur 0 erscheinen. 
SPI_Write() macht es ja korrekt.

Vielleicht gelingt es mir ja noch, die libMPSSE mit cmake so zu bauen 
oder den Code so in mein Projekt einzubinden, dass ich ihn debuggen 
kann. FTDI liefert nur ein VS-Projekt mit.

Ralf

[Harald K. (kirnbichler)]

Ralf G. schrieb:
> Ich wollte das Posting nicht
> mit aufgeblähtem Code unleserlich machen.

Anhang ist schon richtig, nicht in den Text reinkopieren. Wenn der 
Anhang nicht komprimiert ist und *.c, *.cpp oder auch *.ino heißt, dann 
bietet die Forensoftware eine "Quelltext-Angucken-Funktion" an, mit 
Zeilennummer, Syntaxhighlighting.

Hier Beitrag "Tasten in C unter Linux" kannst Du 
sehen, wie das dann aussieht.

[Dieter S. (ds1)]

Wenn man sich SPI_ReadWrite() in "\release\source\ftdi_spi.c" von 
libmpsse-windows-1.0.8.zip (vermutlich die aktuelle Version) anschaut 
dann sieht das schon ein wenig nach "Baustelle" aus...