FreeRTos auf RP6?

[RolfD]

Hallo,
hat schon mal jemand versucht, FreeRTOS auf einem Rp6 evtl. auch mit Zusatzborads ans rollen zu bringen?

Auf http://www.cypax.net/snippets/mucsni...ge=de#mu-asuro gibts ein Projekt mit dem Asuro und seinem Mega8, das sollte nach Anpassung der Hardware also auch mit dem RP6 laufen, oder? Also konzeptionell... nicht jetzt speziell das Beispielprogramm da...

Ich will keine Grundsatzdiskussion über den Sinn von Multitasking vs. irq-Steuerung oder FreeRTos vs. RP6Lib lostreten, mir gehts vor allem um tatsächlichen Erfahrungsaustausch und echte Projekte in dem Bereich laut Betreffzeile. Wer kann berichten?

LG Rolf

[radbruch]

Hallo

Ich will keine Grundsatzdiskussion über den Sinn von Multitasking vs. irq-Steuerung oder FreeRTos vs. RP6Lib lostreten...

Das läßt sich hier wohl leider nicht vermeiden. Echtes Multitasking kann es mit einem AVR nicht geben, weder mit dem Mega8 des asuro, noch mit dem Mega32 des RP6. Man kann zwar Multitasking simulieren, hat dabei aber immer einen Overhead durch das Verwalten und Umschalten der Tasks. Die Grafik auf der RTos-Seite schönt meiner Meinung nach dieses Problem:

Bild hier  
(Grafik von http://www.freertos.org)

Die senkrechten gestrichelten Linien gaukeln vor, dass das Umschalten im Vergleich zur Laufzeit der einzelnen Tasks nahezu keine Zeit benötigt.

Die Library des RP6 hat ein eigenes Tasksystem. Dieses kappselt zwar die einzelnen Tasks nicht, macht aber die Anwendung eines externen Taskschedulers wie z.B. RTos überflüssig.

Gruß

mic

[RolfD]

Hallo radbruch,

Ich will keine Grundsatzdiskussion über den Sinn von Multitasking vs. irq-Steuerung oder FreeRTos vs. RP6Lib lostreten...

Das läßt sich hier wohl leider nicht vermeiden. Echtes Multitasking ...

Doch... und ich sag dir auch ganz genau warum:

Diese Diskussion ist so alt wie die PDP11 auf der immerhin Unix entwickelt wurde und ich führe diese Diskussion selbst schon seid ich einen der ersten Amiga 1000 hatte und mich mit DOS 1.1 Anwendern auf der C'84 in Köln.. dem Vorläufer der CeBit... über Multitasking unterhielt als andere noch auf dem VC20 und der Datasette Musikkasetten schredderten.

Bild hier  
(Quelle: c64-wiki.de)

Und soll ich dir was sagen? das ist nun bald 30 Jahre her...

Nein... über den Sinn von Multitasking ... was immer man auf einer SinglecoreCPU darunter verstehen will ... mag ich heute nicht mehr streiten Back to Topic.

LG Rolf

[radbruch]

Hallo

Der Kern ist das: Der RP6 hat ein eigenes Tasksystem. Warum also sollte man RTos verwenden? Das was SlyD mit der RP6-Lib abgeliefert hat ist eigentlich schon vollkommen ausreichend und funktioniert super.

Die Zeit, die man zur Einbindung der RP6-Funktionen in ein RTos-System benötigt, wird wohl keiner investieren. Es bleibt dir überlassen, ob du das selbst angehen willst. Mit deiner Erfahrung sollte das eigentlich kein großes Problem sein.

Hat schon mal jemand versucht, FreeRTOS auf einem Rp6 evtl. auch mit Zusatzborads ans rollen zu bringen? ... Wer kann berichten?

Im Sinne der Fragestellung ist mein Beitrag zum Thread natürlich OffTopic. Ich befürchte aber, dass bisher noch niemand RTos auf dem RP6 eingesetzt hat und du deshalb wenig bis keine Rückmeldungen erhältst. Zumal du ja anscheinend nicht bereit bist, über eventuelle Vor- oder Nachteile von RTos gegenüber der RP6-Library zu diskutieren.

Gruß

mic

[Edit]
Eine Alternative zu FreeRTos wäre vielleicht das speziell auf AVRs zugeschnittene Femto OS:
http://www.femtoos.org/

[RolfD]

Hallo radbruch,

Der Kern ist das: Der RP6 hat ein eigenes Tasksystem. Warum also sollte man RTos verwenden? Das was SlyD mit der RP6-Lib abgeliefert hat ist eigentlich schon vollkommen ausreichend und funktioniert super.

Mir würde im Traum nicht einfallen, an der RP6Lib rumzukritteln, es geht um was ganz anderes. Interuptgestützte Systeme (ohne echtes Taskmanagement) haben genau so Vorteile wie Schedullersysteme. Vergleichen kann man beide nur wenn man sie wirklich gegeneinander praktisch prüft - und selbst das ist nicht einfach.

Was mich reizt ist aber, das es für den RP6 scheinbar keine Alternative zur Methode von RP6Lib gibt obwohl es möglich scheint. Also blanke Neugier! Wir hätten vielleicht niemals das Auto erfunden denn wir hatten ja gut funktionierende Pferde... aber die ersten Autos waren auch eher Kutschen als Rennwagen... verstehst du?
Allerdings ist der Vergleich etwas weit hergeholt..

Zumal du ja anscheinend nicht bereit bist, über eventuelle Vor- oder Nachteile von RTos gegenüber der RP6-Library zu diskutieren.

Doch bin ich, nur ich würde gern ein Schritt nach dem anderen machen... dazu muss erst mal ein RTOS Port für den RP6 her bevor ich anfange über dessen Vor- oder Nachteile im Speziellen zu grübeln. Sonst sind das ungelegte Eier. Multitaskingsysteme haben Vorteile, dazu brauchen wir nicht die Themen der letzten 30 Jahre zu widerholen oder bei 0 anfangen. Das Rtos auf "kleinen" Systemen mit 16 Mips was bringt zeigt schon die Tatsache das es genug Ports dafür gibt - u.a. auch für den mega32 bzw. dem obsoleten 323. Ich hab schon mit Leuten gesprochen die Rtos auf einer Intel 8051 laufen hatten... Ob und wie sich Rtos jedoch auf einem RP6 nutzen lässt... darüber reden wir also gern wenns läuft Ich glaube nicht mal das Rtos besser als die RP6Lib ist.. aber eben anders.

Ich weis noch nicht ob ich mir das antuen soll nen Port auf gut Glück anzupassen. Um mir da Klarheit zu verschaffen hätte ich eben gern mit Leuten gesprochen die schon mal die Fühler in der Richtung ausgelegt haben. Oder Feedback zu dem Thema gesammelt... wie auch immer. Warscheinlich würden sich die RP6Lib und Rtos nicht mal gegenseitig ausschließen... ich sehe zumindest im Augenblick kein Grund für ein "Entweder oder"... sondern eher eine _vielleicht_ sinnvolle Ergänzung. Das kann aber nur die Praxis zeigen.

Im schlimmsten Fall vergammelt der Thread hier und ich frickel im stillen Kämmerlein allein an rtos rum ... bis ich die Antworten habe die ich suche. Solltest Du mal ein RP6 sehen, an dem das Logo pappt, Bild hier   dann isses vielleicht meiner

LG Rolf

[radbruch]

Hallo Rolf

Da ich mir bisher keine Gedanken über "Multitasking" mit AVRs gemacht habe, bin ich eigentlich noch nicht richtig vorbereitet. Trotzdem würde ich gerne noch ein paar Gedanken austauschen, bevor wir uns in ein Abenteuer stürzen.

Nach einer kurzen Recherche bin ich neben AvrX auf Femto OS gestossen. Das scheint mir auf den ersten Blick für ein Projekt mit dem RP6 besser geeignet, weil es speziell für die begrenzten Resourcen der AVRs zugeschnitten zu sein scheint und eine Portierung für den Mega32 verfügbar ist. Ob die geringe Taktfrequenz des RP6-Base den sinnvollen Einsatz ermöglicht kann ich im Moment noch nicht abschätzen. Die Erweiterungsmodule m32, m128 und arm64 sollten zumindest taktmässig geeignet sein. Femto OS ist auf 16 Tasks beschränkt, bei den vielen Funktionen des RP6 könnte das möglicherweise nicht ausreichen.

Interuptgestützte Systeme (ohne echtes Taskmanagement) haben genau so Vorteile wie Schedullersysteme. Vergleichen kann man beide nur wenn man sie wirklich gegeneinander praktisch prüft ... ich würde gern ein Schritt nach dem anderen machen... dazu muss erst mal ein RTOS Port für den RP6 her

Das sehe ich genauso. Der erste Schritt wäre aber meiner Meinung nach eine kleine Analyse einer Taskverwaltung für den RP6. Hier sehe ich im rein preemptiven Ansatz schon unüberwindliche Hindernisse bei den schnellen ungepufferten Funktionen wie ACS, I2C, bei der Odometrie und der Drehzahlregelung der Antriebe und letztlich auch beim ADC mit seinen acht Kanälen...

Im Moment halte ich ein Multitaskingprojekt für den RP6 für ebenso sinnvoll wie die µC-Programmierung in C++. Machbar, aber beschränkt sinnvoll. Die Vorteile der µC liegen in der Hardwarenähe; viel Leistung und Funktion mit wenig Resourcen auf engstem Raum. Wenn der µC noch zusätzlichen Platz für Task- oder Objektverwaltung bietet, dann ist er falsch ausgewählt. Für mich ist schon die Anwendung von Floats ein Frevel ;)

Viel Erfolg bei der Umsetzung. Ich werde auf das Logo achten. Vielleicht sieht das dann ja auch so aus:
Bild hier  

Gruß

mic

[RolfD]

Hallo radbruch,

Nach einer kurzen Recherche bin ich neben AvrX auf Femto OS gestossen.

femtoos kannte ich noch nicht, gefällt mir aber ganz gut auf dem ersten Blick. AvrX ist mir als Assemblersource zu schlecht zu pflegen - was aber an meinen eingerosteten Kentnissen liegt. Das soll keine Wertung gegen AvrX sein.

Ob die geringe Taktfrequenz des RP6-Base den sinnvollen Einsatz ermöglicht kann ich im Moment noch nicht abschätzen.

Da fällt mir ein.. man kann den mega32 auf dem rp6 doch sicherlich hochtakten oder? Ich hab mir das noch nicht angesehen weil ich 8 Mips für eine recht ordentliche Leistung halte. Aber sollte das zu einem Problem werden, wäre das sicher schnell zu beheben. Natürlich müsste man den UART anpassen usw... keine Ahnung... das Datenblatt des mega32 ist mir jetzt zu lang um das zu erforschen...

Die Erweiterungsmodule m32, m128 und arm64 sollten zumindest taktmässig geeignet sein. Femto OS ist auf 16 Tasks beschränkt, bei den vielen Funktionen des RP6 könnte das möglicherweise nicht ausreichen.

Arm64? hihi. Ich überlege schon, mir eine LPC2138 Stamp auf das Experimentierboard zu löten. Leider nur ARM7 und nicht ARM9

Aber langsam... da muss man eh genauer hinsehen. Auch OS'e wie rtos und femtos haben ISRs...und auf die kann man auch nicht verzichten wenn es um zeitkritische Dinge oder eben interne Interruptquellen geht. Das ist auch genau der Punkt wo ich sage, das die RP6Lib quasi unverzichtbar ist. Ich hab jedenfalls nicht vor alles am RP6 neu zu schreiben...
Man kann einen hardwarenahen Treiber wie z.B. für TWI oder Odometrie nicht nur mit "tasks" bauen. Und dafür reicht die cpu sicherlich aus denn sonst würde sie auch jetzt schon nicht reichen. Bei einem Footprint in der CPU Last von max 20% im schlechtesten Fall - und unter 1% im besten - reichen 16 Tasks auch dicke. Man braucht ja nicht für jeden adc Port ein eigenen Task. Ich schätze mal das man mit 4-8 Systemtasks satt hin kommt, da bleiben noch min. 8 als Usertasks...

Im Moment halte ich ein Multitaskingprojekt für den RP6 für ebenso sinnvoll wie die µC-Programmierung in C++. Machbar, aber beschränkt sinnvoll.

Vielleicht ist das so.. ja.
Wenn man von 30KB Flash auf einem M32 Modul noch 5 kb für eigene Programme Platz hat, ist es definitiv beschränkt sinnvoll. Die RP6Lib belegt aber allein auch schon einige kbs.. wenn man mit 2 zusätzlichen Kbs Multitasking hätte - wie es sich wohl mit femtos anbietet - lohnt sich das.. finde ich wenigstens.
Ausserdem wenn man ein 2.ten Prozessor wie die M32 auf dem RP6 hat, ist die Base eh als dummer i2c-slave kaum zu mehr in der Lage als die i2c-Befehle auszuführen. Auf der M32 braucht man aber viele der RP6Lib Geschichten nicht mehr und genau hier macht sich ein preemptives Multitasking perfekt. Da hat man dann nämlich nur 2 von 30Kb mit dem Femtos belegt und kann mit 16 tasks hantieren.. wenn man die denn auch alle braucht.

Ob das femtos auf der base was nutzt... naja.. keine Ahnung.. aber auf einer M32 nutzt es sicherlich!

Die Vorteile der µC liegen in der Hardwarenähe; viel Leistung und Funktion mit wenig Resourcen auf engstem Raum. Wenn der µC noch zusätzlichen Platz für Task- oder Objektverwaltung bietet, dann ist er falsch ausgewählt. Für mich ist schon die Anwendung von Floats ein Frevel

hrhr .. naja jeder Prozessor ist hardwarenah... es kommt halt immer auf die Relation und letztlich auf die Umsetzung an. So wie du Tasks ablehnst, so lehne ich sleep und msleep ab... weil in der Zeit könnte auch ein anderer Task was leisten statt Prozesorzyklen zu verbrennen.

Viel Erfolg bei der Umsetzung. Ich werde auf das Logo achten. Vielleicht sieht das dann ja auch so aus:
Bild hier  

Danke, Du ich bin da nicht festgelegt... wenn sich femtos als praktisch erweisen sollte, nehm ich auch das Es scheint mir schlanker als RTOS zu sein aber genau sowas wäre mal eingehender zu prüfen. Für mich spielt dabei z.B. auch eine Rolle ob das OS fehlerfrei compiliert wird, ich hab keine Lust OS-Bugs zu suchen und RTOS geht ohne Warnings mit gcc. hab ich eben schon mal probiert. Daran muss sich femtos z.B. auch messen lassen. Ich werds in jedem Fall mal testen.

LG Rolf

[Netzman]

Hallo,

Ich kenne zwar den RP6 nicht, möchte aber ein paar Worte zu einem (RT)OS loswerden:
ein HAL wird hier sogar in den meisten Fällen eher unnötig und verschwenderisch sein, den direkten Hardwarezugriff über einen eigenen Task zu kapseln bringt nur Vorteile wenn mehrere Tasks diese Resource benötigen und die Anzahl der darauf zugreifenden Tasks beim kompilieren nicht bekannt ist bzw. nicht gesteuert werden kann wann welcher Task darauf zugreift.

In der Regel wird nur ein Task auf eine Resource zugreifen (zb. Akkuspannung über einen ADC-Port messen etc), in diesem Fall ist keine gesonderte Behandlung nötig.
Sollten mehrere Tasks diese Ressource zeitweise benötigen, lässt sich das auch noch mit Critical Sections regeln (Gloable Interrupts im kritischen Abschnitt abschalten - kein Taskwechsel).
Ein eigener Treibertask wird vllt höchstens für die Kommunikation nötig sein - hier teilen sich viele Tasks asynchron die Resource.

Über den Sinn oder Unsinn eines (RT)OS bei einer bestimmten Zielsetzung lässt sich streiten - dass aber ein OS ab einer gewissen Anwendungskomplexität sowohl die Entwurfsphase beschleunigen und vereinfachen sowie die Systemstabilität steigern kann ist glaube ich nicht abzustreiten.

mfg

[RolfD]

Hallo Netzman,
dem Einwurf kann ich nur voll und ganz zustimmen.
Ein HAL macht keinen Sinn, was aber Sinn machen würde ist eine Logik, die entscheiden kann welcher Prozessor die Base in welchem Umfang steuert (in dem Fall wo mehr als eine CPU im System aktiv ist). Der mega32 hat laut Amtel Datenblatt angeblich nicht mehr die Probleme mit dem TWI-Busmaster (hängen von Pegeln) wie beim mega323, man kann also vielleicht auch ein Multimastersystem aufbauen und grade dann ist diese Logik für die Base interessant - z.b. in einem Task verpackt eben so wie die Systemaufrufe.
Möglichkeiten für ein OS sehe ich da auch für die Base reichlich. Das geht aber schon fast zu sehr ins Detail da bisher ja nicht mal eine Minidemo eines OS läuft...

FemtoOS scheint wirklich interessant zu sein... aber das hab ich auch gefunden: "With Femto OS you are living on the edge, be prepared to bleed."

Edit: Ich sehe grade, das es dazu schon mal eine Anfrage hier gab.
http://robotikportal.de/phpBB2/viewt...ec0461279b6b7e

Auch interessant:
http://www.youtube.com/watch?v=UgocLNmY2Ro
http://www.youtube.com/watch?v=CvtM8J9ZpJU&NR

LG Rolf

[RolfD]

Ich hab mir das Femtoos was näher angesehen.. alles ganz nett aber es gibt ein schlagendes Kriterium dagegen:
Als Compileroption steht da u.a. für GCC -mint8, was meines Wissens interger auf 8 Bit zwingt. Für kleine komplett selbst geschriebene LED-blink-Programme auf einem ATtiny mag das ok sein aber wenn man portabelen Code nutzt, geht das in die Hose.

Zitat aus der avr-libc FAQ:

"There is a -mint8 option (see Options for the C compiler avr-gcc) to make int 8 bits, but that is not supported by avr-libc and violates C standards (int must be at least 16 bits)."

Damit ist die Gans auf dem RP6 für mich leider tot.

LG Rolf