FT232R auf disconnect überwachen

>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.

>> 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.

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.