Hallo an Alle, ich experimentiere mit RTOS für AVM. Das BlinkAnalogRead- Beispiel hab ich etwas umgeändert und läuft. Ich möchte einen dritten Task, und später noch mehr, hinzufügen. Der dritte Task ist analog den zwei anderen aufgebaut. Er macht bisjetzt nichts, aber beeinflußt die beiden Anderen. Mein "Blinken" geht ganz schnell und die serielle Schnittstelle sagt garnichts mehr. Kann der Atmega328 evtl. nur 2 Tasks?
Jeder Task brauch Verwaltungsinformationen und seinen eigenen Stack. Dafür reservierst du RAM wenn du einen Task erstellst. 1. Irgendwann ist der RAM zu Ende, wenn du zu viele Tasks erstellst. 2. Du must in deinem Task darauf achten, das er nicht mehr verbraucht als du für ihn reserviert hast. Bodo M. schrieb: > ich experimentiere mit RTOS für AVM Du meinst sicher AVR Welches RTOS nimmst du FreeRTOS?
Kooperativ? Preisfrage: Warum funktioniert keine Kooperation, wenn kein kooperatives Verhalten "gelebt" wird?
Gut dass es nur ein RTOS, nur einem ARM (oder AVR?) und nur ein Programm gibt. Ich habe nämlich gerade meine Glaskugel fallen gelassen.
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.
RTOS auf einem ATmega328 klingt für mich nach nach: Ein Spatz soll Kanonen tragen.
Mehr RAM macht bei RTOS mehr Freude, aber für Experimente muss man den AVR deshalb nicht gleich wegwerfen. Obwohl, die Cortex-M gibts ja schon…
ck schrieb: > Welches RTOS nimmst du FreeRTOS? Ja es war FreeRTOS Adam P. schrieb: > AVM ist Hersteller z.B. der FRITZ!Box, was hat das mit Atmega328 zu tun? Man kann sich auch mal verschreiben. Adam P. schrieb: > 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. <Arduino_FreeRTOS.h> Ich nutze ein UNO Pro Mini (oder so ähnlich) mit 3,3V und 8MHz und ATMEGA328. Bis Atmel Studio 4 hab ich noch mitgemacht. Die Arduino-IDE ist beim programmieren einfacher. Jonas schrieb: > Der kann sogar nur 1 Task. Wenn der nur ein Task kann, wozu dann ein RTOS?
Bodo M. schrieb: > <Arduino_FreeRTOS.h> Das ist bisher das größte Codefragment, welches du gezeigt hast. Ein Anfang....
es geht vermutlich um dieses: https://github.com/feilipu/Arduino_FreeRTOS_Library/blob/master/examples/Blink_AnalogRead/Blink_AnalogRead.ino wenn sich die Blinkfrequenz geändert hat, dann hat deine neue Task evtl den Timer verändert den FreeRTOS für seinen Scheduler benötigt.
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
Beitrag #6704128 wurde von einem Moderator gelöscht.
Johannes S. schrieb: > wenn sich die Blinkfrequenz geändert hat, dann hat deine neue Task evtl > den Timer verändert den FreeRTOS für seinen Scheduler benötigt.Meine dritte Task sieht nur so aus: >Achtung "Arduino Fanboy D."< void TaskTest(void *pvParameters) // This is a task. { (void) pvParameters; { } } Da ist doch nichts drin, was die Timer verändern kann.
Bodo M. schrieb: > Da ist doch nichts drin, was die Timer verändern kann. Dann hast du wohl einen Stack Überlauf. Siehe erste Antwort ganz oben.
Bodo M. schrieb: > Da ist doch nichts drin, was die Timer verändern kann. Aber auch nichts anderes. Eigentlich benötigt jede Task eine Endlosschleife und im besten Fall auch irgendeine Form der "Kontrollweitergabe"
1 | void TaskTest(void *pvParameters) // This is a task. |
2 | {
|
3 | (void) pvParameters; |
4 | while(1) |
5 | {
|
6 | vTaskDelay(1); |
7 | }
|
8 | }
|
Bodo M. schrieb: > Da ist doch nichts drin, was die Timer verändern kann. das ist richtig. Die Task wird gestartet (wenn auch ein xTaskCreate() dafür ausgeführt wird) und beendet sich gleich wieder. was passiert mit einer Endlosschleife die nur wartet (evtl. noch eine andere LED blinken lassen) ?
1 | while(1) { |
2 | vTaskDelay( 1000 / portTICK_PERIOD_MS ); // wait for one second |
3 | }
|
Ansonsten kann es schon ein Resourcenproblem sein, wenn der Stack für diese Task auch mit 128 angelegt wird, dann brauchst du schon 3*128 Byte für den Stack, plus das was dein Programm und Arduino noch so haben möchte.
Besten Dank. Eine while Schleife die nix tut, nur wartet. Meine Tasks gehen alle wieder. Es blinkt und die Serielle Schnittstelle sagt auch wieder was. Das in der Task was ausgeführt werden muß, hab ich so nicht gelesen. Die verbrauchten Ressourcen werden doch am Ende des Compilierprozesses angezeigt. Oder? Da sind noch 700Byte frei. 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. Evtl. gibt es auch kleine Module, welche man später auf die Platine löten kann. Ich suche mal.
da habe ich auch etwas falsches geschrieben, es ist bei FreeRTOS tatsächlich nicht erlaubt das eine Task ein return in irgendeiner Form macht. Stattdessen muss man am Ende ein vTaskDelete(NULL); aufrufen wenn die Task nicht mehr laufen soll. Habe das Buch vom Richard in Reichweite :) Aber häufiges Task Delete/Create sollte man sowieso vermeiden, das sind teure Operationen mit Dynamik. Hier gibt es unter Error auch eine Erklärung für das schnelle Blinken: https://github.com/feilipu/Arduino_FreeRTOS_Library#errors Das zeigt einen Heapoverflow an. Die drei Tasks verpackt der Mega328 aber noch, also war das eher das Problem mit dem nicht erlaubten beenden, was vermutlich ebenfalls in den Errorhandler mit dem Blinken läuft. Bei den STM32 kann man gut mit den Nucleo Boards anfangen, dann hast du gleich die Debughardware mit drauf. Die Nucleos sind billig und gibt es in verschiedenen Grössen. Für erste Schritte reicht der AVR sicher, aber wenn Display und Schnickschnack dazu kommt, dann wird es sehr schnell eng. Edit: Doku gibts ja auch als pdf https://www.freertos.org/fr-content-src/uploads/2018/07/161204_Mastering_the_FreeRTOS_Real_Time_Kernel-A_Hands-On_Tutorial_Guide.pdf Kapitel 3.2 Task Functions
Danke, danke. Da hab ich ja Lesefutter bis zur nächsten Mondfinternis und noch drei Monde weiter. Die Nucleo-Board sind ja ganz praktisch, aber kann man hinterher einen Prozessor nehmen, der beschaffbar und lötbar ist. Meine Aufbauten sollen hinterher in eine Platine gegossen werden. Ich werde mal lesen ob das geht: Mit Nucleo entwickeln und debuggen. Wenn es wie gewünscht läuft, verwandten Proz. nehmen.
Bodo M. schrieb: > Mit Nucleo entwickeln und debuggen. Wenn es wie gewünscht läuft, > verwandten Proz. nehmen. genau so!
Bodo M. schrieb: > Die verbrauchten Ressourcen werden doch am Ende des Compilierprozesses > angezeigt. Oder? Da sind noch 700Byte frei. Das ist nur der statisch belegte Speicher. Außerdem belegt praktisch jedes Programm auch dynamisch zur Laufzeit Speicher, das kann der Compiler nicht berechnen. Bodo M. schrieb: > Die STM's sind zwar alle recht cool, aber die Prozessoren sind > meist für mich nicht zu Löten oder nicht lieferbar. Geht mir genau so. Die Nucleo-32 Boards haben ein ähnliches Format, wie der Arduino Nano, zum Beispiel konkret das Nucleo-L031K6 oder das Nucleo-L432KC. Oder das "STM32 Black Pill STM32F411", ist etwas größer. Nur bei den Boards mit STM32F103x8 und STM32F103xB musst du aufpassen, da werden überwiegend schlechte Fälschungen verkauft. Falls du daran Interesse hast, kann ich dir den Shop von Robotdyn empfehlen. Die verkaufen Originale und Fälschungen, geben das aber immer eindeutig in der Artikelbezeichnung an.
Johannes S. schrieb: > Mehr RAM macht bei RTOS mehr Freude, aber für Experimente muss man den > AVR deshalb nicht gleich wegwerfen. Richtig. Zumal es ja inzwischen etliche mit 16kB RAM onchip gibt... Allerdings: RTOS ist prinzipiell eigentlich nur was für die Leute, die µC-Architektur nicht verstehen und versuchen, ihre Kompetenzprobleme auf ein OS abzuwälzen. Denn: "Quasi-Parallel" macht bei µC das Interruptsystem... So kann man das wohl guten Gewissens zusammenfassen.
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.
c-hater schrieb: > So kann man das wohl guten Gewissens zusammenfassen. Nein! Das ist eine sehr einseitige Sichtweise, und damit sicherlich unvollständig und damit falsch. Zumindest ist die Komplexität deines Gewissens damit offenbar. Hatte mir vorher schon gedacht, dass damit irgendwas schief läuft. Danke für die Bestätigung.
Bodo M. schrieb: > Da die ATMEGA wahrscheinlich unter "geht zwar, ist aber sinnlos" laufen, > bin ich jetzt auf der Suche nach einer neuen Entwicklungsumgebung. Anstatt den Ressourcen fressenden Brocken FreeRtos zu verwenden, könntest du auch ein kooperatives, sich an den ProtoThreads(Adam Dunkels) orientierenden System einsetzen. Hier hatte ich mal sowas vorgestellt: Beitrag "Re: Wer benutzt Protothreads?" Am besten den ganzen Thread lesen....
Wenn man den Rest von 2KB RAM minus Statische minus Heap noch in x Stackframes für die Threads aufteilen muß, kommt man eh nicht weit. OS hin oder her.
batman schrieb: > Stackframes für die Threads Die ProtoThreads und seine Verwandten arbeiten "Stackless". Es werden keine Stackframes eingerichtet. Das ist der Vorteil auf kleinen µC.
das ist im FreeRTOS auch als Alternative zu Threads drin, nennt sich da Co-routines. https://www.freertos.org/croutine.html
Naja gut aber ein primitiver Scheduler ist für mich noch lange kein RTOS. LED-Blinker sind da immer ein schlechtes Beispiel für Multitasking-OS.
batman schrieb: > kein RTOS Natürlich kann ein kooperatives System keine Echtzeit Anforderungen garantiert erfüllen. Allerdings ist die harte "Echtzeit" auch gar nicht immer erforderlich. Wenn sich nur um Nebenläufigkeiten dreht, dann sind die Protothreads/CoRoutinen schon eine brauchbare Wahl. Nenne es ruhig "Nicht Fleisch, nicht Fisch" aber es macht dennoch satt.
Arduino Fanboy D. schrieb: > Natürlich kann ein kooperatives System keine Echtzeit Anforderungen > garantiert erfüllen. Natürlich kann es das. Wenn halt jede kooperativ betriebene Komponente "hinreichend" kooperativ und fehlerfrei ist. Der Witz ist: letztlich ist das bei präemptivem MT nicht anders. Der einzige Vorteil ist, dass ein gestorbener Task nicht gleich das gesamte System runter reißt. Die Echzeitbedingung ist aber auch dann NICHT mehr erfüllt. Zumindest nicht im Bezug auf die Aufgabe dieses gestorbenen Tasks. Oder anders ausgedrückt: Auch ein präemptives RTOS ist nicht in der Lage, generell für die gesamte Software die Einhaltung der Echtzeitbedingung zu garantieren, sondern kann das immer nur maximal für einen (den fehlerfreien) Teil der Software tun. Und das gelingt nur unter Inkaufnahme massiver Performance-Verluste. D.h.: Echtzeit ja (mehr oder weniger), aber halt nur laaangsaaaame Echtzeit. Das ist ungefähr, was ein OS ausmacht und warum man die auf µC eher nicht haben will.
c-hater schrieb: > Das ist ungefähr, was ein OS ausmacht und warum man die auf µC eher > nicht haben will. tja, ein paar Ausnahmen scheint es ja zu geben wenn man sich die lange Liste der OS für µC ansieht. Zum Glück teilt nicht jeder deine Ansichten. Da hat sich mal jemand Mühe gemacht: https://www.osrtos.com/
Johannes S. schrieb: > tja, ein paar Ausnahmen scheint es ja zu geben wenn man sich die lange > Liste der OS für µC ansieht. 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. Da muss es dann halt ein fettes präemptives OS sein, um das Austicken des unsäglichen absturzgefährdeten Softwaredrecks erkennen und ggf. neu starten zu können... Aber wie gesagt: zumindest der abgestürzte Teil war definitiv aus der Echtzeit. Erkennen und neu starten ist ein SEHR bedenklicher workaround, keine echte Lösung. Die richtige Lösung ist: finde und beseitige den Fehler! Hast du alle gefunden und beseitigt, dann brauchst du auch kein präemptives RTOS mehr...
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.
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.
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
c-hater schrieb: > Die richtige Lösung ist: finde und beseitige den Fehler! Hast du alle > gefunden und beseitigt, dann brauchst du auch kein präemptives RTOS > mehr... Da muß man sich ja erstmal das Problem zur Lösung produzieren. Aufwendige Fehlersuche spart man sich gerade durch vernünftige Rahmen-Konzepte, wozu ggf. auch das passende OS zählt.
batman schrieb: > Aufwendige Fehlersuche spart man sich gerade durch vernünftige > Rahmen-Konzepte, wozu ggf. auch das passende OS zählt. Alles klar. Genau das ist, was man von RTOS-Usern erwartet. Man spart die aufwendige Fehlersuche... Nein, die einzig richtige Lösung ist, die aufwendige Fehlersuche eben nicht zu sparen.
Na gut, dann such mal schön weiter, wenn du das so toll findest, daß du Fehler in deinen Programmen versteckst. Manche sollen ja auch Schokoladeneier im Wald verstecken, also von da her..
batman schrieb: > Na gut, dann such mal schön weiter, Ach lass ihn doch... Merksatz: §1 Der C Hasser hat immer recht §2 Sollte es einmal so aussehen, als hätte er nicht recht, dann sind alle anderen Idioten.
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.
Harry L. schrieb: > Der ohnehin schon sehr schlanke Footprint ist bei modernen MCUs ja auch > wirklich kein Thema mehr Laber, laber, sülz. 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. Tatsächlich benutzt wird es aber üblicherweise, um Bugs nicht fixen zu müssen, d.h.: es wird konsequent und in großem Umfang mißbraucht. Das ist alles. Und wer etwas anderes behauptet, kennt die objektive Realität nicht. So einfach ist das.
c-hater schrieb: > Und wer etwas anderes behauptet, kennt die objektive > Realität nicht. So einfach ist das. Richtig! Du hast recht! (und alle anderen sind blöd)
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.
:
Bearbeitet durch User
c-hater schrieb: > Tatsächlich benutzt wird es aber üblicherweise, um Bugs nicht fixen zu > müssen, 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. Da verwendet man möglichst schon getestete und bewährte Fertigbausteine, statt das jedesmal wieder neu machen zu wollen und dann die Eiersuche darin zu zelebrieren.
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. mir fällt da Femto OS ein www.femtoos.org (Seite lädt aber bei mir gerade nicht)
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.
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.
:
Bearbeitet durch User
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
Rainer V. schrieb: > Nur weil man sich RTOS draufschafft, ist man noch lange > nicht "Echtzeit" Bodo hat nicht danach gefragt und ich habe es nicht erwähnt. Also was soll der Quatsch?
Rainer V. schrieb: > Nur weil man sich RTOS draufschafft, ist man noch lange nicht > "Echtzeit", glaubt mir... > Gruß Rainer Glaube ich nicht, mit RTOS wird alles einfacher und läuft schneller! Reicht das als Vorlage?
Peter S. schrieb: > 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. Arm Cortex M (Thumbs2) mit 32 Bit, gegebenenfalls mehreren 100Mhz, DMA, auf Wunsch MMU und unmengen an Peripherie?
Gerhard O. schrieb: > Der Gebrauch von "Delays" sind in > solchen Designs absolut verboten und muß mit Zustandsmaschinen Logik > gesteuert werden. Das ergibt sich ja von selbst. Selber nehme ich einfach einen TimeTicker per int und leite daraus diverse Zeitscheiben ab (mit modulo oder bitcheck). Am Ende check ich die verbleibende Zykluszeit (wie bei einer einer SPS). Dazu läuft der Watchdog und ein Prozesszähler ( wenn eins davon nicht stimmt -> Fehler). Semaphore lokale und nichtlokale Vars Strings etc handle ich über units und .h files. Max. gibt es einen Callback in eine andere unit. Das ist dann alle native C und trotzdem schön getrennt. Der Overhaead ist nahe null da sich das "RTOS" aus der Struktur ergibt.
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.
wer RTOS verwenden will mit mehreren Tasks, der muss bereit sein, sich an RTOS anzupassen. Wer versucht, seine gewohnte Arbeitsweise RTOS überzustülpen wird die Vorteile von RTOS nicht kennenlernen. RTOS braucht selbst Ressourcen, also wird nichts durch RTOS schneller, außer vielleicht die Codeerstellung weil jemand anders schon Vorarbeit geleistet hat für das RTOS. RTOS partitioniert die verfügbare Rechenleistung und man kann sie leichter verteilen (Priorisierung von Tasks und osDelay() für Wartepausen wenn eine geringe Reaktionszeit für den Task machbar ist). Die am Schwersten zu schluckende Pille ist, keine Annahme mehr zu machen wie lange die Ausführung von einem Codeblock dauert, da der scheduler reingrätschen kann. Einzig wann die Ausführung eines Codeblocks startet kann man steuern. Schlechte Programmierer machen mit RTOS keinen besseren Code und gute Programmierer schreiben schneller guten Code mit RTOS. Ein AVR wird von freeRTOS unterstützt, also kann der TO getrost seinen AVR für die ersten Gehversuche mit RTOS benutzen. Ist er ein guter Programmierer und lernt er was dazu wird er zum besseren Programmierer. Wenn er noch Spaß dabei hatte kann es kaum noch besser werden.
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.
"Echtzeit" definiert nur das ein bestimmtes Zeitverhalten, das vorher definiert wurde in der Implementation in einer zu definierenden Zuverlässigkeit erfüllt wird. https://de.wikipedia.org/wiki/Echtzeit Wenn ich für mein System definiere das die Reaktion auf einen IRQ innerhalb von 2 Wochen erfolgt, dann ist mein System ein "harte Echtzeit" System, wenn 100% der IRQs innerhalb der vorgegebenen Zeit abgearbeitet werden. Die ms, us und ns Erbsenzähler keinen also die Definition von "harte Echtzeit" nicht. Die Anforderung an das System definiert "RTOS", nicht eine fixe Zahl. BTW, freeRTOS ist nicht safe, da es dynamische Speicherverwaltung enthält, die in einem "harten Echtzeit" System nicht verwendet werden dürfen da eine 100%ige Vorhersage des Zeitverhaltens dadurch nicht möglich ist.
Hi, keine Ahnung ob es hier hilft, aber für die atmels habe ich vor Jahren mal ein OS entwickelt, das ein paar features hat: -Multitasking preemptiv/kooperativ -dynamische taskverwaltung -Speicherverwaltung basierend auf arrays -soft echtzeitfähig -binäre semaphore -messaging system http://sourceforge.net/projects/nanoos/ Es gab hier auch mal einen thread dazu Beitrag "NeuesOS für AVR Mikrocontroller"
Rainer V. schrieb: > 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? Für einen AVR8 (oder andere kleine µC ähnlicher Komplexität) ist das relativ schnell machbar. Wird halt nur auf den meisten Vertretern dieser Art wenig Spaß machen, weil sehr viel von den knappen Resourcen nur dafür verwendet werden muss, ein OS laufen zu lassen, welches sie verwaltet. Spannend wir ein RTOS erst mit mehreren Kernen und/oder komplexer Peripherie (die praktisch selber auch wieder ein Controller mit einiger Komplexität ist).
Klaus W. schrieb: > c-hater Jepp, das könnte ich sicher. Und wenn ich es im AVR8-Umfeld für sinnvoll halten würde, hätte ich es genauso sicher auch schon vor vielen Jahren getan. Aber ich bin damals(tm) recht schnell zu dem Schluß gekommen: ist am ende hochineffizienter Schwachsinn. > Und zwar in 5 Minuten. Naja, ich habe da schon ein wenig länger drüber nachgedacht und eine Umsetzung hätte sicherlich noch deutlich länger gedauert. Aber eins ist 100%ig sicher: In Assembler wäre die Umsetzung deutlich einfacher als in C... Man muss sich doch nur den RTOS-code anschauen, um zu erkennen, dass da an vielen Stellen an C vorbeilaviert werden muss, also letztlich alles wirklich Wichtige in Asm programmiert ist. Vom Task-Switching über die Sync-Objekte, immer ist der wesentliche Knackpunkt in Asm geschrieben. Der Witz ist: das ist auf JEDER anderen Architektur genauso! Asm rules!
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.
Peter S. schrieb: > 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. Wennschon, dann macht man sowas auch mit dem eingebauten Assembler des Compilers. So vollkommen Scheiße und abstrus häßlich der auch sein mag...
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
Rainer V. schrieb: > Das ist doch jetzt alles ziemliches Geschwurbel. Wer hat denn > tatsächlich - ganz ehrlich - ein hartes "Echtzeit-System" programmieren > müssen? Sehr, sehr viele µC-Anwendungen SIND harte Echtzeit. Nur halt ohne ein "System" (=RTOS) drumrum... Halt mit dem umgesetzt, was die Hardware bietet. Bei den weniger Fähigen ist halt der letzte Ausweg der Watchdog-Reset. Spielt de facto effektiv ziemlich genau die Rolle eines RTOS... Verstecke die Bugs, erspare es mir, sie zu suchen und zu beseitigen...
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...
Rainer V. schrieb: > Ja Mann, auch die blinkende LED ist so gesehen eine harte > Echtzeitanwendung! Ganz genau. Zumindest sobald sie von irgendwelchen äußeren Einflüssen gesteuert wird und innerhalb einer exakt definierbaren Maximalzeit mit einem exakt definierten Verhalten diesem Input zu folgen vermag. > Ansonsten...Geschwurbel... Du hältst den eigentlichen Kern der "Echtzeit" für Geschwurbel? Dann bist du definitiv ein Vollidiot.
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.
:
Bearbeitet durch User
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.
Joachim B. schrieb: > man kann sich das Leben auch schwer machen. Aber wenn man mit nem RTOS spielen möchte ist das doch ein guter Ansatz. Ist zwar etwas sinnlos auf der kleinen Platform, aber zum spilen reicht es. Wenn man mit 20 Leuten im Team einen Satelliten baut ist ein RTOS eine große Hilfe. Aber selber hab ich das irgendwann sein gelassen. Das addiert jede Menge Komplexität zu einer Anwendung, Das war bei meinen nie gerechtfertigt. Langsamer wird das ganze auch und irgendwann auch teuer. Nei Mehrkernern kann ich mir aber vorstellen das einzusetzen. Kann FreeRTOS das eigentlich?
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.
Arduino + ESP32 + RTOS + dual core Beispiel https://youtu.be/684KSAvYbw4 mit deutschem Untertitel STM32 freeRTOS und CubeMX Tutorial https://www.st.com/content/st_com/en/support/learning/stm32-education/stm32-moocs/FreeRTOS_on_STM32_MOOC.html im Downloadbereich die Schulung als PDF
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 :-)
Gerhard O. schrieb: > Da der AVR > keine Programmierung der Interrupt Prioritäten zuläßt Diese Lüge (oder Ausdruck maximaler Unwissenheit) habe ich jetzt erst gesehen. Nein, natürlich kann man auch beim AVR8 Interrupt-Prioritäten festlegen. Bei den XMega und ihren aktuellen Nachfolgern sogar in Hardware. Bei den "klassischen" immerhin mittels Software. Selbst letzteres hat noch einen sehr viel geringeren Footprint als ein Software-Monster á la FreeRTOS.
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?
:
Bearbeitet durch User
Der c-hater weiß ganz genau, dass die Xmega und Tiny 0 Serien unter Hobbybastlern selten verwendet werden. Wenn hier jemand AVR ohne weiteren Zusatz schreibt, darf er genau wie alle anderen von den klassischen ATmega ausgehen. Der ATmega328A ist der bekannteste Vertreter dieser Serie und somit das Maß der Dinge.
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: > Der c-hater weiß ganz genau, dass die Xmega und Tiny 0 Serien unter > Hobbybastlern selten verwendet werden. Das weiss ich tatsächlich, ist aber irrelevant bezüglich einer Tatsachenbehauptung über eine Architektur. Also Tipp speziell für dich noch: es gibt außer den Tiny-0-Series inzwischen auch noch viel mächtigeres AVR8-Gerät als XMega-Erben. Tiny-1-Series, Mega-0-Series und (last but not least) AVRxDy. > klassischen ATmega ausgehen. Nunja und für die kann man halt problemlos eine Interruptpriorisierung in Software umsetzen. (Was bei den XMega und -Erben nicht geht, aber die können es halt in Hardware). Man muss halt einfach nur wissen, was man tut. Das ist alles. Du weißt nicht, wie's geht und der Gerhard O. weiss es wohl auch nicht. Ich schon. > Der ATmega328A ist der bekannteste > Vertreter dieser Serie und somit das Maß der Dinge. Na das wäre ja das Allerletzte. Man läßt sich von den Hobbyisten den Rahmen für die objektive Wahrheit vorschreiben. Du spinnst doch!
Peter S. schrieb: > Ja Prioritäten für Interrupts auf AVR ist möglich, aber es ist ein > riesen Handstand. In Assembler: kein Problem.
c-hater schrieb: > Man läßt sich von den Hobbyisten den > Rahmen für die objektive Wahrheit vorschreiben. Du spinnst doch! c-hater schrieb: > In Assembler: kein Problem. Alles klar, die Profis vertrauen dem Mann, der nicht anderes als Assembler akzeptiert. Muahaha!
Stefan ⛄ F. schrieb: > Alles klar, die Profis vertrauen dem Mann, der nicht anderes als > Assembler akzeptiert. Muahaha! Ich kann das natürlich auch in C umsetzen. Aber das mache ich nur für Geld, nicht freiwillig und als Hobby. Bin ja nicht pervers.
c-hater schrieb: > Bin ja nicht pervers. Hoffentlich nicht. Sicher ist allerdings, dass du der verirrte Geisterfahrer bist, der allen anderen zuruft "ey, du fährst falsch herum!".
Stefan ⛄ F. schrieb: > Hoffentlich nicht. Sicher ist allerdings, dass du der verirrte > Geisterfahrer bist, der allen anderen zuruft "ey, du fährst falsch > herum!". Für jemanden, dessen Horizont so ungefähr das Arduino-Unversum umfasst (und nichtmal dies wirklich), hast du eine ganz schön große Klappe.
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.
Peter S. schrieb: > Ehrlich gesagt, kann ich mich mit systemnahem Code in C mit inline > Assembler nicht anfreunden. Es ist an Unübersichtlichkeit kaum zu > überbieten. Assembler Code hat den Charme, dass du bis auf Bit und Takt genau weißt, was sie tun. Je weiter man sich davon entfernt, umso mehr artet das Programmieren in Richtung eines Adventure Games aus, wo man herausfinden muss, was eigentlich los ist und was man machen soll. Deswegen hat Assembler durchaus seine Daseinsberechtigung - nur nicht als einzig wahre Überall-Lösung, wie der c-hater es darstellt.
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.
Peter S. schrieb: > 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. Das ist doch gut dokumentiert, wie man das anstellt und funktioniert perfekt. Die AVR Gcc Toolchain beinhaltet u.A Assembler Compiler und Linker. Diese spielen auch gut miteinander. https://gcc.gnu.org/wiki/avr-gcc
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.
Er meint das vermutlich so, dass alle anderen Programmiersprachen irgendwo Einschränkungen haben. Nur Assembler unterstützt garantiert den vollen Funktionsumfang des Prozessors. Deswegen ist es leicht, jede Frage mit "In Assembler geht das" zu beantworten.
Peter S. schrieb: > 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. 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. Der eigentliche Aufwand ist (um dies auf ein RTOS abzubilden), dass an der Grenze dieser zwei "natürlichen" Phasen einer ISR ein Taskswitch ausgeführt werden muss. Das macht die Sache so elend ineffizient. Taskswitch ist auf AVR8 extrem teuer. Der hat nur einen Satz Register und nicht eins davon wird automatisch gesichert, wenn ein Interrupt passiert. Das betrifft gleichermaßen MCU-Register als auch für die MCU relevante SFIOR, also insbesondere natürlich SP und das Flag-Register (bei den größeren noch ein paar mehr). Die beste Lösung, ein RTOS auf einem AVR8 unzusetzen ist also: Eben KEIN RTOS umzusetzen (jedenfalls keins im üblichen akademischen Sinne).
Stefan ⛄ F. schrieb: > Er meint das vermutlich so, dass alle anderen Programmiersprachen > irgendwo Einschränkungen haben. Nur Assembler unterstützt garantiert den > vollen Funktionsumfang des Prozessors. Deswegen ist es leicht, jede > Frage mit "In Assembler geht das" zu beantworten. Stimmt. So kann man das auch ausdrücken.
> Er meint das vermutlich so, dass alle anderen Programmiersprachen > irgendwo Einschränkungen haben. Nur Assembler unterstützt garantiert den > vollen Funktionsumfang des Prozessors. Und wenn man noch präziser sein wollte, müsste man sagen: Binärcode. Denn neben dem im Assembler offiziellen Befehlen gibt es auch noch inoffizielle Hidden-Codes.
Solche Segmente koennte man ja in Assembler, binaer, inline oder extern zum C schreiben, mit der entsprechenden Latte ifdefs fuer jede Prozessorvariante. Wird aber selten von Noeten sein. Jedenfalls kein Grund, generell nicht in C/C++ zu schreiben.
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.
Beitrag #6727191 wurde von einem Moderator gelöscht.
Beitrag #6727192 wurde von einem Moderator gelöscht.
Beitrag #6727194 wurde von einem Moderator gelöscht.
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.
Moby schrieb im Beitrag #6727191: > Absolut. Die wichtigste Triebkraft für höherbittige ist ganz allgemein > schlechtere Software-Qualität... Das sehe ich anders. Die Anzahl der Bits hat nichts mit Qualität zu tun. Man hat auch nicht die 8-Zylinder Motoren erfunden, weil Motoren mit 4-Zylindern schlechte Qualität haben.
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...
Falk B. schrieb: > Schau dir Schiffsdiesel an, die kriegen 1500PS aus 4 Zylindern hin ;-) Och, die augenblickliche Grenze liegt bei ca 7 Tausend Kilowatt pro Zylinder und davon gibts dann bis zu 14 in einer Reihe. Da ist man dann bei ca 1/8 Million PS an der Welle.
Stefan ⛄ F. schrieb: > Leistung <> Qualität Aha... In Lebensdauer und Wirkungsgrad sind diese Vielstoff 2Takt Motoren ungeschlagen.
Peter S. schrieb: > Mein Beispiel braucht weniger als 100 Befehle für einen vollständigen > Kontextswitch Die Frage ist ja wie oft der Kontext gewechselt wird. Bei einer seriellen mit 115k ist das schnell an der Grenze.
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.
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.