Hallo,
ich habe folgendes Minimalbeispiel gemacht um nur den UART des ATMega644
zu testen. Der Interrupt wird ausgelöst, aber er empfängt kein Byte 170.
Mit einem ATMega32 in der identischen Schaltung funktioniert es
einwandfrei. Der Logicanalyzer bestätigt auch dass Bytes 170 ankommen,
aber der ATMega644 erkennt es nicht. Die Frage ist natürlich wo der Code
noch falsch ist. Was habe ich übersehn? Bin schon drei Tage dabei das
irgendwie zum laufen zu kriegen, aber ich komm einfach nicht dahinter.
Tobias schrieb:
> Mit einem ATMega32 in der identischen Schaltung funktioniert es> einwandfrei.
Ich überfliege gleich mal den Code aber das riecht schon nach:
a) falscher Quarz oder
b) richtiger Quarz aber falsche Fusebit Einstellungen
Edit: Code schaut ansich in Ordnung aus. Die Delays sind zwar sinnlos
und die Aufgabe von ProcessRXByte() kann man gleich in der RXC0 ISR
erledigen aber Fehler konnte ich jetzt keinen entdecken. Ich penn aber
auch gleich ein :)
danke schonmal,
aber das es sich um Hardware-Fehler handelt schließe ich aus, da die
selbe Schaltung mit einem ATMega32 funktioniert.
Die Fuses sind wie auf dem angehängten Bild eingestellt.
kann es sein dass der ATMega644 elektrische Unterschiede hat zum
ATMega32? Dass er beim USART evtl einen anderen Threshold für High hat.
Irgendworan muss es ja liegen.
Hast du eine Möglichkeit, dir anzeigen zu lassen, was du anstelle der
0xAA empfängst?
Hast du ausprobiert, was passiert, wenn du vom µC weg sendest. Empfängt
ein angeschlossenes Terminal dann richtig?
Wenn nicht, wäre das ein Indiz dafür, dass mit der Baudrate/Taktfrequenz
noch irgendetwas nicht stimmt.
nein, ich kompilier natürlich schon extra für den 644.
Das empfangene Byte ansehen, sowie senden ist in der Schaltung beides
ziemlich aufwendig. Wird also etwas dauern bis ich da mehr sagen kann,
wenn es etwas gibt was ich vorher ausprobieren kann würde ich das gerne
tun.
so, nachdem ich jetzt nochmal Zeit hatte ein paar Sachen auszuprobieren:
Das Problem ist ja dass das Byte 170 nicht erkannt wird.
Bei einem Testprogramm das nur das Byte 170 sendet, kommt das bei einem
Empfänger auch so an. Sprich am Takt von µC/Bus kann es nicht liegen.
Wenn ich nun das Byte 170 an den ATMega644 sende und dieser sendet das
empfangene Byte zurück, dann kommt 192 an.
In Binar:
170: 10101010
192: 11000000
also auch nicht invertiert oder ähnliches. Und es kommt auch konstant
die 192 zurück.
Der Kondensator Cmax ist rechter Unsinn. Auch wenn diese Hardware in der
anderen Schaltung funktioniert, so ist sie doch recht schrottig.
Für den Fall, daß der Ausgang des Max hochohmig ist, ist kein Pegel für
den RX-Eingang definiert. Häng lieber einen Pull-Up-Widerstand rein.
an den beiden Pins hängen bloss 2 "Debug"-LEDs dran.
Cmax ist zugegebenermaßen unkonventionell, hat aber Probleme gelöst.
Ohne den hatte ich des öfteren Resets des µC und hier im Forum habe ich
von gleichen Problemen gelesen mit eben diesem Lösungsvorschlag.
Die standardloesung fuer diesen Fall ist einen freien Pin zu nehmen und
bei jeden gelesenen Byte diesen Pin zu pulsen. Mit einem Scope kann man
dann genau sehen, was laeuft.
Hi
>Ohne den hatte ich des öfteren Resets des µC und hier im Forum habe ich>von gleichen Problemen gelesen mit eben diesem Lösungsvorschlag.
Das ist nur ein herumdoktern an Symptomen. Ein passender
Abblockkondensator am Max ist mit Sicherheit hilfreicher. MAXIM gibt
einen Wert von 3,1µ an.
MfG Spess
Hallo,
ein Abblock-Kerko am MAX-IC zwischen VCC und GND direkt am IC ist
anzuraten (im Schaltplan sehe ich keinen) ... (Ich nehme meist 100nF.)
Womöglich ist dann Cmax überflüssig. Ich habe bei RS485 bisher noch nie
irgendeinen Kondensator an RxD gebraucht.
spess53 schrieb:
> MAXIM gibt (für den Abblock-C) einen Wert von 3,1µ an.
Woher hast du diese Information? Im Datenblatt finde ich nichts dazu ...
Ich schalte immer den internen Pull-Up für diesen Pin ein.
Das Einschalten dieses Pull-Ups an RxD beugt Störungen bei offenem
RxD-Pin vor, wenn der Empfänger im MAX-IC nicht aktiv ist; es hält den
Pin auf (inaktivem) High-Level.
Tobias schrieb:
> an den beiden Pins hängen bloss 2 "Debug"-LEDs dran.
Hoffentlich mit den notwendigen Vorwiderständen (das wird leider öfter
fälschlicherweise nicht gemacht), sonst handelt man sich ohne sie wieder
neue Probleme ein ...
ich hab Cmax jetzt mal ausgelötet und den Entstörkondensator zwischen
Vcc und GND beim MAX eingelötet, aber kriege immer noch gleichermaßen
falsche Bytes.
ich hab jetzt mal Kanal A und B vorm Max ans Oszi angeschlossen und
voneinander abgezogen. Die Flanken sind schön steil, aber bei z.B. dem
Byte 170 (binär 10101010) wechselt der Pegel schön von 5V zu -5V wieder
zu 5V etc, aber mitten im Byte ist er 2 Bits lang auf 0V. Warum...noch
nicht die geringste Idee.
Dieser 0V Pegel ist auch bei jedem anderem Byte enthalten.
Leider kann ich keinen Screenshot davon machen.
Normal würde ich ja vermuten dass der Sender das "verbricht", allerdings
funktioniert die Übertragung mit dem ATMega32 ja einwandfrei.
Auch ist dieser 0V Pegel während der Zeit in der keine Übertragung statt
findet vorhanden. Sollte da normalerweise nicht eine Different von 5V
oder -5V sein? (Der Sender ist übrigens eine SPS die auch Pullup und
PullDown Widerstände verwendet.)
