mikrocontroller.net

Forum: Compiler & IDEs _delay_ms Funktion und Interrupts


Autor: Rush ... (rush)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal kurze Frage zur Delayfunktion?
Funktioniert die Hardwareperipherie (Timer/Counter, ICP-Interrupt, etc.) 
eines Atmel Controllers auch zum Zeitpunkt einer _delay_ms Funktion?
Werden, wenn sich der Controller gerade ind er Delayfunktion befindet 
zum Beispiel Interrupts erkannt, oder funktioniert die Tastenentprellung 
mittels Timer trotzdem oder mach der Controller zu diesen Zeitpunkt 
wirklich überhaupts nicht ??

So, dat wars schon?

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die delay-Funktionen sind nichts anderes als Programmschleifen. Der 
Prozessor arbeitet da ganz normal sein Programm ab, alle Interrupts, 
Timer, etc. sind natürlich voll funktionsfähig.

Teilweise ausschlaten kann man den über die verschiedenen sleep-Modi zum 
Stromsparen. Da sind dann je nach Modus nicht mehr alle Interrupts und 
Timer funktionsfähig. Das hat mit delays aber nichts zu tun.

Oliver

Autor: Rush ... (rush)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alles klar, dankeschön.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver wrote:
> Die delay-Funktionen sind nichts anderes als Programmschleifen. Der
> Prozessor arbeitet da ganz normal sein Programm ab, alle Interrupts,
> Timer, etc. sind natürlich voll funktionsfähig.

Das schon, wenn man damit leben kann, dass die Warteschleifen nicht mehr 
akkurat arbeiten, also wenn sie fuer nichts zeitkritisches verwendet 
werden.

Autor: wt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael hat recht. Es ist dringend zu empfehlen, die ISR auszuschalten.
etwa:

#asm("cli")
delay_ms(2);
#asm("sei")

Für unkritische Sachen kann man sich kurze eigene Delay Funktion 
schreiben.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@wt (Gast)

>Michael hat recht. Es ist dringend zu empfehlen, die ISR auszuschalten.
>etwa:

Quark. Das KANN notwendig sein, IST es aber meistens nicht.

>Für unkritische Sachen kann man sich kurze eigene Delay Funktion
>schreiben.

Quark^2. Dann erinden 99% aller Leute das Rad neu, nur eckig. Die 
Funktionen der libc sind gestestet und funktionieren prima.

MFG
Falk

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:

>>Michael hat recht. Es ist dringend zu empfehlen, die ISR auszuschalten.
>>etwa:
>
> Quark. Das KANN notwendig sein, IST es aber meistens nicht.

Insbesondere hatte der OP ja gerade befürchtet, dass der Prozessor
während eines _delay_XX sonst nichts mehr machen könnte, was ihn
offenbar gestört hätte.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eben.

Die Quintessenz kann nur sein:
WENN man ISR weiterlaufen haben möchte UND gleichzeitig genaues Timing 
benötigt, DANN sind die _delay_xx Funktionen nicht das geeignete Mittel.

Autor: wt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Falk

ich rede über wirkliche RealTime Systeme. Du bewegst Dich anscheinend 
irgendwo auf der Stufe zwischen RS232 und 2x16 LCD. Nicht mal vernünftig 
genaue Zeitmessung lässt sich mit deiner Methode implementieren.
Mir bleibt nur die Hoffnung, daß die 99% der Leute anders denken als Du.

gruß

Autor: wt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt hier bereits paar Beiträge, die genau mit diesem Thema sich 
auseinander setzen.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>ich rede über wirkliche RealTime Systeme.
#asm("cli")
delay_ms(2);
#asm("sei")

ROTFL

Immerhin erzielst du mit diesem Code eine garantierte Nicht-Reaktion von 
2ms. Ist in gewisser Weise auch "Real-Time".

Oliver

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@wt (Gast)

>ich rede über wirkliche RealTime Systeme.

Sieht man gleich . . .

> Du bewegst Dich anscheinend
>irgendwo auf der Stufe zwischen RS232 und 2x16 LCD.

Oh Meister, ich bin deines Blickes unwürdig.

> Nicht mal vernünftig
>genaue Zeitmessung lässt sich mit deiner Methode implementieren.

War das das Thema?

>Mir bleibt nur die Hoffnung, daß die 99% der Leute anders denken als Du.

Bleibt nur die Hoffnung, dann nicht alles solche Dampfplauderer sind wie 
du. Ja ich weiss, dies Hoffnung stribt recht schnell ;-)


@ Oliver (Gast)

>Immerhin erzielst du mit diesem Code eine garantierte Nicht-Reaktion von
>2ms. Ist in gewisser Weise auch "Real-Time".

Das ist ein "I've got really time" System, auch als Jamaika-Stil bekannt 
;-)

MfG
Falk

Autor: Rush ... (rush)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leute streitet doch nicht :-D

Wollte doch nur wissen ob der Prozessor für den delaymoment sich aufs 
ohr legt und "nicht ansprechbar" ist oder ob er nebenbei doch noch ISR's 
abarbeiten kann. Das wurde ja schon ganz am Anfang geklärt...

Autor: wt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Oliver

#asm("cli")
delay_ms(2);
#asm("sei")

klar ist das ein quatsch, es ging ja um grundsätzliche Vorgehensweise 
mit Funktionen wie delay_us oder _ms. Wenn der ISR nich aus ist kann ich 
mich nicht darauf verlassen, daß 2us auch 2us sind.

@Rush
Du siest, die Meinungen gehen ganz schön außeinander.

@Falk
kein Kommentar, bleib auf der Wolke, wo Du bist.

gruß
Euer Dampfplauderer

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>klar ist das ein quatsch,

Das du das nicht ernst meinst, kann ich auf den ersten Blick nicht 
erkennen.

>Wenn der ISR nich aus ist kann ich
>mich nicht darauf verlassen, daß 2us auch 2us sind.

Das kannst du sowieso nicht. Ein paar % Abweichung hast du immer, so 
genau läuft kein Quarz.

Ausserdem steht oben in deinem Code nicht us, sondern ms. Und "Real 
Time" bedeutet, zu wissen, wie groß die Abweichung von 2ms werden darf, 
und zu garantieren, daß das eingehalten wird. Das kann je nach 
Anforderung und Gesataltung der ISR-Routinen bedeuten, alle Interrupts 
vorher zu sperren, muß es aber nicht.

Oliver

Autor: wt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
meine Rede!

wenn du die %-Abweichung vom Quarz mit betrachten muß, weil es System 
erfordert, wirst Du vermutlich mit vordefinierter Fkt. delay_us nicht 
glücklich, immerhin sind das bei 10% Abweichung vom 16MHz Quarz +-6ns. 
Die Frage ist in welchen Fällen kannst Du so eine Abweichung dulden.

Bei der Diskussion delay_ms oder _us ist es egal, welche Zeit dahinter 
steht, denn die Programmierung beider Funktionen vom Prinzip her gleich 
ist.

Unter RealTime, wie Du schon sagst, verstehe ich die Fähigkeit des 
Systems genau dannn reagieren, wie ich das als Designer vorgebe. und 
wenn ich sage, daß ein System 2us, ms oder std. lamm gelegt werden muß, 
dann muß genau diese Zeit eingehalten werden.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Wenn der ISR nich aus ist kann ich
>>mich nicht darauf verlassen, daß 2us auch 2us sind.
>
> Das kannst du sowieso nicht. Ein paar % Abweichung hast du immer,
> so genau läuft kein Quarz.

Wo findet man denn einen Quarz mit mehreren Prozent Abweichung?

Autor: wt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wahrscheinllich in China, muß Du aber Dich richtig gut anstrengen, 
standart mit 30-50ppm kriegst Du an jeder Ecke:)

Autor: Thomas W. (wagneth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...darf man zusammenfassen :

1. Der µC-takt bestimmt den Systematischen Fehler.
Die ppm-Angabe auf dem Quarz(-oszi was auch immer) macht bei einer 
"Wartezeit" von 2ms nur einen unbedeutenden Fehler.

2. Bei sequentieller Programmierung macht delay.h Sinn und hat ihre 
Berechtigung.

3. Bei Interruptgesteuerter Prg. ist es sicherlich unschön mit den 
delay-funktionen zu warten.
Je nach ISR kann sich der Fehler stark verändern oder ist immer 
gleichmassig vorhanden.

Ein Counter im Timer zählenzu lassen wäre doch deutlich eleganter.
Bzw den Code schon gar für den Interruptbetrieb auslegen...

Autor: wt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
schöner könnte ich auch nicht schreiben:)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas W. wrote:

> 3. Bei Interruptgesteuerter Prg. ist es sicherlich unschön mit den
> delay-funktionen zu warten.

Als allgemeine Grundregel passt das.  Aber es gibt halt (wie immer :)
auch Ausnahmen von der Regel: für sehr kleine Verzögerungen lohnt
das Anwerfen eines Timers in der Regel nicht.  Wenn du also den
E-Impuls für einen HD44780 (LCD-Controller) erzeugen willst, der
minimal 500 ns breit sein soll, dann ist es schon sinnvoll, einfach
_delay_us(0.5) zu schreiben.  Ob man drumrum noch die Interrupts
blockiert oder nicht, wäre in diesem Falle ziemlich wurscht, da
die 500 ns ja eine minimale Impulsbreite sind.  Wenn halt ein
Interrupt reinfunkt, wird der Impuls breiter, stört auch nicht.

Für alles, was langsameres Timing ist (so ab vielleicht 10 ms
aufwärts), wird man über kurz oder lang bei einem Hintergrund-
Timer rauskommen, der diesen  Takt vorgibt -- selbst dann, wenn man
sonst mit Interrupts in seinem System nicht viel am Hut hat.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.