Der Teensy 4.0 ist fertig

[Sisor]

Ihr scheint nicht wirklich irgendwann mal ein Multitaskingbetriebssystem erstellt und damit dann auch gearbeitet zu haben. Das ist jetzt nicht böse gemeint oder abwertig, aber die Argumente, die hier oft dafür genannt werden, sprechen eigentlich genau dagegen.
...
Auf jeden Fall sollte man sich damit erst einmal im Detail grundlegend auseinandersetzen bevor man meint, man könnte auf etwas nicht verzichten. Sonst bleibt nur, die Nachteile mit noch mehr MHz zu erschlagen.

Zwei Semester Betriebssysteme und ein Semester Echtzeitsysteme reichen nicht? Du vermutest hier ziemlich ins Blaue.

Und was meinst du mit Hauptprogramm? Auf dem Esp32 'endet' die main() im Scheduler, loop() ist nur eine Task.

[Im Folgenden beziehen sich die Aussagen Multitasking betreffend auf FreeRTOS]
Der einzige Nachteil der Nutzung eines präemptiven Multitaskings, den ich sehe, ist, dass auch wenn nur eine Task mit der gerade höchsten aktiven Priorität läuft, sie trotzdem im Scheduler-Takt unterbrochen wird, um zu sehen, ob eine andere Task dran ist. Wenn einem diese kleine Unterbrechung nicht passt, kann man den Scheduler suspenden oder einen kritischen Bereich definieren.
Wenn ich Nebenläufigkeit mit Zeitscheiben will, gebe ich den entprechenden Tasks eine gleiche Priorität, sonst nicht.

Und ich behaupte nicht, nicht auf etwas verzichten zu KÖNNEN, sondern zu WOLLEN. Es ist am Ende eine Frage des Entwicklungszeit. Ich will das Rad nicht jedesmal neu erfinden. Oder mein Design umstellen, wenn ich merke, dass ich Nebenläufigkeit mit Zeitscheiben brauche. Ich will eine API, die ich kenne, und deren Funktionalität getestet und dokumentiert ist.

Wie gesagt: Wenn ich das Multitasking nicht brauche, oder es stört, schalte ich sie aus.

Und das Vorhandensein / die Nützlichkeit von Queues, Semaphoren, Software-Timern, Gruppenevents etc. in diesem Kontext habe ich noch nicht einmal erwähnt... Alles Dinge, die man für gutes Design von System mit Nebenläufigkeit braucht.

[HaWe]

@Ceos:du kannst auch nur immer dieselben hohlen und bornierten Statements wiederholen - ich war nicht derjenige, der hier von vornherein beleidigend war - das war eindeutig Holomino.
Mein Statement war lediglich: für MICH ist preemptives MT unverzichtbar.

Wie gesagt: Wenn ich das Multitasking nicht brauche, oder es stört, schalte ich sie aus.

genau so sehe ich es auch.
Viele meiner Programme laufen im single-task mode.
Aber von einer leistungsfähigen cpu erwarte ich, dass sie AUCH eine API für preemptives MT bietet, und "leistungsfähig" beginnt für mich bei ARM Cortex (M0/M3, spätestens M4).

[Ceos]

Den Ansatz Threads zu nutzen ist Verschwendung von Controller Peripherie, da kann man auch einen ARM ohne großartig Peripehrie mit hoher Taktzahl nehmen.

Eine Aufgabe für die man einen 100Mhz+ ARM braucht weil man mit Threads arbeitet um Peripherie damit zu emulieren kann man auch auf einem 32Mhz µC erledigen.

Eine komplizierte Berechnung, welche fast garkeinen Input über Peripherie benötigt auf einem µC zu packen ist ein Layer 8 (erweitertes OSI) Problem.

Die Darstellung von Inhalt auf einem Display und die gleichzeitige Berechnung von komplizierten Parallelen Aufgaben teilt man dann einfach am besten auf, ein 100+MHZ ARM mit Threads der einen ATTiny oder Mega oder XMega mit grafischen Befehlen versorgt der dann seine ganze reiche Peripherie dafür aufbringt und die begrenzte Rechenzeit der CPU zum organisieren und kommunizieren nutzt.

die Eier legende Wollmilchsau ist der dritte Weg, aber nur wenn man beide Parts nutzen kann auch wirklich Sinnvoll. Das war zumindest der Kern meiner Aussagen.

by the way

ich sehe schon, ihr versteht teilw (?) nicht den Sinn und die Vorteile von preemptivem MT.

war der Punkt an dem du deine Lösung mal wieder über die Lösung anderer gestellt hast was der Kern meines letzen Post war ...

daraufhin habe ich deiner listenartigen typischen Ansprüche genüge getan und erklärt wie ich in meinem Fall damit umgehe und selber behauptet dass meine Lösung besser als deine ist (das war anmaßend, gebe ich zu, aber deine Art triggert mich immer so)

Abschließend hatte ikch argumentiert dass es eine Frage der Problemstellung ist und jede Art ihre Vor- und Nachteile hat
aber dich interssierte auch nach der Argumentation anderer nur dass deine Lösung überlegen wäre indem du Situationen kontruierst die es nur bei dir gibt. Ich muss keinen "hängenden Thread preemtiv verlassen" (wobei das mit der Timer Lösung eigentlich sehr eindeutig regelbar ist) weil es bei mir keine hängenden Prozesse gibt! Eine ordentlich geschriebene Statemachine ist DETERMINISTISCH, d.h. zu jedem Zeitpunkt stabil udn man weis immer wo man sich befindet und es gibt keine unerwarteten Situationen.

Alles unerwartete ist ein Programmierfehler oder schlechtes Desgin. Wenn man per Design erwartet dass etwas unerwartetes passieren kann, muss man eben CPU Zeit und Deterministisches Verhalten opfern und Threads nutzen.

[HaWe]

Den Ansatz Threads zu nutzen ist Verschwendung von Controller Peripherie, da kann man auch einen ARM ohne großartig Peripehrie mit hoher Taktzahl nehmen.

Eine Aufgabe für die man einen 100Mhz+ ARM braucht weil man mit Threads arbeitet um Peripherie damit zu emulieren kann man auch auf einem 32Mhz µC erledigen.

Eine komplizierte Berechnung, welche fast garkeinen Input über Peripherie benötigt auf einem µC zu packen ist ein Layer 8 (erweitertes OSI) Problem.

Die Darstellung von Inhalt auf einem Display und die gleichzeitige Berechnung von komplizierten Parallelen Aufgaben teilt man dann einfach am besten auf, ein 100+MHZ ARM mit Threads der einen ATTiny oder Mega oder XMega mit grafischen Befehlen versorgt der dann seine ganze reiche Peripherie dafür aufbringt und die begrenzte Rechenzeit der CPU zum organisieren und kommunizieren nutzt.

die Eier legende Wollmilchsau ist der dritte Weg, aber nur wenn man beide Parts nutzen kann auch wirklich Sinnvoll. Das war zumindest der Kern meiner Aussagen.

by the way

war der Punkt an dem du deine Lösung mal wieder über die Lösung anderer gestellt hast was der Kern meines letzen Post war ...

daraufhin habe ich deiner listenartigen typischen Ansprüche genüge getan und erklärt wie ich in meinem Fall damit umgehe und selber behauptet dass meine Lösung besser als deine ist (das war anmaßend, gebe ich zu, aber deine Art triggert mich immer so)

Abschließend hatte ikch argumentiert dass es eine Frage der Problemstellung ist und jede Art ihre Vor- und Nachteile hat
aber dich interssierte auch nach der Argumentation anderer nur dass deine Lösung überlegen wäre indem du Situationen kontruierst die es nur bei dir gibt. Ich muss keinen "hängenden Thread preemtiv verlassen" (wobei das mit der Timer Lösung eigentlich sehr eindeutig regelbar ist) weil es bei mir keine hängenden Prozesse gibt! Eine ordentlich geschriebene Statemachine ist DETERMINISTISCH, d.h. zu jedem Zeitpunkt stabil udn man weis immer wo man sich befindet und es gibt keine unerwarteten Situationen.

Alles unerwartete ist ein Programmierfehler oder schlechtes Desgin. Wenn man per Design erwartet dass etwas unerwartetes passieren kann, muss man eben CPU Zeit und Deterministisches Verhalten opfern und Threads nutzen.

Wieder nur hohles Gerede, ohne Nachweis durch Code und Fakten.
mach doch einfach mal mein Programmbeispiel (eine Simulation), das ich oben gepostet habe, mit deinen Methoden nach.
https://www.roboternetz.de/community...l=1#post654263
Ich bin gespannt, wie weit du kommst.

Statemachines aber sind das unterste Ende von Programmiersprachen-Grammatiken, für simpeltste Anwendungen. Wenn dir das reicht, ok, dann brauchst du keine höheren Grammatiken und/oder Architekturen.

[Ceos]

Wieder nur hohles Gerede, ohne Nachweis durch Code und Fakten.
mach doch einfach mal mein Programmbeispiel (eine Simulation), das ich oben gepostet habe, mit deinen Methoden nach.

Machs dir selbst Herr Dr.

https://www.roboternetz.de/community...l=1#post654263
Ich bin gespannt, wie weit du kommst.

Eine komplizierte Berechnung, welche fast garkeinen Input über Peripherie benötigt auf einem µC zu packen ist ein Layer 8 (erweitertes OSI) Problem.

[Manf]

Ich habe schon mitgelesen und viele interessante technische Aspekte gesehen.

Eigentlich ist es Energieverschwendung sich von anderen abheben zu wollen wenn man sich gleichzeitig mit ihnen austauschen möchte. Das ist wohl der interessante nichttechnische Aspekt an der Diskussion.
Ich überlege, dass wenn ich über die Situation und die Beteiligten urteilen will, dann kann ich mich das nächste man nicht unbefangen an anderen Diskussion beteiligen.

Deshalb sollten wir diese Diskussion zum Thema "Der Teensy 4.0 ist fertig" auch erst einmal abschließen.

Vielleicht kann man ja bei Gelegenheit noch mehr praktische Einsatzmöglichkeiten für das System ansprechen.