Hallo allerseits Wer hat Erfahrungen mit ChibiOS & ChibiStudio auf STM32Fxxx im Vergleich zu anderen IDEs und RTOS (z.B. FreeRtos) http://www.chibios.org/dokuwiki/doku.php ChibiStudio scheint ein sehr gut konfiguriertes und aufgeräumtes Sorglos-Eclipse-Packet für ARM-CPUs zu sein und ChibiOS ein performantes RTOS mit guter HAL-Abstraktion und Treiberunterstützung (speziell für STM32Fxxx). Wer verwendet ChibiOs+Studio und wie sind die Erfahrungen?
habe mal kurz mit ChibiOS rumgespielt und fand es sehr gut. Vorallem hat mich der tickless mode interessiert. einziger wermutstropfen, man sollte versuchen sich an die ganzen guidelines und APIs zu halten, wenn nötig die vorhanden erweitern und nicht ein komplett anderes, eigenes Süppchen kochen. Das studio hatte ich nicht wirklich in Verwendung.
ChibiOS in seinen verschiedenen Ausprägungen verwende ich gerne. Funktioniert zuverlässig, das HAL macht wirklich HAL und heißt nicht nur so, die verschiedenen RTOS-Funktionen wie Threads, Locks, Timer, Messages,... haben mir geboten was ich gesucht hab und haben funktioniert wie sie dokumentiert waren. Das Studio habe ich mir nicht angeschaut. Ich würde die Entscheidung RTOS und IDE unabhängig voneinander treffen. RTOS halte ich dabei für die wesentlich wichtigere Entscheidung. Wenn eine IDE nicht übergriffig ist und Dinge tut, die sie nicht sollte (wie z.B. den Buildprozess monopolisieren), dann kann man die auch ohne größeren Stress später noch wechseln wenn man was besseres findet. Lies Dir als Einführung das ChibiOS-Buch durch, dort werden die verschiedenen Konzepte erklärt.
:
Bearbeitet durch User
Peter S. schrieb: > ChibiStudio scheint ein sehr gut konfiguriertes und aufgeräumtes > Sorglos-Eclipse-Packet für ARM-CPUs zu sein wenn es hautsächlich um ein Sorglos Packet geht kann ich noch mbed-os empfahlen. Für die dickeren STM32F4 das mbed-os 5, das enthält Keil RTX5. Für die kleineren F1 (oder auch Cortex-M von anderen Herstellern) ist das ältere mbed 2 besser weil sparsamer, das RTOS kann man da aber auch einfach hinzufügen. Die mbed Implementierung für die STM baut auch auf HAL/LL, Komponenten die nicht im OS enthalten sind kann man sich aus dem HAL selber dazubauen.
ChibiOS hat mir sehr gut gefallen, aber im Original-Zustand ist es nicht
zu gebrauchen, weil mehrere while(1)-Schleifen drin sind. Einen Teil
kann man umdefinieren, weil __attribute__((weak)) verwendet wird, aber
nicht alle. Man müsste also die Quellen ändern, aber das möchte man ja
vermeiden (evt. auch aus Lizenzgründen). Die mehrfach geschachtelten
#defines machen es auch nicht einfacher. ChibiOS scheint zum größeren
Teil aus #defines zu bestehen :(
Aus meinem Merkzettel von damals (es mag besser geworden sein):
vector table:
ChibiOS füllt diese auf dem Umweg über viele #defines und den Rest
mit _unhandled_exception(), was eine Endlos-Schleife ist. Die
Funktion
lässt sich im Original nicht ersetzen. Und in einer eigenen vector
table muss man die ChibiOS-Funktionen von Hand eintragen.
Beides ist nicht akzeptabel. Deshalb müsste der Loader die Adressen
von _unhandled_exception() durch unseren HardFaultHandler()
ersetzen.
Die Lösung in exception.c ist auch nicht so toll: Wenn eine ChibiOS-
Funktion dazu kommt, meldet der Linker ein doppelt definiertes
Symbol.
Wenn aber eine Funktion wegfällt, wird stillschweigend wieder die
_unhandled_exception() eingetragen.
MBED OS ist sicher interessant und umfangreich. So wie ich es sehe kann man sich ein Projekt-Gerüst mit den gewünschten Libraries in der Online-IDE zusammenstellen, ausprobieren und dann exportieren. Auf die Dauer ist die Online-IDE etwas fummelig. Aber bietet MBED auch eine IDE als lokale Installation an? (Vorzugswese für Windows und Linux)
Peter schrieb: > Aber bietet MBED auch eine IDE als lokale Installation an? (Vorzugswese > für Windows und Linux) ja, das geht mit dem mbed-cli (command line interface). Für Windows gibt es einen Installer der die Toolchain, Python und nötige Python Libs in einem Rutsch installiert. Für Linux muss man sich durch die Anleitung hangeln, ist aber auch nicht kompliziert weil nur Standard Pakete benutzt werden. Dann startet man z.B. mit dem mbed-os-blinky (für die fetteren F4/F7), https://github.com/ARMmbed/mbed-os-example-blinky auf den lokalen Rechner clonen. Der ganze Ablauf ist auf der blinky Seite beschrieben:
1 | mbed import mbed-os-example-blinky |
2 | cd mbed-os-example-blinky |
3 | mbed compile -t GCC_ARM -m DISCO_F407VG |
Der import holt den code aus dem git oder mercurial repo und fügt die Library mbde-os hinzu. Das sind einige MegaBytes weil die immer für alle Targets ist und der Download dauert etwas. Dann compiliert man z.B. den Code für ein STM Dicovery F407 oder anderes Target, eine Liste bekommt man wenn man für -m etwas ungültiges wie XX angibt. Auf der mbed Site unter Hardware sind nur die offiziellen 'mbed enabled' boards gelistet, aber man kann per mbed-cli auch andere benuzten. Z.B. das beliebte Bluepill mit dem F103. Das läuft aber besser mit dem mbed2, ein Projekt kann man so erstellen:
1 | md myProject |
2 | cd myProject |
3 | mbed new . --mbedlib |
4 | mbed add https://os.mbed.com/users/mbed_official/code/mbed-dev/ |
5 | mbed compile -m BLUEPILL_F103C8 -t GCC_ARM |
per mbed export kann man dann eine Projektconfig für seine Lieblings IDE oder für ein makefile schreiben wenn man nicht mit 'mbed compile' arbeiten möchte. Ich wollte hierzu immer mal einen Artikel ins Wiki schreiben, vielleicht fange ich am WE mal an.
um den Thread nicht zu kapern habe ich zum Thema mbed einen eigenen Thread aufgemacht, daher bitte den vorherigen Post löschen. Zum Thema mbed geht es hier weiter: Beitrag "mbed - oder es muss nicht immer Arduino sein"
Ich arbeite noch nicht allzu lange mit ChibiOS. Das ganze System dahinter gefällt mir allerdings sehr. Vor allem das interne Debugsystem, was man während der Entwicklung/Debuggen scharf schaltet, kann man gut auf eigenen Code erweitern. Basic Treiber wie ein ChibiOS-printf können problemlos in eigene Treiber erweitert werden. Hilfreich bei Chibios ist auf jeden Fall ein Hardware-Debugger, weil vieles zur Laufzeit stoppt bzw. ausgewertet wird.
Eine weitere Alternative wäre noch embOS und Embedded Studio: https://www.segger.com/products/rtos/embos/ https://www.segger.com/products/development-tools/embedded-studio/ Vorteil ist, dass man nicht auf Cortex-M beschränkt ist sondern auch Support für z.B. RISC-V hat. Wer weiß schon, was man in 3 Jahren einsetzen möchte.
Til S. schrieb: > Vorteil ist, dass man nicht auf Cortex-M beschränkt ist sondern auch > Support für z.B. RISC-V hat. ChibiOS unterstützt auch andere Architekturen wie z.B. Cortex-A, PowerPC oder AVR. Ein Vorteil von ChibiOS gegenüber embOS sehe ich hingegen in der Lizenz. ChibiOS ist dual lizenziert GPLv3 oder kommerziell, wobei es für letztere Variante in gewissem Umfang auch kostenlose Kontingente gibt. Hier ging es aber auch nicht um embOS sondern um ChibiOS. Bezüglich der IDE, also ChibiStudio stimme ich meinen Vorrednern zu. Kann man nutzen, muss man aber nicht. OS und HAL sind grundsätzlich unabhängig von jeglicher IDE.
Christopher J. schrieb: > ChibiOS unterstützt auch andere Architekturen wie z.B. Cortex-A, PowerPC > oder AVR. Danke für den Hinweis, das kannte ich noch gar nicht. Wobei bei AVR steht "Semi-official status, it will likely become official soon.". Christopher J. schrieb: > Ein Vorteil von ChibiOS gegenüber embOS sehe ich hingegen in der Lizenz. > ChibiOS ist dual lizenziert GPLv3 oder kommerziell, wobei es für > letztere Variante in gewissem Umfang auch kostenlose Kontingente gibt. Deswegen hatte ich das auch nur erwähnt. Ist aber bei embOS nicht anders. Seit Ende letzten Jahres gibt es keine technischen Limitierungen mehr in der freien Version und es kann ganz offiziell für nicht kommerzielle Projekte kostenlos eingesetzt werden. Für kommerzielle Projekte gibt es natürlich die normalen Lizenzen. Und den Support gibt es vom embOS Team für beides nicht nur in einem gewissen Umfang ;-). Ich finde ChibiOS aber definitiv ein interessantes Projekt für den Hobbybereich! Ich werde nur in diesem Leben kein Fan mehr von Eclipse ;-).
Til S. schrieb: >> Ein Vorteil von ChibiOS gegenüber embOS sehe ich hingegen in der Lizenz. >> ChibiOS ist dual lizenziert GPLv3 oder kommerziell, wobei es für >> letztere Variante in gewissem Umfang auch kostenlose Kontingente gibt. > > Deswegen hatte ich das auch nur erwähnt. Ist aber bei embOS nicht > anders. Seit Ende letzten Jahres gibt es keine technischen Limitierungen > mehr in der freien Version und es kann ganz offiziell für nicht > kommerzielle Projekte kostenlos eingesetzt werden. Also hier https://www.segger.com/products/rtos/embos/ unter "embOS RTOS—Trial, Library and Source Code" ist die kostenlose Version als "Trial" gekennzeichnet. Und da fehlt ein ganz wichtiges Häkchen bei "embOS source code". Keinen Source zu haben ist ein ganz wesentliche Einschränkung, da ich dann z.B. nicht mehr alles debuggen kann und bei Bedarf auch keine Anpassungen, Erweiterungen oder eigene Bugfixes mehr vornehmen kann. Außerdem ist natürlich nur "non-commercial use" auch eine massive Einschränkung. Projekte mit kommerziell verkaufter Hardware aber Open Source Firmware fallen damit raus. Daher finde ich den Lizenzvergleich zwischen der Segger Trial und ChibiOS GPL oder Apache ziemlich weit hergeholt. Hier sind zum Vergleich mal die License-Details von ChibiOS: http://www.chibios.org/dokuwiki/doku.php?id=chibios:licensing:start > Ich werde nur in diesem Leben kein Fan mehr von Eclipse Ein RTOS ist (hoffentlich) von einer IDE unabhängig und hat daher nichts damit zu tun ob Du Fan von Eclipse bist oder nicht.
Gerd E. schrieb: > Ein RTOS ist (hoffentlich) von einer IDE unabhängig und hat daher nichts > damit zu tun ob Du Fan von Eclipse bist oder nicht. Zumindest bei ChibiOS. Kenne embOS nicht. Nur für das Debuggen nehme ich Eclipse mit OpenOCD. Ist schön bequem. Aber auch nicht das ChibiStudio. Gibt aktuell leider keine Version für Linux und hatte auch noch keine Zeit/Lust mich damit auseinander zu setzen.
Gerd E. schrieb: > Also hier https://www.segger.com/products/rtos/embos/ > unter "embOS RTOS—Trial, Library and Source Code" ist die kostenlose > Version als "Trial" gekennzeichnet. Ja, richtig, wir hätten sie auch "Hugo" oder "Berta" nennen können aber historisch gesehen war die Version nur für die Evaluierung gedacht, daher "Trial". Ich bin aber offen für Namensvorschläge ;-). Gerd E. schrieb: > Und da fehlt ein ganz wichtiges > Häkchen bei "embOS source code". Keinen Source zu haben ist ein ganz > wesentliche Einschränkung, da ich dann z.B. nicht mehr alles debuggen > kann und bei Bedarf auch keine Anpassungen, Erweiterungen oder eigene > Bugfixes mehr vornehmen kann. Die Dateien, die du im Source Code brauchst, um Anpassungen an Hardware zu machen, sind natürlich als Source Code enthalten. Ich gebe dir soweit recht, das RTOS Source Code nice to have ist aber es ist keine wesentliche Einschränkung. Du sollst ja auch nicht das RTOS debuggen oder Bugfixe vornehmen. In dem unwahrscheinlichen Fall, das du tatsächlich ein Problem feststellst kannst du dich einfach bei uns melden und wir kümmern uns um alles weitere noch am gleichen Tag. Die Alternative heißt man hat wie bei ChibiOS oder FreeRTOS den Source Code und muss selber Bugfixe vornehmen oder darauf warten, dass die Community sich darum kümmert. Ich denke beides hat seine Vor- und Nachteile. Gerd E. schrieb: > Außerdem ist natürlich nur "non-commercial use" auch eine massive > Einschränkung. Projekte mit kommerziell verkaufter Hardware aber Open > Source Firmware fallen damit raus. Stimmt, aber das ist halt nicht unserer Zielgruppe. embOS wird entweder von Hobbyisten oder von Firmen für kommerzielle Produkte eingesetzt. Bei kommerziellen Produkten geht es um die "Total cost of ownership" und da übersteigen die Lohnkosten sehr schnell die embOS Lizenzkosten. Und für Hobbyisten ist non commercial per Definition kein Problem. Gerd E. schrieb: >> Ich werde nur in diesem Leben kein Fan mehr von Eclipse > > Ein RTOS ist (hoffentlich) von einer IDE unabhängig und hat daher nichts > damit zu tun ob Du Fan von Eclipse bist oder nicht. Ja, klar, das war auf ChibiStudio bezogen, hat natürlich nichts mit ChibiOS zu tun! Sorry, hätte ich klarer schreiben sollen.
Til S. schrieb: > Die > Alternative heißt man hat wie bei ChibiOS oder FreeRTOS den Source Code > und muss selber Bugfixe vornehmen oder darauf warten, dass die Community > sich darum kümmert. Du versuchst gerade CHibiOS in eine Bastelecke zu schieben. Das ist es aber absolut nicht. Dahinter steckt sicher nicht eine Bude wie Segger. Aber es ist kein Community-Projekt rein aus freiwilligen. Allerdings durch den offenen Quelltext sind Bugs sehr schnell ersichtlich und werden meist innerhalb von wenigen Stunden behoben.
und FreeRTOS hat ja mittlerweile auch ein paar Jahr Entwicklungszeit hinter sich und das Amazon das geschluckt hat zeugt auch von Qualität. Wettbewerb gibt es reichlich in dem Markt, und wenn Til hier Support auf kurzem Dienstweg anbietet finde ich das auch gut. Am 27.02.-01.03. ist ja wieder die embedded World in Nürnberg, wer da ernsthaftes Interesse hat kann sich die verschiedenen Kandidaten ja vorführen lassen und vergleichen.
Nico W. schrieb: > Du versuchst gerade CHibiOS in eine Bastelecke zu schieben. Das ist es > aber absolut nicht. Dahinter steckt sicher nicht eine Bude wie Segger. > Aber es ist kein Community-Projekt rein aus freiwilligen. Nö, wieso Bastlerecke? Ist doch super, dass es heutzutage so viele RTOS gibt, aus denen man wählen kann! Ich dachte nur, das es ein Community Projekt sei aber da liege ich anscheinend falsch? Ich habe auf der Webseite auf Anhieb nicht gefunden, wer dahinter steckt :-).
Til S. schrieb: > Gerd E. schrieb: >> Also hier https://www.segger.com/products/rtos/embos/ >> unter "embOS RTOS—Trial, Library and Source Code" ist die kostenlose >> Version als "Trial" gekennzeichnet. > > Ja, richtig, wir hätten sie auch "Hugo" oder "Berta" nennen können aber > historisch gesehen war die Version nur für die Evaluierung gedacht, > daher "Trial". Ich bin aber offen für Namensvorschläge ;-). Der Name wäre mir nicht so wichtig. Aber "Free" klänge dennoch besser als "Trial". > Ich gebe dir soweit recht, das RTOS Source Code nice to have ist aber es > ist keine wesentliche Einschränkung. Du sollst ja auch nicht das RTOS > debuggen oder Bugfixe vornehmen. In dem unwahrscheinlichen Fall, das du > tatsächlich ein Problem feststellst kannst du dich einfach bei uns > melden und wir kümmern uns um alles weitere noch am gleichen Tag. Bevor ich weiß ob der Bug in meinem Code ist oder im RTOS, muss ich mir das Ganze aber erst mal im Debugger ansehen. Und da finde ich es sehr sinnvoll, wenn ich da durch alles, auch die Teile des RTOS, voll durchsteppen kann und sofort sehe was da passiert. Damit ich da die Datenstrukturen und den C-Source sehe und mich nicht durch Assembler durchkämpfen muss, brauche ich den Source des RTOS. Alles andere ist für mich eine ernst zu nehmende Einschränkung. Oft ist es auch kein klarer Bug in meinem Code oder dem des RTOS, sondern einfach ein nicht voll dokumentierter Randfall oder von mir falsch verstandene Dokumentation. Ein kurzer Blick in den Source klärt das normal viel schneller als jeder Support. Und das, wenns mal notwendig sein sollte, auch spät Abends oder am Wochenende. > Bei > kommerziellen Produkten geht es um die "Total cost of ownership" und da > übersteigen die Lohnkosten sehr schnell die embOS Lizenzkosten. Sich mit dem Support bei einem Hersteller auseinanderzusetzen kostet aber auch Lohnkosten. Meine Erfahrungen bei so manchen Herstellern von Tools und Libraries sind da durchwachsen. Beim einen Hersteller funktioniert es gut, bei anderen braucht man 5x mehr Zeit sich mit dem Support rumzuschlagen und die von der Echtheit eines Bugs zu überzeugen als das kurz selbst zu fixen. Wegen solchen Erfahrungen wird bei uns in der Firma das Angewiesen sein auf Support des Herstellers als deutliches Negativkriterium eingestuft. Und solange wir die Supportqualität eines konkreten Herstellers nicht kennen, das Vorhandensein von Herstellersupport auch nicht als deutlichen TCO-Vorteil.
Gerd E. schrieb: > Der Name wäre mir nicht so wichtig. Aber "Free" klänge dennoch besser > als "Trial". Hmm...finde ich ehrlich gesagt einen guten Vorschlag! Ich werde mal darüber nachdenken. Gerd E. schrieb: > Bevor ich weiß ob der Bug in meinem Code ist oder im RTOS, muss ich mir > das Ganze aber erst mal im Debugger ansehen. Und da finde ich es sehr > sinnvoll, wenn ich da durch alles, auch die Teile des RTOS, voll > durchsteppen kann und sofort sehe was da passiert. Ja, stimmt, das kann es einfacher machen aber meine Erfahrung ist, dass viele Leute noch nicht einmal das Manual lesen und sich dann auch nicht solche Mühe machen wollen. Wir bekommen das dann als Support-Anfragen und können sehr schnell antworten das dieses oder jenes in der Applikation falsch gemacht wurde. Aber auch solche Anfragen sind recht selten weil wir durch viel Debug Code alles, was man so falsch machen kann, abfangen können. Man bekommt dann eine Fehler-Message, die einem sagt, was man falsch gemacht hat, und sieht im Call Stack, wo man es falsch gemacht hat. Gerd E. schrieb: > Sich mit dem Support bei einem Hersteller auseinanderzusetzen kostet > aber auch Lohnkosten. Aber weniger als wenn man es selber fixen muss (solange der Hersteller vernünftigen Support macht). > Meine Erfahrungen bei so manchen Herstellern von Tools und Libraries > sind da durchwachsen. Beim einen Hersteller funktioniert es gut, bei > anderen braucht man 5x mehr Zeit sich mit dem Support rumzuschlagen und > die von der Echtheit eines Bugs zu überzeugen als das kurz selbst zu > fixen. Das kann ich voll bestätigen. Mit so etwas hatte ich auch schon meinen Spaß. Ich mag es selber nicht, wenn ich Support brauche und dann tagelang auf eine Antwort warten muss. Aber gerade in dem Punkt versuchen wir uns ja zu unterscheiden und legen sehr viel Wert auf die Qualität des embOS Supports. Du bekommst den Support direkt von den embOS Entwicklern und musst dich nicht erst mit einem 1st Level Support rumschlagen. Deswegen würde ich jedem, der ein RTOS evaluiert, auch immer raten sich nicht nur die technische Seite anzuschauen sondern auch einfach mal den Support zu testen. Wie schnell bekomme ich eine Antwort? Wie kompetent war die Antwort? usw...
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.