ADC problem mit delay

[Wilfried (wil_w)]

hallo Leute
der klatschalter macht eigentlich was er machen soll. Bei einem Geräusch
schaltet er die LED ein und nach drei sek. wieder aus. Was mir nicht 
klar ist
das ich eine delay von 20000 wählen muss um auf drei Sekunden zu kommen.
Eigentlich müsste eine delay von 3000 richtig sein. Kann mir jemand 
sagen
warum? es so ist.

 //CPU 1200000
 //ATTINY 13a                                                       
 //Klatsch Schalter
#include<avr/io.h>
#include<util/delay.h>
int main (void)
{
DDRB = 0b00000001;
PORTB = 0b00011000;
ADMUX = 2;
ADCSRA = (1<<ADEN)+(1<<ADSC)+(1<<ADATE)+(1<<ADPS2);

_delay_ms(1000);

while(1)
{
while ((ADCSRA & (1<<ADIF))==0);
if (ADC<1014)

{
PORTB |= 0b00000001;
_delay_ms(20000);
PORTB &=~ 0b00000001;
//_delay_ms(1000);
}
ADCSRA |= (1<<ADIF);
}
}

[Mod: bitte künftig selber die [c] Tags setzen wie in der 
Bedienungsanleitung über jeder Texteingabebox beschrieben]

[N. M. (mani)]

Mit Meeresfehler könnte das ein Faktor von 8 sein.
Erster Verdacht: schau Mal die ClkDiv8 Fuse an. Ein Klassiker 😉

[Wastl (hartundweichware)]

Wilfried schrieb:
> hallo Leute

Hallo Wilfried,

guck doch mal das Bildchen oben an.

[Rolf M. (rmagnus)]

Wilfried schrieb:
> Kann mir jemand
> sagen
> warum? es so ist.

Auf was ist den F_CPU eingestellt, wie sind die Fuses eingestellt, und 
das ist deine Taktquelle? Das muss alles zusammenpassen, damit die 
Delays stimmen.
Wenn du 20000 statt 3000 einstellen musst, deutet das darauf hin, dass 
dein µC mit einem höheren Takt läuft als du per F_CPU angibst.

[Klaus H. (hildek)]

Wilfried schrieb:
> _delay_ms(20000);
Durch den Datentyp des Parameters (double) kannst du eine maximale 
Verzögerung von 6,5535 Sekunden erreichen.

Nix mit 20000!

[Rolf M. (rmagnus)]

Klaus H. schrieb:
> Wilfried schrieb:
>> _delay_ms(20000);
> Durch den Datentyp des Parameters (double) kannst du eine maximale
> Verzögerung von 6,5535 Sekunden erreichen.

Das hat nichts mit double zu tun. Mit dem Datentyp kannst du auch Delays 
angeben, die dem mehrfachen der Lebensdauer des Universums entsprechen. 
Die Begrenzung des Delays kommt dadurch, dass intern für die 
Warteschleife ein Zähler mit begrenzter Größe verwendet wird und liegt 
auch bei ganz anderen Werten. Siehe 
https://avrdudes.github.io/avr-libc/avr-libc-user-manual-2.2.0/group__util__delay.html#gad22e7a36b80e2f917324dc43a425e9d3

> Nix mit 20000!

Bei sehr veralteten avr-Toolchains kann es tatsächlich sein, dass das zu 
lang ist, hängt aber vom Takt ab.

[Axel R. (axlr)]

Klaus H. schrieb:
> Wilfried schrieb:
>> _delay_ms(20000);
> Durch den Datentyp des Parameters (double) kannst du eine maximale
> Verzögerung von 6,5535 Sekunden erreichen.
>
> Nix mit 20000!

Na doch. Das geht schon. Allerdings mit verringerter Auflösung von nur 
noch ner Zehntel MilliSekunde.
Steht im Manual

When the user request delay which exceed the maximum possible one, _delay_ms() provides a decreased resolution functionality. In this mode _delay_ms() will work with a resolution of 1/10 ms, providing delays up to 6.5535 seconds (independent from CPU frequency). The user will not be informed about decreased resolution.

Oder interpretiere ich das falsch?
Ebenso steht dort, wenn man F_CPU nicht angibt, er als „fallback“  1Mhz 
zur Berechnung verwendet.

https://www.nongnu.org/avr-libc/user-manual/group__util__delay.html

[Falk B. (falk)]

Axel R. schrieb:
> Oder interpretiere ich das falsch?

Nein, das siehst du korrekt, aber die fehlende Warnung bei zu großen 
Parametern ist doof. Mit 0,1ms Auflösung kann man problemlos leben.

[Klaus H. (hildek)]

Ich habe das von 
https://de.wikibooks.org/wiki/C-Programmierung_mit_AVR-GCC/_Warteschleifen

Kann sein, dass es veraltet ist.
Ich meine aber auch, dass bei mir schon aufgetaucht ist, wobei mein 
Compiler auch alt ist (WinAVR-20100110).

[Axel R. (axlr)]

In muss man aber doch fairerweise eingestehen, dass (20000), also 
20Sekunden schon weit weg von den möglichen 6komma5 Sekunden sind, die 
dort als Maximum angegeben wurden. Auflösung hin oder her.
Muss man direkt mal ausprobieren (geht jetzt hier am Handy schlecht)

[Mario M. (thelonging)]

Aktuelle Compiler machen aus der delay-Funktion einen Zähler mit 
mehreren Bytes. Da sind problemlos mehrminütige Delays möglich.

[Rahul D. (rahul)]

Mario M. schrieb:
> Aktuelle Compiler machen aus der delay-Funktion einen Zähler mit
> mehreren Bytes. Da sind problemlos mehrminütige Delays möglich.

Die maximale Delaytime sollte doch irgendwo dokumentiert sein.

[Mario M. (thelonging)]

Das wurde oben mehrfach verlinkt. Zusammenfassung: Mit einer aktuellen 
AVR-GCC-Toolchain und konstantem Delay-Wert sind es rund 4295 Sekunden 
geteilt durch die CPU-Frequenz in MHz.

[Rahul D. (rahul)]

Mario M. schrieb:
> Das wurde oben mehrfach verlinkt. Zusammenfassung: Mit einer aktuellen
> AVR-GCC-Toolchain und konstantem Delay-Wert sind es rund 4295 Sekunden
> geteilt durch die CPU-Frequenz in MHz.

Dann ist ja alles klar.

[Arduino F. (Firma: Gast) (arduinof)]

Hi hi hi....
Eine lustige Diskussion!

Da lobe ich mir doch die Arduino delay() Funktion.
Die ist (fast) gut Dokumentiert.
Man kann während dessen noch (kooperativ, dank yield()) anderen Kram 
erledigen.
Auch verlängern ISR Läufe nicht die delay() Zeit.

----------

Meinen Dank, für die Gelegenheit, diesen Einwurf machen zu dürfen.

[Axel R. (axlr)]

Arduino F. schrieb:
> Hi hi hi....
> Eine lustige Diskussion!
>
> Da lobe ich mir doch die Arduino delay() Funktion.
> Die ist (fast) gut Dokumentiert.
> Man kann während dessen noch (kooperativ, dank yield()) anderen Kram
> erledigen.
> Auch verlängern ISR Läufe nicht die delay() Zeit.
>
> ----------
>
> Meinen Dank, für die Gelegenheit, diesen Einwurf machen zu dürfen.

auf 'nem ATtiny13. jo nee - iss klar. Viel Spaß mit "yield()"
Das passt irgendwie nicht zusammen.

[Arduino F. (Firma: Gast) (arduinof)]

Axel R. schrieb:
> Das passt irgendwie nicht zusammen.
Einerseits hast du Wahr: Es gibt keinen t13 Arduino.
Es gibt nur derbe abgespeckte t13 Cores für die Arduino IDE

Andererseits, ist die _delay_ms() eine Beilage für alle AVR Arduinos
Nutzt dort nur kaum jemand.

Ausnahme:
Die/Der Ersteller des https://github.com/MCUdude/MicroCore

void delay(uint16_t ms)
{
  while(ms--)
    _delay_ms(1);
}

[Axel R. (axlr)]

Arduino F. schrieb:
> Es gibt nur derbe abgespeckte t13 Cores für die Arduino IDE

Ja weiß ich. nehm ich auch ganz gern.
(hab da gerade einen Tiny2313 - kein t13! -  mit mini-mikro-Oled und 
Betriebsspannungsanzeige am Basteln, der statt der originalen 
Ladekontrollleuchte in die Bajonettfassung gesteckt wird. (Moped MZ 
TS175) Allerdngs mit VSCode und PlatformIO. Wenns absolut nicht 
draufgeht, nehm ich wieder WinAVR und ProgrammersNotepad ;)
bislang kann ich micht erinnern, jemals mit dem Problem konfrontiert 
worden zu sein. delay(20000) wartet jedenfalls brav 20 Sekunden. Vorhin 
probiert. Müsste man sich das LST ausgeben lassen, was die dort 
veranstalten. wahrscheinlich, we oben angegeben eine while mit 
_delay_ms(1) lt. Doku ginge das ja sonst garnicht.

[Axel R. (axlr)]

nochmal zum eigentlichen Thema,
#define F_CPU 12E6
oder #define F_CPU 12000000
mit vor die #include(s) sollte das eigentliche Problem abstellen, denke 
ich.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Axel R. schrieb:
> lt. Doku ginge das ja sonst garnicht.
Nochmal der Verweis auf die Doku:
- https://www.nongnu.org/avr-libc/user-manual/group__util__delay.html

> wahrscheinlich we oben angegeben eine while mit _delay_ms(1)
Warhscheinlich mit einem _delay_ms(0,1) weil das ja die Auflösung ist 
und dann (2^32-1)*0,1s lange Delays möglich sind.

Man muss eben nur den Prescaler richtig einstellen. Wenn man den falsch 
einstellt, sind sogar noch deutlich längere Delays möglich.

Axel R. schrieb:
> #define F_CPU 12000000
Da fehlt ein UL hinten dran. Denn 12000000 passt nicht in einen 
16-Bit-Integer.

[Wilfried (wil_w)]

Hallo Leute
Vielen Dank für die zahlreichen Antworten. Habe den Fehler gefunden.
Es sieht so aus als wäre der Mikrochip das Problem. Ich habe einen neuen 
Chip genommen und siehe da es funktioniert auf Anhieb. Habe noch mit den 
"delay" verschiedene Zeiten probiert es klappt ohne Probleme.
Nochmals vielen Dank.
Wilfried

[Mario M. (thelonging)]

Nicht der Chip ist das Problem, sondern die Einstellung der "Fuses". Die 
Einstellung der Taktfrequenz passt einfach nicht zum Wert von F_CPU in 
Deinem Programm.

[Wilfried (wil_w)]

Hallo Mario
Die "Fuses" waren-sind h-0xFF und l-0x6A .
Gruß Wilfried

[Mario M. (thelonging)]

Sehr interessant, da müsste ja der Prescaler kaputt sein.