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
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
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".
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
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
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
