spontan schrieb:
> Aber es gibt auch Fälle,
Gibt es.
Sind aber eher selten.
Hand aufs Herz: In der Mehrzahl der Fälle, in denen Anfänger mit
_delay_ms arbeiten, wäre eine Timerlösung besser. Und das fängt bereits
mit dem gerne gemachten Lauflicht an, das plötzlich zusätzlich noch auf
Tastendrücke das Muster umschalten soll.
_delay_ms führt gerade bei Anfängern zu einer Programmstruktur, die für
weitergehende Programmerweiterungen nicht geeignet ist. In dem Moment,
in dem mehrere Dinge gleichzeitig passieren soll (Lauflicht UND parallel
dazu soll das Muster zu jedem Zeitpunkt umschaltbar sein), ist dann das
Rätselraten groß und es werden die tollsten Konstrukte erfunden, die
dann auch nicht richtig funktionieren nur damit man am delay weiterhin
kleben kann.
Das es für delays sinnvolle Anwendungsfälle gibt, bestreite ich nicht.
Bruache ich nur schnell ein Programm, welches irgendwas toggelt um eine
Hadrware zu testen, nehm ich ein delay. Brauch ich eine Statusanzeige
vor der Hauptschleife, nehm ich ein delay. Bruach ich was kurzes im µs
Bereich, nehm ich ein delay. Dagegen hat auch keiner was.
Aber abgesehen davon ist in der überwiegenden Mehrzahl der Fälle, mit
denen wir uns hier im Forum rumschlagen müssen, _delay_ms nicht die
Lösung sondern der Problemverursacher. Und der Weg zu einer sauberen
Lösung beginnt damit, dem Aspiranten den Weg zu einem taktbasiertem,
eventbasiertem bzw auf einer Statemachine basierendem Programm zu
zeigen.
