Hallo, ich habe bisher mit sehr gutem Erfolg vier Platinen mit dem FT232RL im Laufe der letzten zwei Jahre erstellt und im Dauereinsatz. Bei der letzten Platine habe ich beim Testen festgestellt, nach 30 - 120 Sekunden kommt es zu Wartezuständen von 40 bis 90 Sekunden. Danach kann es wieder 30 - 120 Sekunden dauern bis der näste Hänger sich einstellt. Bei den anderen Schaltungen konnte ich dies noch nicht beobachten. Als Steuerprogramm habe ich VB.NET 2008 unter XP mit aktuellem FTDI -Treiber. Das Programm durchläuft alle 500-800 ms eine Schleife. Folgende Funktionen werden verwendet. FT_SetDTR FT_Purge FT_Read FT_Send Der Hänger tritt am häufigsten beim FT_Purge auf, er wurde auch beim FT_SetDTR beobachtet. Bislang wurde er nicht beim FT_Read oder FT_Write gesehen. Hat jemand eine Idee? Gruss Klaus.
Ich habe folgendes Problem festgestellt, wenn ich kontinuierlich Daten vom µC zum FT232RL und dann zum PC sende, dann sendet mir der FT232RL keine Daten vom PC zum µC. Das Problem tritt auf bei Baudraten >9600
@ Thomas (Gast) >Ich habe folgendes Problem festgestellt, wenn ich kontinuierlich Daten >vom µC zum FT232RL und dann zum PC sende, dann sendet mir der FT232RL >keine Daten vom PC zum µC. Wie hast du das festgestellt? Oszi an den Pin gehängt? > Das Problem tritt auf bei Baudraten >9600 Ich hoffe du verwendest einen passenden Quarz am uC. MFg Falk
Hallo Thomas, ich sende und empfange mit 2400 Bit/s vom FT232RL zum MSP430F2013. Wie gesagt bisher ohne offensichtliche Probleme. MSP430-seitig treten hier keine Probleme auf. Erstens habe ich da ein Timeout von 1s programmiert und zweitens, mein VB.NET Programm steht bei einem FT_Purge. Der Befehl sollte nichts mit der anderen Seite, dem MSP430F2013 zu tun haben. Die Spannungsversorgung läuft nicht über USB, sondern extern. Beim USB-Kontakt wird der FT232RL auch resetet. Gruss Klaus.
ja,ja, der FT232RL. Ich hatte(hab?)folgende Probleme beim Betrieb über virtuelles Comport: 1.)Schirm der USB-Buchse nicht auf GND gelegt, Resultat: beim ein oder ausschalten der Schreibtischlampe stand die Übertragung. Denke, der Chip ist recht empfindlich auf Störungen und blockiert dann. 2.Nachdem obiges behoben war,zeigte sich im Dauertest, daß es in 24h bei rund 1GB Daten so 7-8 mal vorkam, daß Daten verlorengingen (waren geblockte Daten). Das Problem hab ich bis heut nicht gefunden, interessanterweise ist es beim Kunden nie aufgetreten.Ich vermute am ehesten ein Windows Problem im Zusammenspiel mit der in Lab-Windows geschriebenen Applikation,aber es ist auch nicht ausgeschlossen, daß es am FT232 liegt. Wär interessant, wer noch seltsame Verhaltensweisen dieses Teils kennt. Grüße Gebhard
Hallo Gebhard, ich dachte auch schon daran, es könnte am FT232RL selber liegen. Ein Fehlercode liefert der FT232RL auch nicht zurück. Ich werde mich erst Freitag wieder mit dem Problem beschäftigen können. Dann nehme ich mal eine andere Platine und teste somit PC und Treiber. Gruss Klaus.
@Falk: Anfang dachte ich es sei ein Problem mit der Lib von Peter Fleury, später stellte ich fest, dass der FT232RL die Daten nicht ausgibt. Siehe auch diesen Thread Beitrag "Peter Fleury Uart Lib: Problem mit Rx-Interrupt und getc()" Ich habe sogar extra den kompatibelsten Quarz mit 18,432MHz ausgesucht. ;-) @Geb: Der Schirm liegt bei mir auf Masse/GND. @Klaus: Ich habe und werde keinen speziellen Quellcode schreiben, der explizit den FT232RL ansteuert, bei mir muss das über den virtuellen COM-Port funktionieren. Ich habe zum Testen HTerm benutzt.
Hallo, ich bin eigentlich nicht so recht weitergekommen. Die beschriebenen Hänger treten sporadisch wie beschrieben beim FT_SetDTR FT_ClrDTR FT_Purge auf. Also Funktionen die nicht gerade anspruchvoll sind. Es wird sogar ein FT_Error geniert, IO-Error. Das IC hat den Stempel 0705-A und ist erst seit ein paar Wochen von Reichelt gekauft worden. Errata´s wie bei TI bietet FTDI nicht an. Die lassen sich nicht in die Karten schauen. Das man jetzt noch Chips aus 2007, 5.KW, verkauft ist schon etwas verdächtig. Ich hoffe nicht, dass Reichelt hier besonders günstige Ladenhüter erstanden hat. Nachdem ich wirklich alles geprüft habe bleibt eigentlich nur der Verdacht das der FT232RL ein Problem hat. Ich trau mich aber noch nicht so recht daran den TSSOP 28 auszulöten. Gruss Klaus.
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.