Hallo
um Timerfunktionen z.b für ein Blinken, in der Arduino Umgebung
(Software) zu nutzen gibt es die delay Funktion, mit allen ihren
Problemen wenn das Programm ein wenig mehr machen soll.
Das ist selbst den Arduinoentwicklern klar und deshalb gibt es auch eine
Funktion millis, auf die ich aber auch gerne verzichten würde.
Wieso, weshalb, warum steht nicht zu Diskussion, und zwar bezüglich
meines Wunsch auf Verzicht als auch (!) warum ich die Arduino
Entwicklungsumgebung nutze obwohl ich teilweise Hardware nah arbeiten
möchte - Glaubenskrieger und Missionare können sich woanders austoben
-Danke.
Jetzt findet Google zwar 1001 Tutorials zu "Arduino without delay" aber
bei "Arduino without delay and millis" und Ähnliches erhalte ich keine
brauchbaren Treffer sondern letztendlich die gleichen Tutorials, Fragen,
Hinweise... wie bei der reinen "... without delay..." Suche.
Deutschsprachige Suche bringt eher noch weniger.
Ich möchte aber in der Arduinoumgebung (und nicht in reinen C,
Assembler...) Hardwarenah den ATMega328 bezüglich den Timer (sowohl
"Timer" in der Bedeutung beim µC als auch wie sie im Allgemeinen
Sprachgebrauch verwendet wird)verstehen und nutzen.
Dafür gibt es doch mit hoher Wahrscheinlichkeit schon Tutorials - nur
ich finde diese nicht da die gefühlt Millionen Tutorials zum Ersatz der
Delay Funktion das Auffinden unmöglich machen.
Wer kann helfen (Link, genialer Suchbegriff, eigene Worte...)?
Ardu Ino
Wie ist denn die Blink-Frequenz?
Im Idealfall gibt es in der Loop() kein einzigen Aufruf der eine
Wartezeit verursacht.
Sodas die Loop() mit einer sehr hohen Frequenz durchlaufen ist.
Um ein Blinken ohne Nutzung einer Delay-Funktion zu erzeugen, muss du in
der Loop die vergangene Zeit messen.
Ist die gewünschte Zeit (z.B. 0,5 Sekunden) abgelaufen, schaltest du den
Ausgang um und startest eine neue Zeitmessung, so bekommst du eine
Blinkfrequenz von z.B. 1Hz
> Wer kann helfen (Link, genialer Suchbegriff, eigene Worte...)?
Suchbegriff: "pferd von hinten aufzäumen". Verabschiede Dich von der
Arduinolaufzeitarchitektur oder von genauen Timings. In ersterem Falle:
Herzlichen Glückwunsch, als nächstes bitte das Datenplatt zum
Mikrocontroller lesen und verstehen.
Ardu Ino schrieb:> ... obwohl ich teilweise Hardware nah arbeiten möchte
Es hindert dich keiner daran, eigene Funktionen für hardwarenahen
Anwendungen zu verwenden.
> ... und deshalb gibt es auch eine Funktion millis, auf die ich> aber auch gerne verzichten würde.
Selber schuld - warum?
> -Danke.
Bitte
Ardu Ino schrieb:> Wer kann helfen (Link, genialer Suchbegriff, eigene Worte...)?
Geniale Suchbegriffe wären z.B. "Timer" und "Interrupt".
Wenn du dem Timer-Interrupt, der hinter millis() steht, nicht traust,
setze doch einen eigenen Timer auf. Die Registerbezeichnungen stehen im
Datenblatt und sind auch in der Arduino IDE verfügbar.
Wenn du das nicht kannst/möchtest nutze die Arduino Umgebnung oder lese
dir Grundlagen an, z.B.
https://www.robotshop.com/letsmakerobots/arduino-101-timers-and-interrupts
Wasch mir den Pelz, aber mach mich nicht nass funktioniert hier nicht,
wenn Copy&Paste schon an elementaren Suchbegriffen scheitert
Ardu Ino schrieb:> Ich möchte aber in der Arduinoumgebung (und nicht in reinen C,> Assembler...) Hardwarenah den ATMega328 bezüglich den Timer (sowohl> "Timer" in der Bedeutung beim µC als auch wie sie im Allgemeinen> Sprachgebrauch verwendet wird)verstehen und nutzen.
Schreibe deine Funktion
int main (void)
{
.....
}
in deiner Arduino IDE und vermeide die Implementierungen
Setup();
und
Loop();
Damit bist du Herr über alles ohne auch nur eine Mikrosekunde
deines Controllers hergeschenkt zu haben. Und alle Hardware,
auch die Timer, ist/sind frei verfügbar.
Ardu Ino schrieb:> Ich möchte aber in der Arduinoumgebung (und nicht in reinen C,> Assembler...) Hardwarenah den ATMega328 bezüglich den Timer (sowohl> "Timer" in der Bedeutung beim µC als auch wie sie im Allgemeinen> Sprachgebrauch verwendet wird)verstehen und nutzen.
Schon mal drüber nachgedacht, das Datenblatt zu studieren? Da steht
alles drin, was man so wissen muss.
Ich verstehe das Problem nicht. Warum sollte auf millis() verzichtet
werden? Das ist doch einfach zu benutzen und man kann überprüfen ob eine
Zeit schon abgelaufen ist.
Was ist das Problem mit millis() ?
> Was ist das Problem mit millis() ?
Verstehe ich auch nicht. Jedes PC Betriebssystem hat das, jedes
Smartphone und ARM Kerne haben dazu sogar einen extra Timer integriert.
Wie willst du sonst Zeiten messen? Etwa mit Kondensatoren?
@Ardu Ino (Gast)
>Jetzt findet Google zwar 1001 Tutorials zu "Arduino without delay" aber>bei "Arduino without delay and millis" und Ähnliches erhalte ich keine>brauchbaren Treffer sondern letztendlich die gleichen Tutorials, Fragen,>Hinweise... wie bei der reinen "... without delay..." Suche.>Deutschsprachige Suche bringt eher noch weniger.
Dann suchst du falsch.
>Ich möchte aber in der Arduinoumgebung (und nicht in reinen C,>Assembler...) Hardwarenah den ATMega328 bezüglich den Timer (sowohl>"Timer" in der Bedeutung beim µC als auch wie sie im Allgemeinen>Sprachgebrauch verwendet wird)verstehen und nutzen.
Das ist leicht, denn Arduino ist nicht sooo isoliert wie manche meinen.
Es ist "nur" eine Sammlung von Bibliotheken, die man nutzen KANNN (und
meist auch sollte), der Rest des AVRs ist aber genauso verfügbar und
zugreifbar wie in reinem C ohne Arduino.
>Dafür gibt es doch mit hoher Wahrscheinlichkeit schon Tutorials
Jaja, die ganze Welt als Tutorial. Nerd 2.0
>ich finde diese nicht da die gefühlt Millionen Tutorials zum Ersatz der>Delay Funktion das Auffinden unmöglich machen.
Ich schon. Siehe Multitasking.
Einen Interrupt kann man beim Arduino genauso leicht nutzen wie ohne.
Beitrag "Re: Arduino Nano, SD Card, PCM"
millis() ist genau das, was der TO braucht, unabhängig davon, was er
will. Den millis() arbeitet ja mit einem Timer und dessen Interrupt.
Ich vermute sehr, der TO weiß nur nicht, wie man diese Funktion am
besten einsetzt und zyklisch mit Zustandsautomaten programmiert
(Stichwort Mainloop).
Und deshalb versucht er, seinen Schopf über ein Programm, das direkt im
Timerinterrupt läuft, aus der Schlinge zu ziehen.
Dass er sich damit ganz andere Probleme an die Backe klebt, weiß er
allerdings auch nicht (Stichworte Semaphorenproblem und Racecondition).
Ardu Ino schrieb:> Ich möchte aber in der Arduinoumgebung (und nicht in reinen C,> Assembler...) Hardwarenah den ATMega328 bezüglich den Timer (sowohl> "Timer" in der Bedeutung beim µC als auch wie sie im Allgemeinen> Sprachgebrauch verwendet wird)verstehen und nutzen.
tue es doch
ich kam vom nackten Atmel AVR mit AVR Studio 4.18 zum Arduino, nutze
eigene C-Module die ich einbinde als *.ino als auch LIBs der Arduinio
wahlweise nach Bedarf.
Mich stört weder setup(), noch loop() auch nicht millis() oder eigene
Timerinterrupts, alles kooperiert nach meinen Wunsch und wenn mal nicht
schaue ich wo ich ändern muss, z.B. mal einen anderen Timer wählen.
zur erhellung ohne delay ...
#ifndef PERIODIC_H
#define PERIODIC_H
//usage:
// PERIODIC(100) //{
// digitalWrite(PIN, HIGH/LOW)
// }
//create an unique name from given parameter and line number
#define UNIQUE(name) __CONCAT(name,__LINE__)
//creates an unique timer for each instance, ms period in milli-seconds
#define WAITBLOCK(ms) \
static uint32_t UNIQUE(timer) = millis(); \
if (millis() - UNIQUE(timer) >= ms) {
//creates an unique timer for each instance, ms period in milli-seconds
#define PERIODIC(ms) \
static uint32_t UNIQUE(timer) = millis(); \
if (millis() - UNIQUE(timer) >= ms) { \
UNIQUE(timer) = millis();
//XPERIODIC(ms,1) = WAITBLOCK but takes more program code space!
//XPERIODIC(ms,0) = PERIODIC
//creates an unique timer for each instance, x: repeats 0-255, 0=endless
#define XPERIODIC(ms, x) \
static uint32_t UNIQUE(timer) = millis(); \
static uint8_t UNIQUE(xRepeats) = x; \
static uint8_t UNIQUE(lock); \
if (millis() - UNIQUE(timer) >= ms) { \
if (!UNIQUE(lock)) { \
if ((UNIQUE(xRepeats)==0) || (--UNIQUE(xRepeats))) \
UNIQUE(timer) = millis(); \
else UNIQUE(lock)=1; \
}
#endif //PERIODIC_H
@Lothar Miller (lkmiller) (Moderator) Benutzerseite
>millis() ist genau das, was der TO braucht,
Nein, denn diese Funktion liefert nur einen Timerwert, welche in einem
1ms Timer-Interrupt hochgezählt wird. Die nützt rein gar nichts, wenn
andere Funktionen, warum auch immer, den Programmablauf längere Zeit
"blockieren".
> unabhängig davon, was er>will. Den millis() arbeitet ja mit einem Timer und dessen Interrupt.
Dort kommt man aber so direkt nicht ran, sprich, man kann sich NICHT in
den 1ms Timer einklinken! Dazu müßte es eine Funktion geben, die der
Anwender erstellen kann, welche dann vom Arduino-Framework im 1ms
Interrupt aufgerufen wird. So etwas gibt es nicht, u.a. weil es dem
Konzept der Vereinfachung deutlich widerspricht.
>Ich vermute sehr, der TO weiß nur nicht, wie man diese Funktion am>besten einsetzt und zyklisch mit Zustandsautomaten programmiert>(Stichwort Mainloop).
Das ist nur ein Würg-Around mit begrenzter Leistung. Siehe oben.
>Und deshalb versucht er, seinen Schopf über ein Programm, das direkt im>Timerinterrupt läuft, aus der Schlinge zu ziehen.
Genau DAS ist aber die Lösung der allermeisten Probleme dieser Art!
Außerdem hat der OP ganz sicher sehr wenig Plan von AVRs und Interrupts,
denn ich wette 1 Kasten Bier, daß er für seine Drehgeberauswertung die
rudimentäre Interrupt-Funktionalität des Arduinos nutzt.
https://www.arduino.cc/reference/en/language/functions/external-interrupts/attachinterrupt/>Dass er sich damit ganz andere Probleme an die Backe klebt, weiß er>allerdings auch nicht (Stichworte Semaphorenproblem und Racecondition).
Jaja, und schon wieder sind am Sonntag Morgen die Reichsbdenkenträger
voll dabei, die Welt zur retten. ODer zumindest viel Staub aufzuwirblen!
:-(
Siehe Anhang!!!
>> millis() ist genau das, was der TO braucht,> Nein, denn diese Funktion liefert nur einen Timerwert, welche in einem> 1ms Timer-Interrupt hochgezählt wird. Die nützt rein gar nichts, wenn> andere Funktionen, warum auch immer, den Programmablauf längere Zeit> "blockieren".
Die millis() Funktion ist ideal, um innerhalb eines Zustandsautomaten
Aktionen zu einem bestimmten Zeitpunkt auszuführen. Das Abwarten einer
Zeitspanne zählt auch dazu.
> wenn andere Funktionen... den Programmablauf längere Zeit "blockieren".
Das ist in vernünftigen Multi-Task fähigen Anwendungen ohnehin nicht
zulässig. Größere Aktionen müssen ggf. in kleinere zerlegt werden.
Zustandsautomaten ist das Stichwort zum lernen, sobald man die Grenzen
von delay() und anderen blockierenden Aktionen erkannt hat.
@Stefan Us (stefanus)
>>> millis() ist genau das, was der TO braucht,>> Nein, denn diese Funktion liefert nur einen Timerwert, welche in einem>> 1ms Timer-Interrupt hochgezählt wird. Die nützt rein gar nichts, wenn>> andere Funktionen, warum auch immer, den Programmablauf längere Zeit>> "blockieren".>Die millis() Funktion ist ideal, um innerhalb eines Zustandsautomaten>Aktionen zu einem bestimmten Zeitpunkt auszuführen. Das Abwarten einer>Zeitspanne zählt auch dazu.
FALSCH! Auch du hast das Problem NICHT verstanden!
>> wenn andere Funktionen... den Programmablauf längere Zeit "blockieren".>Das ist in vernünftigen Multi-Task fähigen Anwendungen ohnehin nicht>zulässig. Größere Aktionen müssen ggf. in kleinere zerlegt werden.
Jaja, soweit die Theorie. Dumm nur, daß das selbt für Profis bisweilen
nicht möglich ist, weil bestimmte Funktionen bzw. Bibliotheksfunktionen
schlicht länger dauern und nicht teilbar sind.
Hier geht es um das gleiche Problem. Und besonders dort ist millis()
fehl am Platz. Der schelle, zeitkritische Kram gehört in die Timer-ISR,
der langsame LCD-Kram in die Hauptschleife.
Beitrag ""Interrupt" durch Vergleich von Variablen möglich? Timingprobleme durch zu lange Programmlaufzeit">Zustandsautomaten ist das Stichwort zum lernen, sobald man die Grenzen>von delay() und anderen blockierenden Aktionen erkannt hat.
Eben dafür braucht es KEINE gottverdammte millis() Funktion, die nur ein
Arduino-Würg-Around ist! Denn in den allermeisten Fällen will man
diverse State Machines mit einer definierten, konstanten Frequenz
aufrufen, damit ergibt sich das Timing von allein und diverse
Verzögerungen werden in den FSMs per Zustand und Zähler gemacht. Un komm
mir jetzt nicht mit der 101 Ausnahme, welche die Regel bestätigt!
> millis() Funktion, die nur ein Arduino-Würg-Around ist!
Dann schau Dir mal Java an, oder Windows, oder Linux, oder Android, oder
ARM Kerne. Die haben alle einen Millisekunden-Zähler mit mehr oder
weniger ähnlichem Namen.
> weil bestimmte Funktionen bzw. Bibliotheksfunktionen> schlicht länger dauern und nicht teilbar sind
Diese Funktionen würde ich als Designfehler bezeichnen. Mit einem OS das
aktiv Threads unterbricht könnte man sie verwenden, aber auf µC wären
sie fehl am Platz.
Blockierende Warteschleifen dürfen meiner Meinung nach nur wenige Nano-
bis Mikrosekunden dauern.
@ Stefan Us (stefanus)
>> millis() Funktion, die nur ein Arduino-Würg-Around ist!>Dann schau Dir mal Java an, oder Windows, oder Linux, oder Android, oder>ARM Kerne. Die haben alle einen Millisekunden-Zähler mit mehr oder>weniger ähnlichem Namen.
Du Nase! Wer hat denn die Existenz dieser Sache abgestritten?
Es ging um die Frage, wie man sinnvoller, bzw. optimalerweise ein
minimales Multitasking auf einem uC gestaltet. Und schau dir mal
diverse Java-Anwendungen an, dann weißt du, warum die Mist sind
(Performance, was ist das?) Ob das an den schlechten Konzepten der
mittelmäßigen Programmierer und dernen millis() Funktion liegt?
@Stefan Us (stefanus)
>>> weil bestimmte Funktionen bzw. Bibliotheksfunktionen>> schlicht länger dauern und nicht teilbar sind>Diese Funktionen würde ich als Designfehler bezeichnen. Mit einem OS das>aktiv Threads unterbricht könnte man sie verwenden, aber auf µC wären>sie fehl am Platz.
Schon wieder Unsinn. Heute nicht dein Tag, oder?
Beispiel. Das VORZÜGLICHE FATfs vom Meister Elm Chan aus dem fernen
Osten hat diverse Funktion, die halt mal länger und mal kürzer dauern.
Willst du daraus schließen, daß dFATfs Mist ist? NEIN! Denn wenn man
damit was performantes auf die Beine stellen will, muss man halt "nur"
wissen wie das geht. Mein schon mehrfach zitierter DMX Rekorder macht
das mit 22kB/s. Totz daß diverse FATfs Funktionen eher Millisekunden
brauchen.
Wie kann denn etwas ein Arduino-Würg-Around sein, was in praktisch allen
anderen Programmiersprachen und Betriebssystemen ebenso vorhanden ist?
> in den allermeisten Fällen will man diverse State Machines> mit einer definierten, konstanten Frequenz aufrufen
Ich kenne das als eine mögliche Lösung.
Ich habe aber schon wesentlich mehr State Machines gesehen, deren
hauptschleife einfach nur schnellstmöglich ausgeführt wird. Unter
anderem in Arduino, µC Projekte die auf LwIp und µIP basieren (somit
auch ESP8266), fast alle meine eigenen µC Projekte, zahlreiche Windows
Programme, die Event-Loop vom QT Framework, ...
Vielleicht beginnst du mal zu akzeptieren, dass viele Wege zum Ziel
führen und deiner nicht der einzig richtige ist.
In Sachen millis() und delay(), bin ich schon fast eine Fachkraft.
Zumindest eine eingewiesene Person, mit fundiertem Halbwissen.
Die Hierarchie des ArduinoZeitHändlings:
Einfache Dinge ruhig mit delay().
Solange, bis es einem auf die Füße fällt....
Dann das BlinkWithoutDelay Konzept anwenden.
Damit kann man eigentlich alles erschlagen.
Ja, wenn es einen nicht stört, dass dauernd millis() aufgerufen und
verglichen wird.
Wird dann schlußendlich ein exaktes Timing gebraucht, kann man ja noch
immer die HardwareTimer zur Hilfe nehmen. Ein UNO hat 3 davon, wobei
Timer0 vom Core belegt wird.
Da ist man dann an dem Punkt, wo es ohne Datenblatt nicht weiter geht.
----
Auch gibt es die Chance den Arduino Core abzuändern.
In dessen Timer0 ISR eine Weak Funktion rein zu klemmen ist eine
Kleinigkeit von 3 oder 4 Zeilen.
Dieser Interrupt kommt alle, ca. 1ms. Er ist nicht ganz exakt. Damit
millis() korrekt läuft wird da im Core noch rumkorrigiert.
Arduino F. schrieb:> Dieser Interrupt kommt alle, ca. 1ms. Er ist nicht ganz exakt. Damit> millis() korrekt läuft wird da im Core noch rumkorrigiert.
Warum? 16MHz:1KHz geht doch im CTC-Mode glatt auf. Oder benutzen sie den
Timer als Atmega8-Gedächtnis-Timer nur im OVF?
Falk B. schrieb:> @Lothar Miller (lkmiller) (Moderator) Benutzerseite>> millis() ist genau das, was der TO braucht,> Nein, denn diese Funktion liefert nur einen Timerwert, welche in einem> 1ms Timer-Interrupt hochgezählt wird.
Das reicht für übliche zeitliche Abläufe völlig aus.
> Die nützt rein gar nichts, wenn andere Funktionen, warum auch immer,> den Programmablauf längere Zeit "blockieren".
Dann haben wir das Problem ja schon erkannt: der Programmablauf der
Hauptschleife darf schlicht und einfach nicht blockiert werden. Das
wars. Wenn man sich daran hält, dann kann man ganz einfach wartbare und
erweiterbare und vor allem portierbare Programme schreiben.
Die wichtigste (Überwachungs-)Funktion meiner Hauptschleife ist der
Abschnitt, wo die minimale, maximale und durchschnittliche Zykluszeit
berechnet wird. Und wenn ein durch die Anwendung bestimmter Grenzwert
der maximalen Zykluszeit überschritten wird, dann habe ich gerade eben
einen Fehler reinprogrammiert.
Merke: der am einfachsten erkennbare Programmierfehler ist ein
delay_ms().
Falk B. schrieb:> Das VORZÜGLICHE FATfs vom Meister Elm Chan aus dem fernen Osten hat> diverse Funktion, die halt mal länger und mal kürzer dauern. Willst du> daraus schließen, daß dFATfs Mist ist?
Doch. Genau das ist es: wenn es mir wegen irgendwelcher Warterei auf
irgendwelche Hardware das Timing verhagelt, dann ist das Murks.
Und ich muss dann auf die eine oder andere Art einen Workaroud drumrum
basteln.
Falk B. schrieb:>> Dass er sich damit ganz andere Probleme an die Backe klebt, weiß er>>>allerdings auch nicht (Stichworte Semaphorenproblem und Racecondition).> Jaja, und schon wieder sind am Sonntag Morgen die Reichsbdenkenträger> voll dabei, die Welt zur retten. ODer zumindest viel Staub aufzuwirblen!
Falk, du lenkst ab. Hier schlagen doch laufend Anfänger auf, die sich
wundern, warum ihre volatile Variable, die im Interrupt und im
Huptprogramm verwendet wird, ab&zu "spinnt".
Und ich kenne einige Fälle, wo Anfänger um genau solche Fälle dann mit
"Dreifach-Abfragen mit anschließendem Vergleich" übel um genau dieses
Semaphoren-Problem herumflicken.
Denn das ist nichts, was einem Angst machen soll, sondern man muss es
einfach wissen um daraus entstehende Probleme zu vermeiden. So wie du es
weißt und auf diese Art Probleme vermeidest.
Falk B. schrieb:> Du Nase!
Falk, könntest du bitte die Antworten OHNE solche absolut vollkommen
unnötigen persönlichen Angriffe und Beleidigungen schreiben? Den Rest
meiner Antwort spare ich mir!
@Stefan Us (stefanus)
>Wie kann denn etwas ein Arduino-Würg-Around sein, was in praktisch allen>anderen Programmiersprachen und Betriebssystemen ebenso vorhanden ist?
Falsch! Du verwechselst die Verfügbarkeit einer Methode mit deren
optimalem Einsatz.
>> in den allermeisten Fällen will man diverse State Machines>> mit einer definierten, konstanten Frequenz aufrufen>Ich kenne das als eine mögliche Lösung.
Na immerhin.
>Ich habe aber schon wesentlich mehr State Machines gesehen, deren>hauptschleife einfach nur schnellstmöglich ausgeführt wird. Unter>anderem in Arduino,
WOW! Was für eine Referenz! Vor allem was die Performance angeht!
> µC Projekte die auf LwIp und µIP basieren (somit>auch ESP8266),
Hmm.
>fast alle meine eigenen µC Projekte,
Naja.
> zahlreiche Windows>Programme, die Event-Loop vom QT Framework, ...
Sinngemäßes Zitat von Bertrand Russel
"Nur weil eine Meinung von der Mehrheit vertreten wird, ist kein Beweis,
daß es nicht vollkommener Unsinn ist."
Mein letztes Plädoyer zum Thema.
Man KANN mit einer Funktion ala millis() diverse Statemachine betreiben,
die ggf. auch nur so schnell wie möglich oder auch langsamer aufgerufen
werden. Für einige Anwendungen ist das ausreichend.
Manchmal MUSS man es machen, weil es nicht besser geht und ggf. mit den
daraus folgenden Einschränkungen leben.
ABER!!!!!
Wenn möglich, versucht man bei einer Problemlösung von vorn herein
erstmal KEINE Kompromisse zu schließen und eine schnelle,
leistungsfähige Lösung anzustreben. Das bedeutet hier, eine Statemachine
mittels Timer oder gar ISR im festen Zeitraster aufzurufen, ohne
sonstige Kompromisse. Und genau DAS will und braucht der OP!!! OK, es
war der andere Thread, die Diskussion ist aber praktisch die Gleiche,
weil das grundlegende Problem das Gleiche ist!
Beitrag ""Interrupt" durch Vergleich von Variablen möglich? Timingprobleme durch zu lange Programmlaufzeit">Vielleicht beginnst du mal zu akzeptieren, dass viele Wege zum Ziel>führen und deiner nicht der einzig richtige ist.
Das habe ich nie behauptet. Siehe oben.
@ Lothar Miller (lkmiller) (Moderator)
>>> millis() ist genau das, was der TO braucht,>> Nein, denn diese Funktion liefert nur einen Timerwert, welche in einem>> 1ms Timer-Interrupt hochgezählt wird.>Das reicht für übliche zeitliche Abläufe völlig aus.
Nö. Definiere mal "übliche zeitliche Abläufe".
>> Die nützt rein gar nichts, wenn andere Funktionen, warum auch immer,>> den Programmablauf längere Zeit "blockieren".>Dann haben wir das Problem ja schon erkannt: der Programmablauf der>Hauptschleife darf schlicht und einfach nicht blockiert werden. Das>wars. Wenn man sich daran hält, dann kann man ganz einfach wartbare und>erweiterbare und vor allem portierbare Programme schreiben.
Bla! Auch das ist, wie bereits geschrieben, in einigen Fällen nicht
möglich, vor allem bei Einsatz von Fremdsoftware oder Bibliotheken.
>> Das VORZÜGLICHE FATfs vom Meister Elm Chan aus dem fernen Osten hat>> diverse Funktion, die halt mal länger und mal kürzer dauern. Willst du>> daraus schließen, daß dFATfs Mist ist?>Doch. Genau das ist es: wenn es mir wegen irgendwelcher Warterei auf>irgendwelche Hardware das Timing verhagelt, dann ist das Murks.
Pure Arroganz und Ignoranz! Beschäftige dich mal mit der Software, dann
kannst du ggf. einen fundierten Kommentar abgeben!
>Und ich muss dann auf die eine oder andere Art einen Workaroud drumrum>basteln.
Jain. Eine vergleichbare Software, die beliebig multitaskingfähig ist,
braucht entweder ein echtes, prääemtives Multitasking oder einen
deutlich anderen Softwareansatz. Beides ist ziemlich aufwändig. Der
Kompromiss der bestehenden Lösung ist IMO optimal.
Natürlich muss man des Öfteren Kompromisse und manchmal auch Workarounds
machen. Die Frage ist aber, ob man ohne Not gleich damit anfängt. Und
meine Antwort darauf ist: NEIN!
Falk B. schrieb:
>> Dass er sich damit ganz andere Probleme an die Backe klebt, weiß er>>>allerdings auch nicht (Stichworte Semaphorenproblem und Racecondition).> Jaja, und schon wieder sind am Sonntag Morgen die Reichsbdenkenträger> voll dabei, die Welt zur retten. ODer zumindest viel Staub aufzuwirblen!>Falk, du lenkst ab. Hier schlagen doch laufend Anfänger auf, die sich>wundern, warum ihre volatile Variable, die im Interrupt und im>Huptprogramm verwendet wird, ab&zu "spinnt".
Ja und? Das Problem ist mit einem volatile lösbar. Und die Grundlagen
dazu sind im Artikel Interrupt zu finden.
>Und ich kenne einige Fälle, wo Anfänger um genau solche Fälle dann mit>"Dreifach-Abfragen mit anschließendem Vergleich" übel um genau dieses>Semaphoren-Problem herumflicken.
Auch das ist ein lösbares Problem. millis() macht es nicht wirklich
besser. Du willst nicht die Stützräder am Fahrrad abschrauben sondern
bunt anmalen. Das klingt sehr fürsorglich, entmündigt aber nur.
>> Du Nase!>Falk, könntest du bitte die Antworten OHNE solche absolut vollkommen>unnötigen persönlichen Angriffe und Beleidigungen schreiben?
Nö, manchmal geht es einfach nicht anders.
> Den Rest meiner Antwort spare ich mir!
Ist auch besser so, moralinsaure Gardinenpredigten sind sowieso sinnlos,
in meinem Alter erst recht ;-)
Hallo
danke für die diversen Links und auch für die sich entwickelnde
Diskussion die meist interessant und teilweise sogar hilfreich für mich
ist.
Aber bitte: Es handelt sich um ein Technisches Thema - da sollte eine
vernünftige Diskussionskultur doch möglich sein?
Das sich hier einige Leute herumtreiben die erkennbar richtig viel
Wissen und Erfahrung in anspruchsvollen Technischen Bereichen haben,
aber gleichzeitig wie ein Holligan oder ein 18 jähriger besoffener am
Samstagmorgen um 4:00Uhr in der Partymeile einer Großstadt
"argumentieren" ist nur noch als beschämend zu bezeichnen.
Mensch Leute, seid Nett zueinander, akzeptiert andere Meinungen,
Vorgehensweisen und das nicht alle genauso viel fachlich Wissen wie man
selbst.
Ardu Ino
Ardu Ino schrieb:> deshalb gibt es auch eine> Funktion millis, auf die ich aber auch gerne verzichten würde.> Wieso, weshalb, warum steht nicht zu Diskussion
Sollte es aber.
"millis" gibt Dir nur einen Zeitstempel zurück, ist also überhaupt nicht
böse. Es gibt daher keinen Grund darauf verzichten zu wollen. Der
Unterschied, ob man CPU-Leistung verschwendet oder nicht, liegt allein
an Dir, wie Du "millis" anwendest.
Eine bequeme Lösung für parallele Tasks mit verschiedenen Verzögerungen
kann dann ein Scheduler sein, der z.B. in 1ms oder 10ms Schritten
aufgerufen wird:
Beitrag "Wartezeiten effektiv (Scheduler)"
@Matthias Melcher (Firma: privat) (quadraturencoder)
>Ich verstehe den Aufruhr nicht. Hat doch bei Heise alles schon mal>gestanden. Man nimmt einen Timer Interrupt und gut:
Na wenn das bei heise steht, MUSS es ja die reine Wahrheit sein ;-)
Naja, die Begründung, warum ein delay() schlecht ist, ist aber auch eher
schlecht 8-0
Daß dabei die CPU steht und zum Nichtstun verdonnert wird, kommt dort
nicht wirklich rüber! Außerdem ist die Ungenauigkeit der Funktion das
kleinste der Probleme, mal ganz davon abgesehen, daß sie gar nicht so
ungenau ist, sondern mit einer Auflösung und Genauigkeit von wenigen
CPU-Takten arbeitet. Naja, das übliche IT-Fastfood von heute . . .
Falk B. schrieb:> @Matthias Melcher (Firma: privat) (quadraturencoder)>>>Ich verstehe den Aufruhr nicht. Hat doch bei Heise alles schon mal>>gestanden. Man nimmt einen Timer Interrupt und gut:>> Na wenn das bei heise steht, MUSS es ja die reine Wahrheit sein ;-)
Auch wenn das gleiche bei Falk B. steht? ;-)
Falk B. schrieb:> Das bedeutet hier, eine Statemachine> mittels Timer oder gar ISR im festen Zeitraster aufzurufen, ohne> sonstige Kompromisse. Und genau DAS will und braucht der OP!!!
Warum machst du dich jetzt über heise lustig, obwohl dort die gleiche
Meinung vertreten wird, wie du sie vertrittst?
@Krull (Gast)
>Warum machst du dich jetzt über heise lustig, obwohl dort die gleiche>Meinung vertreten wird, wie du sie vertrittst?
Weil die Begründung eher schlecht ist. Man kann das richtige meinen aber
schlecht ausdrücken.
Falk B. schrieb:> mal ganz davon abgesehen, daß sie gar nicht so> ungenau ist, sondern mit einer Auflösung und Genauigkeit von wenigen> CPU-Takten arbeitet. Naja, das übliche IT-Fastfood von heute . . .
...aber (fast) jedes µC-Programm arbeitet auch mit Interrupts. Und diese
Interrupts unterbrechen logischerweise auch ein delay(). Damit (und das
ist eigentlich der Normalfall) wird das delay() auf jeden Fall nicht
mit der Genauigkeit von wenigen CPU-Takten arbeiten!
@Krull (Gast)
>> mal ganz davon abgesehen, daß sie gar nicht so>> ungenau ist, sondern mit einer Auflösung und Genauigkeit von wenigen>> CPU-Takten arbeitet. Naja, das übliche IT-Fastfood von heute . . .>...aber (fast) jedes µC-Programm arbeitet auch mit Interrupts.
Viele. Die Arduino-Welt nahezu ohne, vom "unsichtbaren" 1ms Timer mal
abgesehen.
>Und diese>Interrupts unterbrechen logischerweise auch ein delay(). Damit (und das>ist eigentlich der Normalfall) wird das delay() auf jeden Fall nicht>mit der Genauigkeit von wenigen CPU-Takten arbeiten!
Nö, du konstruierst schon wieder eine Sachlage, die so gar nicht
existiert. So nach dem Motto, wenn ich ein 10m Maßband nur zu Hälft
ausrolle, kann ich keine 10m messen. ;-)
Wer des Lesens und vor allem des sinnerfassenden Lesens mächtig ist,
wird in der Doku davor gewarnt. Und dann kann man mit delay() recht
genaue Zeiten erreichen, z.B. einfache Pulsgeneratoren. Für einige
Anwendungen ist das OK, wenn die CPU so oder so nix besseres zu tun hat.
In vielen Fällen hat sie das aber.
Falk B. schrieb:> Nö, du konstruierst schon wieder eine Sachlage, die so gar nicht> existiert. So nach dem Motto, wenn ich ein 10m Maßband nur zu Hälft> ausrolle, kann ich keine 10m messen. ;-)
Und wenn ich mein Maßband in 1µm kleine Teile schneide, kann ich sogar
sehr genau messen ;-)
Ich frage mich, wer hier etwas konstruiert, nur damit er recht behält.
Willst du allen ernstes behaupten, daß ein delay(), wenn es tausendmal
durch einen Interrupt unterbrochen wird, der selbst ja logischerweise
auch Zeit braucht, dann genauso lang ist wie ein delay(), was ganz
allein und ungestört läuft? Ein delay() weiß doch nicht, wie lange ein
Interrupt dauert, oder? Vor allem, weil ja innerhalb der isr noch
Verzweigungen auftreten können, die auch von externen Ereignissen
bestimmt werden können...
@Krull (Gast)
>Willst du allen ernstes behaupten, daß ein delay(), wenn es tausendmal>durch einen Interrupt unterbrochen wird, der selbst ja logischerweise>auch Zeit braucht, dann genauso lang ist wie ein delay(), was ganz>allein und ungestört läuft?
Keine Sekunde, nicht mal delay(1) ;-)
Mein Gott, willst du mich nicht verstehen oder kannst du mich nicht
verstehen oder willst du nur schwätzen um des Schwätzens willen?
>Ein delay() weiß doch nicht, wie lange ein>Interrupt dauert, oder?
Jaja, also doch nur Schwätzen!
>Vor allem, weil ja innerhalb der isr noch>Verzweigungen auftreten können, die auch von externen Ereignissen>bestimmt werden können...
BlaBlaBla!
Krull schrieb:> Ein delay() weiß doch nicht, wie lange ein> Interrupt dauert, oder? Vor allem, weil ja innerhalb der isr noch> Verzweigungen auftreten können, die auch von externen Ereignissen> bestimmt werden können...
Bitte "Non-blocking Virtual Delay" anschauen - es wird ein Vergleich mit
dem internen 1ms-Timer gemacht -- der Fehler der dabei entsteht ist ..
1ms -- was häufig ausreichen sollte. Wie lang andere Abläufe dauern
ist dabei nicht wichtig.
@ Jens Grabner (jensg)
>Bitte "Non-blocking Virtual Delay" anschauen
Hab ich gemacht.
>- es wird ein Vergleich mit>dem internen 1ms-Timer gemacht
Stimmt.
> -- der Fehler der dabei entsteht ist ..>1ms
Stimmt nicht!
> -- was häufig ausreichen sollte.
Dito!
> Wie lang andere Abläufe dauern ist dabei nicht wichtig.
Falsch! Es wird nur festgestellt, ob die vorgegebene Wartezeit erreicht
wurde oder nicht. Ob die um 1, 10, oder 1.000.000 ms überschritten wurde
wird weder geprüft, noch gemeldet noch könnte man was dagegen tun!
Zumindest nicht direkt. Denn wenn die anderen Abläufe zu lange brauchen,
erfolgt die Prüfung und damit ggf. die Reaktion auch zu spät. Und wenn
man dann periodisch den virtuellen Timer wieder starten will,
akkumuliert sich der Fehler! Ganz toll!
Mal ganz abgesehen davon, daß auch die Beispiele dort Mist sind. So
lernt niemand eine gescheite Programmierung und Struktur von Programmen,
sondern nur den allgegenwärtigen Arduino-Murks.
Ergo. Gute Tutorials fallen nicht vom Himmel und sind eher rar.
Falk B. schrieb:> @ Jens Grabner (jensg)>>>Bitte "Non-blocking Virtual Delay" anschauen>> Hab ich gemacht.
Ich auch....
Selbst wenn ich ähnliche Verfahren anwende, muss ich sagen, dass das
Tutorial/Code nicht schön ist.
z.B. static in Makros.
Darauf reagiere ich mittlerweile recht allergisch.
Das kann die Wiederverwendung von Funktionen und Klassen/Objekten derbe
einschränken.
Könntest du bitte mal meine Fragen beantworten?
Deine drei letzten "Antworten" sind dafür nicht geeignet.
Ich frage dich, ob ein delay, das durch Interrupts ständig unterbrochen
wird, genauso lang ist ist, wie ein "ungestörtes" delay?
Und du antwortest darauf:
> "keine Sekunde" ---???
Ich frage dich, ob ein delay weiß, wie lange Interrupts brauchen?
Deine Antwort:
> Jaja, also doch nur Schwätzen! --???
Ich stelle fest, daß innerhalb der isr noch Verzweigungen auftreten
können und damit die Ausführungsdauer einer isr nicht bestimmbar ist.
Deine Antwort:
> BlaBlaBla!
Also bitte gib mir jetzt die richtigen Antworten, ja?
Falk Brunner -- Besten dank für die genaue Beschreibung -- ein
RealTimeOS oder auch nur ein Sytem zur Zeitsteuerung ist für viele
"Anfänger" einfach schon eine Hürde -- Arduino ist auf der anderen
Seite auch nie für professionelle Dinge gedacht gewesen -- weshalb hier
sehr heftig unterschiedliche Denkmuster zusammenlaufen.
aber gut -- delay() und die Beispiele dazu hätten "nie" Standard werden
dürfen -- ohne delay() vermeidet man viele Probleme.
@Jens Grabner (jensg)
>RealTimeOS oder auch nur ein Sytem zur Zeitsteuerung ist für viele>"Anfänger" einfach schon eine Hürde
Sicher.
>-- Arduino ist auf der anderen>Seite auch nie für professionelle Dinge gedacht gewesen -- weshalb hier>sehr heftig unterschiedliche Denkmuster zusammenlaufen.
Mag sein.
>aber gut -- delay() und die Beispiele dazu hätten "nie" Standard werden>dürfen -- ohne delay() vermeidet man viele Probleme.
Mag auch sein. delay() hat schon seine Berechtigung, sei es für
einfach(ste) Arduino-Sachen oder wo es halt unkritisch ist. Ebenso die
Funktion millis() und deren Anwendung. Man sollte aber dennoch in einer
vernünftigen, anschaulichen Art und Weise zeigen, wie man es besser
machen kann, wenn es denn nötig ist. Nicht mehr und nicht weniger wollte
ich sagen.
Jens G. schrieb:> delay() und die Beispiele dazu hätten "nie" Standard werden> dürfen
Schwachsinn!
Ein delay() ist leicht zu verstehen, und tut genau das, wofür es
vorgesehen ist.
Außerdem kan man während eines delay() noch tausend andere feine Dinge
tun, nur nicht das delay() vorzeitig abbrechen.
Vielleicht habe ich ja auch Aussagen oder Anforderungen überlesen:
Aus Prinzip alles in eine isr zu packen ist sicher kurzsichtig und blöd.
Falk B. sprach vom Drehgeber. Klar Stich gemacht, aber man weiß doch gar
nicht, WAS der TO eigentlich machen will. Ein Dogma erarbeiten ist da
nun auch nicht zielführend.
Eine Statemachine die millis() benutzt hat von mir auch quasi jedes
Programm. Zugegebenermaßen neben härteren Echtzeit-Geschichten. Wenn ich
alle 10s einen Feuchtigkeitswert angucken will, mache ich da keinen
Timer für, sondern vergleiche mit der Systemzeit.
Mit delay_ms() operieren zu wollen ist an sich (fast) immer unklug. ich
sage fast, weil man damit auch ein Programm schreiben kann, welches gut
damit funktionieren kann wenn man das im Vorfeld weiß.
Werkzeug zum Problem wählen.
@Falk:
Könntest du bitte mal meine Fragen beantworten?
Deine drei letzten "Antworten" sind dafür nicht geeignet.
Ich frage dich, ob ein delay, das durch Interrupts ständig unterbrochen
wird, genauso lang ist ist, wie ein "ungestörtes" delay?
Und du antwortest darauf:
> "keine Sekunde" ---???
Ich frage dich, ob ein delay weiß, wie lange Interrupts brauchen?
Deine Antwort:
> Jaja, also doch nur Schwätzen! --???
Ich stelle fest, daß innerhalb der isr noch Verzweigungen auftreten
können und damit die Ausführungsdauer einer isr nicht bestimmbar ist.
Deine Antwort:
> BlaBlaBla! ---???
Also bitte gib mir jetzt die richtigen Antworten, ja?
Krull schrieb:> Ich frage dich, ob ein delay, das durch Interrupts ständig unterbrochen> wird, genauso lang ist ist, wie ein "ungestörtes" delay?> Und du antwortest darauf:
Ein bisschen verspannt heute?
Weißt du es wirklich nicht, oder willst du nur Streit?
Arduino F. schrieb:> Krull schrieb:>> Ich frage dich, ob ein delay, das durch Interrupts ständig unterbrochen>> wird, genauso lang ist ist, wie ein "ungestörtes" delay?>> Und du antwortest darauf:>> Ein bisschen verspannt heute?>> Weißt du es wirklich nicht, oder willst du nur Streit?
Ich suche absolut keinen Streit. Ich habe dem Falk ein paar Fragen
gestellt. Seine "Antworten" kannst du selbst lesen.
Aber vielleicht kannst du mir die Fragen beantworten? Falk will es
offensichtlich nicht.
Wichtig ist zu erkennen ob Delay das Projekt nun "zerstört" oder
hinreichend ist. Im ersteren Falle muss man einen einfachen Workaround
schaffen, da brauch man nicht diskutieren und lange Sinnlos Schwafeln.
Wenn Du alles unbedingt mit einem Timer umsetzen möchtest, geht das
auch..
Die Frage ist nur, reichen Deine Fähigkeiten dazu aus das ohne
Delay/Millis zu machen oder nicht.
Millis ist schonmal ein guter Ansatz das Delay zu umgehen.. das ist
mehrschichtig auch nicht "Super einfach" und verlangt auch schon Grips.
(Bei einem siehts einafch aus.. mach mal nen BlinkWithoutDelay mit 3
LEDS, und 3 IF/FOR)
Wenn man das mit Millis kann braucht es nur noch eine
Timerinitialisierung und ein "Suchen/ersetzen" um es auf einen Timer
umzumünzen.
Krull schrieb:> Aber vielleicht kannst du mir die Fragen beantworten?
Sicher!
Es liegt ganz an der Implementierung!
1: Das AVR Lib (util/delay.h) Delay wird von jedem ISR Ereignis
verlängert.
2: Bein Arduino delay() verlängert, schlimmstenfalls, die letzte ISR die
Pause.
Jetzt alle Klarheiten beseitigt?
Arduino F. schrieb:> Krull schrieb:>> Aber vielleicht kannst du mir die Fragen beantworten?>> Sicher!>> Es liegt ganz an der Implementierung!>> 1: Das AVR Lib (util/delay.h) Delay wird von jedem ISR Ereignis> verlängert.>> 2: Bein Arduino delay() verlängert, schlimmstenfalls, die letzte ISR die> Pause.>> Jetzt alle Klarheiten beseitigt?
Alle noch nicht, aber damit kann ich auf jeden Fall wesentlich mehr
anfangen als mit der "Gesprächskultur" von Falk.
Danke dir dafür.
Der erste Punkt (AVR-Delay) war mir bekannt, deshalb habe ich dem Falk
die Fragen gestellt.
Der zweite Punkt ist mir neu. Da werde ich mich mal damit
auseinandersetzen und versuchen den Grund herauszufinden, warum nur die
letzte ISR das Delay verlängert. Allein daß das so ist, wußte ich nicht.
Das ist aber (meiner Meinung nach) kein Grund für Falk, mir nur mit
"blabla" zu antworten. Ist er so abgehoben, daß er sich nicht vorstellen
kann, daß es noch Leute gibt, die weniger wissen als er? Ich für meinen
Teil finde das einfach arrogant. Sorry :-(
Auf jeden Fall danke ich dir für deine Antworten :-)
Krull schrieb:> arrogant
Ich halte es für recht schwierig, Arroganz und Kompetenz auseinander zu
halten, wenn ich die Person nicht kenne.
Auch kommen soziale und fachliche Kompetenz nicht immer in Personalunion
vor.
PS:
Auch du zeigst hier ein irritierendes Verhalten.
(ein mich irritierendes)
Arduino F. schrieb:> Krull schrieb:>> arrogant>> Ich halte es für recht schwierig, Arroganz und Kompetenz auseinander zu> halten, wenn ich die Person nicht kenne.>> Auch kommen soziale und fachliche Kompetenz nicht immer in Personalunion> vor.
Das mag ja sein, aber wenn ich kompetent bin, gibt mir das nicht das
Recht, jemandes Frage einfach mit "blabla" zu beantworten. Das ist dann
der Punkt, wo sich die fachliche Kompetenz von der sozialen Kompetenz
gründlich verabschiedet hat. Tut mir auch leid für Falk. Ich hoffe, er
hatte nur einen "schlechten Tag" und ist nicht immer so :-)
BlaBla schrieb:> Liegt wohl heute am Wetter. Ich hoffe es sind keine Psychopathen> oder/und Soziopathen unter uns.
Da mache dir mal keine zu großen Hoffnungen.
Meiner Schätzung nach tragen ca 2% der Weltbevölkerung eine neurotische
Fehlanpassung mit sich rum.
Ob die sich hier rudeln, ka, manchmal kommt es mir so vor.
Arduino F. schrieb:> PS:> Auch du zeigst hier ein irritierendes Verhalten.> (ein mich irritierendes)
Darf ich mal fragen, was genau dich irritiert?
Kommt es nicht so häufig vor, daß man Antworten einfordert, wenn man
Fragen gestellt hat? Oder was ist es?
Krull schrieb:> Kommt es nicht so häufig vor, daß man Antworten einfordert, wenn man> Fragen gestellt hat?
Z.B.:
Wenn in Fragen schon die gewünschte Antwort vorgegeben wird, empfinde
ich das als provokant.
Als unangenehm.
Oft wird sowas (unbewusst?) als subtile Methode genutzt, um eine
Eskalationsspirale zu starten, oder zu fördern.
Und das ist etwas, woran ich nur selten Spaß habe.
Arduino F. schrieb:> 2: Bein Arduino delay() verlängert, schlimmstenfalls, die letzte ISR die> Pause.
Das würde ich etwas relativieren.
Das Arduino-Delay (ms) basiert auf den "Standard-Millis". Wenn da
mehrere Interrupts hintereinander kommen (incl. der Millis ...) dann
wartet das Arduino-Delay diese alle ab (soweit mein Verständnis). Wenn
ein Spassvogel die "Millis" deaktiviert, dann gibt es gar ein St.
Nimmerlein-delay.
Das (Arduino-Delay (µs) ) arbeitet mit "NOP" und kann gleichfalls
beliebig durch ISR unterbrochen und verzögert werden.
Das halte ich für einen konstruierten Sonderfall.
Wenn die ISR so dicht aufeinander folgen, dass noch nicht mal ein
delay() sein Ende (recht pünktlich) findet, dann ist was ganz anderes
faul.
Mindestens ein Maschinenbefehl, des Hauptprogramms, wird zwischen 2 ISR
ausgeführt!?!
Also findet das delay() sein Ende.
Arduino F. schrieb:> Das halte ich für einen konstruierten Sonderfall.
Das ist Dein gutes Recht:-) - aber der "schlimmste Fall"
Arduino F. schrieb:> 2: Bein Arduino delay() verlängert, schlimmstenfalls, die letzte ISR die> Pause.
ist nunmal oft ein Sonderfall.
Arduino F. schrieb:> Mindestens ein Maschinenbefehl, des Hauptprogramms, wird zwischen 2 ISR> ausgeführt!?!
So sei es. Die "Arduino-Delay (ms)"-Routine besteht aus einigen
"Maschinenbefehlen" - oder?
Arduino F. schrieb:> Außerdem kan man während eines delay() noch tausend andere feine Dinge> tun, nur nicht das delay() vorzeitig abbrechen.
Das würde ich gerne erklärt bekommen. Nach meinem Verständnis ist delay
blockierend, während dieser Zeit kann kein weiterer Code ausgeführt
werden.
>Wessen - von wann? Wir schreiben das Jahr 2017 ...
Genau so ist es. Im Jahr 2017 gibt es GitHub. Und dort befindet sich das
aktuelle Arduino Repository. Und darauf habe ich verlinkt. Sogar auf's
richtige File mit Angabe der Zeilennummer.
Zu schwer?
> Das würde ich gerne erklärt bekommen. Nach meinem Verständnis ist delay> blockierend, während dieser Zeit kann kein weiterer Code ausgeführt> werden.
Interrupts können delay() unterbrechen.
Ich schätze, du hast den Thread nicht mitverfolgt, oder?
Manfred schrieb:> Das würde ich gerne erklärt bekommen. Nach meinem Verständnis ist delay> blockierend, während dieser Zeit kann kein weiterer Code ausgeführt> werden.
Testprogramm:
chris schrieb:> Genau so ist es. Im Jahr 2017 gibt es GitHub. Und dort befindet sich das> aktuelle Arduino Repository. Und darauf habe ich verlinkt. Sogar auf's> richtige File mit Angabe der Zeilennummer.>> Zu schwer?
Scheinbar ... 2005 - 2006 war einmal (von wem auch immer ...)
Arduino F. schrieb:> Manfred schrieb:>> Das würde ich gerne erklärt bekommen. Nach meinem Verständnis ist delay>> blockierend, während dieser Zeit kann kein weiterer Code ausgeführt>> werden.
Außer ISR - und das kannst Du nachlesen :-)
man lernt hier immer noch dazu, danke an alle
wie ist das mit Serial.event und Serial.available() mit Serial.read();
unterbricht das delay_ms()?
Das ich eigene ISR nutzen kann weiss ich schon.
Joachim B. schrieb:> wie ist das mit Serial.event und Serial.available() mit Serial.read();>> unterbricht das delay_ms()?
Nein!
Aber der von Serial genutzte Interrupt tut das.
Also: JA!
ööhmmmm...
Ein kleines Jain, auf die Frage, weil sie in sich einen logischen Fehler
hat.
Das paradoxe an Frameworks ist: Sie sollen die Arbeit erleichtern. Doch
früher oder später kommen Detailfragen auf, zu deren Beantwortung man in
den Quelltext schauen muss. Spätestens, wenn das Framework darüber
hinaus nicht genau das tut, was man braucht, muss man sich fragen, warum
man überhaupt ein Framework verwendet hat.
Ich wollte diese Erkenntnis als Java Enterprise Entwickler viele Jahre
lang nicht akzeptieren, doch mittlerweile wurde ich mehrfach auf die
harte Tour (durch negative Erfahrung) eines besseren belehrt.
>Das paradoxe an Frameworks ist: Sie sollen die Arbeit erleichtern...
Ja, heutzutage kämpft man eigentlich nur noch mit den Frameworks.
Ich neige dazu, alles selber schreiben zu wollen. Aber am Ende bleibt
einem halt doch nur, Frameworks nutzen zu müssen.
Bei den Arduinosachen hat man zumindest die Möglichkeit bis auf die
unterste Ebene rein zu schauen und notfalls kann man da was ändern.
Bei den STM-HAL Sachen kann das aber richtig übel werden und eigentlich
helfen da nur Workarrounds.
Arduino F. schrieb:> ööhmmmm...> Ein kleines Jain, auf die Frage, weil sie in sich einen logischen Fehler> hat.
wo?
ich habe void serialEvent(void) erst spät entdeckt ist ja eine
Interruptnutzung
somit müsste
void serialEvent(void)
{ while (Serial.available())
{ char incomingByte = (char)Serial.read();
auch delay_ms unterbrechen
wo soll der logische Fehler sein?
Stefan U. schrieb:> Interrupts können delay() unterbrechen.
Allerdings würde ich in einer ISR nicht
Arduino F. schrieb:> noch tausend andere feine Dinge
tun.
Autor: Dieter F. (jim_quakenbush)
>Scheinbar ... 2005 - 2006 war einmal (von wem auch immer ...)
Oha, ich dachte mein Link sei das Main-Arduino-Repository.
Falls jemand das von 2015 findet, würde mich ein Link stark
interessieren.
Joachim B. schrieb:> ich habe void serialEvent(void) erst spät entdeckt ist ja eine> Interruptnutzung
Ist es nicht.
serialEvent() wird in der main() Loop aufgerufen.
Ein Schritt vor, oder nach, dem Aufruf von loop().
Also im ganz normalen Programmkontext.
Nicht in einem Interrupt.
Rolf M. schrieb:> Stefan U. schrieb:>> Interrupts können delay() unterbrechen.>> Allerdings würde ich in einer ISR nicht>> Arduino F. schrieb:>> noch tausend andere feine Dinge>> tun.
Ein drohendes Darama bei dem yield() ist, dass rekursive Aufrufe
stattfinden könnten.
Das wird man (durch Disziplin?) unterbinden müssen.
Stefan U. schrieb:> Nach meinem Verständnis ist delay>> blockierend, während dieser Zeit kann kein weiterer Code ausgeführt>> werden.>> Interrupts können delay() unterbrechen.
Das ist mir klar, aber ich sehe diese eher als Sonderform zeitkritischer
Anwendungen denn im Tagesgeschäft.
> Ich schätze, du hast den Thread nicht mitverfolgt, oder?
Aber doch! Bei solchen Themen schaue ich immer, ob ich ein paar
Informationen oder Anregungen für mich mitnehmen kann.
Manfred schrieb:> Das ist mir klar, aber ich sehe diese eher als Sonderform zeitkritischer> Anwendungen denn im Tagesgeschäft.
Was hast Du denn für ein Tagesgeschäft mit AVR-Mikrocontrollern?
Autor: Dieter F. (jim_quakenbush)
>Google kennst Du? Die Welt hat sich weiter gedreht :-)
Bei mir wirft Google dieses:
https://github.com/arduino
Aber Google ist ja schlau und präsentiert Userabhängige Ergebnisse.
Vielleicht will's mich ärgern, weil ich kein Android-Handy habe.
Jetzt zeig mal den Link den Google Dir zeigt.
Arduino F. schrieb:>> Das würde ich gerne erklärt bekommen. Nach meinem Verständnis ist delay>> blockierend, während dieser Zeit kann kein weiterer Code ausgeführt>> werden.> Testprogramm:
Oops, da hast Du etwas gemacht, was mir vollkommen unbekannt ist. Mit
einer Internetsuche lande ich auf einer Bachelorarbeit an der Uni
Hamburg und finde "yield" als Scheduler beschrieben.
Heisst also, mit "void setup(void) und void loop(void)"
springst Du jedesmal durch void yield(void)?
Das muß ich erstmal sacken lassen :-)
Danke Dir!
chris schrieb:> Vielleicht will's mich ärgern, weil ich kein Android-Handy habe.
Dann müsste Google mich noch mehr ärgern, weil ich gar kein
Schei..-Handy/-Schmartphone habe :-) (auch kein Fatzebook und kein
Whatsapp etc. ) habe
Dieter F. schrieb:> chris schrieb:>> Jetzt zeig mal den Link den Google Dir zeigt.>> Ich wusste gar nicht, dass dafür ein Kurs erforderlcih ist :-)>> https://github.com/arduino-org/arduino-core-nrf52/...
Arduino.org ist ein toter Ast in der Arduinowelt.
Und der nrf52 ist kein typischer Arduino.
Dein Link zeigt also ins Gebüsch.
Dieter F. schrieb:> Willkommen im Club der Ignoranten
Wer weiß, vielleicht sind wir ja noch mehr.
Arduino F. schrieb:> Arduino.org ist ein toter Ast in der Arduinowelt.
Und wo wachsen die Blätter? Arduino.org hört sich für mich nach oberster
Instanz an. Oder ist das jetzt Alduino.cn?
Manfred schrieb:> und finde "yield" als Scheduler beschrieben.
Über die Geschichte weiß ich nichts...
Aber irgendwo in den Tiefen der Arduino Doku findet sich ein Spruch
dazu:
> yield() ist für Entwickler von Libraries bestimmt,> um Kooperative Scheduler zu implementieren.
(möglichst sinngemäß wiedergegebeben)
Manfred schrieb:> Heisst also, mit "void setup(void) und void loop(void)"> springst Du jedesmal durch void yield(void)?
yield() wird in delay() aufgerufen.
Halt um die Wartezeit sinnvoll nutzen zu können.
Thomas E. schrieb:> Und wo wachsen die Blätter? Arduino.org hört sich für mich nach oberster> Instanz an. Oder ist das jetzt Alduino.cn?
Der Arduino.cc Trupp hat sich in die Wolle bekommen.
Arduino.org hat sich abgespalten.
Kürzlich war die Wiedervereinigung.
Damit ist Arduino.org weg vom Fenster.
Das war ein Prozess über ca. 2 Jahre.
Dieter F. schrieb:>> Das ist mir klar, aber ich sehe diese eher als Sonderform zeitkritischer>> Anwendungen denn im Tagesgeschäft.> Was hast Du denn für ein Tagesgeschäft mit AVR-Mikrocontrollern?
Mein Tagesgeschäft im beruflichen Erwerbsleben hat leider keine Hardware
mehr, früher war ich dort mal mit 2MHz-Taktfrequenz und Assembler
unterwegs.
Arduino setze ich im Hobbybereich ein, für überschaubare Steuerungs- /
Meßaufgaben. Meist renne ich da in einer Schleife herum und vergleiche
diverse Millisekunden, um dann in einer Unterroutine etwas zu tun. Diese
Unterroutine kann auch mal blockierend sein oder einige Dutzend
Millisekunden dauern.
Interrupt habe ich eingesetzt, um auf eine Eingabe in akzeptabler Zeit
zu reagieren.
Als nächstes will ich Entladekurven von Akkus auf eine SD-Karte
schreiben, das wird aus Sicht des Prozessors im Prinzip unendlich
langsam ablaufen.
> Copyright (c) 2005-2006 David A. Mellis>lol - aber vergiss es, ich lasse euch jetzt in Ruhe :-)
Die letzte Änderung im File ist aber vom Dez.2015:
https://github.com/arduino/Arduino/commit/b1231c39e9fa6d8602ac24305b07f074c1145633
Es sieht so aus, als wenn sie das Datum im Header nicht aktualisiert
haben.
Das ist aber auch lästig, wenn man wegen jeder kleinen Änderung im File
den Copyright Header ändern muss.
Joachim B. schrieb:> sitzt definitiv ausserhalb der loop
Außerhalb von loop(), ja.
Aber innerhalb der Schleife, welche sich typischer weise in main()
befindet.
Und damit eben nicht in einem Interrupt.
Es verlängert nicht das delay_ms()
Das Gegenteil ist der Fall:
Ein delay_ms() verzögert den serialEvent() Aufruf.
Siehe:
https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/cores/arduino/main.cpp
Dort wird serialEventRun() aufgerufen, welches wiederum dann die
diversen serialEvent() aufruft.
Thomas E. schrieb:> Und was macht er damit?
Habe ich eben schon beschrieben:
Arduino F. schrieb:> Ein drohendes Darama bei dem yield() ist, dass rekursive Aufrufe> stattfinden könnten.> Das wird man (durch Disziplin?) unterbinden müssen.
Arduino F. schrieb:> Außerhalb von loop(), ja.> Aber innerhalb der Schleife, welche sich typischer weise in main()> befindet.> Und damit eben nicht in einem Interrupt.> Es verlängert nicht das delay_ms()
das wiederum hatte ich nirgens behauptet, es wurde behauptet das während
delay_ms nichts abgearbeitet wird, das war meine Frage, aber egal ich
nutze mein eigenes my_delay_ms() und da wird nebenbei anderes
abgearbeitet.
D.h. während my_delay wartet wird dort weitergearbeitet.
Arduino F. schrieb:> Ist es nicht.> serialEvent() wird in der main() Loop aufgerufen.
hört sich nach Ausrede an, in der Arduinowelt gibts nur loop()
klar liegt noch eine main loop drüber, dann schreibe das doch
deutlicher, wenn in Arduino von loop gesprochen wird dann ist doch
loop() gemeint und nicht while(1);
Dabei habe ich doch extra "main() Loop" geschrieben!
Die Klammern mit Bedacht gesetzt.
Merksatz:
> Ich bin für das verantwortlich, was ich sage.> Nicht für das, was du verstehst.
Und von deinem_delay() weiß ich natürlich nichts...
Aber das könntest du gerne mal zeigen.
Joachim B. schrieb:> in der Arduinowelt gibts nur loop()
Das ist übrigens auch nicht richtig.
Ein korrektes Arduino Programm kann auch so aussehen:
1
intmain()
2
{
3
for(;;);
4
return0;
5
}
Man wird dann aber auch auf die ganzen Arduino Features verzichten
müssen.
Arduino F. schrieb:> Ein korrektes Arduino Programm kann
stimmt, nur dann brauchts auch nicht mehr die IDE
Arduino F. schrieb:> Merksatz:>> Ich bin für das verantwortlich, was ich sage.>> Nicht für das, was du verstehst.
kenne ich schon, ist aber auch nur platt
Arduino F. schrieb:> Aber das könntest du gerne mal zeigen.
dazu bin ich ein zu schlechter progger, das hilft niemanden hier und
Häme gibts ja genug, das brauche ich nicht, für mich reichts eben :)
