ATmega8515: Änderung der Taktfrequenz durch MKII?

[Robert D. (d0rni)]

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

[spess53 (Gast)]

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)]

Robert Dorn schrieb:
> Die Fuse steht auf int.Osc. 4MHz.

Poste mal deine Fuse-Werte.

[... (Gast)]

fosc=4MHz
19,2kbps
bei U2X=0 ist UBRR=12 oder 0xc
bei U2X=1 ist UBRR=25 oder 0x19

[Robert D. (d0rni)]

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.

#include<avr/io.h>

#define BAUD 2400UL
//#define TAKT 1000000UL
#define F_CPU 4000000UL  

unsigned char Banane;
int Zahl;
int Zahl2;
int BAUD2 = 19200;

void INIT_USART(void)
{

  UBRRL = (F_CPU / (16ul * BAUD2))-1;
  UBRRH = 0;
  UCSRA |= (0 << U2X);
  UCSRB |= (1 << TXEN) | (1 << RXEN);
  UCSRC |= (1 << URSEL) | (1 << UCSZ1) | (1 << UCSZ0);

}

Gruss Robert

[spess53 (Gast)]

Hi

Wie stellst du die Baudratenänderung fest?

MfG Spess

[Robert D. (d0rni)]

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

[spess53 (Gast)]

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

[Robert D. (d0rni)]

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

[spess53 (Gast)]

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

[Robert D. (d0rni)]

Hallo,

ja, habe ich. Wo könnte ich also messen um dir mehr Input zu geben?

[spess53 (Gast)]

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)]

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)]

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.

[Chris L. (kingkernel)]

lass doch testweise mal mithilfe von

DDRD |= (1 << PD0);
while(1)
{
  PORTD ^= (1 << PD0);
  _delay_ms(1);
}

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.

[Robert D. (d0rni)]

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

[spess53 (Gast)]

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

[Robert D. (d0rni)]

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

[spess53 (Gast)]

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)]

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.

[Simon K. (simon)]

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

[spess53 (Gast)]

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)]

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)]

Simon K. schrieb:
> Bei jedem Mitarbeiter bei Atmel?

Bei denen vielleicht auch ;)

[spess53 (Gast)]

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)]

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.