Übertragungsproblem FT233RL keine Anfängerfragen :-)

So!! nach eigener Fehlersuche traue ich mich, nach dem ich mich ein Jahr ohne zu Fragen durchgeackert habe auch eimal eine Frage zu stellen.
Sie ist zwar recht ungewöhnlich aber überfordert mich gerade einfach etwas.

Ich habe mich auf ein Projekt eingelasse, einen Funktionsgenerator, 2 Digitale
und 2 Analoge Eingänge, sowie zwei Digitale Ausgänge zu bauen und zu programmieren(Assembler). (paralell zu meiner Diplomarbei, wie dumm muss man sein?)
Hierfür verwende ich einen Atmega16 (SMD) und einen FT232 RL mit dazugehöriger Schaltung.
Die hauptaufgabe des Geräts besteht darin die Eingelesenen Werte bzw. aus dem EPROM gelesene Funktionen via RS232 und dann via Usb an den PC zu übertragen.
Ich habe 3 Prototypenstadien, versucht und korrigiert bis das Gerät nach meinen Vorstellungen funktionierte.
Dann habe ich 5 Geräte aufgebaut und ausgibig getestet. d.h. jeden Modus in jedem Gerät durchgespielt. Alle 5 haben einwandfrei funktioniert.
(Datenrate 38400 baut / 6 Mhz aus ft232)
Jetz kommt das Kuriose.
Um die Dinger abzugeben musste ich noch eine Dokumentation erstellen was eine Woche dauerte. Während dieser Woche Fuhr ich sie in meinem Kofferaum "spazieren" (ohne fette Endstufe o.ä.) danach hab ich noch mal eins testen wollen und es kam nur noch Datensalat heraus. und zwar aus allen 5 der selbe. Das riecht verdächtig nach falscher Übertragungsrate hab ich mir gedacht und sie an 3 Pcs getesten, überall das selbe.
jetzt habe ich das Programm mit PonyProg noch mal verifiziert , es passt noch. Was könnte sich verändert haben??????????????????

Ich finde keine logische Erklärung dafür und lade daher zum "fantasieren" ein. Was Hat sich verändert????????

mfg Uwe
rechtschreibfehler bitte ich zu entschuldigen hab meinen Frust etwas ertränkt

:-b .

hallo uwed!

toll dass es noch andere "nachtfalter" gibt ;-)

ich habe zwar noch nie mit dem FT232RL gearbeitet, aber mir das datenblatt mal durchgelesen.
ich nehme mal an, die 6MHz bekommst du aus dem OSCO Pin, indem du den 12MHz takt halbierst.
kannst du das mal nachmessen, ob da wirklich 6MHz rauskommen, oder ob sich die interne programmierung des FT232 verabschiedet hat und da jetzt 12MHz oder mehr rauskommen?

MfG

Schoko

Morgen Schokohoernl.
Der Takt ist mit dem Programm Mprog von Ftdi einstllbar (echt gutes Programm) wenn ich den Chip auslese bekomme ich noch die Eistellungen wie ich sie programmiert habe, saran liegts also nich, messen kann ich leider nicht , da ich noch kein oszi habe (kommt aber vom ersten Gehalt)
Trozdem danke.
Noch eine kleine Frage. Hab gerade gesehen dass ich im Basic forum gelandet bin, kannst du mir sagen wie ich den Tread ins assembler verschiebe ?
Uwe

Nachtfalter? Das kann ich auch! ;-)
Zu deinem Problem: Hört sich komisch an! Das die Programmierung sich offensichtlich nicht verändert hat, muss es an der Hardware liegen. Kann sich irgendwas gelöst haben? Wobei das auch unwahrscheinlich ist... Hm, schwierig!
Einfach mal neu programmiert, alles überscvhrieben?

Hi,
hatte mal ein seltsames Phänomen mit nem M8 mit Bootloader und einer scheinbar etwas unstabilen Versorgungsspg und zu niedrigem BODLevel.
Es kam sporadisch vor, dass die Fusebits beim nächsten Start verkurbelt waren und somit die Clockfrequenz nicht mehr passte.
Lies mal die Fuses aus und kontrollier mal, ob sie (noch) richtig stehen.

Danke mal für die Tips, es hat aber alles nichts geholfen.
Die Fuse Bits passenund die Versotgungsspannung ist auch stabil, da ich sie direkt über den USB Port bezeihe. Neu programmiert hab ich ihn auch schon.
Ich hab mal mein UART testprogramm draufgemacht (internen Takt 600 Baut)
um die beeinflussing durch den externen Takt auszuschließen. Ich empfange auch einen String der aber 2 Byte zu Kurz ist jedoch binär betrachtet dem Sollstring sehr ähnlich ist. (ist subjektiv 1er und 0 er sind ja immer ähnlich).
Fehler interne Frequenz.... aber 600 Baut gehn ja normal gut, geht ja bis max 4800.
Meine Experimentierplatine angehängt funktioniert, also kanns am Terminalprogramm auch nicht liegen. die einzige Erklärung wäre, dass der FT232 bzw. der Virtuell Com Port Treiber die Bautrate verzerrt (was eigentlich ja nicht sein dürfte aber ich bin Ratlos). Ich verwende HTerm und habe mal in Wiki geschaut ob es Terminalprogramme gibt, die Autobauting beherschen, und zwar jeden wert, nicht nur die Standardraten. leider ohne erfolg. Kennt jemand eins ?.
Wenn das nicht funktionier muss ich nächste woche mal Versuchen, direkt am Atmega TxD abzugreifen um zu sehen in welchem Chip der Fehler auftritt.

Für weitere Tipps und sind sie noch so verrückt wäre ich Dankbar

mfg Uwe

Hast du mal einen Schaltplan? Wird einfacher dann, wenn man die Schaltung vor Augen hat.

Sicher doch hängs als Bild an, wenn es als Eagel datei lieber ist mach ich das auch noch. (hoffe es klappt).
Den Programmcode häng ich auch an, aber meiner Meinung nach dürfte es an dem nicht liegen. (wenn sich jemand sie 12 Seiten antun will).
Der USB teil ist von weitgehend von Jürgen Woetzel http://www.avr-projekte.de/index.htm übernommen.
Der Pull UP für Reset ist nicht aud dem Layout er hängt zwischen den 2 Vias eins beim Poti und eins beim Elko unterm Mega.
Der Schaltpan sieht villeicht nicht so professionenn aus, aber ich studiere auch Maschinenbau und hab mir alles so beibringen müssen.
(Und auf das SMD Layout war ich als es noch gieng recht stolz ](*,) )
Uwe

PS: hab im FAQ nicht gefunden wie ich diesen Beitrag ins Assembler oder Elektronif Forum verschieben kann, Auserdem sollte der Chip FT232 heißen, geht das irgendwie zu ändern.

Hab mal gegooglet nach einem Terminal, aber auch nichts gefunden... Der Schaltplan ist aber echt fies, hast du mal die Tests von Eagle durchgeführt? Ob da alle Verbindungen stimmen bezweifle ich... Den AVR solltest du voll beschalten, alle Supply-Pins (AGND etc) sollten verbunden sein. Ist das richtig, das kein Quartz in der Schaltung vorkommt? Die grünen Punkte an den Bahnen im Schaltplan sin eigentlich immer da, wo sich drei oder mehr Bahnen berühren, wenn eine Bahn nur an einen Pin angeschlossen wird, ist dor kein Punkt. Und wenn Bahnen verbunden sein sollen, ist dort ein Punkt. Der Reset des AVR sollte mit einem 10k Widerstand definiert gehalten werden und auf Tastendruck wird der Reset-Pin an VCC geschaltet. Das dass mal funktioniert hat ;-)
Soviel erstmal dazu, vielleicht fällt mir noch was ein.

Fangen ich mal von oben an. Das Chaos 3 Gründe
1. Ich bin Eagel noch nicht ganz fit da ich bisher auf Lochraster gearbeitet
habe.
2 ich bin ein Schlamper (wichtiger Grund :-b )

3. Eigentlich sollt nur der FT mit dem Mega und dieser mit dem Dipschalter verbunden werden und einen Funktionsgenerator darstellen. Und dann gings vom Proff los weiter könnt mer das nicht noch und das......

OK das mit den Supply pins klingt logisch, ich löt aber vorerst keine 5 Neuen zusammen, ich versuch sie mal mit litze zu Verbinden.
Wieder meine alte Verwirrung "Die dinger sind schon fehlerfrei gelaufen"
Die Tests in Eagel hab Ich nicht gemacht "du meinst wegen der vielen Luftleitungen ?" ich hab in Hardware getestet.
Eagel ist in dem Stück manchmal aber auch etwas "uneinsichtig" wenn ich an meinen manuell gezeichneten Gnd Rahmen eine Luftlinie von Gnd verbinden will, nimmt er sie nicht. Wahrscheinlich mein Fehler.
Nein es gibt keinen Quarz, der FT hat einen programmierbaren Clock ausgang (48/24/12/6 Mhz) ich hab 6 gewählt.
Die Punkte hab ich z.t mit absicht manuell reingemacht wenn Eagel es nicht gleich erkennen wollte wenn ich was geändert hab (Hassanfall).
Wie gesagt wenn ich meine Diplomarbeit nicht machen würde, würd ichs noch ordnen aber ich wills nur noch zuende bringen. Auserdem kenn ich mitlerweile fast jeden pin und jede bahn auswendig.
Das mit dem Wiederstand ist bekannt und so umgesetzt, sieht man nur nicht im Schaltplan (Reset funktioniert auch wunderbar).
Ach ja und das "abgefressene" Ende an AREF kommt noch aus der zeit als ich mit externen Referenzspannung arbeiten wollte, Der FT hatt sie aber so verrauscht dass ich auf interne umgestiegen bin.
Muss dann doch mal zu den FH Elektronikern und das mal mim Oszi anschauen #-o die finden sicher was tolles zu lästern.
Naja ich danke mal für die mühe, villeicht hat ja noch jemand eine Idee.
Ich werd mal ein bild machen um jegliche bedenken auszuräumen. Denkst du ich löt 400 SMD pins an und schau nach Brücken .... ohne zu wissen das das Ganze prinziiell funkioniert. :-k (hat).
nicht beleidigt sein der Zynismus schlägt langsam durch.

Uwe

Bei 6MHz und 38400 Baud hast Du einen Fehler von 2%.

Das kann wenns blöd läuft, schon zu Problemen führen.

Entweder Du hast vor der Lagerung im Auto Glück gehabt, oder eine andere Baudrate benutzt und weist es nicht mehr.

Auf der anderen Seite ist die Lagerung im Auto natürlich Suboptimal.
Evtl. haben die Temperaturwechsel ein paar Bauteile, von den Toleranzen her gesehen, etwas altern lassen und es passt jetzt einfach nicht mehr.

Löte einfach mal einen 6,144Hz Quarz ein und schau nach was passiert.

Der Quarz ist für 38400 Baud der Richtige.

Oh oh, hört sich nicht gut an. Eagle macht alles, was richtig ist. Bei mir alles kein Problem... Tja, ich kenn das, wenn was nicht funzt... Hatte ich mal mit Lochraster: Ging, liegen gelassen, nächster Tag Kurzschluss, nix geändert, nichts mehr zu retten, keine Ahnung warum...

Danke Dneber dass noch jemand miträtseln will.

Ja das mit den 2% weis ich, ich kann jetzt aber nicht mehr umsteigen und lief ja bisher auch alles stabil (bzw. läft noch). Ich hab mal 2 Fotos gemacht
1. Bild fast die genze Bande Hinten 2 mal zum abgeben, vorne links ist der Letzte Prorotyp der noch funktioniert (Bild 2) Ich hab auch schon auf 9600 geändert da ist der fehler ja minimal, tut auch nicht.Wenns sich irgendwie doch rausstellen sollte, das es daran liegt geh ich runter und gut, ist ja nur für Lehrzwecke.
Das mit der Alterung ist ein Interesanter Ansatz, den ich gerne mal ausbreiten würde, was das Wahrscheinlichste ist.
Ich habe also
1 Atmega16
1 FT232R der mir einen 6 MHz Takt erzeugt
2 SMD Tantalkondensatoren
1 Indultivität
1 Elko um die Spannung zu glätten
1 Keramikkondensator für Reset
Sonst noch ein Paar wiederstände Transistonren und Optokoppler, die aber mit der Übertragung nichts zu tun haben.
Welches Bauteil währe am Alterungsempfindlichsten,es muss ein systematischer Fehler sein, denn alle haben ja den gleichen.

Noch mal zu Eagel. Ich seh schon ein, dass der Fehler bei der Verwendung von Eagel bei mir liegen wird da muss ich noch etwas üben. 3D CAD, Catia, Solid Works sind ja eher die vertrauten Felder des Maschinenbauers. O:)

Uwe

Puh, ich kann mir nich vorstellen, das Autofahren irgendeinem teil davonwas tut... Ich denke, dass entweder der Elko oder FT232R am ehesten altern, letzteren nur, weil ich ihn nicht kenne :-) Wie waren denn die Temperaturen? Nur Sommer, oder?

Laut Datenblatt hält der FT232R -40-85 Grad. Die hattest du doch nie im Leben?! Und er ist für "automotive and industrial applications", also sollte es daran nicht liegen. Dem Mega16 Dürfte eigentlich auch nichts passieren. Hast du Links zu den Elkos?

Ja nur Sommer, den Juli ddurch grob gesagt.
Und bei dem was ich den Dingern beim Löten angetan hab, hätt die sonne noch 3 Gänge hochschalten müssen.
Ich werde wohl um die Osz sitzung nicht rumkommen,
Noch eis kann ich bringen
der Haben String kommt aus dem Fehlerhaften Gerät der Soll aus dem letzten Prototyp, der ja noch geht. Es ist jedoch möglich, dass die Klammer nicht der Anfang ist sonder um N Bytes verschoben.
Bsp. "0015MenueN¸_ START0"

Haben
"[WŸŸŸ�•e5#<21>5c�AYW}"

Soll
"START00015MenueN¸_ "
villeicht siehst du ja im Binärbstring den Fehler den ich nicht gefunden hab.

MFG
Uwe

Ich würde am FTDI erstmal den Ausgang mit dem Eingang verbinden und per Terminal Programm testen, ob das, was gesendet wird auch wieder zurückgeschickt wird. Dann würde ich per Max232 den Atmega an den Comport Stöpseln und testen, ob alles so läuft wie es soll. Ich nutze bei Verwendung des FTDI232RL einen externen 16 MHZ Quarz und 38400 Baud ohne Probleme. Selbst 57600 liefen im Test fehlerfrei, habe aber wieder zurückgeschaltet, da ich an dem Programm immer wieder mal rumbastele und die Software per Bootloader einspiele und da die niedrigere Fehlerquote bevorzuge. (Bootloader lief aber auch mit 57600 ohne Probleme) Den Taktgenerator des FTDI habe ich noch nicht benutzt. Ich kommuniziere nur beim Bootloader per virtuellem Comport, sonst nutze ich die Kommunikation per ftd2xxl.dll.

edit:
Da fällt mir noch etwas ein:
Wenn ich per Comport kommuniziere arbeite ich immer mit den Eingangsbuffern, denn das Data_Arrival Ereignis wird erst bei vollem Buffer ausgelöst. Um Fehler zu vermeiden sende ich immer ein bestimmtest ASCiI Zeichen als Anfang und ein Anderes am Ende des Strings, so werden fehlerhafte Übertragungen ignoriert.

Und? Wie sieht es aus? Lösung gefunden?

War erst heut am Oszi, würd ich nicht wagen meine Lösung nicht zu posten :-)
Wenn ich eine hätte.

Also es gibt gute und verwirrende Nachrichten.
Zuerst die Gute: Die übertragungsgeschwindigkeit passt, 1 Byte ca. 25us
also etwas unter 40000 baut =38400.
Nun das verwirrenden dabei. Die Taktung dabei sieht "beschissen" aus.
Die Länge einer Welle passt mit mit "166" ns doch die Form ist wie gesagt b. wenn er auf High ist bricht er bis auf null zusammen,zappelt, nimmt einen neuen Anlauf und geht dann auf Low. siehe Bild Taktung Falsch.
Dann hab ich mal ein Atmel gelöscht und siehe da, anderes bild Taktung fast gut.
Kein Plan kann irgend jemand sich äußern, ist der FT232R Clock Ausgang zu schwach um einen Atmega Clock Eingang zu Takten ?

Und nun Das Richtig Komische. Der Prototyp der funktioniert arbeitet auch mit dem schlechten Takt.
Und wie man sieht sind die Uart Signale ja 1a, Auch auf der Versorgungsspannung sind keinerlei Stötungen auszumachen.
den Ausgang und den Eingang des FT232 bin ich noch nicht dazu gekommen , werd ich morgen früh mal versuchen.
Die Hauptfrage nun Woher kann dieses schlechte Taktsignal kommen, das gut wird sobald kein Programm auf dem Controller ist???????
Neben der Taktleitung liegten zwei Massefeld und es sind nirgest sonst Störungen zu finden, auch das USB Signal ist sauber.

Hallo Uwed,

ich arbeite sehr häufig mit dem FT232RL und habe eigentlich noch nie Probleme gehabt. Zumindest nicht wegen dem FTDI. Was mir aber aufgefallen ist und was mir schon häufig Probleme bereitet hat, ist der fehlende Abblockkondensator. Ich habe ein Schaltung mit normalem MAX232 die oft Müll sendet, wenn der Kondensator nicht drin ist. Löte einfach mal einen 100nF Kondesator möglichst dicht an den M16 zwischen VCC und GND.

Vielleicht hilft es.

Gruß Frank

Hallo an alle,
ich hatte das Ding jetzt 3 Wochen auf Eis liegen, da ich meine Diplomarbeit dringenst abschlißen musst, und ich sonst sehr leicht abzulenken bin.
Ich hoffe mir werden diese Schlechten Manieren verziehen.

Ich habe ein wenig gemessen und bin zu volgendem Ergebnis gekommen.
Der Atmega hat nichts mit dem Problem zu tun, hierfür habe ich mit 1200 Baut ein "101010" verschickt und mit dem Oszi eingefangen, bei 38400 und nicht bekannten Zeichen war das schlecht zu überprüfen. Man sieht sauber die Bits hier ist alles OK.
Der FT232R bekommt also ein gutes Signal, das er auch verarbeitet (TX kontroll LED blinkt).
Leider kann ich mit den signalen auf der USB-Seite nichts anfangen da das Protokoll ja immer läuft ind ich nicht nur meinen String seh.
Weiterhin hab ich festgestellt, dass das Hyperterminal wenn ich dort 1200 Baut einstelle gear nichts bekommt, erst wenn ich hoch geh kommt was an (Müll)

Ich denke jetzt, dass der Fehler nicht in der Schaltung liegt, da
1. Korrekter String vom Atmel
2. FTDI erkannt wird
3. FTDI korrekt 6Mhz liefert und TX Kontrolled blinkt.

sondern doch irgendwo im PC liegen muss.
Hier hab ich meiner meinung nach 3 Potentiolle Fehlerquellen.
1. FTDI Treiber
2. Hyperterminal
3. Mittlerweile habe ich 45 virtuelle COM-Ports

Ich verwende den CDM 2.00.00 Treiber der einen Virtuellen COM erzeugt.
Leider habe ich von DLL s keine Ahnung, gibt es eine Möglichkeit eine solche in LAB VIEW zu integrieren.
Andererseits laufen 2 Prototypen mit diesem Treiber ja sauber.

Werd jetzt mal versuchen die 45 Coms auszumisten. ansonsten binn ich für alles Dankbar

Danke Frank, für den Tipp mit dem Kon, aber ich glaube meine Messungen schließen das als Grund aus. Wenn du den Chip schon oft verwendet hast, wie hast du ihn im PC abgefagt?

Hier noch 1 Bild vom Teststring

Hallo uwed,

ich benutze meist den direkten Zugriff über die ftd2xx.dll. Für meine eigenen Programme nutze ich Delphi, für Kunden habe ich aber auch schon Demos in c# und VB.net geschrieben, die allesamt ohne Probleme funktionieren.

In einem aktuellen Projekt nutze ich den virtuellen Comport mit Delphi (Async32) aber auch hier funktioniert alles.

Ich habe Geräte im VW Testcenter im Einsatz die schon seit Wochen ununterbrochen ohne Fehler laufen.

Unsere Hardware wird mittels 4 Byte Protokoll mit 19200 Baud gesteuert. Allerdings haben wir auch 9600 Baud und 38400 in einigen Geräten.

Selbst unter Linux mit neu compilierten Kernel (FTDI Treiber) läuft alles rund.

Klemm doch einfach mal einen MAX232 an RX/TX und schau dir an was da raus kommt.

Auf der FTDI Seite gibt es übrigens ein LAbview Beispiel. http://www.ftdichip.com/Projects/Cod...es/LabVIEW.htm

Von Labview habe ich aber keine Ahnung, weis auch nicht ob das funktioniert.

Gruß Frank

Hallo Frank,
das Hab ich schon gemacht, (und zwar nicht mit einem MAX232 sondern einem FTDI der am virtuellen COM12 hängt und funktioniert)
die die nicht mehr Funktionieren haben COM 39-44.
Ich nenn die 2 hier mal 12 und 42.
Also wenn ich mit 12 das Signal vom M16 aufnehme passt es.
Wenn ich über den 42 was schicke und es vor dem M16 mit dem 12 abhöre komt Müll raus (aber es kommt was).
Der Fehler muss also zwischen PC und 42 UART liegen.
Ich würde ja eine Kalte Lötstelle auch in Betracht ziehen, aber an 5 Chips die gleiche Kalte, und diese so, dass er mit Mprog programmierbar ist, erkannt wird, und reproduzierbare wenn auch falsche Daten liefert ich wüsste nicht an welchem Pin das sein soll.

Der Treiber kanns ja eigentlich auch nicht sein da der 12er ja funktioniert.
also Bleibt nur noch dass der Treiber bzw. Windows mit so vielen Ports nicht klar kommt, oder die Chips die Bautrate durcheinander bringen.

wenn ich dem 42 "hallo" geschickt habe hat 12 "©::\n" eingelesen. also 5 geschickt 4 wieder eingelesen, hierzu würde auch passen, dass ich mit 42 nur etwas empfange wenn ich die Bautrate hoch setzte.
Ich bin irgendwie ratlos.
Im Gerätemanager stehen nur die COMs die gerade angeschlossen sind, weißt du zufällig wo ich die anderen Deinstallieren kann.
Besten dank für die Lab beispiele, die sind mir noch nie aufgefallen.
Wenns mal wieder funktioniert werd ich mich damit mal auseineander setzen.

Uwe

Hallo Uwe,

eigentlich bleibt ja nur noch ein Treiberproblem bzw. ein Windowsproblem mit zuvielen virtuellen Schnittstellen oder ein Defekt des FT232.

Ich würde zur Sicherheit noch einmal mit einem MAX232 oder mit einem anderen PC "abhören", damit du Sicher sein kannst, dass der Treiber keinen Müll ausgibt. Immerhin greifen ja mehrere FTDIs auf den gleichen Treiber zu und bei der Menge an Comports!

Auf der FTDI Seite gibt es ein Tool FTClean - Driver Removal Utility, vielleicht bekommst du damit die Ports wieder weg. Dann könntest du ja noch versuchen die neueste Treiberversion zu installieren. Die ist glaub ich 2.02 oder so.

Sonst fällt mir auch nichts mehr ein. Höchsten noch einen Versuch über die Direct Driver ft2xx.dll.

Gruß Frank

Hallo an alle hier kommt die Auflösung des Rätsels,
wobei ich keinesfalls stolz darauf bin sondern mich eher schäm weils so einfach war und ich mich so verrannt haben.](*,) ](*,) ](*,) #-o #-o #-o

Fehler: Der FTDI war so eingestellt, dass er die Signale des Uart invertiert.
Das kann man mit MProg verstellen. (ähnich Fuse Bits in Pony)

Zu meiner Schande.
Ich hab nach allem anderen geschaut aber das ist mit beim Vergleich mit den Funktionierenden nicht aufgefallen, da ich so verbohrt war weil die Dinger beim Funktionstest gelaufen sind.

Meine einzige erklärung dafür wäre, dass ich nach dem ich sie geprüft habe die Konfiguration noch mal überschrieben habe. Ich kann mich aber nur erinnern wie ich sie nach der Kontrolle ins Gehäuse geschraubt habe und dann noch mal durchgeprüft. Welcher noremale Mensch verändert danach noch was ohne es sofort zu kontrollieren?? Villeicht wars ein Anfall geistiger Umnachtung ! Aufreg!!!!!!!!!!!!!!!!!!!!!!!!!

Bleibt noch zu sagen:
1. Der Fehler liegt immer bei einem selber und ich überleg mir jetzt mal ne art Loggbuch für jedes Projekt zu machen, da wird manches villeicht nachvollziehbarer. (außer es waren doch Aliens)

2. 1hdsquad, du hattest Recht wenns auch nicht die Fuse vom Atmel waren, sondern die Andern.

3. Danke an Frank, für einige dinge bei FTDI, die ich noch nicht gefunden hab.

Und 4. Kann den FT232 als "Nachfolger" für den Max232 nur jedem empfelen, wenn er läuft ist er toll und kann einiges.

Uwe ] ](*,)

Nachfrage:
hast Du Deine 42 com Ports löschen können?
Falls Nein, und Du XP hast, kann ich möglicherweise was hilfreiches dazu sagen. da ich das Problem auch schon mal lösen musste.
Ansonsten Gratulation zum Sieg über die Widrigkeiten der Technik.

Netter Gruß

Besten Dank marvin,
die Coms haben sich für XP erstaunlich leicht beseitigen lassen,
FTClaen aufüren und weg warn sie.:lol:

Uwe