www.mikrocontroller.net

Forum: Mikrocontroller und Elektronik RTOS für Cortex-M3

Important announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Arne (Gast)
Datum: 02.07.2009 07:20

Moin zusammen,

bin momentan auf der Suche nach einem RTOS für einen Cortex-M3 (wird
sehr wahrscheinlich ein STM32F103VB - 128kB Flash/20kB SRAM). Für
Eval-Zwecke benutze ich ein EvalBoard von IAR mit einem STM32F103RB,
d.h. auch die IAR EWARM Umgebung, mit der ich äußerst zufrieden bin.
Wir (primär ich) werden also auch weiterhin diese Umgebung nutzen.
Warum RTOS? Ich möchte weg von der Superloop. Zumal das Projekt eine
vollständige Neuentwicklung ist - keine Altlasten :-D
Anwendungsgebiet: Weisse Ware.
Harte Echtzeitbedingungen haben wir keine, Temperaturen, Füllstände etc.
ändern sich nur langsam. Lediglich die ADC Ergebnisse sollen immer mit
gleichem delta-t (Zeit) vorliegen, weil ich da einen Tiefpassfilter in
Software drauf fahren werde.

So, wie sind denn Eure Erfahrungen mit RTOS (kommerziell/Freeware).
Ich hätte drei Kandidaten:
- IAR PowerPac (würden wir nur im Objektcode kaufen, weil sonst zu
teuer)
- TN-Kernel
- pC/OS

Höchstwahrscheinlich werden wir nie ein FAT-Dateisystem, USB-Stack,
TCP/IP-Stack benötigen. Das wäre der klare Vorteil von IAR.
Was ich vom RTOS erwarte, sind die "üblichen" Komponenten:
- Threads (preemptiv, Round-Robin auf gleicher Priorität nicht zwingend
notwendig)
- Pipes/Queues/Mailboxes (oder etwas in der Art für
Interprozesskommunikation)
- Semaphoren

So, ich hoffe, dass die Parameter ausreichen.

PS: auf keinen Fall CMX!


Thanx, Arne
Autor: nobody (Gast)
Datum: 02.07.2009 07:47

Gutten morgen,

wir haben vor kurzem das Rtos von Keil eingesetzt.
Dies dürfte deine Bedürfnisse befriedigen.
Allerdings ist es nicht ganz günstig. Aber ich denke es ist ja auch kein
Hobby Projekt.

Kannst es Dir ja mal auf der Webseite ansehen.

Gruß
nobody
Autor: gerhard (Gast)
Datum: 02.07.2009 07:48

>PS: auf keinen Fall CMX!
und warum nicht?

gruss
gerhard
Autor: Steffen H. (Gast)
Datum: 02.07.2009 07:53

>PS: auf keinen Fall CMX!

würde mich auch interessieren. Wir setzen CMX für Cortex jetzt schon in
zwei Geräten ein und haben absolut keine Probleme.

Also < warum > ?
Autor: nurso (Gast)
Datum: 02.07.2009 08:40

Welches RTOS sollte man bei Hoppy Projekten einsetzen?

Gruß

nurso
Autor: K. J. (theborg0815) Benutzerseite
Datum: 02.07.2009 08:43

Hi, für den Cirkle1 gibt es nen RTOS denke des wird sich anpassen
lassen.
Autor: nobody (Gast)
Datum: 02.07.2009 08:44

>Welches RTOS sollte man bei Hoppy Projekten einsetzen?
>Gruß
>nurso


Es gibt FreeRtos, da kannst Du mal nachsehen ob es für dich passt.
Autor: Random ... (thorstendb)
Datum: 02.07.2009 09:22

nobody schrieb:
> Gutten morgen,
>
> wir haben vor kurzem das Rtos von Keil eingesetzt.
> Dies dürfte deine Bedürfnisse befriedigen.
> Allerdings ist es nicht ganz günstig. Aber ich denke es ist ja auch kein
> Hobby Projekt.
>
> Kannst es Dir ja mal auf der Webseite ansehen.
>
> Gruß
> nobody

Hi,

spiele schon seit langem begeistert mit dem Keil RTOS rum. Ist "frei" in
der uVision enthalten, auch in der Demo. TCP/IP, Flash-FS etc. findet
man dann im RL-ARM Paket, dies ist allerdings extra.

Das schöne am Keil RTOS ist, das ich es ohne RTOS Vorkenntnisse
einsetzen konnte. Soll heissen, ich hatte es in ein paar mins im eigenen
Projekt am Laufen, und es nun um einen Taskmanager erweitert :-)
http://www.keil.com/rl-arm/


Dann gibt es da noch von Segger das embOS:
http://www.segger.com/embos_general.html

Sonst fallen mir da noch das µCos und eCos ein, und dann gab es da noch
eine Entwicklung von jemanden, die aus einem freien kernel heraus kommt,
und auch wieder frei ist, mir fällt aber der Name nicht mehr ein g


---
Benutzt Du den gelben IAR-jLink oder den schwarzen jLink? Bis auf den
gelben laufen alle auch im Keil uVision.


VG,
/th.
Autor: Gast (Gast)
Datum: 02.07.2009 10:14

Ganz klar RTOS von Segger. Technisch gesehen sind die einfach
Marktführer, sie verkaufen das zwar nicht immer so gut werbetechnisch
wie die Mitbewerber, aber es hat schon seinen Grund wieso z.B. das IAR
Powerpac von Segger kommt (Powerpac ist nichts anderes als die Segger
Produkte).

Gerade wenn du mit IAR Workbench arbeitest, biette dir embOS viele
Vorteile, weil IAR und Segger eng zusammenarbeiten und damit die Sache
super zusammenlaufen. Gerade z.B. das embOS plugin für IAR Workbench ist
mittlerweile einfach nur noch genial.

Und falls deine Waschmaschine doch mal TCP, USB oder nen Display
bekommt, gibts das auch alles von Segger und du du weißt das auch diese
Sachen problemlos zusammen laufen.

Ich würde dir aber auch einfach mal empfehlen die Trial Versionen bei
den Herstellern runterzuladen und die Sachen auszuprobieren, um zu
schauen womit du am besten zurecht kommst. Bei Segger kannst du sogar
soweit gehen und mit der Trial Version schon deine Entwicklung anfangen
ohne einen Euro bezahlen zu müssen, das die Trial Version nicht
funktional eingeschränkt ist.

Vorteil dabei natürlich von Keil oder Segger ist, das du deutschen
Support bekommst. Wobei ich natürlich nicht weiß, ob es bei Keil
überhaupt Support gibt, wenn es frei ist, wahrscheinlich eher nicht.
Autor: Jimmy (Gast)
Datum: 02.07.2009 10:22

embOS ist kein richtiges OS, es muss immer dazugelinkt werden, d.h es
kommt als Lib und nicht als Executable. Aber wenn Du keine nachladbare
Applikation brauchst, dann ist es gut.
Suche mal nach L4 Kernel. z.B OKLabs oder nach Pistachio
os.inf.tu-dresden.de/L4/. Da gibt es sogar freie Implementierungen.


Jimmy
Autor: Gast (Gast)
Datum: 02.07.2009 11:36

"embOS ist kein richtiges OS"

aha....und was sonst? Jane, ist klar, alles was nicht auf CD kommt und
über ein Setupprogramm installiert wird ist kein OS??

Google doch mal bitte wie ein RTOS definiert ist. Im
Mikrocontrollerbereich ist es eher unüblich (ok, auch wenn sich das mit
mehr Leistungsfähigkeit und mehr Speicher der Mikrocontroller nach und
nach ändert) seine Applikation als Executables draufzuladen. Wie soll
das auch gehen bzw. wofür soll das gut sein? Letzlich will ich in der
Produktion ein bin File in den Mikrocontroller flashen und auch bei der
Entwicklung bringt es keine Vorteile. Ein Kandidat für deine
Vorstellungen ist natürlich Linux, aber du kannst Linux nicht mit sowas
wie embOS vergleichen, schau mal wieviel Speicher Linux braucht und mit
wie wenig embOS auskommt.


"d.h es kommt als Lib und nicht als Executable."

aha, das OS deiner Wahl kommt dann als .exe?


"Aber wenn Du keine nachladbare Applikation brauchst, dann ist es gut."

Blödsinn, natürlich ist auch das mit embOS möglich, was glaubst du denn
wie das z.B. im Segger J-Link funktioniert?
Autor: Willi (Gast)
Datum: 02.07.2009 12:28

Keil RL-ARM
Ist zu Beginn etwas hakelig und es gibt wenige Hilfsmittel (zB Anzeigen
über CPU-Verbrauch und wer grade welches Mutex hat u.ä.) Kann man aber
(teilweise) nachrüsten. Sehr brauchbares und belebtes Forum, aber
Support mitunter etwas zäh.

Segger embOS
läuft rund, tolle Tools, guter Support.

Kosten tun sie halt beide was;)
gruß
Willi
Autor: Random ... (thorstendb)
Datum: 02.07.2009 13:15

> "d.h es kommt als Lib und nicht als Executable."

Wie soll ein OS für uC denn als executable kommen?

1. musst du dann alle appl. irgendwie nachladen
2. nimmt man sich idR. ein OS für einen µC, um die eigene Applikation
geschlossen mit den Vorteilen eines OS zu schreiben
3. ist der Kram für einen µC deshalb so kompakt und generisch, da die HW
Treiber nicht dabei sind. Dies wird oft auch gar nicht benötigt, bzw. je
nach Bedarf dazugebaut.

Schon mal nen Linux-Kernel gebacken? Da wählt man sich die Module aus,
die man benötigt, und compiliert das ganze zu einem kernel - nicht
anders läuft es bei einem embedded OS auch, nur dass man da Teile des
"Kernel" selbst schreibt.

Ein eigenes "komplettes" OS (woran ich in meinem Hobby z.Zt. arbeite :-)
) implementiert dann die IO layer und die "tools" selbst, oder baut sie
dazu.


Für ein embedded RTOS ist es wichtig, das es simple, klein und schnell
ist.


VG,
/th.
Autor: Gast (Gast)
Datum: 02.07.2009 17:21

"Welches RTOS sollte man bei Hoppy Projekten einsetzen?

Gruß

nurso"


embOS von Segger, Trial Versionen gibts kostenlos. Im Hobbybereich
brauchste eigentlich nicht mehr...und falls doch...naja, da gibts auch
Möglichkeiten ;-). Wüsste nicht wieso ich mich im Hobbybereich mit
irgendsoeinem Frickelkram rumschlagen sollte, soll doch schließlich Spaß
machen. Und von der Bedingung her gibts wohl nix einfacheres als embOS.
Passendes Start Projekt für deinen Compiler/CPU bzw. sogar Evalboard
runterladen, starten, und glücklich sein. Bei mir waren es keine 3 min
bis mein erstes Programm lief.
Autor: Jimmy (Gast)
Datum: 02.07.2009 23:11

@gast

wer sagt den was von .exe? Du scheinst noch nie etwas von Executables im
embedded Bereich gehört zu haben. Mit Deinem Halbwissen solltest Du
nicht so überheblich sein! Es hat schon Sinn, Applicationen nachzuladen.
Falls Du mal was dazulernen willst, schau Dir die L4-Kernels an, klein,
sicher, die Zukunft.

Nichts für ungut, aber embOS ist eben doch kein richtiges OS, eben nur
ne lib. Ich gebe Dir aber Recht, für eine Application auf nem MC
geeigent. Und wenn man Peripherie hat, kommt mit embOS ne ganze Menge
mit.

Jimmy
Autor: Steffen (Gast)
Datum: 02.07.2009 23:54

> schau Dir die L4-Kernels an, klein, sicher, die Zukunft.

LOL
Autor: Robert Teufel (robertteufel)
Datum: 03.07.2009 00:00

@nurso
schau doch mal circleOS an. Ist umsonst, hat Basisfunktionen aber
Treiber wie TCP/IP sind nicht zu erwarten.

http://www.stm32circle.com/circleos_doc/index.html

@Jimmy,

musste erst mal etwas suchen bis ich irgendeinen Hinweis gefunden hab
wieviel Speicher der sogenannte "MIKRO"kernel denn braucht. Vielleicht
hab ich ja was falsches gefunden aber das war der einzige Hinweis in dem
FAQ
---------
  What hardware does Fiasco run on?
    Fiasco runs on PCs with any x86 CPU from i486 up. A Pentium-class
CPU is recommended. Fiasco doesn't yet support SMP, although we
currently work on an SMP port.

    Fiasco can also be configured to run inside Bochs and Plex86.

    Fiasco requires !!! 2 MB RAM !!! and currently manage up to 1GB RAM.
---------
Also wer fuer einen STM32 mit 20KB RAM einen kernel mit 2MB RAM Bedarf
empfiehlt, der hat doch meines Erachtens nach gewisse Probleme mit der
Sprache. Kann mir das nicht verkneifen, der Name der Implementierung,
Fiasco, ist der Programm :-))

Wir reden von einer Implementierung auf einem abgeschlossenen System,
die 128 KB Flash und 20KB SRAM sind alles was da ist. Uebrigens kann so
ein System bei 72 MHz in Punkto Echtzeitanforderungen durchaus einen
2GHz PC schlagen, allerdings nur wenn es mit so was wie embOS, RL-ARM
oder aehnlichem laeuft.

Gruss nach D, auch an den Gast in NRW, Robert
Autor: gerhard (Gast)
Datum: 03.07.2009 09:09

@arne:
du hast steffen's und meine frage noch nicht beantwortet.
warum, nicht cmx?

danke im voraus!
gerhard
Autor: Martin Thomas (mthomas) (Moderator) Benutzerseite
Datum: 03.07.2009 17:38

ChibiOS (auf sf.net) ist noch einen Blick wert. Nicht selbst
ausprobiert. Die ""üblichen" Komponenten", CM3-Unterstützung und STM32
Beispiel sind vorhanden. Lizenz GPL+Exception, also etwas strickter als
z.B. FreeRTOS aber dank der Ausnahme für Eigenentwicklungen mit
closed-source Komponenten augenscheinlich unproblematisch.

Antwort schreiben

Die Angabe einer Email-Adresse ist freiwillig. Wenn Sie automatisch per Email über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel




Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichungen und Screenshots im PNG- oder GIF-Format hochladen.
Siehe Bildformate

Hinweis: der Originalbeitrag ist mehr als 6 Monate alt.
Mit dem Abschicken erkennst du die Nutzungsbedingungen an.

webmaster@mikrocontroller.netImpressumNutzungsbedingungenWerbung auf Mikrocontroller.net