[winavr] _delay_ms dauert zu lange

[Christian M. (Gast)]

Ich hab mir dieses Ding gekauft: eStick 
http://www.technikum-wien.at/studien/bachelorstudien/elektronik/estick/
Das Ding wird von der FH Technikum Wien für wenig Geld am Tag der 
offenen Tür verkauft.

Das ist ein µC Starterkit mit einem at90usb162 der mit 8Mhz getaktet ist 
und per Flip über USB Programmiert wird.

Funktioniert auch wunderbar nur folgendes:

Wenn ich eine Schleife Programmiere die ein _delay_ms enthält zB:

  while(1)
  {
  PORTB = 0xFF;

    for(i=0;i<256;i++)
    {
      PORTB = ~i;  /* Wert an LED */
      _delay_ms(10);
   
    }
  }

Dann dauert ein Durchlauf der for-Schleife nicht 2,56 Sekunden sondern 
20,5 Sekunden. Exakt 8-mal solange wie eigentlich gewünscht.

Die Frequenzangabe im AVR-Studio ist mit 8000000 auch korrekt 
eingestellt und das Ding ist wirklich mit 8Mhz getaktet (oder zumindest 
ungefähr, habe es nur mit dem Oszi überprüft)

Man verzeihe mir meine blöde Frage: Was mache ich falsch?
Kann da noch irgendwo irgendwas falsch eingestellt sein?

Danke schon mal im Voraus

[Hannes L. (hannes)]

Es soll AVRs mit integrierten Timern geben...

...

[Andreas K. (a-k)]

Und die CKDIV8 Fuse?

[Christian M. (Gast)]

Danke für den Hinweis!
Mit Flip kann ich Fusebits weder auslesen noch verändern.

Irgendwie Doof, ich mal ein pin togglen und schauen ob ich so irgendwie 
auf den Takt komme.

[Andreas K. (a-k)]

Takt im Studio auf 1MHz definieren, dann passt das Delay wieder.

[Christian M. (Gast)]

Ja, das stimmt natürlich auch wieder.
Es wundert mich nur, weil in den Beispielen und in den Unterlagen von 
8Mhz die Rede ist.

Ich werde mich bei Gelegenheit mal dort erkundigen.

[Andreas K. (a-k)]

Man kann die Fuses auch ohne Programmer per Programm auslesen.

#ifndef SPMCSR
#define SPMCSR SPMCR
#endif

void fuses(void)
{
    SPMCSR = 1<<BLBSET | 1<<SPMEN;
    uint8_t lo = pgm_read_byte(0);
    SPMCSR = 1<<BLBSET | 1<<SPMEN;
    uint8_t hi = pgm_read_byte(3);
    PRINTF("Fuses: low=%02X high=%02X\n", lo, hi);
}

Obacht: Die exakte Code-Sequenz ist hier wichtig, die ersten 4 Zeilen 
der Funktion sollten also exakt so bleiben und Optimierung muss 
eingeschaltet sein. Getestet mit WinAVR 20070525 ATmega32.

[Christian M. (Gast)]

Danke!

Sofern ich das jetzt Richtig kapiert habe, ist das entsprechende 
Fuse-bit gesetzt.

[Andreas K. (a-k)]

Obacht Sprache. Bei einer gesetzten (programmierten) Fuse ist das 
Fusebit gelöscht und umgekehrt:

CKDIV=1 = /1 = Fuse gelöscht
CKDIV=0 = /8 = Fuse programmiert

Das hat schon manchen Einsteiger aus der Kurve geworfen.

[Jörg W. (dl8dtl) (Moderator)]

Optimierung aktiviert?  Gibt zwar eine Warnung, wenn du's nicht
machst, aber hast du dir die Warnungen auch angesehen?

[Christian M. (Gast)]

Der Controller hat 4 Fusebytes

void fuses(void)
{
    SPMCSR = 1<<BLBSET | 1<<SPMEN;
    uint8_t lo = pgm_read_byte(0);
    SPMCSR = 1<<BLBSET | 1<<SPMEN;
    uint8_t hi = pgm_read_byte(3);
//    PRINTF("Fuses: low=%02X high=%02X\n", lo, hi);
  PORTB = lo;
}

So komme ich IMO an das richtige Fusebit
(Wie das Wirklich funktioniert habe, ich gestehe, überhauptnicht 
verstanden)

Gesetzt = 0, ist mir klar!



Warnung hats nicht gegeben (ausgenommen, die nicht verwendete Variable 
"hi")

Optimierung hab ich im Avr-Studio unter "Project Options"
auf "-Os" gestellt(also nichts verändert). Ist das Richtig?

[Andreas K. (a-k)]

Yep, stimmt so. Wenn also CKDIV8=0 dabei rauskam passt es, denn der 
effektive Takt ist dann 1MHz.

[Andreas K. (a-k)]

Christian M. wrote:

> (Wie das Wirklich funktioniert habe, ich gestehe, überhauptnicht
> verstanden)

Ist nichts anderes als das was im Datasheet steht (Boot Loader../Self 
Programming.../Reading the Fuse...). Die 2 Bits setzen und innerhalb von 
3 Takten das entsprechende Byte per LPM lesen.

[Christian M. (chrisreg)]

Okay, danke!

[Christian M. (chrisreg)]

Eine, möglicherweise blöde, Frage habe ich noch.

Kann die USB Funktion und der Bootloader funktionieren, wenn das CKDIV8 
fuse versehentlich gesetzt ist?

Spricht wäre es möglich, dass das Fuse-Bit falsch programmiert ist aber 
der  Controller trotzdem funktioniert nur langsamer?

danke, Christian

[Andreas K. (a-k)]

Der USB Takt ist von der Fuse nicht betroffen.

[Andi (Gast)]

Andreas K. schrieb:
> Man kann die Fuses auch ohne Programmer per Programm auslesen.

Geht das auch umgekehrt? Kann ich über die Software die Fuses setzen?
In einem Programm habe ich folgendes gefunden:

FUSES =
{
   .low      = 0xFF,
   .high     = 0xD9,
   .extended = 0xFD,
};

Kann mir hier jemand diesbezüglich weiterhelfen?

[Philipp S. (pschaefer)]

möglich ist das. Aber der Programmer muss das unterstützen.

siehe hier: 
http://www.nongnu.org/avr-libc/user-manual/group__avr__fuse.html

[Stefan E. (sternst)]

Philipp Schaefer schrieb:
> möglich ist das. Aber der Programmer muss das unterstützen.

Ich glaube eher er meint, ob das Programm auf dem µC selber direkt die 
Fuses schreiben kann. Und das geht nicht.

[Verwirrter Anfänger (Gast)]

Soweit ich weiss kann man die CKDIV8 fuse auch aus dem Programm heraus 
setzen. Beim Atmega32u4 zum Beispiel über das CLKPR – Clock Prescaler 
Register.

[Verwirrter Anfänger (Gast)]

Für den AT90USB162 sollte das auch gehen:

// 8 MHz
CLKPR &= ~((1 << CLKPS3) | (1 << CLKPS2) | (1 << CLKPS1) | (1 << CLKPS0));

// 1 MHz
CLKPR &= ~((1 << CLKPS3) | (1 << CLKPS2));
CLKPR |=   (1 << CLKPS1) | (1 << CLKPS0);

[spess53 (Gast)]

Hi

>Soweit ich weiss kann man die CKDIV8 fuse auch aus dem Programm heraus
>setzen. Beim Atmega32u4 zum Beispiel über das CLKPR – Clock Prescaler
>Register.

Ein gesetzte CKDIV8-Fuse bewirkt, das CLKPR nach einem Reset auf einen 
Teiler von acht gesetzt wird. Das Überschreiben von CLKPR hat aber 
keinen Einfluss auf die CKDIV8-Fuse.

MfG Spess

[Verwirrter Anfänger (Gast)]

spess53 schrieb:
> Hi
>
>>Soweit ich weiss kann man die CKDIV8 fuse auch aus dem Programm heraus
>>setzen. Beim Atmega32u4 zum Beispiel über das CLKPR – Clock Prescaler
>>Register.
>
> Ein gesetzte CKDIV8-Fuse bewirkt, das CLKPR nach einem Reset auf einen
> Teiler von acht gesetzt wird. Das Überschreiben von CLKPR hat aber
> keinen Einfluss auf die CKDIV8-Fuse.
>
> MfG Spess

Das stimmt natürlich, da hab ich mich sehr schlecht ausgedrückt.

Was ich eigentlich sagen wollte, ist das dies für den OP ein einfacher 
workaround ist, wenn er Programme mit 8MHz ausführen will.

[Stefan E. (sternst)]

Verwirrter Anfänger schrieb:
> Was ich eigentlich sagen wollte, ist das dies für den OP ein einfacher
> workaround ist, wenn er Programme mit 8MHz ausführen will.

Um den OP geht es aber gar nicht mehr (mal auf das Datum geschaut?).
Es geht momentan um
> Andreas K. schrieb:
>> Man kann die Fuses auch ohne Programmer per Programm auslesen.
>
> Geht das auch umgekehrt? Kann ich über die Software die Fuses setzen?
Und da lautet die Antwort ganz simpel: Nein.

[Oliver J. (skriptkiddy)]

Christian M. schrieb:
> Der Controller hat 4 Fusebytes
> void fuses(void)
> {
>     SPMCSR = 1<<BLBSET | 1<<SPMEN;
>     uint8_t lo = pgm_read_byte(0);
>     SPMCSR = 1<<BLBSET | 1<<SPMEN;
>     uint8_t hi = pgm_read_byte(3);
> //    PRINTF("Fuses: low=%02X high=%02X\n", lo, hi);
>   PORTB = lo;
> }


Andreas K. schrieb:
> Man kann die Fuses auch ohne Programmer per Programm auslesen.
> #ifndef SPMCSR
> #define SPMCSR SPMCR
> #endif
>
> void fuses(void)
> {
>     SPMCSR = 1<<BLBSET | 1<<SPMEN;
>     uint8_t lo = pgm_read_byte(0);
>     SPMCSR = 1<<BLBSET | 1<<SPMEN;
>     uint8_t hi = pgm_read_byte(3);
>     PRINTF("Fuses: low=%02X high=%02X\n", lo, hi);
> }

Sorry fürs Leichenfleddern, aber da der Thread hier im Wiki verlinkt 
ist, muss ich mich doch zu Wort melden. Man kann mittlerweile die Fuses 
und die Lock-Bits so hier auslesen:

#include <avr/boot.h>

int main()
{
    uint8_t lf = boot_lock_fuse_bits_get(GET_LOW_FUSE_BITS);
    uint8_t hf = boot_lock_fuse_bits_get(GET_HIGH_FUSE_BITS);
    uint8_t ef = boot_lock_fuse_bits_get(GET_EXTENDED_FUSE_BITS);
    uint8_t lk = boot_lock_fuse_bits_get(GET_LOCK_BITS);
}

Grüße
Oliver