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
Wie wird Dein Takt erzeugt? Quarz oder interner Oszillator?
Soll eigentlich Intern sein.
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
Gast
#1615651
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.
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
Gast
#1615900
Wenn Du bei beiden Controllern jeweils den zum Quarz gehörenden Wert unter "crystal" in das Programm einträgst....
Gast
#1615913
Und nicht vergessen, die Fuses auf externen Takt zu stellen sowie "Clkdiv8" (falls vorhanden) zu deaktivieren ...
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
Angehängte Dateien:
-
Atmega16.JPG
(29 KB)
-
Atmega32.JPG
(29 KB)
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ß
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.
Gast
#1617723
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.
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.
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
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
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
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.
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?.
Fehlt da nach Case "A" bzw. Case "B" nich jeweils ein Doppelpunkt? Also:
1 | |
2 | |
3 | |
4 | |
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.
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.
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).
Äh...ich seh grade, du hast im letzten, von dir geposteten Quellcode keine Do..Loop schleife
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
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?
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
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".
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
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.
Es kann manchmal so einfach sein, dass man im Leben nicht drauf kommt :D
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.