Hi.
Habe mal wieder ein kleines Problem.
Seit gut 2 Tagen versuche ich jetzt mit meinem Atmega8 einen Char an den
PC zu senden. Aber irgendwie passiert überhaupt nichts.
Eigentlich sollte es doch schon funktionieren oder?
Das STK ist auf standard gestellt. In der Anleitung steht, dass es
standardmäßig 3,68mhz sei.
Woran könnte es liegen?
Hab schon 3 Terminalprogramme ausprobiert, aber es kommt wirklich gar
nichts an.
Evtl. habt ihr ein paar Tipps für mich!
MfG
Conehead
Hi
>Das STK ist auf standard gestellt. In der Anleitung steht, dass es>standardmäßig 3,68mhz sei.
Hast du bei den HW-Settings nachgesehen? Abgesehen davon ist der interne
Takt des STK500 nicht sonderlich genau.
>Hab schon 3 Terminalprogramme ausprobiert, aber es kommt wirklich gar>nichts an.
Die Verbindung vom Port zu RXD/TXD ist in Ordnung?
MfG Spess
Ne habs nur über den PC.
Ein LED-Dongle hab ich nicht.
Es ist auf Com6.
Und es funktioniert auch, da ich ja zumindest den Chip immer über den
selben Port flashe.
Ich stecke dann nur das Kabel um.
1) Der Hauptfehler ist die falsche Berechnung des UBRR-Wertes. Nach
Datenblatt wäre richtig:
#define USART_BAUD_SELECT (F_CPU/16/USART_BAUD_RATE-1)
Wenn das Ergebnis nicht ganzzahlig ist, wird allerdings nicht gerundet,
sondern abgeschnitten. Hier gibt es eine "cleverere" Berechnung:
AVR-Tutorial: UART
2) Oszillator-Takte sind nicht "irgendwie", sondern genau:
#define F_CPU 3686400UL
Mit dem "UL" teilt man dem Präprozessor das Format (Unsigned Long) mit,
damit er bei späteren Berechnungen nicht "aus Versehen" eine negative
Zahl annimmt.
Welchen Oszillator-Takt das STK500 ausgibt, kannst Du im STK500-Plugin
von AVR-Studio 4 abfragen: Im STK500-Fenster den Reiter "HW Settings"
wählen und dort bei "Clock Generator" auf "Read" klicken.
3) (1<<USBS) bedeutet 2 (zwei) Stopp-Bits. Willst Du das wirklich? Lass
es einfach weg, dann bleibt es bei 1 (einem) Stopp-Bit.
Bei wirren Ausgaben, drück mal für 2 Sekunden den RESET-Knopf auf dem
STK500-Board.
viele grüße
ralph
Hi
>3) (1<<USBS) bedeutet 2 (zwei) Stopp-Bits. Willst Du das wirklich? Lass>es einfach weg, dann bleibt es bei 1 (einem) Stopp-Bit.
Schon mal überlegt, wen das stören könnte?
MfG Spess
spess53 schrieb:>>3) (1<<USBS) bedeutet 2 (zwei) Stopp-Bits. Willst Du das wirklich? Lass>>es einfach weg, dann bleibt es bei 1 (einem) Stopp-Bit.>> Schon mal überlegt, wen das stören könnte?
Na mich zum Bleistift. Ich hab mich ja schon bei der
Schnarchgeschwindigkeit von 9600 Baud und bei der fehlenden
Initialisierung von UBRRH zurückgehalten.
viele grüße
ralph
Hi
>Na mich zum Bleistift. Ich hab mich ja schon bei der>Schnarchgeschwindigkeit von 9600 Baud und bei der fehlenden>Initialisierung von UBRRH zurückgehalten.
UBRRH ist nach Reset mit $00 initialisiert. Was sollte man daran ändern?
Und 9600Bd haben mir meistens ausgereicht.
MfG Spess
Doh...das man umstecken muss auf dem Board muss man auch erst mal wissen
:D
Jetzt empfange ich etwas...jedoch nicht das richtige, sondern wilde
Zeichen.
Die Baud-Rate habe ich so bestimmt:
#define F_CPU 3686400UL
#define USART_BAUD_RATE 9600
#define USART_BAUD_SELECT
((F_CPU+(USART_BAUD_RATE*8))/(USART_BAUD_RATE*16))-1
So steht es ja zumindest oben in dem Link.
Avr Studio gibt auch 3,686 Mhz an.
Sicher dass es dann auch 3686400UL sein sollte oder 3686000?
Habs rausgefunden!
Fuse für den externen osc oder sowas war noch nicht eingeschaltet.
Hab jetzt einfach F_CPU = 1 mhz gesetzt und nun scheint es zu klappen ;)
Vielen Dank!
Hmm doch noch ein Problem.
Jetzt wollte ich Zeichen empfangen, aber irgendwie kommt immer etwas
anderes an :/
data = receiveChar();
sendChar(data);
unsigned char receiveChar (void) {
while(!(UCSRA & (1<<RXC))) {}
return UDR;
}
Jemand auch da ne Idee, wo das Problem sein könnte?
Ich meinte damit nur:
Er empfängt das falsche Zeichen.
Also nicht immer etwas unterschiedliches, sondern einfach ein falsches
Zeichen.
Wenn ein Char empfangen wird, lasse ich ihn sofort wieder zurücksenden.
Und dabei kommt nichts sinnvolles raus.
So hab nochmal die Hexzahlen geprüft.
Wenn ich eine 1 Sende (31), dann kommt eine 91 heraus.
Bei einer 2 (32) kommt eine 92 heraus usw.
Bei einem kleinen a (61) kommt ein A1 heraus.
Als wäre alles etwas verschoben.
Ralph B. schrieb:> 3) (1<<USBS) bedeutet 2 (zwei) Stopp-Bits. Willst Du das wirklich? Lass> es einfach weg, dann bleibt es bei 1 (einem) Stopp-Bit.
wenn es das nicht ist, wäre mein tipp, dass der interne oszillator zu
ungenau ist.
Hi
>Bei einem kleinen a (61) kommt ein A1 heraus.>Als wäre alles etwas verschoben.
Deine Baudrate stimmt nicht (Stopbit wird als Datenbit gelesen).
MfG Spess
Hmm das hab ich schon rausgenommen.
Aber wie kann es sein, dass das Senden immer zu 100% funktioniert und er
beim empfangen solche Probleme macht.
Und das Ergebnis ändert sich ja nicht jedes mal.
Es ist einfach nur falsch
Hi
>Aber wie kann es sein, dass das Senden immer zu 100% funktioniert und er>beim empfangen solche Probleme macht.
Weil PC und µC anders ticken.
Ich hatte dir schon weiter oben geschrieben, das der interne Takt des
STK500 nicht sehr genau ist. Nimm einen Quarz.
MfG Spess
Ich bin davon ausgegangen, dass ich den internen momentan verwende und
nicht den vom STK. Zumindest schließe ich es daraus, dass ich 1mhz
angegeben habe und es so funktioniert.
spess53 schrieb:> Ich hatte dir schon weiter oben geschrieben, das der interne Takt des> STK500 nicht sehr genau ist. Nimm einen Quarz.
Stammt der nicht von einem Quarz und einem Hardware-Timer? Zumindest
würde der Schaltplan das nahelegen...
Ich würde das sehr wohl als genau bezeichnen.
Sollte Conehead einen Quarz haben, ist das natürlich das Mittel der
Wahl.
Hi
Also den internen RC-Oszillator des Controllers. Der ist genauso
grenzwertig.
Außerdem ergeben schon genaue 1MHz und 9600Bd einen Baudratenfehler von
7%.
MfG Spess
Dann versuch 4800Baud/s als Baudrate oder/und den Takt vom STK500 für
den Atmega8.
XTAL1 Jumper muss dann geschlossen und OSCSEL zwischen 1 und 2
geschlossen sein.
Hi
>Kurz und knapp:>Ich habe gerade keinen hier ;)
Ok. Dann setze den Controllertakt erst mal auf 8 MHz. Da hast du für die
Baudrate eine feinere Abstimmung. Wenn das nicht hilft, dann mit dem
OSCCAL-Register den Takt in die Reihe bringen. Zum Spielen sollte das
erst mal reichen.
MfG Spess
@Conehead:
Der interne Oszillator des STK500 ist schon ziemlich genau. Zumindest
reicht es, um UBRR (mit Rundung) richtig zu belegen. Andererseits hat
der interne RC-Oszillator des ATMega8 für eine saubere Übertragung die
falschen Taktraten. Ich schaffe es mit dem internen Takt noch nicht
einmal, eine Sendung richtig zu empfangen, geschweige denn irgendetwas
Nachvollziehbares als Echo zu bekommen- welches Terminalprogramm benutzt
Du?
Nimm den Oszillator vom STK500:
Im STK500-Fenster unter Fuses wählst Du bei SUT_CKSEL "Ext.
Crystal/Resonator High Freq.; Start-up time: 16K CK +64 ms" und klickst
auf "Program". Mit einem Klick auf "Read" prüfst Du nach, ob diese
Einstellung auch angekommen ist.
Dann verbindest Du auf dem STK500 bei OSCSEL Pin 1 und 2 mit einem
Jumper. Solltest Du irgendwann einen Quarz in CRYSTAL benutzen wollen,
dann müssen Pin 2 und 3 gejumpert werden. Die Stifte von XTAL1 müssten
bereits mit einem Jumper verbunden sein.
Im Programm gibst Du als F_CPU den Wert an, der Dir das STK500-Plugin
beim Read von "HW Settings" unter "Clock Generator" im weißen Feld
ausgespuckt hat (Copy&Paste). Kompilieren, Flashen, RESET auf dem STK500
drücken.
Alles andere ist Gewurschtel.
Folgendes Programm funktioniert bei mir ohne Beanstandung:
Danke noch mal an alle.
Habs jetzt mal versucht auf extern zu stellen und es funktioniert auch!
@Ralph:
Ich benutze HTerm und hab es jetzt auch zum laufen bekommen mit dem
internen Takt.
