Mahlzeit, ich habe ein kleines Verständnisproblem was die Einstellung des internen Oszillators des Atmega8515 angeht. Die Fuse steht auf int.Osc. 4MHz. Wenn ich ein Programm mit einer FCPU = 4000000UL und einer Baudrate von 19200 konfiguriere, bekomme ich korrekte Zeichen bei 19200Baud nur mit angeschlossenem AVRISPMKII und mit abgezogenem AVRISPMKII und neu gestartetem µC bei 38400Baud. Das ganze passiert im STK500. Rechnerisch wären FCPU/(16xBaud)=13. Wenn ich nun zurückrechne: 13x16x38400 komme ich auf ca. 8Mhz. Wo liegt da mein Denkfehler? Ich möchte schon meine Applikation ohne MKII mit der programmierten Geschwindigkeit laufen lassen. Gruss Robert
Gast
#2701691
Hi >Das ganze passiert im STK500. Rechnerisch wären FCPU/(16xBaud)=13. Die richtige Formel für UBRR ist aber (FCPU/(16xBaud))-1. >Ich möchte schon meine >Applikation ohne MKII mit der programmierten Geschwindigkeit laufen >lassen. Wer hindert dich daran? Allerdings kannst du eine stabile Verbindung mit dem internen Oszillator vergessen. MfG Spess
Gast
#2701731
Robert Dorn schrieb: > Die Fuse steht auf int.Osc. 4MHz. Poste mal deine Fuse-Werte.
Gast
#2701740
fosc=4MHz 19,2kbps bei U2X=0 ist UBRR=12 oder 0xc bei U2X=1 ist UBRR=25 oder 0x19
Guten Morgen! Fuses sind auf 0xC3 und 0xD9. Alles soweit original, bis auf den "Int. RC Osc. 4 MHz; Start-up time: 6 CK + 0 ms". Das dieser interne Oszillator ohne einen ungeraden Baudratenquarz mit Fehlern bei asynchroner Übertragung behaftet ist, ist mir schon bewusst. Ich weiß nur immer noch nicht, warum sich die Baudrate ändert wenn ich den AVRISP MKII anstöpsel. Da sich der Code nicht ändert kann sich ja nur die Taktrate ändern. Da gibts ja noch die SPI Frequenz, die steht aber weiterhin auf 125kHz. Ich stehe da gerade ein bischen auf dem Schlauch - vor allem weil die Baudrate nur dann passt, wenn der MKII angeklemmt ist. Hier mal der Vorkopf und das USART_INIT.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
Gruss Robert
Gast
#2701839
Hi Wie stellst du die Baudratenänderung fest? MfG Spess
Ich hab nen Terminal nebenbei am laufen. Da hat mal ein Tobias Hammer einen richtig guten Terminal namens hterm irgendwo im Netz gepostet, da kann ich während der Übertragung quasi ausprobieren, mt welcher Übertragungsrate das Board nun sendet. Die Übertragungsrate stimmt dann auch mit z.Bsp. Hyperterminal oder Term95 vom frühen NC überein. Habe auch ne LED bei jedem Sendevorgang aufleuchten lassen, der Blinktakt verlangsamt sich wenn das MKII dran steckt. Robert
Gast
#2701870
Hi An dieser Stelle hast du schon mal einen Fehler: UBRRL = (F_CPU / (16ul * BAUD2))-1; UBRRH = 0; 16-Bit-Register werden in der Reihenfolge H-L geschrieben. Siehe 'Accessing 16-bit Registers' im Datenblatt. MfG Spess
Hallo, danke für den Hinweis. Habe es mal direkt abgeändert - zeigt aber keine Änderung. Ich mache nachher mal den Versuch mit einem anderen µC um einen Fehler dessen auszuschließen. Robert
Gast
#2701904
Hi Also bei mir ändert ändert sich mit deiner Konfiguration (ATMega8515/STK500/AVR ISP MKII) nichts. Egal ob ISP dran oder nicht. Hast du einen Oszi? MfG Spess
Hallo, ja, habe ich. Wo könnte ich also messen um dir mehr Input zu geben?
Gast
#2701930
Hi
>ja, habe ich. Wo könnte ich also messen um dir mehr Input zu geben?
Na einfach an PORTD1 hängen.
Wie sieht denn deine Senderoutine aus?
MfG Spess
Gast
#2701968
Robert Dorn schrieb: > Fuses sind auf 0xC3 und 0xD9. Alles soweit original, bis auf den "Int. > > RC Osc. 4 MHz; Start-up time: 6 CK + 0 ms". Versuch mal die Fuses auf 0xE3 und 0xD9. Weil mit 6 CK und 0 ms, kann es bei einer "langsam" ansteigenden Versorgungsspannung zu Problemen kommen.
Gast
#2701970
Robert Dorn schrieb: > Das dieser interne > > Oszillator ohne einen ungeraden Baudratenquarz mit Fehlern bei > > asynchroner Übertragung behaftet ist, ist mir schon bewusst. Liegt bei <0,2%, insofern kein Thema.
lass doch testweise mal mithilfe von
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
nen rechtecksignal ausgeben und schau, ob sich dessen frequenz auch ändert, wenn du deinen Dongle abziehst. Bei mir ändert sich da nämlich auch nichts an der Frequenz.
... schrieb: > Versuch mal die Fuses auf 0xE3 und 0xD9. > Weil mit 6 CK und 0 ms, kann es bei einer "langsam" ansteigenden > Versorgungsspannung zu Problemen kommen. Das hat funktioniert, bin jetzt auf "Int. RC Osc. 4 MHz; Start-up time: 6 CK + 64 ms" gegangen, die Taktfrequenz ist gleich geblieben. D.h. er hatte gleich beim einschalten seine 4 Mhz, beim aufstecken des ISP behielt er seine Taktfrequenz bei. Sehr schön. Ich war eben bei Conrad einkaufen und habe das gleiche mit einem anderen 8515 ausprobiert - funktioniert auch. Ihr seid klasse! Gruss Robert
Gast
#2702067
Hi >Sehr schön. Ich war eben bei Conrad >einkaufen und habe das gleiche mit einem anderen 8515 ausprobiert - >funktioniert auch. Dann hättest du auch mal einen anständigen AVR kaufen können. Da gibt es diese Effekte nicht. MfG Spess
Welchen könntest du denn zum Anfang empfehlen? Ich habe mir noch nen 3.6864 Quarz, Attiny2313 und nen Attiny13 zum spielen mitgenommen. Gruss Robert
Gast
#2702126
Hi >Welchen könntest du denn zum Anfang empfehlen? Ich habe mir noch nen >3.6864 Quarz, Attiny2313 und nen Attiny13 zum spielen mitgenommen. ATMega644P. Oder gleich einen ATMega1284P. MfG Spess
Gast
#2702161
spess53 schrieb: > Dann hättest du auch mal einen anständigen AVR kaufen können. Da gibt es > > diese Effekte nicht. Den Effekt hast du bei jedem Atmel weil, du musst dem Oszillator schon Gelegenheit zum Einschwingen geben bevor du die Taktfrequenz frei gibst. Kürzere Zeiten kannst du nur einstellen, wenn du mit einem externen Quarzozillator arbeitest.
... schrieb: > spess53 schrieb: >> Dann hättest du auch mal einen anständigen AVR kaufen können. Da gibt es >> >> diese Effekte nicht. > > Den Effekt hast du bei jedem Atmel Bei jedem Mitarbeiter bei Atmel?
Gast
#2702202
Hi >Den Effekt hast du bei jedem Atmel weil, du musst dem Oszillator schon >Gelegenheit zum Einschwingen geben bevor du die Taktfrequenz frei gibst. Beim ATMega8515 bleibt der Takt nach dem Einschalten auf 8MHz, obwohl per Fuses 4MHz eingestellt sind. Bei angeschlossenem ISP sind die 8MHz auch kurzzeitig sichtbar, schalten dann aber auf die 4MHz um. Möglicherweise löst der AVR ISP MKII nochmal einen Reset aus. Im Datenblatt findet sich lediglich der Hinweis, das die 6CK+0ms beim internen RC-Oszillator in Verbindung mit der BOD zu benutzen ist. Hat aber bei mir keinen Einfluss gehabt. Mit einem ATMega644P habe ich den Effekt nicht nachvollziehen können. Kann natürlich daran liegen, das auf die 4MHz per Software umgeschaltet werden muss. Das waren aber bei mir die ersten zwei Befehle (Assembler) im Programm. MfG Spess
Gast
#2702284
spess53 schrieb: > Im Datenblatt findet sich lediglich der Hinweis, das die 6CK+0ms beim > > internen RC-Oszillator in Verbindung mit der BOD zu benutzen ist. Da findet sich aber auch der Hinweis auf Fast rising power und Slowly rising Power: Table 13. Start-up Times for the Internal Calibrated RC Oscillator Clock Additional Delay from Reset (VCC = 5.0V) Recommended Usage 6 CK – BOD enabled 6 CK 4.1 ms Fast rising power 6 CK 65 ms Slowly rising power spess53 schrieb: > Mit einem ATMega644P habe ich den Effekt nicht nachvollziehen können. Geht auch nicht, da der von zu Hause aus nur 8MHz macht. Da kann dann noch der Clockdivider durch 8 per Fuse eingeschaltet werden. Aber auch da findest du die verschiedenen Additional Delays.
Gast
#2702290
Simon K. schrieb: > Bei jedem Mitarbeiter bei Atmel? Bei denen vielleicht auch ;)
Gast
#2702291
HI >Da findet sich aber auch der Hinweis auf Fast rising power und Slowly >rising Power: Und auch auf BOD. Lt. der von dir zitierten Tabelle ist 6CK+0ms in Verbindung mit eingeschalteter BOD zulässig. Oder? MfG Spess
Gast
#2703022
spess53 schrieb: > nd auch auf BOD. Lt. der von dir zitierten Tabelle ist 6CK+0ms in > Verbindung mit eingeschalteter BOD zulässig. Oder? Das ist richtig, dann habe ich falsch verstanden weil du "lediglich" geschrieben hattest.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.