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?
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
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.
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.
@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
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.
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.
@ 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ß
Es gibt hier bereits paar Beiträge, die genau mit diesem Thema sich auseinander setzen.
>ich rede über wirkliche RealTime Systeme.
1 | #asm("cli")
|
2 | delay_ms(2); |
3 | #asm("sei")
|
ROTFL Immerhin erzielst du mit diesem Code eine garantierte Nicht-Reaktion von 2ms. Ist in gewisser Weise auch "Real-Time". Oliver
@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
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...
@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
>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
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.
>>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?
wahrscheinllich in China, muß Du aber Dich richtig gut anstrengen, standart mit 30-50ppm kriegst Du an jeder Ecke:)
...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...
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.