delay.h defekt

[Stefan K. (oxid)]

Hallo zusammen

Ich habe ein Problem mit den Routinen in delay.h. Wenn ich zb. 
_delay_ms(100) aufrufe geht es statt 100ms ganze 15s bis das Warten 
vorüber ist.

Diese Problem habe ich seit ich mein ubuntu auf 10.04 aktualisiert habe. 
Als Entwicklungsumgebung verwende ich eclipse und avr-gcc.
Sobald ich jetzt  -nach dem update- ein Projekt kompiliere, 
funktionieren eben die Wartefunktionen nicht mehr richtig.

Was ich bis jetzt alles ausprobiert habe:


- in meine Code nach Fehlern gesucht
- Einstellungen für den Takt in den build configurations kontrolliert -> 
1MHz intern ->stimmen
- neue delay.h runtergeladen
- Compiler optimierung geändet/ausgeschaltet
- openjdk durch sun-java6  ersetzt
- Neue Version von eclipse installiert

Anbei noch die Source -> Zeile 65 und 81.

Was soll ich sagen, es funktioniert immer noch nicht. Jetzt bin ich mit 
meine Latein am Ende und weiss nicht mehr weiter, wär wirklich schön 
wenn jemand noch ne Idee hätte.

Danke schon mal

Gruss Steff

[holger (Gast)]

- Compiler optimierung geändet/ausgeschaltet

Nicht ausschalten, einschalten.

[Andreas K. (derandi)]

Ganz am Rande: Eine ganze Sekunde Delay in einem Interrupt verblödeln is 
aber ohnehin nicht fein.

Was passiert denn du aus 100ms Delay 50ms machst, werden dann aus den 15 
minuten auch 7,5 min.?

[Christian H. (netzwanze)]

volatile für alle Variablen benutzen, die in Interrupt-Routinen 
verändert werden.

[holger (Gast)]

Und diese

uint8_t  timeisrun =0, safestart= 0;
uint16_t startcounter;

alle volatile

Und nimm das gottverschissene _delayms(1000) aus dem
Timerinterrupt raus!

[Christian H. (netzwanze)]

Andreas K. schrieb:
> minuten auch 7,5 min.?

Soooo schlimm ist es auch nicht, es sind nur Sekunden ;-)

[Christian H. (netzwanze)]

anzeige_7seg_zahl(startcounter);
_delay_ms(1000);
startcounter = eeprom_read_word(&counter_eeprom);

Das gehört alles nicht in eine INT-Routine.

[holger (Gast)]

>uint16_t startcounter;

In main() kann man auf startcounter nicht zugreifen
ohne den Int zu verbieten. Stichwort ATOMAR

Und das ist Schrott:

SIGNAL(SIG_OVERFLOW1)
{
  cli();
  TCNT1 = 49911;
  sei();

sei() macht man nicht in ungestraft in Interrupts.
cli(); ist überflüssig. Interrupts sind beim Aufruf
der Interruptroutine sowieso deaktiviert.

[Stefan K. (oxid)]

Also Optimierungen hab ich alle ausprobiert -O0 bis -O3 und -Os
Variablen sind jetzt alle volatile.

Christian H. schrieb:
> anzeige_7seg_zahl(startcounter);
> _delay_ms(1000);
> startcounter = eeprom_read_word(&counter_eeprom);
> Das gehört alles nicht in eine INT-Routine.


Sind jetzt raus, haben aber meiner Meinung nach nichts mit dem Problem 
zu tun, da diese Funktionen erst aufgerufen werden wenn der Countdown zu 
ende ist.

Andreas K. schrieb:
> Was passiert denn du aus 100ms Delay 50ms machst, werden dann aus den 15
> minuten auch 7,5 min.?


Ja mit _delay_ms(50) geht es halb so lange -> 7.5s

Also das Problem besteht weiterhin, hat alles nichts gebracht.

[Christian H. (netzwanze)]

http://www.rn-wissen.de/index.php/Fallstricke_bei_der_C-Programmierung

[Stefan K. (oxid)]

holger schrieb:
> Und das ist Schrott:
>
> SIGNAL(SIG_OVERFLOW1)
> {
>   cli();
>   TCNT1 = 49911;
>   sei();

Okay, cli() und sei() sind raus.
Irgendwo in einem tut habe ich gelesen das man interrupts deaktivieren 
soll, wenn auf TCNT1 zugegriffen wird, hat aber anscheinend nichts mit 
meinem Problem zu tun.

Was ich nicht verstehe vor dem Update hat der Code mit all denn 
offensichtlchen Fehler perfekt funktioniert. :(

[Peter D. (peda)]

Laß Dir mal F_CPU ausgeben.

Man sieht leider öfters den Schwachsinn, daß mit #ifndef eine mehrfache 
oder fehlende Definition verschleiert wird.

Da muß es aber richtig krachen, also eine #error-Anweisung.
Denn wenns 2-mal erfolgt oder fehlt, ist das ein Fehler!


Peter