- Labornetzteil AliExpress         
Seite 2 von 3 ErsteErste 123 LetzteLetzte
Ergebnis 11 bis 20 von 27

Thema: Übertragungsproblem FT233RL keine Anfängerfragen :-)

  1. #11
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    29.01.2005
    Alter
    52
    Beiträge
    294
    Anzeige

    E-Bike
    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.
    Das Gegenteil von "gut" ist "gut gemeint"!

  2. #12
    1hdsquad
    Gast
    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...

  3. #13
    Benutzer Stammmitglied
    Registriert seit
    19.03.2006
    Beiträge
    44
    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.

    Uwe
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken geraetesammlung.jpg   empfangener_string_hex.jpg  

  4. #14
    1hdsquad
    Gast
    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?

  5. #15
    1hdsquad
    Gast
    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?

  6. #16
    Benutzer Stammmitglied
    Registriert seit
    19.03.2006
    Beiträge
    44
    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>5cAYW}"

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

    MFG
    Uwe

  7. #17
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    18.05.2007
    Ort
    Berlin
    Alter
    53
    Beiträge
    765
    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.
    Wenn das Herz involviert ist, steht die Logik außen vor! \/

  8. #18
    1hdsquad
    Gast
    Und? Wie sieht es aus? Lösung gefunden?

  9. #19
    Benutzer Stammmitglied
    Registriert seit
    19.03.2006
    Beiträge
    44
    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.
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken datenfluss.jpg   taktung_falsch.jpg   taktung_890.jpg  

  10. #20
    Benutzer Stammmitglied
    Registriert seit
    06.04.2006
    Beiträge
    48
    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

Seite 2 von 3 ErsteErste 123 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

fchao-Sinus-Wechselrichter AliExpress