Mahlzeit, ich schreibe aktuell eine Software (C++, Linux, D2XX-Treiber), die per USB Daten von einem AVR empfängt. Wenn ich jetzt wären des Betriebes den FT232R abstecke und wieder anstecke, bekommt das Programm Probleme, weil die übertragenen Daten nicht mehr stimmen. Kann ich ressourcenschonend innerhalb der Schleife, in der ich die Daten lese, feststellen, ob der Chip noch angesteckt ist? Die Überprüfung von FT_GetStatus hat keinen Effekt. Da wird, trotz disconnect, FT_OK ausgegeben. thx4hlp
>Wenn ich jetzt wären des Betriebes den FT232R abstecke und wieder >anstecke, bekommt das Programm Probleme, weil die übertragenen Daten >nicht mehr stimmen. Kein Wunder. Ziehst du das Kabel von deiner Festplatte auch einfach so raus?
Wenn meine Platte Hotplug-fähig ist, dann ja. Und USB ist Hotplug-fähig, wenn ich mich nicht irre.
holger schrieb: >>Wenn ich jetzt wären des Betriebes den FT232R abstecke und wieder >>anstecke, bekommt das Programm Probleme, weil die übertragenen Daten >>nicht mehr stimmen. > > Kein Wunder. Ziehst du das Kabel von deiner Festplatte > auch einfach so raus? Was soll den so eine sarkastische Antwort? USB wir nunma als Plug&Play was viele auch als UnPlug&GoAway sehen. Und wenn man Software entwickelt, muss man nunmal auch immer an DAUs denken und so viele potentielle Fehlerquellen wie möglich ausschliesen. Überleg mal wenn du während der Fahrt in einem Auto den Zundschlüssel ausversehen ziehst, Lenkradschloss geht rein du baust nen Unfall bei 120 und der Airbag löst nicht aus. Was sagt dann der Hersteller der Versicherung?
>> Kein Wunder. Ziehst du das Kabel von deiner Festplatte >> auch einfach so raus? >Was soll den so eine sarkastische Antwort? Genau so war sie auch gemeint;) Verbindung unterbrochen? Timeout benutzen. Nach Timeout versuchen neu zu verbinden. Kommt nix? Dann aufhören.
holger schrieb:
> Verbindung unterbrochen?
Das war genau die Frage, wie das festzustellen ist.
Ich stelle fest, einmal eine Antwort, die unnütz ist, beim zweiten mal
eine, die lediglich meine Frage wiederholt.
Was sollen mir deine Posts jetzt bringen?
Wenn du nicht helfen kannst/willst, solltest du nicht die
Übersichtlichkeit hier absichtlich verringern indem du unnützes postest.
Danke.
>> Verbindung unterbrochen? >Das war genau die Frage, wie das festzustellen ist. Frage senden. Kommt keine Antwort, Frage nochmal senden. Kommt keine Antwort Frage nochmal senden. Kommt keine Antwort Frage nochmal senden. Irgendwann aufhören die Frage zu senden weil es keinen Sinn mehr macht? Verbindung unterbrochen. Versuchen Verbindung komplett neu aufzubauen. Kommt nix, dann abbrechen.
Und welche Frage soll ich senden, wenn ich Daten empfange? Genau das hab ich im ersten Post geschrieben. Wenn der µC auf keine Daten wartet, kann ich dem senden, was ich will, der wird nie antworten. Trotzdem danke für deine Mühe, ich hoffe aber trotzdem darauf, dass jemand antwortet, der meine Frage gelesen hat.
Na dann mach doch einfach das der uC Daten empfängt, dafür ist ja schlieslich ein Empfangs Interrupt da. PC mit FT sendet Ping uc sollte Pong antworten. Antwortet er nicht dann Error
Multi schrieb:
> Wenn ich jetzt wären des Betriebes den FT232R abstecke
Wie denn, was denn? Trennst du im Betrieb den FT232 vom µC oder meinst
du nur das Herausziehen des USB-Steckers?
Was hältst du von der simplen Methode, die am USB-Anschluss anliegende
Versorgungsspannung zu überwachen? Wenn keine Spannung vorhanden ist,
dürfte entweder die Verbindung getrennt worden sein, oder der Host ist
stromlos.
Gruß,
Magnetus
>Trotzdem danke für deine Mühe, ich hoffe aber trotzdem darauf, dass >jemand antwortet, der meine Frage gelesen hat. Das habe ich. >Kann ich ressourcenschonend innerhalb der Schleife, in der ich die Daten >lese, feststellen, ob der Chip noch angesteckt ist? Ja, wenn für eine festgelegte Zeit nix mehr kommt, dann ist die Verbindung tot. Sowas nennt sich Protokoll. Wenn du eine Verbindung überprüfen willst, dann mußt du Daten hin und her senden. Kommen keine Daten mehr dann ist der Stecker raus.
@Matthias ich werde nicht die Firmware ändern, da ist in diesem Fall völlig indiskutabel und IMO unsinnig @Magnetus ich stecke den USB ab. Und ich dachte mit meiner Aussage, ich würde unter Linux und dem D2XX-Treiber arbeiten, würde klarmachen, dass ich vom PC aus überwachen will ob der FTDI abgesteckt wird. Nochmal, um alle klarheiten zu beseitigen ;) AVR -> FTDI -> PC AVR sendet ausschliesslich Daten und empfängt gar nichts (das bleibt auch so) PC empfängt die Daten in einer Schleife und verarbeitet diese. Wenn nun der USB-Stecker abgezogen wird, soll das die Software auf dem PC erkennen. Da dummerweise FT_Read und FT_GetStatus weiterhin FT_OK liefern, klappt es damit nicht. Die Schleife läuft weiter und nach ein paar sekunden bricht das Programm mit nem Speicherzugriffsfehler ab, weil irgendwelche seltsamen Daten eingelesen werden, die entweder vom USB-Puffer oder dem D2XX-Treiber kommen, in jedem Fall sind die unerwünscht. Um den Programmabsturz zu vermeiden will ich eben feststellen, wann die USB-Verbindung unterbrochen wird. In diesem Fall wird die Routine aufgerufen. die am Anfang feststellt, ob ein Chip angeschlossen ist. Ich hoffe, jetzt ist wirklich alles klar und mein Problem eindeutig beschrieben. Und danke an alle, die helfen oder es zumindest versuchen.
holger schrieb: > Ja, wenn für eine festgelegte Zeit nix mehr kommt, > dann ist die Verbindung tot. Und da liegt das Problem, es kann sein, dass stundenlang keine Daten kommen, da die von externen Sensoren abhängen. Timeout fällt aus.
Gibts in der D2xx.DLL nicht ne Funktion, die das überwacht? FT_RESET/FT_RESCAN/FT_CYCLEPORT, irgendeine dieser Funktionen ist glaub ich dafür gedacht, ein Device wieder zu erkennen. Ralf
Ich hatte ähnliche Probleme. Wenn mein Programm gestartet wird und der FT232 noch nicht angeschlossen war, dann frage ich im Sekundentakt mit GetFTDeviceCount() ab ob Geräte angeschlossen sind. Wenn ich jetzt den FT232 an den USB Port anschließe, dann bekomme ich von GetFTDeviceCount() eine 1. Meine anschließenden GetFTDeviceDescription() und Open_USB_Device_By_Device_Description() lösen aber trotzdem ein "Invalid Handle" Error aus. Abhilfe brachte eine Abfrage: If GetFTDeviceDescription(a)<> FT_OK then abort; Das Stecker ziehen funktioniert bei mir jetzt ebenfalls ohne Fehlermeldung. Vor dem Read Befehl steht bei mir: If Get_USB_Device_QueueStatus() <> FT_OK then .... Und das Funktioniert bei mir. (WinXP, Delphi, FT232RL, Treiber von der Homepage) P.S. die Für Delphi mitgelieferte D2XXUnit.pas enthällt folgende Funtkionen: Function Get_USB_Device_QueueStatus : FT_Result; Begin Result := FT_GetQueueStatus(FT_Handle,@FT_Q_Bytes); If Result <> FT_OK then FT_Error_Report('FT_GetQueueStatus',Result); End; Function GetFTDeviceDescription( DeviceIndex : DWord ) : FT_Result; Begin Result := FT_ListDevices(DeviceIndex,@FT_Device_String_Buffer,(FT_OPEN_BY_DESCRIPT ION or FT_LIST_BY_INDEX)); If Result = FT_OK then FT_Device_String := GetDeviceString; If Result <> FT_OK then FT_Error_Report('GetFTDeviceDescription',Result); End; Die Zeilen mit dem Errorreport musste ich jeweils auskommentieren, denn sonst wird die Fehlermeldung angezeigt befor ich darauf reagieren kann. Ich kenne mich unter Linux nicht aus, denke aber es wird ähnlich sein.
Multi schrieb: > @Matthias > ich werde nicht die Firmware ändern, da ist in diesem Fall völlig > indiskutabel und IMO unsinnig Ja wenn du so uneinsichtig bist, kann man dir eben nicht helfen. Eine einseitige Datenübertragung ohne Handshake, die auch noch beliebig lange ruhen kann, ist unsafe by design, sowas darf einem Entwickler einfach nicht unterlaufen. Ohne bidirektionale Übertragung ist das Problem nicht lösbar, egal mit welcher Übertragungsstrecke. USB-Trennung ist nur ein Teilproblem, für Hotplug muss eben auch die Software hotplugfähig sein, und das ist sie nicht. Natürlich schreist du jetzt los, dass dir das keine Hilfe ist. Genauso ist es, war auch meine Absicht. Was anders kannst du nicht erwarten, wenn du jeden vernünftigen Vorschlag als völlig indiskutabel bezeichnest. Es mag ja sein, dass du am µC schlicht nichts ändern kannst, aber dann kannst du eben auch das Problem nicht sachgerecht lösen. Gruss Reinhard
>hne bidirektionale Übertragung ist das Problem nicht lösbar
Ich kenne einige Sensoren, die nur in eine Richtung senden und die sind
auch "Sicher". Vielleicht sollte man die Daten aber in einen Rahmen
packen, damit der PC besser erkennen kann ob alles stimmt. Ähnlich wie
bei GPS Modulen, die reden auch einfach so los ohne gefragt zu werden.
Matze schrieb: >>hne bidirektionale Übertragung ist das Problem nicht lösbar > > Ich kenne einige Sensoren, die nur in eine Richtung senden und die sind > auch "Sicher". Vielleicht sollte man die Daten aber in einen Rahmen > packen, damit der PC besser erkennen kann ob alles stimmt. Ähnlich wie > bei GPS Modulen, die reden auch einfach so los ohne gefragt zu werden. Die reden auch dauernd (immer das gleiche), und es ist nicht schlimm, wenn man was verpasst. Das scheint beim Fragesteller anders zu sein, sonst hätte er ja kein wirkliches Problem. Gruss Reinhard
Der Fragesteller wird auch Daten verlieren wenn er den Stecker zieht. Er möchte nur das der PC erkennt wenn der Sensor abgezogen wurde, weil er dezeit (so wie ich es verstanden habe) weitere Daten vom USB Port lesen kann und nicht weis ob es zufällige Daten sind, oder sie von seinem Sensor stammen. Das kann man umgehen wenn man einen Rahmen drum macht. Startbyte+Daten+Stopbye+CRC. Wenn die empfangenen Daten nicht in den Rahmen passen, dann ist das Gerät abgezogen. Oder man nutzt die Get_USB_Device_QueueStatus() Funktion, bei mir funktioniert es so.
Reinhard Kern schrieb: > Die reden auch dauernd (immer das gleiche), und es ist nicht schlimm, > wenn man was verpasst. Das scheint beim Fragesteller anders zu sein, > sonst hätte er ja kein wirkliches Problem. Ich habe das Problem, dass die Software auf dem PC mit nem Buffer-Überlauf abbricht. Ob ich beim ziehen des Steckers Daten verliere, geht mir sonstwo vorbei. Ich hab auch nirgends geschrieben, dass der Datenverlust irgendein Problem darstellt. Du kannst mir aber gerne erklären, wie ich 1-Wire-Sensoren dazu bringe, eine Zweiwegekommunikation zu fabrizieren. Dummerweise geben die Mittel für das Projekt nicht her, eigene Sensoren entwickeln zu lassen nur damit dieses in zwei Richtungen Daten austauschen. Offensichtlich ist das auch nicht nötig, sonst würde niemand diese, deiner Aussage nach, unsicheren Sensoren nutzen. Ich gehöre somit zu den vielen tausenden uneinsichtigen, die eine einseitige Datenübertragung nutzen, weil es technisch nicht anders lösbar ist. Schande über mich! BTW: der Controller am USB redet auch ständig das gleiche, nur nicht pausenlos. Es gehen bei einer Unterbrechung der Übertragung maximal 3 Byte verloren. Also bitte nicht irgendwas in meine Posts reininterpretieren, was da nicht steht, das bringt mich und auch andere keinen Schritt weiter. @Matze danke, das probier ich mal. @Ralf danke, schau mir die Funktionen an. Da wird hoffentlich was dabei sein und ich kann das Problem jetzt lösen :)
Wenn der Sensor einfach etwas vor sich hin plappert, kommt es nicht so genau darauf an, ob man einen Messwert erwischt oder nicht. Der Treiber wird eine exception werfen wenn der USB gezogen wurde, dh man kann diese Exception abfangen und nachher wieder neu aufsetzen.
Multi schrieb: > Du kannst mir aber gerne erklären, wie ich 1-Wire-Sensoren dazu bringe, > eine Zweiwegekommunikation zu fabrizieren. ... > BTW: der Controller am USB redet auch ständig das gleiche, nur nicht > pausenlos. Es gehen bei einer Unterbrechung der Übertragung maximal 3 > Byte verloren. Also bitte nicht irgendwas in meine Posts > reininterpretieren, was da nicht steht, das bringt mich und auch andere > keinen Schritt weiter. Hallo, das entspricht nun aber garnicht mehr deiner Beschreibung von 23:57 und 00:00 Uhr, da war noch von einem AVR als Sender die Rede. Und wenn ein Sensor Daten schickt, manchmal aber auch stundenlang nicht, finde ich das nach wie vor unsicher, egal wer das verbrochen hat - du weisst ja dann stundenlang nicht mal, ob da draussen überhaupt noch ein Sensor ist, auch ganz ohne Leitungsstörung. Ganz abgesehen vom Sachproblem, ich finde es auch nicht in Ordnung, dass du so patzige Antworten jedem gibst, der dich auf Unstimmigkeiten hinweist, schliesslich will dich niemand hier fertigmachen, aber du stösst genau die Leute vor den Kopf, die dein Problem am genauesten verstanden haben. Ich bin da ja nicht der Einzige, das fängt schon mit den ersten Posts an. Gruss Reinhard
unverschaemtes Verhalten...der sitzt wohl am Arbeitsplatz und der Chef hat ihn...
Die Antwort von Matze ist doch die Lösung. Natürlich kann man den FT232 auch mit einem nur sendenden AVR dafür auf Disconnect prüfen. Die Routinen sind im Treiber enthalten. Vor jedem Empfangen testen, ob das Device mit der Seriennummer noch vorhanden ist und dann einlesen. Steht alles gut in den Beispielen beschrieben. Ich nutze das unter VB6 + Windows XP seit einiger Zeit. Wie es mit den Linux Treibern aussieht, weiß ich nicht. Am PC nutze ich kein Linux.
Reinhard Kern schrieb: > das entspricht nun aber garnicht mehr deiner Beschreibung von 23:57 und > 00:00 Uhr, da war noch von einem AVR als Sender die Rede. Stimmt, allerdings besteht das Problem auch, wenn nur der nackte FT232 am Port hängt. Somit ist es zur Problemlösung völlig unwichtig welche Daten wie woher gesendet werden. Da das Betriebssystem erkennt, wann das USB-Kabel gezogen wird, ging ich davon aus, es ist kein Problem, das auch aus einem Programm raus zu überwachen. Ich will ja die Lösung nicht nur für dieses eine Projekt nutzen sondern auch für weitere. Meine Antworten sollten nicht patzig rüberkommen, wenn dem so ist, entschuldige ich mich. @lassativ ich bin mein eigener Chef und dieses Projekt Hobby. Da du nichts zum Thema beiträgst, halte ich deinen Post für unverschämt, weil er mir unwares unterstellt und völlig OT ist. @all Mit den Hinweisen hier werde ich das Problem noch lösen, ich hab schon nen Ansatz muss aber vorher noch anderes machen. Sobald ich den Code komplett hab, werde ich ihn hier für die Nachwelt posten :) Danke an alle, die geholfen haben.
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.