ich möchte mit einem PC-Programm einen EEPROM AT25160B mit Daten beschreiben, um ein anderes Gerät zu parametrieren. Programm (Oberfläche) in vb.net (ist neu für mich) ist fertig, nun soll der EEPROM beschrieben/gelesen werden. Im Fundus habe ich einen Adapter PLM2232 (mit FT2232D) und ein Mini Development Board mit FT2232H.
Mit Hilfe von Beispielen und der FTDI-Doku habe ich mich soweit herangearbeitet, dass ich den entsprechenden Port A öffnen konfigurieren kann:
Funktioniert soweit, allerdings gibt es ein Problem beim Lesen der Daten vom EEPROM, hier werden immer nur 14 Byte gelesen, egal wieviele angefordert werden. Werden per Parameter <= 14 Byte angefordert, funktioniert das Lesen, bei mehr als 14 Byte kommt der Timeout zum Tragen.
Ich weiß hier nicht mehr weiter, auch das Herabsetzen der Baudrate auf 19600 bringt keine Änderung. FT2232D und FT2232H verhalten sich hier identisch. Ich bin mir recht sicher, dass ich irgendeinen Bock eingebaut habe und würde mich freuen, wenn ein Kundiger da unterstützen würde.
Danke für alle Hinweise,
Thomas
PS: Sollte Bedarf an Beschimpfungen bestehen, eröffne ich gerne einen zweiten Thread zum späteren Versenken.
Schuss ins Blaue (ohne irgendwie zu verstehen, was der Code macht): mehr passt nicht in ein USB-Paket rein als Antwort. Wenn du mehr lesen willst, musst du das aufteilen.
Der Code öffnet ein (vorher gesucht & gefundenes) USB-Device über den vom Betriebssystem vergebenen Locator, danach wird der FT2232D/FT2232H in den MPSSE-Modus versetzt, die SPI-Parameter eingestellt und Timeout/Laterncy-Parameter gesetzt.
Dann wird ein Lesepuffer deklariert und initialisiert und der Lesebefehl in den FT2232 geschrieben. Anschließend wird gelesen und dabei in den Timeout gelaufen.
FTDI meint, dass die USB-Übertragung in Stücken von irgendwas über 65.000 Bytes erfolgt, die sollten bei 14 gelesenen Bytes noch nicht erreicht sein.
Was spräche denn dagegen, dass du deinen EEPROM in kleineren Stücken
liest und schreibst, statt weiter gegen Windmühlenflügel zu kämpfen?
Hmm, eigentlich nix, aber da FTDI die Anzahl der zu lesenden Bytes mit dem Typ Int angibt, kann ich mir nicht vorstellen, dass das wirklich nur mit 14 Bytes (und dazu noch einer so dv-technisch krummen Zahl) funktionieren soll. Irgendwas habe ich da übersehen...
Jeder doofe Controller kann so einen SPI-EEPROM in ganzer Länge in einem Rutsch auslesen, da muss doch ein FT2232 wenigstens 64 Bytes am Stück lesen können.
Beim Schreiben wird das dann noch verrückter, da hat der EEPROM ja page-Grenzen und wenn da noch so ein Limit dazukommen sollte, wird es noch übler.
Jeder doofe Controller kann so einen SPI-EEPROM in ganzer Länge in einem
Rutsch auslesen, da muss doch ein FT2232 wenigstens 64 Bytes am Stück
lesen können.
Das Problem ist ja nicht der FTDI, sondern der USB. Der hat halt limitierte Paketgrößen. Die Library drunter muss also deine gewünschte Datenmenge aufteilen.
Beim Schreiben wird das dann noch verrückter, da hat der EEPROM ja
page-Grenzen und wenn da noch so ein Limit dazukommen sollte, wird es
noch übler.
Das ist natürlich wahr.
Ich habe es gerade mit Python probiert (pyftdi.spi), da kann ich problemlos mehr als 14 Bytes am Stück lesen.
Ist nun halt die Frage, an welcher Stelle bei dir das Problem entsteht bzw. was unter deinem vb.net drunter liegt.
Da liegt die FTD2XX_Net drunter, wie von FTDI angegeben.
Dann ist es möglicherweise ein Problem im Zusammenspiel dessen mit dem vb.net?
Unter pyftdi liegt einfach nur PyUSB und eine der möglichen libusb-Implementierungen, kein proprietärer Code von FTDI. Das haben wir bei einem früheren Projekt bereits ausgiebig auch unter Windows benutzt, um mit einem UWB-Transceiver von NXP zu reden.
Da liegt die FTD2XX_Net drunter, wie von FTDI angegeben.
Dann ist es möglicherweise ein Problem im Zusammenspiel dessen mit dem
vb.net?
Das weiß ich nicht, ich wollte nie tiefer in die FTD2XX_NET einsteigen und das Zeug nur benutzen, um Anwendern eine einfache Möglichkeit zur Parametrierung zu geben.
Ich werde da in den nächsten Tagen mal mit dem LA drangehen und versuchen herauszufinden, ob schon der Lesevorgang des EEPROMs scheitert, oder die Datenweitergabe über den FT2332 und USB das Ganze verstümmelt.
Wäre eventuell auch denkbar, wenn sich hier absolut keine Lösung oder Jemand mit einschlägiger Erfahrung finden sollte.
Mit vb kann ich einigermaßen umgehen und bin froh, die Funktionen und die Logik der Elemente der Oberfläche erfolgreich umgesetzt zu haben, bei Python würde ich wieder bei Null anfangen müssen - ich habe damit noch nie eine Oberfläche programmiert.
bei Python würde ich wieder bei Null anfangen müssen - ich habe damit
noch nie eine Oberfläche programmiert.
Wenn es nicht gerade mit kommerziellen Interessen (und Lizenzkosten) in Konflikt gerät, kann ich da PySide (Qt-Anbindung in Python, die von Qt selbst bereitgestellt wird) empfehlen. Damit bekommt man relativ schnell GUIs hin, die auch noch plattformunabhängig (Win, Mac, Unix) sein können.
Schau dir mal die Application Note AN_135 FTDI MPSSE Basics auf der FTDI Seite an. Ist zwar nicht in vb geschrieben, aber der Ablauf sollte ähnlich sein. Im Abschnitt 5.2 "Configure FTDI Port For MPSSE Use" steht unter anderem die Zeile
Wenn es nicht gerade mit kommerziellen Interessen (und Lizenzkosten) in
Konflikt gerät, kann ich da PySide (Qt-Anbindung in Python, die von Qt
selbst bereitgestellt wird) empfehlen.
Danke für die Empfehlung, ist kein kommerzielles Projekt und betrifft bestenfalls 10 User. Ich behalte das mal im Hinterkopf, wenn der eingeschlagene Weg eine Sackgasse werden sollte.
Schau dir mal die Application Note AN_135 FTDI MPSSE Basics auf der FTDI
Seite an. Ist zwar nicht in vb geschrieben, aber der Ablauf sollte
ähnlich sein. Im Abschnitt 5.2 "Configure FTDI Port For MPSSE Use" steht
unter anderem die Zeile
So eine Zeile finde ich in deinem vb code nicht. Da wird die
Transfergröße fürs Schreiben und Lesen festgelegt.
Danke für den Hinweis, ich bin gerade beim Stöbern in der FTD2XX_NET, da finde ich nichts Derartiges. Da sollte es ja einen default-Wert geben. Auf der anderen Seite schlägt da mein Unwissen über die USB-Internas zu; ich kann mir nicht vorstellen, dass die Paketgröße den Nebeneffekt hat, dass nach einem Paket die Übertragung eingestellt wird. Ein Timeout von 5000 ms sollte ja ausreichen, dass weitere Pakete übertragen werden.
Je kleiner die Paketgröße, je größer der Anteil des Overheads an den übertragenen Daten, das leuchtet mir noch ein, aber ein Abbruch?
Auf der anderen Seite schlägt da mein Unwissen über die USB-Internas zu;
ich kann mir nicht vorstellen, dass die Paketgröße den Nebeneffekt hat,
dass nach einem Paket die Übertragung eingestellt wird. Ein Timeout von
5000 ms sollte ja ausreichen,
Du hast vollkommen falsche Vorstellungen von USB...
Die Paketgröße ist bei Fullspeed(1.1) und Bulk fest 64 Bytes pro Transfer. Bei Highspeed(2.0) wären es übrigens 512 Bytes. Auf diese Packet Size hast du aber von der Anwendungsseite keinen Zugriff und musst das auch nicht beachten. Es ist immer Aufgabe des Treibers einen Usermode Read in entsprechende Häppchen aufzuteilen. Kann ein Device einen Bulk In nicht mit Daten beantworten oder weniger als 64 Bytes liefern, so sieht USB vor mit einem Short Packet die Übertragung zu beenden. Ein Timeout kommt nur wenn nach Ablauf der Timeoutzeit immer noch nichts geliefert wurde.
Ich kenn mich mit Basic und im speziellen mit NET nicht aus, aber für mich sieht das das Read nach einem normalen gekapselten Readfile des Win OS aus.
Nachdem der Versuch mit der FTD2XX_Net leider an irgendeiner Befindlichkeit der read-Funktion gescheitert ist, habe ich das Ganze jetzt mal auf die libmpsse.dll umgestellt. Geht auch nicht ohne Weiteres, da vb.net diese DLL nur über Umwege ansprechen kann. Dank ChatGPT wurde in kürzester Zeit ein Wrapper gebaut. Das ganze Konstrukt funktioniert und ich kann jetzt die gewünschten 96 Byte an einem Stück lesen und in einem Puffer ablegen, weiter bin ich noch nicht.
