Hallo miteinander Ich beschäftige mich schon länger mit den FTDI-Chips und seit neustem auch etwas intensiver mit dem FTD2xx Treiber, um die Kommunikation zu beschleunigen und ebenfalls nicht immer den virtuellen Com-Port zu verwenden. Jetzt ist es mir schon oft passiert, dass ich beim PC-Programm ein grösseres Datenpacket (>100Bytes) gesendet habe, aber beim Brenner den MCU nicht vom Reset gelöst habe. Dann bleibt die ganze Software immer gleich hängen und "reagiert" nicht mehr. Die Library stellt eine Funktion (FT_GetStatus oder so ähnlich) zur Verfügung, wodurch ich eigenltlich die Rx und Tx Byte-Anzahl heraus lesen kann. Aber die Funktion wird nicht neu aufgerufen, wodurch ich ein neues Beschreiben des FTDI-Buffers überhaupt nicht verhindern kann. Wie könnte ich elegant solche Fehler abfangen? Da diese ja nicht nur passieren können, wenn ich den MCU im Reset halte, sondern wenn dieser sich irgendwie blockiert hat. Soweit ich weiss, basiert der FTD2xx Treiber auf dem Bulk-Protokoll, und ist ebenfalls asynchron. Aber wie ich jetzt solche Fehler feststelle und eventuell die Aktion unterbrechen könnte, habe ich bis jetzt noch nicht festgestellt. Besten Dank für die Hilfe MFG Patrick
Dein Problem ist etwas undeutlich (für mich zumindest). Was hat ein im Reset gehaltener Controller mit dem Buffer des FTDI-Chips zu tun? Wenn kein Hardware-Handshake verwendet wird, pustet der FTDI die Daten raus, egal ob die Gegenstelle bereit ist oder nicht. Und für die FTD2xx.DLL gibt's ja einstellbare Timeouts. Beschreib dein Problem bitte nochmal etwas deutlicher :) Ralf
Ok, ich will es mal versuchen: Ich verwende einen FT245 in Kombination mit einem dsPIC als "Empfänger". Der PIC ist fast immer über das ICD2 an den PC angeschlossen. Leider hat das ICD die Eigenschaft, die ich nicht ändern kann, dass der PIC nach erfolgreichem Programmieren weiterhin im Reset gehalten wird, bis ich ihn manuel daraus löse. Falls ich dies jetzt nicht gemacht habe, so wird vom FT245 nichts gelesen (parallel IO). Beim PC-Programm sende ich jetzt durchschnittlich 32kByte auf einmal. Dies passiert immer in dieser Art:
1 | ftStatus = FT_Write(ftHandle, TxBuffer, 9, &BytesWritten); |
2 | if (ftStatus == FT_OK) { |
3 | // FT_Write OK |
4 | } |
5 | else{ |
6 | // FT_Write Failed |
7 | } |
Wenn ich jetzt den PIC vergessen habe, aus dem Reset zu lösen, so passiert folgendes: Ich sende die 32kByte, und diese werden ohne Fehler in den FTD2xx Buffer geschreiben (FT_OK). Ab jetzt weiss ich nicht genau, ob nochmal die Funktion für das Senden aufgerufen wird. Mit Labels habe ich ermittelt, dass dies noch 0-3 mahl der Fall ist. Dann bleibt die Software hängen (vernebelter Bildschirm) -> "Die Software reagiert nicht mehr" Fehlermeldung wird angezeigt. Ich denke, dass hier ein Buffer-Overflow oder so stattfindet, denn anders als bei der RS232 Schnittstelle wird beim Parallelport des FT245 nichts ohne MCU ausgegeben. Und in den FTD2xx Dokumentation habe ich leider nicht vieles für solche Errors gefunden. Es kann auch sein, dass der Windows USB Zugriff einen Absturz verursacht. Nur möchte ich dies gerne vermeiden... Besten Dank für die Hilfe MFG Patrick
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.