Hallo Forum,
ich bin grade dabei auf einem ATmega2560 zu programmieren.
Dieser kommuniziert mittels USART über einen FTDI mit dem Rechner (kein
eigenes USART programmiert, sondern eingebautes USART0 benutzt).
Gleichzeitig spreche ich per SPI mehrere Peripherie geräte an (wieder
das eingebaute SPI benutzt, kein eigenes Programmiert).
Dies klappt wunderbar und funktioniert ohne Zwischenfall stundenlang.
Doch dann setze ich den fast-pwm auf Pin L5 ein (Hardware-PWM), der auch
funktioniert (Periodendauer = 8s wie gewünscht), und wir haben das
Problem: Nach unvorhersehbaren Zeitabständen zwischen 1s und 2min bricht
die USART Kommunikation vorrübergehen zusammen, PuTTY sagt das Lesen am
Port funktionierte nicht mehr, MATLAB sagt das gleiche.
Dabei ist das globale Interrupt bit deaktiviert.
Hatte jemand schonmal so ein Problem?
@Niklas Rpunkt (hobbycoder)
>Doch dann setze ich den fast-pwm auf Pin L5 ein (Hardware-PWM), der auch>funktioniert (Periodendauer = 8s wie gewünscht),
ACHT Sekunden Periodendauer? Das ist eher ein langsames Blinken als PWM.
> und wir haben das>Problem: Nach unvorhersehbaren Zeitabständen zwischen 1s und 2min bricht>die USART Kommunikation vorrübergehen zusammen, PuTTY sagt das Lesen am>Port funktionierte nicht mehr, MATLAB sagt das gleiche.>Dabei ist das globale Interrupt bit deaktiviert.>Hatte jemand schonmal so ein Problem?
Nö, aber es ist mit hoher Wahrscheinlichkeit ein Programmierfehler und
kein Hardwaredefekt. Poste vollständigen Code als Anhang.
Felix A. schrieb:> Was soll "Dabei ist das globale Interrupt bit deaktiviert" bedeuten?> Steuert ihr alles aus einem Hauptprogramm ohne Interrupts?
Das bedeutet im SREG ist das Interrupt bit auf 0 gesetzt. Die
Kommunikation über USART und die Kommunikation erfolgt beide male via
polling. Sprich wir fragen so lange ab, ob wie senden können, bis wir
senden können. Beim Empfang das gleiche. Aber da die latenz zwischen
Senden und Empfangen via SPI so gering ist, ist dies kein Nachteil. Und
USART benutzen wir eh nur unidirektional.
"PuTTY sagt das Lesen am Port funktionierte nicht mehr"
Das hört sich eher danach an als ob der FTDI die Grätsche macht..
Ist das USB-Gerät in dem Zustand noch da? Kannst du die USB-Verbindung
mal trennen und wieder herstellen? Geht es dann wieder?
Chris schrieb:> "PuTTY sagt das Lesen am Port funktionierte nicht mehr"> Das hört sich eher danach an als ob der FTDI die Grätsche macht..> Ist das USB-Gerät in dem Zustand noch da? Kannst du die USB-Verbindung> mal trennen und wieder herstellen? Geht es dann wieder?
Wenn ich PuTTY direkt wieder öffne, dann empfange ich auch wieder die zu
erwartenden Daten. Das geht ein paar Sekunden gut und dann bricht sie
wieder zusammen.
Wird in Richtung PC seriell gesendet? Oder sendet ihr mit Putty Richtung
uC?
In letzterem Fall könnte ich mir vorstellen, dass da vielleicht die
Zeichen nicht schnell genug abgeholt und manchmal überschrieben werden.
Ich fürchte, ohne einen Schaltplan und ein Layout kann ich da nicht mehr
weiterhelfen.
Da der Fehler eher zufällig auftritt, vermute ich eher ein
Layoutproblem. Softwareprobleme will ich damit aber nicht prinzipiell
ausschließen.
Ohne das Layout rauszugeben, könntest du den Verlauf der Leitung
kontrollieren. Läuft diese dicht am USART entlang oder an dessen
Leitungen? Oder sehr dicht am FTDI? Was hängt an dieser PWM-Leitung?
Hintergrund ist, dass hier steile Flanken auftreten, die eventuell
kapazitiv in den USART oder FTDI einkoppeln.
Die beiden USART Leitungen und die Leitung mit PWM laufen so weit
auseinander wie irgend möglich auf dem Board :/
Am Ende der PWM Leitung liegt ein Relais das angeblich im worst case max
9mA zieht.
Niklas Rpunkt schrieb:> Am Ende der PWM Leitung liegt ein Relais das angeblich im worst case max> 9mA zieht.
Dann ersetze das Relais doch mal durch einen passenden Widerstand ud
prüfe nochmals. Deine Fehlerbeschreibung deutet darauf hin, dass auf der
seriellen Schnitte Störungen sind, die den Treiber im PC zum Absturz
bringen. Und eine Relaisspule, passend beschaltet, kann da durchaus
interessante Effekte bringen.
Bauteiltöter schrieb:> Hast du den TEST-Pin am FTDI beschaltet? Bleibt der offen ergibt sich so> ziemlich das gleiche Fehlerbild.
TEST ist auf GND
Felix A. schrieb:> Gibt es eine Freilaufdiode am Relais? Wird dieses über einen Transistor> betrieben oder wirklich direkt über den Pin?
Darüber weiß ich leider nichts, da das relais in einem weiteren Bauteil
versteckt ist, über das ich keine großartigen Daten habe außer welchen
Pin ich high bzw. low machen muss
Georg G. schrieb:> Dann ersetze das Relais doch mal durch einen passenden Widerstand ud> prüfe nochmals.
Das werde ich tun, sobald ich den Aufbau entsprechend umgebaut habe.
Hallo,
es scheint ja so, als ob der FTDI kurz "verschwindet". Wie wird der
betreiben? Bus-powered? Eigentlich sind die Teile nicht sehr
empfindlich.
Welche Baudrate wird denn benutzt? Die UART-Leitungen mit Störungen auf
dem Weg zum FTDI so zu versauen daß der FTDI sich abmeldet ist garnicht
so einfach.
Wenn das Relais eine Rolle spielt müßte der Fehler ja zu provozieren
sein, der Absturz käme dann beim Schalten des Relais, das sollte doch zu
beobachten sein.
Wenn es nur bei Einsatz der fastPWM passiert würde ich eher ein
Softwareproblem vermuten.
Gruß aus Berlin
Michael
Was ist denn jetzt mit dem Schaltplan?
Fällt der - genauso wie manchmal das Ohmsche Gesetz - unter "STRENG
GEHEIM"?
Ein Relais mit 9mA kommt mir schon etwas exotisch vor. Handelt es sich
vielleicht um ein SSR?
Gerne ist auch falsche Sparsamkeit bei Abblockkondensatoren der Grund
für solche merkwürdigen Fehler.
Ich hab das mit dem Widerstand statt relais jetzt gemacht. Keine
Ausfälle mehr. Ich nehme an dass das relais schuld ist und werde das so
weitergeben. Vielen Dank füe eure Hilfe.
Eine eigene Frage?
Dieser Thread ist über 10 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
