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
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
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
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.
Bitteschön. Den relevanten Teil meines Testcodes habe ich angehängt. Im Hauptprogramm wird noch das hier gemacht:
1 | quint32 index; |
2 | int value; |
3 | |
4 | SpiDevice::getIndexByDescription(ID_STR, index); |
5 | m_device = new SpiDevice(index, this); |
6 | m_adc0 = MCP300X::create(*m_device, 8); |
7 | m_adc0->init(); |
8 | m_adc0->readChannel(0, value); |
Falls Du den Fehler findest kläre mich bitte auf. Grüße, Ralf
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.
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?
Jens B. schrieb: > Und wie hast Du das festgestellt? Hat er doch geschrieben: Ralf G. schrieb: > Wie ich mit meinem MSO sehen kann
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
:
Bearbeitet durch User
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.
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...
Harald K. schrieb: > Hier Beitrag "Tasten in C unter Linux" kannst Du > sehen, wie das dann aussieht. Danke für den Hinweis. Sieht gut aus. Dieter S. schrieb: > 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... Das kann ich mir ja jetzt anschauen, nachdem es mir endlich gelungen ist, die Dateien der libMPSSE in mein Projekt einzubinden. Dann sollte auch das Debuggen möglich sein. Ralf
So, Ursache gefunden. Harald K. schrieb: > 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. Hat sie aber. Nachweislich. Ich bin also doch mal wieder der erste und einzige, der das Problem hat (und es lösen will!). Alle anderen haben entweder SPI_ReadWrite() nie verwendet oder gleich ihre eigenen Funktionen geschrieben. Der Fehler ist in Zeile 747 der Datei ftdi_spi.c. In der Funktion SPI_ReadWrite() heißt es da:
1 | status = FT_Channel_Write(SPI, handle, sizeof(cmdBuffer),cmdBuffer, &noOfBytesTransferred); |
Richtig wäre:
1 | status = FT_Channel_Write(SPI, handle, 3, cmdBuffer, &noOfBytesTransferred); |
sizeof(cmdBuffer) ist 4, es sind aber nur 3 Bytes (die Bytes 0..2) initialisiert und es dürfen hier, analog zur Funktion SPI_Write(), auch nur 3 Bytes gesendet werden. Wenn ich den Code wie oben korrigiere funktioniert es und ich bekomme die korrekten Werte vom ADC. Zwei Zeilen vor dem Aufruf von FT_Channel_Write() findet man als Kommentar:
1 | // memcpy(&cmdBuffer[3],outBuffer, CurrentXferSize); |
Das war wohl irgendwann mal so und da hätte dann (vielleicht) auch sizeof(cmdBuffer) (also 4) funktioniert. Und was mache ich jetzt mit dieser Erkenntnis? Es wäre sinnvoll, wenn das Problem "an der Wurzel" gepackt, d.h. von FTDI in deren Quellcode offiziell korrigiert würde. Wie sind denn da die Erfahrungen? Lohnt es sich überhaupt, denen einen Bugreport zu schicken und wenn ja wohin? Vielleicht an support1@ftdichip.com? Grüße, Ralf
Und Google hat dir das dazu nicht gefunden? https://de.mathworks.com/matlabcentral/answers/518039-ftdi-libmpsse-0-6-spi_readwrite-weird-behaviour-loadlibrary-calllib Oliver
:
Bearbeitet durch User
Oliver S. schrieb: > Und Google hat dir das dazu nicht gefunden? Nein. Andernfalls hätte ich nicht gefragt. Und trotz "FTDI support promised to fix the issue in the next version of the library" hat FTDI den Bug bisher nicht korrigiert, obwohl die selbst schon vor 5 Jahren (!) den Fix dazu vorgeschlagen haben. Seit der Meldung des Bugs gab es bereits 8 neue Versionen der Bibliothek und in dem aktuellen Code ist er immer noch drin. Ralf
Ralf G. schrieb: > Oliver S. schrieb: >> Und Google hat dir das dazu nicht gefunden? > > Nein. Andernfalls hätte ich nicht gefragt. Kommt ja nur ganz oben in der Suche… Oliver
Oliver S. schrieb: > Kommt ja nur ganz oben in der Suche… Die Suche ist Müll, weil eben "ganz oben" nur noch KI-generierter Dreck anstelle von Informationen angezeigt werden. Dazu wird das Ergebnis indidivuell umsortiert, um möglichst viel weiteren Müll einzublenden ... Google hat fertig.
Harald K. schrieb: > Dazu wird das Ergebnis > indidivuell umsortiert, um möglichst viel weiteren Müll einzublenden ... Das muß dann an deinem individuellen Suchverlauf liegen. Oliver
Angehängte Dateien:
-
Suche.PNG
57 KB
Naheliegende Suchanfrage und Ergebnis siehe Bild. Rot markiert ist die Lösung.
Harald K. schrieb: > Die Suche ist Müll, weil eben "ganz oben" nur noch KI-generierter Dreck > anstelle von Informationen angezeigt werden. Dazu wird das Ergebnis > indidivuell umsortiert, um möglichst viel weiteren Müll einzublenden ... Stimmt leider. Ich habe mir auch mal den "Spaß" erlaubt, chatGPT zu dem Problem zu befragen. chatGPT wollte mir weismachen, dieses Verhalten sei "By Design", es sei eine Eigenschaft der Hardware, abhängig davon, wie die Leitungen initialisiert werden und kein Fehler! Und je mehr ich nachgebohrt habe, desto abstruser wurden die Antworten. Mir den Link auf das von Oliver S. genannte Posting nennen konnte diese "Fehlende Intelligenz" jedenfalls nicht. Egal. Ich weiß ja jetzt, wie ich das Problem für mein Projekt lösen kann. Ralf
Oliver S. schrieb: > Das muß dann an deinem individuellen Suchverlauf liegen. Macht das auch nur irgendwas besser, außer daß Du Dich anscheinend irgendwie überlegen fühlst?
Ich habe das Problem einfach nicht, außer natürlich dem KI-Quatsch an erster Stelle. Ansonsten macht Google bei mir das, was es schon immer gemacht hat. Und an den Screenshot zwei Beiträge weiter oben scheint das bei anderen auch so zu sein. Aber wer Google nicht mag, nutzt halt einfach eine der anderen Suchmaschinen. Es gibt ja genug davon. Oliver
Ralf G. schrieb: > hat FTDI den Bug bisher nicht korrigiert Normal soweit, machen alle großen Firmen so. Du musst den Bug-Report mit einer Absender-Adresse @siemens.de , @ibm.com oder so abschicken, dann geht's schneller.
Niklas G. schrieb: > Normal soweit, machen alle großen Firmen so. Du musst den Bug-Report mit > einer Absender-Adresse @siemens.de , @ibm.com oder so abschicken, dann > geht's schneller. Das hätten wir mal mit unseren Anwendern so machen sollen. In solchen Fällen hat unser Chef bzw. dessen Chef dann nämlich einen Anruf "von oben" bekommen und du kannst sicher sein, dass so ein Fehler dann auch korrigiert worden wäre. Ich verstehe es besonders deshalb nicht, weil die Lösung bereits seit Jahren bekannt ist und die Korrektur in wenigen Sekunden erledigt wäre. Die nötigen Tests laufen doch heute normalerweise automatisiert ab. Zumindest war das in meiner früheren Tätigkeit schon vor Jahren so. Ralf
Ralf G. schrieb: > In solchen Fällen hat unser Chef bzw. dessen Chef dann nämlich einen > Anruf "von oben" bekommen Und "von oben" hat sich für Kunden interessiert die Stückzahlen unter 100000 kaufen? Vermutlich haben sie den wichtigen Kunden einfach eine reparierte DLL per Email geschickt, Thema erledigt. Ralf G. schrieb: > Ich verstehe es besonders deshalb nicht, weil die Lösung bereits seit > Jahren bekannt ist und die Korrektur in wenigen Sekunden erledigt wäre Naja Ticket anlegen, Planungsmeetings, Scrum Punkte Poker usw. dauert halt... Ralf G. schrieb: > Die nötigen Tests laufen doch heute normalerweise automatisiert ab. Sehr optimistisch! Die "Tests" haben den Fehler ja auch nicht gefunden...
Niklas G. schrieb: > Und "von oben" hat sich für Kunden interessiert die Stückzahlen unter > 100000 kaufen? Um Stückzahlen ging es da nicht. Allerdings waren die Nutzer der in unserem Auftrag entwickelten Software fast alle VIPs. Wenn da einer hustete wackelte manchmal das Gebäude ;-) Ich erinnere mich, dass nicht alle für die Probleme der IT Verständnis hatten und ich mal eine Abhandlung darüber schreiben musste, wie eine bestimmte Software die Passwörter verwaltet, weil ein Nutzer mit den dadurch bedingten Einschränkungen nicht klar kam. Niklas G. schrieb: > Sehr optimistisch! Die "Tests" haben den Fehler ja auch nicht > gefunden... Gut, den entsprechenden Test dafür müsste man dann vielleicht noch schreiben bzw. anpassen. Ralf
Harald K. schrieb: > Jens B. schrieb: >> Und wie hast Du das festgestellt? > > Hat er doch geschrieben: > > Ralf G. schrieb: >> Wie ich mit meinem MSO sehen kann Ja, wer lesen kann. peinlich
Ralf G. schrieb: > Um Stückzahlen ging es da nicht. Allerdings waren die Nutzer der in > unserem Auftrag entwickelten Software fast alle VIPs. Sind nicht VIPs äquivalent zu "Leute mit Stückzahlen"... Bei Halbleiterherstellern ist man nur VIP wenn man mindestens 1E5 p.a. kauft...
Thread beobachten
Seitenaufteilung abschaltenBitte 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.