RTOS mit Arduino

Bodo M. schrieb:
> AVM

AVM ist Hersteller z.B. der FRITZ!Box, was hat das mit Atmega328 zu tun?

Bodo M. schrieb:
> ich experimentiere mit RTOS

Welches RTOS?

Bodo M. schrieb:
> Kann der Atmega328 evtl. nur 2 Tasks?

Die Hardware hat erstmal gar nichts mit den Tasks zu tun.

Titel deutet auf Arduino hin... wäre auch interessant ob du nun 
irgendwas aus der Arduino IDE (Lib) nutzt oder das RTOS unter 
AtmelStudio nutzt und dafür aber ein "Arduino" Board verwendest.

Fragen über Fragen.

Bodo M. schrieb:
>> Der kann sogar nur 1 Task.
>
> Wenn der nur ein Task kann, wozu dann ein RTOS?

Der Atmega hat halt nur einen "Kern".
Er kann zu einem Zeitpunkt nur eine Aufgabe erledigen.
Das RTOS sorgt mittels zeitlichen oder eventbasierten Interrupts für 
einen Taskwechsel, so das es aussieht als ob alles parallel laufen 
würde.
(mal ganz einfach gesagt)

FreeRTOS auf Atmega328 ist möglich aber mit 2KB RAM, nunja, aber siehe 
selbst: (google "freertos atmega328)

https://www.admindu.de/wordpress/?p=1061
https://yalneb.blogspot.com/2017/05/run-freertos-on-arduino.html
https://scienceprog.com/using-freertos-kernel-in-avr-projects/
https://www.freertos.org/a00098.html

Bodo M. schrieb:
> Mit Nucleo entwickeln und debuggen. Wenn es wie gewünscht läuft,
> verwandten Proz. nehmen.

genau so!

Ich empfehle xTaskCreateStatic zu verwenden. Da wird nicht zur Laufzeit 
mit Malloc der Speicher allokiert, sondern man muss static/globale 
Arrays anlegen, und der Funktion übergeben.

Da sieht man schon an der Compilerausgabe wie viel Speicher vom RAM 
belegt ist.

Genau!

Und wer gut Auto oder Motorrad fahren kann, braucht auch keinen Gurt und 
keinen Helm.

Oder er ignoriert die echte Welt und fährt seit seinem 3. Lebensjahr im 
Bobbycar rum.

Bodo M. schrieb:

> Da die ATMEGA wahrscheinlich unter "geht zwar, ist aber sinnlos" laufen,
> bin ich jetzt auf der Suche nach einer neuen Entwicklungsumgebung. Die
> STM's sind zwar alle recht cool, aber die Prozessoren sind meist für
> mich nicht zu Löten oder nicht lieferbar.

Schau Dir das hier an:

https://www.microchip.com/wwwproducts/en/PIC32MX250F128B

Das kannst Du problemlos löten, und vom Speicher und der Rechenleistung 
ist das schon ganz ordentlich. NuttX und FreeRTOS sollten darauf laufen.

fchk

Johannes S. schrieb:
> c-hater schrieb:
>> Das sind zum überwiegenden Teil rein akademische Spielereien. Klar,
>> einiges wird auch tatsächlich benutzt, aber eben nur von Leuten, die
>> ihre Software-Qualität nicht in den Griff bekommen.
>
> Glaubst den Stuss den du schreibst wirklich selbst? Gut, bei dem Nick
> kann ich dich sowieso nicht ernst nehmen.

c-hater hat ganz offensichtlich sehr viel Erfahrung,aber seine Argumente 
sind in vielen Fällen inzw. etwas angegraut (min. 30J abgehangen).

Würde er FreeRTOS kennen käme da nicht so ein Blödsinn.

Und wäre FreeRTOS eine "rein akademische Spielerei" würden sich wohl 
kaum so viele (wirklich große) Firmen darauf stürzen.

Der ohnehin schon sehr schlanke Footprint ist bei modernen MCUs ja auch 
wirklich kein Thema mehr - auf einem ATTiny macht das natürlich keinen 
Sinn.

Moin,

Bitte nicht schießen;-)

Bei den kleinen 8-Bit Dingern kommt es hauptsächlich auf die 
"Heimarbeit" an. Zuerst muß man sich im Klaren sein wie die HW 
Ressourcen "gleichzeitig" verwendet werden sollen und dokumentiert die 
Aufgaben des uC planmäßig.

Dann muß man sich Gedanken machen wer, wann und wo Zugriff auf geteilte 
Peripherien haben muß und wie man mit möglichen Ressource Konflikten 
umgehen muß um ein zufriedenstellendes Ergebnis zu erhalten. Da der AVR 
keine Programmierung der Interrupt Prioritäten zuläßt (beim STM32 
besser) muß man sehr aufpassen. Auch helfen Zeitpläne der verschiedenen 
nicht synchronen Events und welchen Druck sie auf den Rest ausüben, 
einen klare Vorstellung davon zu bekommen wie der uC damit umgehen muß 
und wo Konflikte auftreten können und wie man das umschifft.

Das nächste ist, den Programmablauf so zu konzipieren, daß NIEMALS 
Blockaden auftreten können. In der Main Loop darf es absolut keine 
Warteschleifen geben. Sollte Warten notwendig sein, muß das mit 
Zustandsmaschinen und State-Flags implementiert werden. Der Einsatz von 
Zustandsmaschinen erlaubt Time-Slice Verteilung der Aufgaben und ISRs 
erledigen den Rest. Eine Timer ISR als Master Scheduler hilft die 
Zustandsmaschine optimal auszunützen. Serial, SPI, I2C, CAN muss alles 
gepuffert sein. Beim Senden darf z.B. das UART nicht den CPU aufhalten. 
Das UART muss durch ISR sich die Daten im Puffer selber holen und 
abarbeiten. Kommunikationssachen wie UART, I2C, SPI lassen sich alle per 
ISR erledigen und fällt meist gar nicht mehr auf.

Für mich hat sich diese Arbeits- und Planungsweise vielfach bewährt und 
brauchte noch nie dringend ein RTOS. Planung und Architektur der 
Anwendung ist hier ALLES. Viele AVR und PIC, 8051 Projekte liefen auf 
diese Weise in Real-Time ohne merkbare Verzögerungen. Blinkende LEDs 
(Heartbeat Anzeige) blinken per ISR absolut gleichmäßig. Auch bei 
Schrittmotoren merkt man nichts. Man kann z.B. mit dem UART "funken" und 
alles andere läuft gleichmäßig. Der Gebrauch von "Delays" sind in 
solchen Designs absolut verboten und muß mit Zustandsmaschinen Logik 
gesteuert werden.

Wie gesagt, sorgfältige Planung, Dokumentation, Zeit-Diagramme und 
bewährte Real-Time Methoden sind essentiell für erfolgreiche Exekution 
des Designs.
Wer das alles optimal macht wird überrascht sein was ein 8-Bitter 
vermag. Das arme Ding (AVR) läuft immerhin mit bis zu 20 Millionen 
Instruktionen per Sekunde. Da sollte sorgfältiges Design schon etwas 
nützen.

Ist nur meine Meinung anhand meiner bisherigen Erfahrungen.

Gerhard

c-hater schrieb:
> Der Punkt ist: der Einsatz eines präemptiven RTSO bietet eine gewisse
> erhöhte Sicherheit bezüglich einiger Teile der Software, nämlich der
> Fehlerfreien.

Autsch!
Würdest du FreeRTOS kennen, wüsstest du auch, das Preemption zwar 
möglich aber nicht obligatorisch ist.

> Tatsächlich benutzt wird es aber üblicherweise, um Bugs nicht fixen zu
> müssen, d.h.: es wird konsequent und in großem Umfang missbraucht.
>
Steile These und vollkommener Blödsinn.
In der Realität verlangt so ein System dem Programmierer deutlich mehr 
Disziplin ab, als ohne ein RTOS.

Das ist nur ein weiteres Indiz dafür daß du nicht wirklich weist, 
worüber du redest.

> Das ist alles. Und wer etwas anderes behauptet, kennt die objektive
> Realität nicht. So einfach ist das.

Jaja....du verwechselst offenbar Objektivität mit deiner pers. 
antrainierten und scheinbar unumstößlichen Meinung.
"Deine Realität" scheint aber vor 30J stattgefunden zu haben.

Merke: wer nicht mit der Zeit geht, geht mit der Zeit.

batman schrieb:
> Richtig, weil man weniger programmiert und damit weniger Bugs
> produziert, vor allem in oft verwendetem Low-Level-RT-Framework, was
> relativ schwer zu debuggen ist.

... oder andersrum gerechnet: in derselben Zeit kommt man weiter.

Weiss jemand ob es so ein kleines RTOS für AVR auch in Assembler gibt? 
Es muss nichts ernstes/kommerielles sein, es geht mir rein um das Hobby.

Peter S. schrieb:
> Weiss jemand ob es so ein kleines RTOS für AVR auch in Assembler gibt?
> Es muss nichts ernstes/kommerielles sein, es geht mir rein um das Hobby.

Wozu? Investiere 3.70€

https://www.reichelt.de/mips32-m4k-mikrocontroller-32-bit-2-3-3-6v-128-kb-spdip-28-32mx150f128b-isp-p121326.html?&trstct=pol_5&nbc=1

und 20 € für einen PICKIT3-Clone beim Chinamann und erkunde die 
Möglichkeiten. Das ist noch nicht mal der größte, aber eben das, was 
Reíchelt in DIL halt gerade da hat.

https://www.ebay.de/itm/193939430486

fchk

Peter S. schrieb:
> Weiss jemand ob es so ein kleines RTOS für AVR auch in Assembler gibt?
> Es muss nichts ernstes/kommerielles sein, es geht mir rein um das Hobby.

Ehrlich gesagt, wenn schon, dann würde ich sowas nur im kommerziellen 
Bereich vermuten. Welcher Bastler - außer Chuck Norris natürlich - 
schreibt denn mal rasch ein kleines Betriebssystem für (s)einen 
Controller?
Gruß Rainer

Rainer V. schrieb:
> Peter S. schrieb:
>> Weiss jemand ob es so ein kleines RTOS für AVR auch in Assembler gibt?
>> Es muss nichts ernstes/kommerielles sein, es geht mir rein um das Hobby.
>
> Ehrlich gesagt, wenn schon, dann würde ich sowas nur im kommerziellen
> Bereich vermuten. Welcher Bastler - außer Chuck Norris natürlich -
> schreibt denn mal rasch ein kleines Betriebssystem für (s)einen
> Controller?
> Gruß Rainer

c-hater

Und zwar in 5 Minuten.

Rainer V. schrieb:
> Peter S. schrieb:
>> Weiss jemand ob es so ein kleines RTOS für AVR auch in Assembler gibt?
>> Es muss nichts ernstes/kommerielles sein, es geht mir rein um das Hobby.
>
> Ehrlich gesagt, wenn schon, dann würde ich sowas nur im kommerziellen
> Bereich vermuten. Welcher Bastler - außer Chuck Norris natürlich -
> schreibt denn mal rasch ein kleines Betriebssystem für (s)einen
> Controller?
> Gruß Rainer

Ich habe das schon mal gemacht und zwar für die PDP-11 (genauer den 
T11). Das war kein ausgewachsenes RTOS mit allen Schnittstellen, aber 
man konnte Jobs starten (aber nicht löschen). Es gab Semaphore for 
Resourcen (etwa um ein malloc zu machen konnte man die MEM Resource 
zuerst beanspruchen), man konnte Prozesse auf Events warten lassen. Das 
ganze hatte noch einen Line Time Clock (ja es gab die SLEEP sub-routine, 
die legte einen Job für 1..65536 Ticks schlafen). Es war preemptive und 
hatte Job Prioritäten.
In der Zwischenzeit habe ich den Source Code wieder ausgegraben und bin 
daran das ganze in AVR zu übersetzen als Hobby Projekt. Aber bevor ich 
einfach etwas Bestehendes und Altes (es hat über 30 Jahre auf dem 
Buckel) transcode hätte es mich interessiert ob es da schon etwas gibt 
und vielleicht sind da ja Lösungen oder zusätzliche Features drin die 
praktisch wären. Vor allem was moderne Schnittstellen anbelangt.
Der PDP-11 Source Code (ohne Device Treiber oder Interrupt Routinen) war 
sehr kompakt, der Core hatte ca. 300 Assembler Instruktionen.
Eigentlich müsste ja so ein RTOS auf einem AVR recht flott 
funktionieren, ein T11 Computer war typischerweise auch nur mit 
16-32kbyte ROM und wenn es hoch kam mit 16kbyte RAM ausgestattet. Ein 
Atmega1284P dürfte da einem T11 um einiges überlegen sein. Auch wenn man 
in Betracht zieht, dass der AVR ein 8-bit Prozessor ist und der T11 ein 
16-bit. Aber der T11 brauchte für eine Instruktion mindestens 1.6usec. 
In der Zeit führt ein AVR 30 Instruktionen aus.
Calling Convention war mit DECUS C kompatibel, d.h. die eigentlichen 
Jobs konnte man in Assembler oder C schreiben.

Peter S. schrieb:
> Ich habe das schon mal gemacht und zwar für die PDP-11

Und du hast das echt als Bastler/Hobbyist gemacht?? So oder so sollte 
dir das nun für die AVR keine Probleme bereiten. Damals war Assembler, 
die Struktur war/ist dir klar, heute ist auch Assembler. Wünsche 
jedenfalls viel Spass!
Gruß Rainer

Nein der Co

Rainer V. schrieb:
> Und du hast das echt als Bastler/Hobbyist gemacht??

Nein der PDP-11 Code war nicht als Bastler sondern als 
Echtzeitprogrammierer. Nur ist das jetzt schon eine längere Zeit her 
(sie obigen Post) und was damals gut war muss ja nicht unbedingt dem 
entsprechen was man heute so machen würde. Seit dieser Zeit programmiere 
ich nicht mehr kommerziell. Daher meine Frage nach einem Beispiel.
Damals war Assembler das Mass der Dinge, gerade wenn man Hardwarenah 
programmieren musste. Man muss dazu natürlich sagen, dass die 
Entwicklungsumgebung für MACRO-11 einiges komfortabler war als man das 
heute von frei verfügbaren Assemblern sieht. Es hat richtig Spass 
gemacht. Ich bin dann irgendwie bei Assembler hängen geblieben und kann 
mich bei Hardwarenaher Programmierung einfach nicht davon lösen. Es ist 
halt ein Hobby.

Der Code ist soweit mal übersetzt, die Tests der ersten Funktionen tun 
soweit. Als nächstes kommt der Tick Interrupt und die SLEEP Funktion. 
Und dann werde ich mal ein BLINKENLIGHTS und ein HELLO WORLD dazunehmen.
Wobei ich dann natürlich mehrere BLINKENLIGTHS gleichzeitig laufen 
lassen kann. Und vielleicht sollte ich ein bisschen mehr Kommentar in 
den Source Code einfliessen lassen :-)

Peter S. schrieb:

> gemacht. Ich bin dann irgendwie bei Assembler hängen geblieben und kann
> mich bei Hardwarenaher Programmierung einfach nicht davon lösen. Es ist
> halt ein Hobby.

Und warum nimmst Du dann nicht eine bessere Plattform? MIPS-Assembler 
ist so übel nun auch nicht, und MIPS gab es auch schon in den 80'ern. 
Den gleichen Binärcode, der 1991 auf meiner DECstation 3100 (25 MHz 
R2000) lief, kannst Du jetzt auf dem obigen 3.70€ PIC32MX (50 MHz 
MIPS4k) laufen lassen.

fchk

Peter S. schrieb:
> für die PDP-11

Hmm, ich liebäugele jetzt mit dem umgekehrten Weg, d.h. z.B. FreeRTOS 
auf meine PDT-11/150 zu portieren. Damit gäbe es dann endlich mal eine 
"sinnvolle Anwendung". Wahrscheinlich gäbe es auch ähnlich viele Nutzer 
wie für Josefs bo8. Nächster Schritt: FreeRTOS auf bo8? Nein, das muss 
ich mir nicht antun, insbesondere weil es da ja auch keine Interrupts 
gibt.

Nun da

Frank K. schrieb:
> Und warum nimmst Du dann nicht eine bessere Plattform? MIPS-Assembler
> ist so übel nun auch nicht, und MIPS gab es auch schon in den 80'ern.
> Den gleichen Binärcode, der 1991 auf meiner DECstation 3100 (25 MHz
> R2000) lief, kannst Du jetzt auf dem obigen 3.70€ PIC32MX (50 MHz
> MIPS4k) laufen lassen.
>
> fchk

Man muss unterscheiden zwischen dem Assembler/Instruktionssatz und dem 
Assembler der einem zur der Plattform zur Verfügung gestellt wird. Beim 
PDP-11 gab es MACRO-11, verschiedenen Preprozessoren und einen Linker 
(TKB), man konnte neben den Standard Libraries eigene Libraries 
erstellen. Die Macro Sprache hat den Namen wirklich verdient, es war 
eine sehr flexible Macro Sprache. Dazu gab es noch viele weitere Tools 
und sie waren alle sehr gut dokumentiert.
Ich kenne jetzt den MIPS Assembler nicht, daher kann ich da nichts dazu 
sagen. Aber vielleicht kann mir ja mal jemand kurz erzählen was mich da 
erwartet, vor allem von den Tools aus. Nur mit "gas" werde ich mich nie 
anfreunden können. Für meine Begriffe ist er hässlich.
Was den Instruktionssatz und die Assembler Syntax der AVR Prozessoren 
anbelangt kann ich mich nicht beklagen. Er gehört zu den schönsten den 
ich von Microprozessoren kenne, schade ist nur, dass avrasm2 ein 
stand-alone assembler ist der direkt binären Code produziert und man 
nicht module linken kann.
Wichtig ist für meine Hobby Projekte, dass die IO pins der 
Microcontroller 5V TTL kompatibel sind, da ich meistens Erweiterungen 
für meinen PDP-11 bastle und ich will mich (noch) nicht mit Pegelwandler 
herumschlagen. Mir reicht schon dass Gefummel mit den notwendigen Bus 
Treiber. Ich war zwar kurz davor diesen Weg zu gehen , aber dann hat 
Microchip die AVR128 Familie vorgestellt. Die hat eigentlich alles was 
ich brauche.
Der Preis der einzelnen MCU spielt dabei keine Rolle, mit dem Schweizer 
Einzelstückpreiszuschlag ist jede MCU teuer.

Andreas S. schrieb:
> FreeRTOS
> auf meine PDT-11/150

Und warum nimmst du nicht RSX-11S? Oder RT-11

Peter S. schrieb:

> Wichtig ist für meine Hobby Projekte, dass die IO pins der
> Microcontroller 5V TTL kompatibel sind, da ich meistens Erweiterungen
> für meinen PDP-11 bastle und ich will mich (noch) nicht mit Pegelwandler
> herumschlagen.

Dann wären die dsPIC33EV256GM1xx mit 70 MHz was für Dich.

https://www.microchip.com/wwwproducts/en/dsPIC33EV256GM102

fchk

Frank K. schrieb:
> Dann wären die dsPIC33EV256GM1xx mit 70 MHz was für Dich.

Danke für den Tip, das muss ich mir anschauen, vor allem DMA wäre noch 
auf meiner Wunschliste gewesen. Und 16-bit Architektur macht auch vieles 
einfacher. SMD ist kein Problem, und ein Pickit 3 liegt auch noch rum.

P.S. Blinkenlights und Hello World mit timer funktionieren jetzt :-) und 
parallel dazu eine interaktive Anwendung. Multi-Tasking ist doch ganz 
nett. Jetzt kommt der erste Device Treiber für den UART dran.

Peter S. schrieb:
> Andreas S. schrieb:
>> FreeRTOS
>> auf meine PDT-11/150
>
> Und warum nimmst du nicht RSX-11S? Oder RT-11

Das gibt es doch schon. Und für echte neue Applikationen würde ich 
heutzutage eher keine PDP/PDT-11 einsetzen. Dann schon eher eine VAX. 
Aber FreeRTOS auf einer PDT-11 wäre so unfassbar sinnbefreit, dass es 
schon wieder Spaß bereiten könnte. Vielleicht reicht dann ja der 
Speicher, um in einem Task eine Laufzeitumgebung für Befunge, Brainfuck 
oder Whitespace laufen zu lassen.

Andreas S. schrieb:
> Aber FreeRTOS auf einer PDT-11 wäre so unfassbar sinnbefreit, dass es
> schon wieder Spaß bereiten könnte.

Ja, krieg' dich wieder ein... die Frage ist und bleibt doch "was heißt" 
Echtzeit!! Und man muß definitiv immer wissen, was man tut! Sonst ist es 
piepegal, womit du programmierst. Eine lächerliche Weisheit, ich weiß, 
aber eine immer noch gültige :-)
Gruß Rainer

Stefan ⛄ F. schrieb:
> Der ESP32 läuft unter Arduino bereits mit RTOS.

Ich wage jetzt noch mal die zweifelnde Bemerkung, dass man wissen muß, 
was man tut! Nur weil man sich RTOS draufschafft, ist man noch lange 
nicht "Echtzeit", glaubt mir...
Gruß Rainer

Ihr müßt es nicht glauben...glaubt mir...
Rainer

Mein mini RTOS steht. Mindestens als Experiment wie es eigentlich Bodo 
ursprünglich wollte. Mit mini meine ich, ich habe nur das absolute 
Minimum an Funktionen eingebaut die ich für nötig halte.

acquire: dient dazu um einen lock/resource zu bekommen
release: dient dazu um einen lock/resource frei zu geben
block: dient dazu um auf einen Event zu warten (aka Interrupt)
unblock: dient dazu einen Event zu signalisieren
create: dient dazu einen Job zu starten
_sleep: (sleep ist als instruction schon vergeben) legt einen Job eine 
gewisse Anzahl (1..32678) ticks schlafen
setpriority: setzt die priorität des aktuellen job

Jeder Job braucht einen Job Control Block und einen Stack

Vorbereitet ist eine Interrupt Dispatching genannte Funktion die es 
einem Interrupt erlaubt auf einem zentralen Kernel Stack weiter zu 
machen, damit nicht jeder Job Stack mehr Reserve haben muss als für eine 
minimale Interrupt Routine nötig ist. Kann man benutzen muss man nicht.

Wie gesagt es ist (und bleibt womöglich auch) ein Experiment und hat 
einfach nur Spass gemacht. Mehr nicht. Und es enthält sicher noch 
Fehler. Ob ein RTOS sinnvoll ist oder nicht muss jeder selbst 
entscheiden und hängt sicher von der jeweiligen Anwendung ab. Es gibt ja 
nicht immer nur die Lösung.

Rainer V. schrieb:
> Ja, krieg' dich wieder ein... die Frage ist und bleibt doch "was heißt"
> Echtzeit!!

Ich habe nicht geschrieben, dass ich irgendeine Anwendung mit 
Echtzeitanforderungen betreiben will, sondern damit liebäugele, FreeRTOS 
zu portieren.

Außerdem ist der Begriff "Echtzeit" in Bezug auf das Ablaufverhalten von 
Software bzw. Steuerungen recht genau definiert.

> Und man muß definitiv immer wissen, was man tut! Sonst ist es
> piepegal, womit du programmierst. Eine lächerliche Weisheit, ich weiß,
> aber eine immer noch gültige :-)

Ach wirklich? Das ist mir im Laufe der letzten Jahrzehnte noch nie 
aufgefallen. Was sollen hier also solche hohlen Phrasen.

c-hater schrieb:
> Asm rules!

Genau :-)

Am schönsten wäre es wenn das ganze in Kombination möglich wäre. Mit dem 
AVRASM2 zusammen ist das leider nicht der Fall.

Ich habe mir auch schon überlegt in meiner minimal Version die Calling 
convention von C zu berücksichtigen aber dann stehe ich vor dem Problem 
wie kombiniere ich das? Hat jemand eine Idee wie man das hinbiegen 
könnte? Auf der PDP-11 war das so einfach, dass ich mir nie viel 
Gedanken darüber machen musste wie man Module die in verschiedenen 
Sprachen geschrieben wurden zusammenfügt.

Das ist doch jetzt alles ziemliches Geschwurbel. Wer hat denn 
tatsächlich - ganz ehrlich - ein hartes "Echtzeit-System" programmieren 
müssen? Der Bastler im Leben nicht ( wie Heinz Becker sagen würde) und 
der Firmware-Spezi in seltensten Fällen. Hat sich hier auch noch keiner 
zu Wort gemeldet....außer "hätt, wenn und würde..." Also sage ich, 
schön, dass wir drüber gesprochen haben :-)
Gruß Rainer

c-hater schrieb:
> Sehr, sehr viele µC-Anwendungen SIND harte Echtzeit. Nur halt ohne ein
> "System" (=RTOS) drumrum...

Ja Mann, auch die blinkende LED ist so gesehen eine harte 
Echtzeitanwendung! Ansonsten...Geschwurbel...

c-hater schrieb:
> Sehr, sehr viele µC-Anwendungen SIND harte Echtzeit. Nur halt ohne ein
> "System" (=RTOS) drumrum...

Da muß ich c-hater ausnahmsweise mal zustimmen.
Ein populäres beispiel ist z.B. die HDD-Clock:
https://www.youtube.com/watch?v=XK9en2H7rBA&ab_channel=mb1988mb1988
"Echtzeit-Fehler" würde man sofort sehen....

Jede gemultiplexte Anzeige ist "harte Echtzeit" - sonst würde das 
flackern.

Allerdings kann man das -zumindest im Fall von FreeRTOS- auch mit dem 
RTOS erreichen.

das Eine schließt das Andere nicht aus.

c-hater schrieb:
> Wennschon, dann macht man sowas auch mit dem eingebauten Assembler des
> Compilers. So vollkommen Scheiße und abstrus häßlich der auch sein
> mag...

Dann lass ich das lieber bleiben, da ist es für meine Basteleien 
angenehmer ich bleibe bei 100% avrasm2.

Bodo M. schrieb:
> ich experimentiere mit RTOS für AVM. Das BlinkAnalogRead- Beispiel hab
> ich etwas umgeändert und läuft.
> Mein "Blinken" geht ganz schnell und die serielle Schnittstelle sagt
> garnichts mehr. Kann der Atmega328 evtl. nur 2 Tasks?

man kann sich das Leben auch schwer machen.
Ich mache das nicht mit RTOS noch Tasks, ich schreibe alles was ich auf 
dem LCD sehen will, Uhrzeit, Feuchtewerte, Temperaturen, Statusmeldungen 
für meine Rolläden oben/unten zu jeder Zeit wo sich was ändert in ein 
char Array dem LCD angepasst 14 Zeichen mit 0 also 15 char/Zeile x 6 
Zeilen für das Nokia5110 ins RAM und per Timer IRQ 10ms in der 
Tastenentprellroutine habe ich Counter z.b. 25 für LCD Update oder 
andere und immer wenn ein Counter abgelaufen ist if(!lcd_count) , z.B. 
LCD update wird in der loop zum LCD Update gesprungen und aufs LCD 
geschrieben und der Counter danach wieder auf 25 gesetzt. In der 10ms 
Timer IRQ wird der decrementiert if(lcd_count) lcd_count--;

klar 4x pro Sekunde ist noch gut lesbar und die Uhrzeit läuft 
geschmeidig.
Für ADC Werte könnte man auch 10 LCD prints / Sekunde machen, mehr ist 
eh nicht lesbar.

Nun muss man "nur" noch feststellen wielange so eine "Task" benötigt, 
ich setze am Begin einen Port und am Ende setze ich den zurück, 
dazwischen schaue ich mit dem Oszi die Zeitdauer ob es reinpasst.
Am AVR kann ich sogar in der IRQ eine I2C Tastaturabfrage machen, dauert 
1,5µs und passt locker in die 10ms Timer IRQ.
Ich kann sogar mit IRMP 15000Hz Abfragen machen vorgeschaltet bis 150 
zählen für 10ms und dann weiterverarbeiten.
Damit läuft IRMP und 10ms Timer zusammen.
Es kann natürlich sein das die beiden mal kollidieren, aber da IR 
sowieso mehrfach senden ist mir da noch nie eine Fehlfunktion 
aufgefallen.

Eine ADC Wandlung die schneller ist z.B. 34µs und einen schnell ändernen 
Wert liefert kann man eh nicht ablesen, man kann Mittelwerte bilden und 
diese anzeigen, oder man zeigt Maxima und Minima.

Mucky F. schrieb:
> Nei Mehrkernern kann ich mir aber vorstellen das einzusetzen. Kann
> FreeRTOS das eigentlich?

angeblich beim ESP32 2 Kerner, aber das Zusammenspiel wird etwas 
komplizierter, soweit bin ich noch nicht.

Hurra, jetzt habe ich dank dem Experiment mit meiner RTOS Version 
endlich einen blöden Bug in einem debugging Modul von mir gefunden. Ich 
hatte ja schon länger den Verdacht, dass ich da irgendwas verbockt habe 
aber gefunden habe ich es nicht. Es hat sich also so oder so gelohnt :-)

c-hater schrieb:
> Diese Lüge (oder Ausdruck maximaler Unwissenheit) habe ich jetzt erst
> gesehen.

gähn
Was soll das? Es war vorher schon klar was Gerhard gemeint hat. Das was 
du geschrieben hast, per HW ist die Priorisierung nicht vorhersehen aber 
mittels SW kann man da schon etwas machen.
Ach so, dir war das nicht klar.
Und was hat FreeRTOS mit Interruptprioritäten zu tun?

Ja Prioritäten für Interrupts auf AVR ist möglich, aber es ist ein 
riesen Handstand. Besonders mühsam ist, dass der Prozessor Status nicht 
automatisch auf dem Stack landet. Wenn man jetzt Funktionen hat die von 
verschiedenen Prioritäten benutzt werden, dann muss man irgend wie immer 
von Hand ablegen was gemeint ist. Das ist definitiv nicht das was ich 
unter verschiedenen Prioritäten verstehe. Eine PDP-11 hat das wesentlich 
eleganter gelöst.
Und auch bei den zwei Interrupt Ebenen die einige AVR MCUs beherrschen 
ist das nicht wirklich besser.

Stefan ⛄ F. schrieb:
> Alles klar, die Profis vertrauen dem Mann, der nicht anderes als
> Assembler akzeptiert. Muahaha!

Ehrlich gesagt, kann ich mich mit systemnahem Code in C mit inline 
Assembler nicht anfreunden. Es ist an Unübersichtlichkeit kaum zu 
überbieten.

Wenn ich mir die Source von Real-Time OS in C anschaue, dann kräuseln 
sich bei mir die Zehennägel. Das hat mit C nicht mehr viel am Hut.

Stefan ⛄ F. schrieb:
> Deswegen hat Assembler durchaus seine Daseinsberechtigung - nur nicht
> als einzig wahre Überall-Lösung, wie der c-hater es darstellt.

Ja und darum bin ich immer noch auf der Suche wie ich richtigen 
Assembler mit C auf AVR kombinieren könnte. Ohne Erfolg bis jetzt.

Vielleicht wenn ich mal zu viel Zeit habe um alle meine Sources und 
Macros anzupassen. Aber bis dann warten ich noch ab. Das ABI war mir 
schon bekannt. Das ist ja auch nicht mein Problem.

c-hater schrieb:
> In Assembler: kein Problem.

Das mit dem kein Problem würde ich gerne etwas näher betrachten. Was ist 
dein Ansatz? Ich sehe das so, dass jede OS Funktion zwei Eingänge haben 
muss, einen für normale jobs/task und einer für Interrupts, dann wäre es 
in der Tat nicht so kompliziert.

c-hater schrieb:
> Nicht ganz. Es ist NOCH einfacher. Man kann nämlich jede ISR in zwei
> Teile zerlegen. Einen, der exclusiv (also nicht unterbrechbar)
> ausgeführt wird und einen, der einfach nur noch "Task mit höchster
> Priorität" ist. Das ist billig.

Das sind dann aber weniger hierarchische Interrupts als vielmehr ein 
einfacher Fork.

Moby schrieb im Beitrag #6727194:
> Wozu? Das steigert erstens die Komplexität unnötig und verbraucht
> zweitens selber Ressourcen. Nutze wie von Gerhard und c-hater
> beschrieben das viel effizientere Interrupt-System, denn dafür ist es
> da!

Warum sollte die Komplexität steigern, nur weil ich klar voneinander 
getrennte Jobs habe nimmt die Komplexität sicher nicht zu. Und wieviel 
Resourcen ein solches RTOS verbracht hängt davon wie es implementiert 
ist. Ohne RTOS muss ich die verschiedenen Aufgaben auch verwalten. Mein 
Beispiel braucht weniger als 100 Befehle für einen vollständigen 
Kontextswitch. Das bearbeiten von Ticks ist auch nicht aufwändiger als 
mit einem selbstgestrickten Scheduler. Resourcen können reserviert 
werden ohne Interrupts über längere Zeit auszusperren. Es ist im 
Gegenteil sehr übersichtlich wenn das CLI oder der Kommunikationsprozess 
ein eigener Job ist und er gesteuert von externen Events seine Aufgaben 
macht und mit Hilfe der Prioritäten muss man bei unwichtigen Jobs nicht 
immer dafür sorgen, dass sie selbst oder extern gesteuert ihre Aufgabe 
aufteilen müssen. Es ist sicher nicht die einzige Lösung aber in meinem 
Fall passt es perfekt. Die Performance aktueller AVR Prozessoren reicht 
locker, da kann ich das bisschen CPU Overhead gut verkraften, dass ich 
für jeden Job einen eigenen Stack brauche ist kaum der Rede Wert, ich 
brauche für meine Aufgabe etwa 8kbyte RAM, die AVR128 haben 16kbyte, das 
reicht locker für die 9 Jobs die ich plane. Und die Interrupts, auch in 
den 2 prioritäten, stehen mir immer noch zur Verfügung.
Und das Wichtigste, es hat Spass gemacht. Eigentlich wollte ich schon 
immer einen kleinen Kernel bauen. Dank diesem Thread habe ich den alten 
PDP-11 Source hervorgekramt und den Core nach AVR übersetzt. und siehe 
da es war erstaunlich einfach.

Stefan ⛄ F. schrieb:
> Man hat auch nicht die 8-Zylinder Motoren erfunden, weil Motoren mit
> 4-Zylindern schlechte Qualität haben.

aber man hat 16-Zylindermotoren gebaut weil man 1500PS Leistung noch 
nicht aus 4-Zylinder bekommt.
vielleicht irgendwann

A45 AMG
Modell: Mercedes-Benz A-Klasse
UVP: Ab 49.313,6€
Motorleistung: 306 bis 387 PS
Beschleunigung 0-100 km/h: 4 bis 4,8 Sekunden
Motorisierung: 2,0 l 4-Zylinder
https://www.youtube.com/watch?v=d241BY0J1SI

Joachim B. schrieb:
> aber man hat 16-Zylindermotoren gebaut weil man 1500PS Leistung noch
> nicht aus 4-Zylinder bekommt.
> vielleicht irgendwann

Schau dir Schiffsdiesel an, die kriegen 1500PS aus 4 Zylindern hin ;-)

Joachim B. schrieb:
> weil man 1500PS Leistung noch
> nicht aus 4-Zylinder bekommt.

...kommt wohl schlicht auf den Zylinder an...unglaublich dick und 
sagenhaft lang...

Mucky F. schrieb:
> Die Frage ist ja wie oft der Kontext gewechselt wird. Bei einer
> seriellen mit 115k ist das schnell an der Grenze.

Darum gibt es bei mir auch einen UART Treiber und jeweils einen 
Ring-Buffer für RX und TX. Das mache ich auch ohne RTOS immer so.