Delay bei ATtiny4

[Tim H. (hotty)]

Hallo,

ich spiele gerade mit dem ATtiny4 etwas rum... es soll eignetlich nur 
ein einfaches Blinklicht mit 2 LEDs werden.
Zum Test habe ich also mal ein Programm geschrieben, was PORTB an und 
aus machen soll:

#include <avr/io.h>

#define F_CPU 1000000UL
#include <util/delay.h>



int main(void)
{
  DDRB = 0xFF;
    PORTB = 0x00;
  
    while(1)
    {
    PORTB = 0x00;
    _delay_ms(500);
    PORTB = 0xFF;
    _delay_ms(500);
    }
}

das funktioniert soweit auch ganz gut. Nur komisch finde ich es wenn ich 
das Delay auf z.b. 100ms setzen möchte. Dann sagt mir der Compiler:

 error: unable to generate reloads for:
 internal compiler error: in find_reloads, at reload.c:3821

Wenn ich bei 100ms F_CPU auf 8000000 setze läuft das Projekt wieder ohne 
Fehler durch.
Ich kann mir jetzt irgendwie nur vorstellen, dass die delay Bibilotheken 
noch nicht für die neuen Tinys angepasst wurden (obwohl die neuste 
AVRStudio-Version nutze)
Hatte einer von euch schonmal so ein Problem? Wahrscheinlich übersehe 
ich gerade einfach nur eine Kleinigkeit.

Danke schon mal für eure Antworten !

Gruß

[Johann L. (gjlayde)]

Tim H. schrieb:

>  error: unable to generate reloads for:
>  internal compiler error: in find_reloads, at reload.c:3821

Atmel hat den avr-gcc aufgebohrt um die tinys zu unterstützen und dabei 
alle Register aus des Registerklasse "w" verboten.

An anderer Stelle — nämlich den delay-builtins — fordern sie aber, daß 
das Loop-Register die Constraint "w" haben muss.

Du sieht gerade den Effekt davon.

Ergo:

- Die Inline-Assebler-Version aus der avr-libc verwenden.
  Da gibt's irgendwo ein Makro das erkennt ob built-ins da sind oder
  nicht.

- Die Zeiten so stückeln, daß der Fehler nicht mehr auftritt.

[Tim H. (hotty)]

Johann L. schrieb:
> Ergo:
>
> - Die Inline-Assebler-Version aus der avr-libc verwenden.
>   Da gibt's irgendwo ein Makro das erkennt ob built-ins da sind oder
>   nicht.
>
> - Die Zeiten so stückeln, daß der Fehler nicht mehr auftritt.

Danke erstmal!

Kannst du mir da ein Beispeil geben? Ich komme mit Assembler nicht so 
wirklich klar :)

[User (Gast)]

bei einem Micro mit 512 Byte Flash nimmt man auch keinen C Compiler

[Ingo (Gast)]

Warum nicht? Wenn man Assembler nicht kann, Atmel es nun möglich macht, 
sehe ich keine Gründe die dagegen sprechen. Es sei denn das Prjekt 
scheitert weil der Code zu groß ist, dass muss man aber vorher 
abschätzen. So pauschal kann man das nicht sagen.


Ingo

[(prx) A. K. (prx)]

Ich frag mich eher andersrum: Warum sollte jemand, der nicht zigtausende 
davon verbaut, so ein Ding einsetzen?

[Johann L. (gjlayde)]

@Tim: Schau einfach mal in die delay.h rein, da gibt's ein Makro daß
du setzen musst.

[Tim H. (hotty)]

Also die Flash größe reicht mir... Das Programm oben braucht 92 Byte 
Flash. Und ja ich habe vor davon um die 1000 Stück zu verbauen.

Und: meint ihr soein Makro?

/** \ingroup util_delay_basic

    Delay loop using a 16-bit counter \c __count, so up to 65536
    iterations are possible.  (The value 65536 would have to be
    passed as 0.)  The loop executes four CPU cycles per iteration,
    not including the overhead the compiler requires to setup the
    counter register pair.

    Thus, at a CPU speed of 1 MHz, delays of up to about 262.1
    milliseconds can be achieved.
 */
void
_delay_loop_2(uint16_t __count)
{
  __asm__ volatile (
    "1: sbiw %0,1" "\n\t"
    "brne 1b"
    : "=w" (__count)
    : "0" (__count)
  );
}

[Johann L. (gjlayde)]

Tim H. schrieb:

> Und: meint ihr soein Makro?

Prinzipiell: Ja

Konkret: Nein

Denn es verwendet Constraint "w", die Atmel aus Bequemlickkeit aus dem 
Compiler gekickt hat, und zudem SBIW, den es auf tiny nicht hat.

Also "=w" durch "=d" ersetzen und SBIW durch das längere, aber 
gleich-schnelle SUBI+SBCI.

[Tim H. (hotty)]

Hallo,

danke für die Antwort.
jetzt bekomme ich diese Fehlermeldung:
Error: illegal opcode sbiw for mcu attiny4
in der Schleife:

void _delay_loop_2(uint16_t __count)
{
  __asm__ volatile (
    "1: sbiw %0,1" "\n\t"
    "brne 1b"
    : "=d" (__count)
    : "0" (__count)
  );
}

Ich denke ich muss diese Zeile anpassen: "1: sbiw %0,1" "\n\t" aber wie?

Gruß

[(prx) A. K. (prx)]

Einfach mal lesen was Johann geschrieben hat.

[Ingo (Gast)]

Der Befehl SBIW gibt's nicht, wie Johan angemerkt hat, du jedoch nicht 
beachtest...

[Tim H. (hotty)]

ja das weiß ich nur aus dem einen muss ich ja 2 Befehle machen ... nur 
wie?

[Max (Gast)]

http://www.home.unix-ag.org/tjabo/avr/dlg_02/dlg02.php nim einfach das 
da....

[Tim H. (hotty)]

hmm gibt es keine Möglichkeit die delay.h einfach anzupassen?

[Eumel (Gast)]

Schreib dir doch ne eigene Delay Routine....ist jetzt nicht so 
schwierig.

[Cyblord -. (cyblord)]

http://www.home.unix-ag.org/tjabo/avr/AVRdelayloop.html

[Tim H. (hotty)]

Hallo,

danke für eure Hilfe schonmal. Ich hab jetzt diese Schleife geschrieben:

void delay(uint8_t ms){
  uint16_t cnt = 17355;

  while(cnt != 0){  
    cnt--;
  }
}

Die Schleife läuft genau 1s wenn ich den Code nicht optimiere. Aber 
dadurch braucht PORTB=0x00; auch mehrere Befehle. Wenn ich wieder die 
Optimierung einstelle, dann wird meine Schleife einfach wegoptimiert...

[alarm (Gast)]

Tim H. schrieb:
> Wenn ich wieder die
> Optimierung einstelle, dann wird meine Schleife einfach wegoptimiert...
Dann pack ein volatile asm("nop") rein.

[Tim H. (hotty)]

Danke!
Funktioniert super :)

[Johann L. (gjlayde)]

Lass doch den MURKS mir C-Warteschleifen!

Korrigiere stattdessen den Header!

void _delay_loop_2 (uint16_t __count)
{
  __asm__ volatile (
    "1: subi %A0,1" "\n\t"
    "sbci %B0,0"    "\n\t"
    "brne 1b"
    : "=d" (__count)
    : "0" (__count)
  );
}

Wie's aussieht, hat Atmel nichtmal ein built-in Makro eingebaut, mit dem 
man diese brainf**ck Architektur abfragen kann...

http://distribute.atmel.no/tools/opensource/avr-gcc/gcc-4.5.1/32-gcc-4.5.1-avrtiny10.patch