Hallo. Ich weiß, dass leidige Thema ^^ Bevor die Rufe laut werden, das gabs schon oft genug, bitte ich erstmal aufmerksam zu sein und wenns angemessen ist, danach zu kritisieren ;). Ich habe zwei Controller: ATMEGA48 sendet und ATMEGA16 empfängt. Das Problem ist nicht schwer zu erkennen, wie man sieht. Der ATMEGA 48 sendet, das habe ich durch LEDs bewiesen. Ob er das richtige sendet weiß ich nicht, ich habe kein Oszilloskop. Der Sender ist auf einer Experimentierplatine, die mit mit GND und VCC mit dem STK500 verbunden ist. Als "Datenleitung" verwende ich nur ein Kabel. Treiber habe ich auch nicht verwendet, da die Entfernung < 10cm ist. Der ATMEGA16 empfängt etwas, kann man durch seine Reaktion und den Quellcode logisch erschließen. Danach gibt er das empfangene Zeichen am PORTA aus. Die LEDs zeigen 0b01111110. Da das Signal invertiert wird, heißt das 0b10000001, was DEC 129 ist. Gesendet wurde ein '!', kommt leider nicht hin. Ich habe die Taktquelle (beide externer Quarz 4MHz) oft genug überprüft. Baudrate wird durch <util/setbaud.h> auch berechnet. Dann noch der Quellcode beider Controller: ATMEGA48: #include <avr/io.h> #define F_CPU 4000000 #define BAUD 19200 #include <util/setbaud.h> #include <util/delay.h> void uart_init(void) { UBRR0H = UBRRH_VALUE; UBRR0L = UBRRL_VALUE; UCSR0B |= (1<<TXEN0); UCSR0C |= (1<<UMSEL01) | (1<<UCSZ01) | (1<<UCSZ00); } int main(void) { uart_init(); while(1) { while (!(UCSR0A & (1<<UDRE0))) { } UDR0 = '!'; _delay_ms(100); } } ATMEGA16: #include <avr/io.h> #define F_CPU 4000000 #define BAUD 19200 #include <util/setbaud.h> #include <util/delay.h> void uart_init(void) { UBRRH = UBRRH_VALUE; UBRRL = UBRRL_VALUE; UCSRB |= (1<<RXEN); UCSRC |= (1<<URSEL) | (1<<UCSZ1) | (1<<UCSZ0); } uint8_t uart_getc(void) { while (!(UCSRA & (1 << RXC ))); return UDR; } int main(void) { uart_init(); DDRA = 0xff; uint8_t c; while (1) { _delay_ms(100); _delay_ms(100); c = uart_getc(); PORTA = 0b01010101; _delay_ms(100); PORTA = c; } } Ich würde gerne wissen, was vielleicht falsch läuft, wenn man das so schon erkennen kann. Wenn nicht, sagt mir, was ich ausprobieren kann, um zu erkennen, was nicht funktioniert. Ich hoffe auch, dass man erkennen kann, dass ich mich bemüht habe die typischen Fehler (Baudrate falsch/Taktquelle,-rate falsch) auszuschließen. Wegen des nicht so schönen Testprogramms bitte Nachsicht, es sei denn, da steckt der Fehler ;). Etwas ratlose Grüße, Tim
Ich wäre wirklich dankbar, wenn jemand mir helfen könnte. Habe auch selber weiterhin versucht herauszufinden, was nicht funktioniert. Ich habe den ATMEGA48 umprogrammiert, sodass er jetzt ein 'x' sendet, allerdings zeigen die LEDs an PORTA genau das gleiche wie vorher mit '!'. Scheint so, als würde das auslesen aus dem UDR nicht funktionieren??? Ich weiß, dass es langweilig ist, sich immer mit diesem Thema rumzuärgern, bin ja auch nicht de erste, der damit Probleme hat. Aber ein kleiner Tip, mit dem ich alleine weiter arbeiten kann, wäre schon eine sehr gute Hilfe :). Hoffnugsvolle Grüße, Tim
OK, zugegeben, das war unglücklich vormuliert. Am STK500 werden meines Wissens die LEDs invertiert angesprochen. Soll heißen, dass wenn der Pin auf High ist, die LED auf Low ist, mehr wollte ich damit nicht sagen. Und wieso ist das wichtig, das ausgegebene Zeichen ist ja sowieso nicht richtig :( Ich freue mich immernoch auf Hilfen. Freundliche Grüße, tim
Hi Warum testest du nicht das Senden und Empfangen einzeln mit dem STK500 und einem Terminalprogramm auf dem PC? Du hast zwar Delays drin, aber sicherer wäre vor dem Senden UDRE und vor dem Auslesen RXC abzufragen. MfG Spess
Hey Leute. Ich weiß, dass das Thema schon so oft abgearbeitet wurde, aber ein kleiner Hinweis würde mich wirklich freuen.
oh sry, manchmal kommts auf ne Minute an:D. spess53 schrieb: > Du hast zwar Delays drin, aber sicherer wäre vor dem Senden UDRE und vor > dem Auslesen RXC abzufragen. Versteh ich nicht, habe ich doch gemacht!? Und soweit funktionierts auch. Nur das empfnagene Zeichen ist Müll. Das mit dem Terminalprogramm schaue ich mir mal an ;) Vielen Dank schonmal. Für weitere Vorschläge bin ich auch dankbar.
Hi
>Versteh ich nicht, habe ich doch gemacht!?
Entschuldige. Hatte ich übersehen. Allerdings nützt das nur etwas, wenn
du es auch wieder zurücksetzt. Sonst bleibt es nach dem ersten Zeichen
immer auf 1.
MfG Spess
"Hmm, beim Mega16 muss ich beim Schreiben nach UCSRC das Bit URSEL setzen. Komisch, beim Mega48 gibt es das Bit gar nicht. Ach, macht nichts, dann nehme ich dort halt einfach UMSEL01. Nicht nötig im Datenblatt nachzulesen, was diese Bits überhaupt bedeuten, der Name ist so ähnlich, dann wird das schon passen."
Wenn man aus UDR ausliest, bzw reinschreibt werden UDRE, bzw RXC gelöscht. Daran kanns auch nicht liegen, da ich jetzt das Programm vom Empfänger neu geschrieben habe. Das ganze läuft jetzt nureinmal durch, dann ist das Programm zuende. Hat den Vorteil, dass der Zustand von PORTA gespeichert bleibt. Sollte ich das ganze vielleicht mal mit der niedrigsten Baudrate die geht betreiben um Übertragungsfehler zu minimieren? Immer noch ratlose Grüße, Tim
Und schon wieder zulange gewartet. @Stefan: Falls das ne Andeutung sein soll, du kannst gerne im Datenblatt nachsehen. Das Bit was sonst URSEL heißt, heißt beim ATMEGA48 UMSEL01. Jedenfalls laut meinem Datenblatt. Und ich meine zu wissen, dass dieses Bit entweder die Beschreibung von UBRRH oder UCSRC festlegt ;).
Tim mit m schrieb: > Das Bit was sonst URSEL heißt, heißt beim ATMEGA48 UMSEL01. Nein. Diese Bits haben komplett unterschiedliche Bedeutungen. Die sind noch nicht mal ansatzweise ähnlich.
Im Datenblatt steht:
UCSR0C | UMSEL01 | UMSEL00 | UPM01 | UPM00 | USBS0 | UCSZ01/UDORD0
|UCSZ00/UCPHA0 | UCPOl0 |
Passt nicht alles in Reihe drauf.
Sry, da es das Bit URSEL nicht gibt, habe ich angenommen, das es hier
eben UMSEL01 heißt, da es ja an der gleichen Stelle ist, wie beim
ATMEGA16 das Bit URSEL.
Wenn du das Bit URSEL siehst, sag mir Bescheid :)
Und wenn nicht UMSEL01 den Zweck von URSEL hat, welches dann?
Das Datenblatt habe ich von reichelt, da ich dort auch den ATMEGA48
gekauft habe.
Meine Nachtbarin heißt auch Ursel :) du sagtest das Signal wird invertiert. Die Daten lassen sich einfach einfach invertieren, jedoch das Start und Stopbit nicht, da diese zum Protokoll gehören und du davon nichts mitbekommst. Kann es daran liegen, kenne deine Schaltung nicht... Ingo
Ok, wird Zeit mal wieder meine Fehlaussagen zurückzupfeifen: Ich meinte nicht, dass die Daten invertiert werden, sondern nur der Zustand der LEDs am STK500. Dann noch mal zu deiner Nachbarin, die warscheinlich auch nur nachts zusehen ist ;) Im Tutorial zur UART stand, dass sich UBRRH und UCSRC MANCHMAL ein Register teilen, ich habe angenommen, das das bei jedem Controller der Fall ist, obwohl ich es die ganze Zeit vor der Nase hatte :D -> Sry deshalb an Stefan ;) Werde gleichmal sehen, obs jetzt funktioniert. Vielen Dank, Tim
oh, sry mal wieder mit dem falschen Timing, aber ich hoffe, Stefan ist mir deshalb nicht allzu böse ^^
So, ich hätte jetzt gerne das Programm vom Sender umgeschrieben, aber leider bekomme ich jetzt lauter Compilerfehler, weil er die Registernamen nicht akzeptiert. Nicht mal PORTA oder DDRA scheint er zukennen :( Woran liegt das, ich habe überhaupt nichts am Rest des Programmes verändert. Und da er vorher ohne Probleme kompiliert hat, habe ich überhaupt keine Ahnung, was jetzt schon wieder nicht funktioniert!!!! vollkommen ratlose Grüße :(, Tim
Ich wünschte das wäre es gewesen, aber leider ist <avr/io.h> eingebunden. Trotzdem gibt der Compiler bei jedem Registernamen einen Fehler: 'UBRRH' (undeclared) first in this function aber bei dem Programm ist <avr/io.h> nunmal eingebunden, deshalb bin ich echt ratlos. Bei älteren Projekten gibt es aber keine Schwierigkeiten. Hat jemand Erfahrung/Ahnung, was passiert sein kann???????
auch nicht. ich habe ja nichts verändert. ich war gerade fertig, dass BIT URSEL aus dem Quellcode zu entfernen. Kompilierbefehl und zack, dieFehlermeldungen. Beim Quellcode vom Empfänger das gleiche. Nur bei älteren Projekten läuft allse einwandfrei :(
Tim mit m schrieb: > So, ich hätte jetzt gerne das Programm vom Sender umgeschrieben, aber > leider bekomme ich jetzt lauter Compilerfehler, weil er die > Registernamen nicht akzeptiert. Nicht mal PORTA oder DDRA scheint er > zukennen :( Ich dachte Sender = Mega48? Der Mega48 hat aber kein Port A ... Tim mit m schrieb: > 'UBRRH' (undeclared) first in this function ... und auch kein Register "UBRRH".
Habe mal den code vom Sender in ein altes funktionierendes Projekt kopiert, und es gab keine Compilerfehler. Nur bei neueren gibts jetzt welche :(
So ich bins nochmal. Sry wegen der Verwirrung, hat sich wieder geklärt. Klar, das bit UMSEL zusetzen war natürlich sinnfrei. Am Gesamtergebnis hat das aber leider nichts geändert. Nach wie vor zeigt soll das empfangene Zeichen 0b10000001 sein, manchmal ist es auch 0b10010001. Hat jemand noch mehr Ideen, was nicht richtig funktioniert? Freundlche Grüße, Tim
Auf dem STK-500 ist eine Spare-RS232 drauf. Damit verbinden und schauen, was am PC ankommt. Ist ja Blödsinn hier an 2 Dingen einen Fehler zu suchen ... Gruß Jobst
Tim mit m schrieb: > Als "Datenleitung" verwende ich nur ein Kabel. Jetzt mal eine ganz dumme Frage: hast Du auch GND miteinander verbunden? Gruß Dietrich
Jobst M. schrieb: > Auf dem STK-500 ist eine Spare-RS232 drauf. Damit verbinden und schauen, > was am PC ankommt. > Ist ja Blödsinn hier an 2 Dingen einen Fehler zu suchen ... Ich bin deinem vorschlag gefolgt und habe mal mit hyperterminal das Signal des Controllers angesehen. Leider war das Zeichen kein '!', sondern ein 'a'. Weiß nicht, wo man die codierung bei hyperterminal einstellen kann, vielleicht wars die falsche. Somit ist denke aber schonmal bewiesen, das überhaupt etwas gesendet wird. Dietrich L. schrieb: > Jetzt mal eine ganz dumme Frage: hast Du auch GND miteinander verbunden? Der sendene Controller, wenn er denn auf der Experimentierplatine ist, bekommt die Energieversorgung vom STK500. Ich glaube somit erübrigt sich diese Vermutung. Das Problem scheint also am empfangenen Controller zuligen. Kann man da so ähnlich testen? Vielen Dank schonmal, für die Hilfe
Tim mit m schrieb: > Leider war das Zeichen kein '!', sondern ein 'a'. > Weiß nicht, wo man die codierung bei hyperterminal einstellen kann, > vielleicht wars die falsche. dann würd ich erst mal beim Sender den Fehler suchen. Egal welche Codierung - aus einem '!' wird mit Sicherheit nie ein 'a'. Gib mal mehrere Zeichen aus. Sascha
Tim mit m schrieb: > Leider war das Zeichen kein '!', sondern ein 'a'. Das hört sich für mich nach avr-seitig falscher Baudrate an. Ist häufig auf die falsche Takteinstellung zurückzuführen, sofern im Hyperterminal alles richtig eingestellt ist und auch das Baudratenteiler-Register im AVR richtig gesetzt ist. Sicher das der Takt stimmt? Nimm mal eine LED und lass sie im Sekundentakt blinken. Hast du zufällig die CKDIV8-fuse gesetzt?
1 | LED_AN(); |
2 | _delay_ms(500); |
3 | LED_AUS(); |
4 | _delay_ms(500); |
Wenn die LED im Sekundentakt blinkt, dann liegt es schon mal nicht am Systemtakt des AVR. Gruß Oliver
Hallo nochmal. Ich habe das Programm wieder umgeschrieben: Gesendet werden soll folgendes: ABCDEabcdeABCDEabcdeABC usw. aber ankommen tut folgendes: ƒ„âヅáâä僄…âã䂃 Wenn wenigstens die Anzahl der Zeichen, die sich wiederholen gestimmt hätte, hätte man denken können, dass es sich lediglich um eine Verschiebung des Werts handelt. Aber mit diesem Ergebnis, scheint tatsächlich die Geschwindigkeit falsch eingestellt zusein. Oliver J. schrieb: > Hast du zufällig die CKDIV8-fuse > gesetzt? nein, bei diesem Projekt habe ich darauf geachtet, diese Fuse nicht zusetzen. Taktquelle ist: EXTFSXTAL_16KCK_14CK__65MS. Frequenz : 4MHz Wo sich der Fehler befindet ist mir schleierhaft, da ich mit UART keine Erfahrung habe, bzw sie gerade mache ;) Ich hoffe, ihr könnt mit den Infos genug anfangen. Vielen Dank, Tim
Hi Tim, das sieht nach falschen Terminal Parametern aus. Stelle Deinen UART auf 300 Baud 8N1 ein, genauso dann Dein Terminalprogramm am PC. Das muss erst einmal passen. Gruss Ingo
Oliver J. schrieb: >
1 | > LED_AN(); |
2 | > _delay_ms(500); |
3 | > LED_AUS(); |
4 | > _delay_ms(500); |
5 | >
|
Das ist doch kein Programm ... Gibt es die Funktionen LED_AN() und LED_AUS() ? Da muß noch 'ne Schleife drum rum. Vermutlich doktort er nun daran herum ... %) Gruß Jobst
Jobst M. schrieb: > Das ist doch kein Programm ... Oh die Schleife hab ich glatt vergessen. Aber da hätte er ja selbst drauf kommen müssen.
1 | while(42) |
2 | {
|
3 | LED_AN(); |
4 | _delay_ms(500); |
5 | LED_AUS(); |
6 | _delay_ms(500); |
7 | }
|
Gruß Oliver
Hi. Ich habe gestern einfach aufgehört weil ich keine Lust mehr hatte. Das mit der Schleife oder LED_an oder so wäre auch nicht das Problem ^^ Ich habe wie vorgeschlagen mal ne LED im Sekundentakt ein und aus geschaltet. Gemessem habe ich auch mal: In 60 Sekunden blinkt die LED 52 mal. würde bedeuten, dass die Taktrate vom Controller theotetisch 52/60 * 4MHz = 3,46666 MHz wäre. wenn ich die Daten vom STK500 auslese, beträgt die Taktrate vom "Clock generator" 3,68MHz. Ich weiß nicht, ob das die Frequenz ist, mit der der Controller laufen sollte, da im Crystal-slot noch ein Quarz steckt mit 4MHz. Ich hoffe, wie immer, dass diese Informationen bei der fehlersuche weiterhelfen ;)
Hi >Ich hoffe, wie immer, dass diese Informationen bei der fehlersuche >weiterhelfen ;) Dann steck mal den Jumper OSCSEL um. Einen 4MHz hast du aber im Sockel stecken? MfG Spess
ok, ich habe den Jumper von OSCEL mal umgesteckt. vorher war er auf OSCEL1, ich habe ihn auf die andere Position gesteckt. Wenn er weg ist, läuft der Controller nicht mehr, obwohl der Jumper XTAL gesetzt ist. Wenn der Jumper auf OSCEL umgesteckt ist, blinkt die LED etwa 55 mal/60 Sekunden.
Hi Damit der AVR mit dem Quarzoszillator des STK läuft muss - der OSCAL-Jumper die beiden linken Pins verbinden - XTAL1-Jumper gesteckt - Quarz im CRYSTAL-Sockel gesteckt sein. Die Bedeutung der Jumper ist übrigens auf der Unterseite des STK aufgedruckt. MfG Spess
Also ist er nachdem ich den Jumper umgesteckt habe mit dem Quarzoszillator gelaufen. Ich werde mal die Baudrate etwas verringern, vielleicht kommt dann ja nicht so ein Schrott am Rechner an ;) Freundliche Grüße, und DANKE für die nette Hilfe, Tim
Hey Leute, ich habe in allerletzter Verzweiflung den Controller wieder auf meine experimentierplatine gesteckt und es kommt tatsächlich "ABCDEabcde" in Dauerschleife beim Rechner an :D Scheint so als würde das Problem bei der Taktquelle des STK500 liegen. Bevor die Glaskugeln herausgeholt werden, sage ich lieber gleich, welche Jumper gesteckt sind: BSEL2 OSCEL1 oder OSCEL (kommt der gleiche Schrott an) RESET AREF VTARGET Wieder hoffnugsvolle Grüße, Tim
Hmmm ... :-/ Also, bei 55/s passt das recht gut mit 3.68MHz Es passt allerdings auch ungefähr: 4MHz 55 --------- = ---- 3.68MHz 52 Daher habe ich die Vermutung, daß "_delay_ms(500);" nicht ausreichend genau ist. Gruß Jobst
@Jobst M. (jobstens-de) >Daher habe ich die Vermutung, daß "_delay_ms(500);" nicht ausreichend >genau ist. Doch, ist es, wenn die Optimierung im Compiler eingeschaltet ist -Os. Im Übrigen. http://www.mikrocontroller.net/articles/AVR_Checkliste#UART.2FUSART Befolge ALLE Hinweise korrekt, und du wirst Erfolg haben. MfG Falk
Also ist doch diese Vermutung korrekt: Jobst M. schrieb: > Also, bei 55/s passt das recht gut mit 3.68MHz Aber es wurde ja auch schon geschrieben, daß es im anderen Board nun läuft. Was geht da ab? :-D Gruß Jobst
Jetzt bin ich auch etwas verwirrt: Wenn auf dem STK500 OSCEL1 (also Oszillator) gesetzt ist, dann sinds 55/60. Wenn OSCEL anders gesetzt ist, dann sinds 52/60. Wenn ich aber den Controller auf die Explatine setze, sinds 55/50. Und die Datenübertragung funktioniert einwandfrei. Wenn der Controller auf dem STK500 sitzt, (egal wie OSCEL steht) kommt nur Schrott an. Irgendwas läuft unlogisch auf dem STK500!? Wer kann mir sagen was forgeht? (Ich habe auch mal die AVR-Checkliste durchgelesen und auch -os werde ich mir mal ansehen)
Habe das Programm an die vermeintliche Taktrate des STK500 angeglichen. Statt vorher 4MHz habe ich einfach mal 3,686MHz eingestellt. Mit dem Oszillator kommt jetzt auch das richtige an, mit der anderen Einstellung kommt wieder Müll an. Ich bin zwar verwirrt, aber aber trotzdem erleichtert, dass es soweit funktioniert. Wenn sich jemand vorstellen kann, was denn jetzt der Fehler mit dem STK500 war, würdeich mich auch freuen :D. Vielen Dank für die Unterstützung, Tim
Tim mit m schrieb: > Scheint so als würde das Problem bei der Taktquelle des STK500 liegen. Was du nicht sagst. > Wenn sich jemand vorstellen kann, was denn jetzt der Fehler mit dem > STK500 war, würdeich mich auch freuen :D. Es gibt ein Manual und ein Schematic. Schau da mal selbst rein. Gruß Oliver
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.