Forum: Mikrocontroller und Digitale Elektronik Erster Test mit UART was mache ich falsch


von Matze G. (maroni666)


Angehängte Dateien:

Lesenswert?

Hallo,

ich versuche mich gerade in UART, ja ich habe versucht alle möglichen 
Posts zu lesen aber nichts gefunden was zu meinem Problem passt, darum 
wende ich mich nun an Euch.

Und zwar versuche ich per Atmega644 einen Befehl an einen Atmega32 zu 
senden.
Folgende Codes verwende ich siehe oben.

Verbunden sind sie ganz einfach über RX TX gekreuzt.

Das Problem was ich habe ist, das die LED nur ein bis zwei mal 
sporadisch angeschaltet wird aber sonst bleibt Sie aus und es wird 
"Unbekannter Befehl" gesendet.

Was kann ich verbessern? Wo ist mein Fehler?

Gruß  vom Anfänger

Matze

von Christian T. (shuzz)


Lesenswert?

Wie wird Dein Takt erzeugt? Quarz oder interner Oszillator?

von Matze G. (maroni666)


Lesenswert?

Soll eigentlich Intern sein.

von Andreas F. (aferber)


Lesenswert?

Mit internem Oszillator wird das nichts, viel zu ungenau, ausser er wird 
kalibriert. Mach entweder an beide Controller einen Quarz dran, oder 
benutz irgendeine synchrone Schnittstelle. SPI würde sich da anbieten.

Andreas

von Spezi (Gast)


Lesenswert?

Hallo,

>> Wie wird Dein Takt erzeugt? Quarz oder interner Oszillator?

> Soll eigentlich Intern sein.

In deinem Code steht:

> $crystal = 16000000

Der Takt wurde also mit 16 MHz angegeben. Daraus berechnet BASCOM die 
Einstellungen für die UART-Baudrate.
Der interne (RC-) Oszillator kann aber weder beim Mega32 noch beim 
Mega644 diesen Takt. Also stimmen die Baudraten beider Controller nicht.

Du musst entweder beide Controller mit einem 16MHz-Quarz betreiben oder 
die tatsächlich am Controller eingestellte Taktfrequenz im jeweiligen 
Code eintragen.

Normalerweise verwendet man für UART-Kommunikation nicht den internen 
Oszillator; sein Takt ist zu ungenau. Allerdings sollte es mit 9600 Baud 
noch gehen; höhere Datenraten und auch eine Kommunikation mit einem 
anderen Teilnehmer (z.B. PC) erfordern einen (Baudraten-) Quarz.

von Matze G. (maroni666)


Lesenswert?

Danke für die Tipps,

so ich hbae jetzt den internen Takt bei beiden auf 8Mhz laut 
http://www.engbedded.com/fusecalc/ gefust. Leider immer noch nur 
sporadisch An/Aus.

Würde es denn auch funktionieren wenn ich an einen Atmega einen 8,00 MHz 
Quarzoszillator hängen würde und an den andern einen 16MHz? Weil diese 
beiden habe ich hier noch rum liegen.

Gruß

Matze

von Otto (Gast)


Lesenswert?

Wenn Du bei beiden Controllern jeweils den zum Quarz gehörenden Wert 
unter "crystal" in das Programm einträgst....

von Spezi (Gast)


Lesenswert?

Und nicht vergessen, die Fuses auf externen Takt zu stellen sowie 
"Clkdiv8" (falls vorhanden) zu deaktivieren ...

von Matze G. (maroni666)


Angehängte Dateien:

Lesenswert?

Hallo,

so ich habe es jetzt mit den beiden Quarzoszillatoren versucht leider 
auch ohne den gewünschten Erfolg.

Habe dabei auch leider meinen 644 verfust nutze jetzt einen Atmega16 
dafür.

Aktuell in gebrauch Atmega16 = Sender / Atmega32 = Empfänger

Im Anhang die Aktuellen Codes und die Fuses laut Pony :).

Vielleicht könnt Ihr ja mal schauen ob ich die Fuses jetzt richtig dem 
Code nach eingestellt habe. Dann könnte ich das schonmal ausschliessen.

Wenn dem so sein sollte, habt Ihr vielleicht eine Idee was ich noch 
machen kann.

Oder gibt es sonst eine einfache und zuverlässigen Weg solche Befehle zu 
übertragen.(TWI, RS484)

Gruß

Matze

von Matze G. (maroni666)


Angehängte Dateien:

Lesenswert?

So ich habe jetzt noch eine andere Variante getestet. Leider wird auch 
hierbei nur sporadisch die LED an bzw. aus geschaltet.

Vielleicht könnt Ihr mir sagen was ich falsch mache bzw. woran es liegen 
kann.

Mein Ziel ist es einfach per Uart (AVR <-> AVR)eine LED An bzw. Aus  zu 
schalten.

Ob in C oder Bascom ist mir eigentlich egal.

Gruß

von Karl H. (kbuchegg)


Lesenswert?

Matze Gw schrieb:

> Vielleicht könnt Ihr mir sagen was ich falsch mache bzw. woran es liegen
> kann.

Ich will mich jetzt nicht darüber auslassen, woran es liegen kann. Aber 
ich weiß, was ich an deiner Stelle tun würde.

Ich würde zunächst eine Unbekannte eliminieren und nicht AVR mit AVR 
quatschen lassen. Denn da siehst du nur geht oder geht nicht. UNd damit 
hat man beim Fehlersuchen wenig angefangen.

Ic würde mir als allererstes einen der beiden Purschen an die Serielle 
eines PC hängen und dort mit einem Terminalprogramm anzeigen lassen bzw. 
die jeweilige Gegenstelle händisch spielen.

Idealerweise fang ich dabei mit dem Sender an.
Ich seh mir im Terminalprogramm an, was der sendet und vergleiche mit 
dem was er eigentlich senden sollte. Und solange das nicht identisch 
ist, wird ausschliesslich am Sender gearbeitet und mit dem PC 
kontrolliert.

Funktioniert der Sender nehm ich mir den Empfänger vor und spiele dem 
vom Terminal auf dem PC aus seine Daten per Hand rein und achte auf die 
Reaktion. Solange die nicht richtig ist, wird nur am Empfänger 
gearbeitet.

Und erst dann, wenn beide unabhängig am PC funktionieren, werden sie 
zusammengeschaltet.

von Gast 50 (Gast)


Lesenswert?

Bei der Verbindung per Uart ist es oft sinnvoll erst einmal
die eine "Seite" z.B. per Hyperterminal oder einem anderen
ähnliche Programm zu testen. (=kommt auch das "raus" was ich will)

Und dann die andere "Seite" testen: Reagiert die so auf die Kommandos
wie ich will-

Logisch daß mit der "Original-Baudrate" getestet wird, dann sollte es
in der Regel funktionieren. Eine Unsicherheit gibt es noch:
Wenn die Baudraten "grenzwertig" sind (Abweichung) und die Kombination
Hyperterminal etwas Fehlertoleranter ist.

Bei 9600 Baud recht der interne Oszillator noch recht ordentlich,
besonders wenn man die Baudrate einer "Seite" an die andere Seite 
automatisch andere "anpassen" kann. Z.B. über das Ausmessen der 
Bitbreite.
Als Testzeichen  bieten sich das Leerzeichen 0x20 (ein Bit breit)
oder die "0" 0x30 (zwei Bit Breite) an. Wurde bereits mehrfach
erfolgreich eingesetzt.

von Matze G. (maroni666)


Lesenswert?

Also ich habe natürlich bevor ich die beiden zusammen geschlossen habe, 
Sender sowie Empfänger auf deren Funktion getestet.

Habe beide mit meinem PC verbunden und über HTerm getestet.

Sender -> sendet mit Waitms 300 erst A dann B
Empfänger -> Wenn ich A eingebe geht die LED an bei B wieder aus sofern 
ich etwas anderes sende kommt Unbekannter Befehl.

von Karl H. (kbuchegg)


Lesenswert?

Matze Gw schrieb:
> Also ich habe natürlich bevor ich die beiden zusammen geschlossen habe,
> Sender sowie Empfänger auf deren Funktion getestet.

OK. Gut

Nimm mal die PRINT raus. Die brauchen ziemlich lange

von Matze G. (maroni666)


Lesenswert?

Wenn ich Print rausnehme sieht das über kurze Strecken schon wesentlich 
besser aus. Sprich die LED geht gleichmässig AN/AUS aber leider auch nur 
für 10-20sek. dann kommt kommt sie wieder aus dem Tritt bzw. Takt

von Matze G. (maroni666)


Angehängte Dateien:

Lesenswert?

Jetzt habe ich den Receive Code ein wenig geändert und jetzt kommt fast 
immer das selbe LED an/aus Muster raus.

4 x An/Aus dann LED länger(als der Waitms Befehl) An bzw. Aus

Es ist bestimmt nur noch eine Kleinigkeit die im Code geändert werden 
muss damit es so läuft wie ich es mir vorstelle.

Gruß

Matze

von Karl H. (kbuchegg)


Lesenswert?

Und du bist sicher, dass die 9600 Baud auch auf dem PC gestimmt haben?

Das klingt nämlich alles nach: Der Sender überfährt den Empfänger, 
sprich: er sendet zu schnell hintereinander.
Nur. Bei 9600 Baud kann das eigentlich nicht sein. Alle 300ms ein 'A' 
oder ein 'B' kann nicht zu schnell sein.

Wenn natürlich deine im Basic File angegebenen Quarzraten nicht stimmen, 
könnte das vieles erklären.

von Matze G. (maroni666)


Lesenswert?

Ob die Baudrate an meinem PC stimmt?

Zumindest habe ich bei HTerm 9600 stehen und in meinem Gerätemanager vom 
PC steht die COM1 auch auf 9600 wenn Du das meinst?.

von Florian S. (der_picknicker)


Lesenswert?

Fehlt da nach Case "A" bzw. Case "B" nich jeweils ein Doppelpunkt?

Also:
1
Select Case I
2
   Case "A" : Led=1
3
   Case "B" : Led = 0
4
End Select

von Karl H. (kbuchegg)


Lesenswert?

Matze Gw schrieb:

> Zumindest habe ich bei HTerm 9600 stehen und in meinem Gerätemanager vom
> PC steht die COM1 auch auf 9600 wenn Du das meinst?.

Ja. das meinte ich.
D.h. die angegebenen 8Mhz werden ziemlich sicher stimmen.

von Matze G. (maroni666)


Lesenswert?

Florian Schütte schrieb:
> Select Case I
>    Case "A" : Led=1
>    Case "B" : Led = 0
> End Select

Ja die : waren nicht da habs geändert, aber es bleibt alles so wie 
vorher, leider.

von Florian S. (der_picknicker)


Angehängte Dateien:

Lesenswert?

Also ich hab das ganze mal aufgebaut. Bei mir funktioniert es 
einwandfrei.
2 Mega8, 8MHz intern, 9600 Baud, TX/RX gekreuzt, Vcc und GND 
angeschlossen, Pullup an Reset, das wars. Fuses: Nur Häkchen bei STU0, 
CKSEL3/1/0. Aber das sollte alles klar sein.
Hatte ich auch vorher eig. keine Zweifel dran, da alles korrekt 
aussieht. Im Anhang nochmal mein Sourcecode dazu. Vielleicht entdeckst 
du ja doch noch was (kann ich mir aber nicht vorstellen, weil so 
simpel).

von Florian S. (der_picknicker)


Lesenswert?

Äh...ich seh grade, du hast im letzten, von dir geposteten Quellcode 
keine Do..Loop schleife

von Matze G. (maroni666)


Lesenswert?

Florian Schütte schrieb:
> Äh...ich seh grade, du hast im letzten, von dir geposteten Quellcode
> keine Do..Loop schleife

Die ist kurz nach dem Post wieder reingekommen

von Matze G. (maroni666)


Lesenswert?

Danke für deine Hilfe ich habe jetzt deinen Code übernommen bzw. meinen 
angeglichen.

Das Problem besteht leider immer noch.
Ich denke jetzt das es wohl an meiner zur Verfügung stehen peripherie 
liegt.

Den Atmega16 betreibe ich auf einem Evalboard Ver. 2.01
den Atmega32 betreibe ich auf einem Avr-Net-Io Board

beide verden von der selben Spannungsquelle versorgt.

Was habe ich vergessen?

von Florian S. (der_picknicker)


Lesenswert?

Hm, dann weiß ich auch nicht weiter. Hast du nicht zufällig zwei gleiche 
Controller? In meinem Hirn kreist grad die Idee, dass die beiden den 
internen Takt zu unterschiedlich erzeugen. Ansonsten bleibt nurnoch das 
gleiche wie immer: alles wieder und wieder checken, also Fuses, 
Programm, Beschaltung.
Hier gibts auch ne Checkliste: 
http://www.mikrocontroller.net/articles/AVR_Checkliste

von Florian S. (der_picknicker)


Lesenswert?

Ah, du benutzt die Pollin-Boards. Liegt es dann vielleicht an den 
MAX232? Dies sind zwar an beiden Seiten vorhanden, aber bei mir haben 
die auch schon probleme gemacht. Auf dem Eval-Board kannst du TX/RX ja 
an JP1/2 abgreifen, weiß nich ob das beim Net-Board auch geht. Also am 
besten wäre es, TX/RX direkt zu verbinden. Wäre irgendwie auch unsinnig, 
die Pegel zu wandeln, da die Controller sich ja "direkt verstehen".

von Matze G. (maroni666)


Angehängte Dateien:

Lesenswert?

So vielen Dank an all die, die bei bei der Lösung des Problems geholfen 
haben.

Anbei die Funktionieren Codes mit Print :).

Das Problem war mal wieder so Simpel, nach dem die Sources endlich 
richtig waren konnte es nicht mehr an so viel liegen. Dank Florian 
Schütte, habe ich mal einfach die Massen beider Boards verbunden und 
siehe da die LED lief so wie sie sollte.

Besten Dank und Gruß

Matze

von Matze G. (maroni666)


Lesenswert?

Florian Schütte schrieb:
> MAX232? Dies sind zwar an beiden Seiten vorhanden,

Habe das RX/TX Signal davor abgegriffen liefen also auch nicht über die 
MAX232.

Vielen Dank nochmals.

von Florian S. (der_picknicker)


Lesenswert?

Es kann manchmal so einfach sein, dass man im Leben nicht drauf kommt :D

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
Noch kein Account? Hier anmelden.