Forum: Mikrocontroller und Digitale Elektronik Betriebssystem für 32 Bit µCs?


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.
von HAL9k (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Kann man größere µC inzwischen etwas 'abstrakter' programmieren?

So wie auf einem PC, wo man sich nicht selbst um Interrupts und Co 
kümmern muß und ich mein Programm max. neu kompilieren muß wenn ich die 
Hardware wechsel (z.B. Intel-PC ->  ARM Board)

Mit groß meine ich z.B. STM32H743ZI (2 MByte Fash, 1 MByte SRAM)

(Ja, da läuft wohl auch Linux drauf, aber für das eigentliche Programm 
ist dann nicht mehr viel Platz)

Also 'Linux in klein' mit vielen Treiber währe nett..

Beitrag #5222956 wurde von einem Moderator gelöscht.
von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
Natürlich kann man das!

Aber du darfst nicht erwarten, dass das schon jemand für dich 
schluckgerecht vorgekaut hat.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Es gibt mbed für die Cortex-M. Das ist von ARM und unterstützt nicht nur 
die fetten 2MB M4/M7, ich benutze es auch für kleine LPC812 M0 mit 16 kB 
Flash.
mbed 2 (auch mbed classic genannt) ist da platzsparender, das neuere 
mbed 5 hat ein RTOS integriert und eignet sich daher für die grösseren. 
Komponenten wie Filesystem, USB und Ethernet werden auch unterstützt.

von Rolf H. (b0d0)


Bewertung
0 lesenswert
nicht lesenswert
Eigentlich sind µC Anwendungen eine eigene Welt, die mit der "PC"-Welt 
nicht vergleichbar sind. Das fängt schon mal mit den Echt-Zeit 
Anforderungen an.

Auf µC gibt es natürlich auch Betriebssystem um portable Anwendungen zu 
schreiben. Aber da es so viele verschiedene RTOS gibt, ist das nicht 
immer einfach zu entscheiden.

Die Kriterien sind 1. um welche Anwendungen (welche Klasse von 
Anwendungen) handelt es sich und 2. welches Programmiermodell / welche 
Programmierspache wird verwendet. Mit diesen Anforderugen sucht man sich 
dann das passende, portable RTOS aus. Eventuell muss man dann noch etwas 
Geld in die Hand nehmen um div. Treiber zu bekommen.

Falls die Geld-Frage noch konnotiert ist: Nein, die kostenlose 
Eier-legenden Wollmilch-Sau ist eine Legende ;)

von MAN RTOS (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Kuckt man RTOS:
Beispiel:
https://www.freertos.org/

Es gibt mehrere.

Und nein: Linux ist keine gute Idee, weil nicht Echtzeitfähig und viel 
zu fett.

Für Linux nimmt man solche SOCs wie im Raspberry PI oder einen i.MX6.
Was eine mögliche Lösung für viele Probleme ist, mit µC hat das aber 
nichts zu tun.

von Johannes S. (jojos)


Bewertung
1 lesenswert
nicht lesenswert
Es wurde nicht expliziet nach einem RTOS gefragt, ich hatte das nur als 
eines von vielen Features von mbed angeführt.
Ein Blinky sieht das z.B. so aus:
1
DigitalOut led(LED1);
2
3
while (1)
4
{
5
    led = !led;
6
    wait_ms(100);
7
}

und das funktioniert so auf einem M0 und genauso M7, auf 
NXP/ST/Atmel/Kinetis/Nordic usw.

Das Ganze mit dem was man so für den Anfang braucht, DigitalIn/Out, SPI, 
I2C, UART usw.
Und alles Quelloffen, kostenlos und alles mit sehr offener Lizenz. Ich 
finde das ist schon sehr nah an der EWMS.

: Bearbeitet durch User
von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
MAN RTOS schrieb:
> Für Linux nimmt man solche SOCs wie im Raspberry PI oder einen i.MX6
> Was eine mögliche Lösung für viele Probleme ist, mit µC hat das aber
> nichts zu tun

Bevor man bei einem größeren 32-Bit uC mit RTOS anfängt, kann man auch 
das Pi Compute Module mit Flash mit RTOS nehmen, kein Problem mit harter 
Echtzeit. Allerdings braucht man dann zum Programmieren ein weiteres Pi 
mit Desktop, und schiebt dann das fertige Binary auf das Compute Module. 
Also wie bei uC Programmierung auch.

https://www.raspberrypi.org/documentation/hardware/computemodule/cm-emmc-flashing.md

https://www.riscosopen.org/content/downloads

von Programmiersprachentheaterintendant (Gast)


Bewertung
1 lesenswert
nicht lesenswert
HAL9k schrieb:
> Kann man größere µC inzwischen etwas 'abstrakter' programmieren?
>

Ich werfe noch eLua und EmbeddedPython und MicroPython in die 
Runde:
- <http://wiki.eluaproject.net/Boards>;
- <https://wiki.python.org/moin/EmbeddedPython>;
- <https://micropython.org/>;

Schliesslich klappt es auch eine Z80 zu emulieren und dann *CP/M* 
darauf laufen zu lassen (was dann ein leichtgewicht-BS ist weil urspr. 
mit 32kB RAM zufrieden)
- <https://www.mikrocontroller.net/articles/AVR_CP/M>;
- 
<http://www.projekte.daleske.de/prog/11_EMUZ80_RPI/prog_EMUZ80_RPI_en.htm>;

von Georg A. (georga)


Bewertung
-1 lesenswert
nicht lesenswert
eCos (http://ecos.sourceware.org/about.html) ist auch weit verbreitet 
und läuft auf fast allem, was Register hat.

von Arduino Fanboy D. (ufuf)


Bewertung
-2 lesenswert
nicht lesenswert
Ich glaube nicht, dass man noch groß über CPM reden muss.
Es ist in der Bedeutungslosigkeit versunken.

Einzig der Spieltrieb, oder das Museum, bietet dafür noch Raum.

Auch möchte er plattformneutralen/portablen Code erstellen.
Ein OS mit "allen" Treibern, ist gewünscht.

Soweit mir bekannt, wird CPM nicht mehr so dolle unterstützt.
Frische Treiber (kennt CPM das überhaupt?) wirds nicht geben.

von Programmiersprachentheaterintendant (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Auch möchte er plattformneutralen/portablen Code erstellen.
> Ein OS mit "allen" Treibern, ist gewünscht.

Also doch eLua & Python.

> Also 'Linux in klein' mit vielen Treiber währe nett..

Hat man mal ein Linuxkern (inkl. der endlichen, kleinen Anzahl an 
Treiber f. eine gegebene Embedded-Plattform) und z.B. busybox, ist 
also der Käse gegessen: ob man seine eigene Anwendung dann in das 
busybox Binary integriert oder als eigenständige Datei hält ist nicht 
mehr entscheidend.

NB: siehe auch noch  bitlash f. Arduino)

von Programmiersprachentheaterintendant (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ach was: da kommt ja noch FORTH hinzu, zur Vollständigkeit der 
Diskussion!

von chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>NB: siehe auch noch  bitlash f. Arduino)

https://playground.arduino.cc/Code/Bitlash

Hast Du es schon mal benutzt?

von uuu (Gast)


Bewertung
-5 lesenswert
nicht lesenswert
Ein kleines kompaktes Linux waere CentOS. Aber irgendwer wird's 
portieren und konfigurieren muessen.

Irgendwann sollte man dann doch rausruecken was die Anforderungen sind.

von Bernd K. (prof7bit)


Bewertung
-1 lesenswert
nicht lesenswert
uuu schrieb:
> Ein kleines kompaktes Linux waere CentOS. Aber irgendwer wird's
> portieren und konfigurieren muessen.

Für embedded Linux Geschichten nimmt man eher so frei konfigurierbare 
Meta-Distributionen aus der Yocto/Poky/Openembedded Ecke, wenn der 
Hersteller des Moduls was taugt liefert er dafür auch schon die 
passenden BSP-Layer so daß gleich alles mehr oder minder stressfrei 
funktioniert.

Aber für so kleine Microcontroller wie vom Threaderöffner gefragt würd 
ich nicht unbedingt Linux verwenden wollen.

: Bearbeitet durch User
von Christopher J. (christopher_j23)


Bewertung
1 lesenswert
nicht lesenswert
HAL9k schrieb:
> Also 'Linux in klein' mit vielen Treiber währe nett..

Das was dem meiner Meinung nach sehr nahe kommt ist Nuttx 
(http://nuttx.org/).
Läuft auf verschiedensten Architekturen, von Z80 über AVR bis zu Pic32, 
Cortex-M und sogar Cortex-A. Dabei passt es durchaus in weniger als 64kB 
Flash, inkl. Shell und Pseudo-FS. Treiber gibt es sowohl für USB, als 
auch für Netzwerk, verschiedene Dateisysteme, etc. Man hat darüber 
hinaus die Wahl, ob man Kernel und Applikation zusammen in eine Binary 
linkt oder ob man es trennt. Bei letzterem ist es dann schon fast wie am 
PC. Man kann das OS drauf lassen und lediglich die Binary des Programms 
tauschen.

von Ben W. (ben_w)


Bewertung
-1 lesenswert
nicht lesenswert
warum alleine nur auf RTOS begrenzen?
es gibt ja noch Java für den Cortex-m3, m4, m7
python, javascript, micro .net.

aber heutzutage würde ich auch eher einen SoC empfehlen, z.B. den Nano 
pi duo, 7$ und breadboard friendly ...

von Programmiersprachentheaterintendant (Gast)


Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
>>NB: siehe auch noch  bitlash f. Arduino)
>
> https://playground.arduino.cc/Code/Bitlash
>
> Hast Du es schon mal benutzt?

Ja!
Funktioniert erfrischend straightforward für improvisierte Sachen, 
wenn man sonst des öfters auf Bash/BusyBox rumturnt um 
Entwicklungsabläufe bei Embeddedsysteme zu Automatisieren.
Da ich nicht in der SPS-Welt Zuhause bin, hat mir Bitlash als 
Billigersatz hergehalten (natürlich nur auf TTL-Ebene).

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
HAL9k schrieb:
> Kann man größere µC inzwischen etwas 'abstrakter' programmieren?
>
> So wie auf einem PC, wo man sich nicht selbst um Interrupts und Co
> kümmern muß und ich mein Programm max. neu kompilieren muß wenn ich die
> Hardware wechsel

Ja, man kann - aber erstmal selber machen. Dazu muß man sich aber ein 
wenig Mühe geben, um die verschiedenen Ebenen sauber voneinander zu 
trennen und um auch ein sauberes, potentes und erweiterungsfähiges API 
zu definieren.

Ich hatte vor Jahren dieses mit der Lernbetty durchgeturnt. Da gab es 
eine BettyBase, die sozusagen das kleine OS dargestellt hatte und die 
diverse Dienste per API bereitgestellt hat. Zum Beispiel gepuffertes I/O 
zu diversen UART's, ein GDI zum Benutzen des grafischen Displays, eine 
Systemuhr, Konvertierungen, und so weiter.

Die Anwendungen haben diese Dienste per SVC angesprochen und somit waren 
Anwendungen und Base sauber voneinander getrennt, so daß sie völlig 
separat compiliert werden konnten.

Das Blöde ist nur, daß der GCC keinerlei SVC's beherrscht, weswegen man 
für den GCC extra noch ein Assembler-Interface basteln mußte. Der Keil 
kann SVC's richtig gut und macht damit einen sehr kompakten Code. Nun 
gut, die Lernbetty war ein ARM7TDMI und mit den heutigen Cortexen ist 
das alles ein wenig entspannter.

W.S.

von Uwe D. (monkye)


Bewertung
0 lesenswert
nicht lesenswert
Guckst Du mal hier: https://mongoose-os.com/

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
> es gibt ja noch Java... python, javascript, micro .net.

Das sind keine Betriebssysteme, sondern Programmiersprachen

von chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Das sind keine Betriebssysteme, sondern Programmiersprachen

So gesehen kann ein Computer ohne Betriebssystem funktionieren. Hatte 
der C64 ein Betriebssystem?
Micropython: Filesystem? Multitasking?

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
> So gesehen kann ein Computer ohne Betriebssystem funktionieren

Ja natürlich.

von Alex G. (dragongamer)


Bewertung
0 lesenswert
nicht lesenswert
Kommt ein wenig auf die Definition von "Computer" an.
Wenn man darunter den modernen Begriff eines vielseitigen Arbeits- und 
Unterhaltungsgerät meint, dann eher nicht.
Wenn man alles drunter fasst was programmiert Berechnungen ausführen 
kan, dann natürlich.

: Bearbeitet durch User
von chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Wenn man darunter den modernen Begriff eines vielseitigen Arbeits- und
>Unterhaltungsgerät meint, dann eher nicht.

Ob der TO wohl ein vielseitiges Arbeits- und Unterhaltungsgerät bauen 
will?

von Adam P. (adamap)


Bewertung
0 lesenswert
nicht lesenswert
Guten Abend zusammen,

ich klink mich mal ein, da ich auch schon seit längerem 
überlege/nachlese und mit dem Gedanken spiele ein RTOS einzusetzen 
(auszuprobieren).

Habe mir Bsp. von FreeRTOS (Atmel) angesehen und jetzt Nuttx, da es hier 
erwähnt wurde und ich es nocht nicht gehört habe.

Bei Nuttx finde ich die Unix ähnlichkeit sehr gut.

Gibt es nun markante Gründe lieber das RTOS X anstatt RTOS Y oder Z zu 
nutzen oder ist das reine Geschmackssache.

Im Moment laufen unsere Geräte ohne OS, ob nun ein RTOS notwendig ist, 
müsste man abschätzen, jedoch hat es schon seine "Annehmlichkeiten".

Wenn es möglich ist, würde ich ungerne mehrere RTOS ausprobieren um dann 
vllt. festzustellen, dass das erste am besten wäre - außer: es geht 
nicht anders, dann werde ich nicht drum herum kommen.

Die Auswahl ist nämlich echt nicht klein an verfügbaren RTOS.

Gruß

: Bearbeitet durch User
von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Adam P. schrieb:
> ich klink mich mal ein, da ich auch schon seit längerem
> überlege/nachlese und mit dem Gedanken spiele ein RTOS einzusetzen
> (auszuprobieren).

Frage dich lieber, WOZU du sowas benötigst.

Brauchst du zwingend einen Scheduler mit Multitasking (preemptiv oder 
nicht)?

Oder brauchst du eher eine Verwaltung der diversen Peripherie, wie 
gepufferte serielle Kanäle, Displayansteuerung, Tastenverwaltung, 
Filesystem, Systemuhr, Konvertierungen und dergleichen?

W.S.

von Adam P. (adamap)


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Brauchst du zwingend einen Scheduler mit Multitasking (preemptiv oder
> nicht)?
>
> Oder brauchst du eher eine Verwaltung der diversen Peripherie, wie
> gepufferte serielle Kanäle, Displayansteuerung, Tastenverwaltung,
> Filesystem, Systemuhr, Konvertierungen und dergleichen?

1. Ja, ein Multitasking benötige ich. Präemptiv würde auf meine 1ms 
Tasks treffen, denn diese müssen ausgeführt werden um die ADC Daten zu 
sampeln.

2. Die Verwaltung der Peripherie ist soweit kein Problem, aber besser 
geht immer.

3. Ich würde es auch einfach nur gern mal lernen / ausprobieren und im 
Wissen nicht stehen bleiben wollen...ich finde das ist schon Grund 
genug, dass ich es "brauche".

von A. S. (achs)


Bewertung
1 lesenswert
nicht lesenswert
Adam P. schrieb:
> Präemptiv würde auf meine 1ms
> Tasks treffen, denn diese müssen ausgeführt werden um die ADC Daten zu
> sampeln.

Interrupts?

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
Zu 1:
Oftmals kann der ADC von einem Timer getriggert werden.
Das braucht dann keine Task.


Mein Tipp:
Schöpfe erstmal aus, was kooperativ geht.

Preemptives Multitasking ist erheblich RAM fressender.
Alleine schon die Taskkontrollblöcke, und die Stackframes, schlagen da 
derbe zu Buche.

Auf kleinen µC will man das nicht.
Kann man das meist nicht.

: Bearbeitet durch User
von Adam P. (adamap)


Bewertung
0 lesenswert
nicht lesenswert
Arduino F. schrieb:
> Oftmals kann der ADC von einem Timer getriggert werden.
> Das braucht dann keine Task.

Es sind die internen ADC sowie 3 externe ADS1299 über SPI.

Und noch vieles mehr muss da ablaufen.
- interne ADC
- externe ADC über SPI DMA
- Daten zusammenfassen
- Daten in Buffer schieben
- Daten auf SD sichern
- Daten per USB / WLAN versenden


Ja ich versteh eure Gedanken und Einwände.

Es läuft auch alles wie es soll, mit Interrupts und SysTick und Timern.
Ich wollte/will einfach nur dazu lernen.

Ein OS/RTOS kennenlernen und vllt. auch wenn es nur dazu dient, dass ich 
Ideen übernehme, was die Abstraktion der Hardware betrifft.

Mein System läuft...
Wollte einfach nur mal vllt. testen wie es mit einem RTOS wäre.
Wo halt einige Dinge bestimmt besser gelöst wurden.

Derzeit wird der SAM4E eingesetzt, so wenig RAM hat der nun auch nicht.

Mein Ansporn war es, Infos zu erhalten, ob sich das eine oder andere 
RTOS eher lohnt (um sich einzuarbeiten)... nicht ob es ohne geht und ob 
ich eins benötige.

Ich bin wissbegierig und mehr nicht, will einfach nur was neues 
ausprobieren und Designfehler meinerseits erkennen...

von Lothar (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Adam P. schrieb:
> Multitasking benötige ich. Präemptiv

Dafür bekommst Du dann Race-Conditions, Starvation, keine harte 
Echtzeit, Priority-Inversion und Ausreden vom RTOS Lieferant:

https://space.stackexchange.com/questions/9178/how-did-nasa-remotely-fix-the-code-on-the-mars-pathfinder

von Adam P. (adamap)


Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> Dafür bekommst Du dann Race-Conditions, Starvation, keine harte
> Echtzeit, Priority-Inversion und Ausreden vom RTOS Lieferant:

Also ja...guter Einwand...aber dann frage ich mich echt:

Wenn man doch alles mit Timern und IRQ regeln kann,
wozu dann der Aufwand mit einem RTOS in einer Firmware
die eh nur auf ein Device mit fixer Funktion programmiert wird?

Leuchtet mir nicht ganz ein.

von Abdul K. (ehydra) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Ist halt wie mit der bevorzugten Biersorte. Es gibt schlicht keine 
allgemeine Antwort drauf. Vor allem aus dem Grund das der einzelne noch 
nie alles Sorten probierte.

von Adam P. (adamap)


Bewertung
0 lesenswert
nicht lesenswert
Also wären wir wieder bei dem Punkt:

Lieber selber schreiben (programmieren) und man(n) weiß, dass es 
funktioniert wie es soll aufs System zugeschnitten.

Aber das kann es doch irgendwie nicht sein - immer das Rad neu erfinden.

von Abdul K. (ehydra) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ich kann nur für mich sprechen. Es ist okay, wenn man sich mal andere 
Konzepte ansieht und manchmal was draus lernt. Aber selber proggen ist 
definitiv einfacher als sich in die Denkweise anderer 
Programme/Programmierer reinzuverstehen. Zumindest ich brauch dafür 
einfach zu lang.

(Arbeite aber auch immer alleine)

von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Adam P. schrieb:
> wozu dann der Aufwand mit einem RTOS in einer Firmware

Zunächst mal kommt ein gutes RTOS mit einem geprüften Kernel bzw. HAL 
mit standardisiertem API und hat deutlich weniger Bugs als eine 
Hersteller Library und läuft zudem im Supervisor-Mode. Selbst wenn man 
damit eine Regelung mit Super-Loop ganz ohne Interrupts im User-Mode 
macht ist das sicherer.

von (prx) A. K. (prx)


Bewertung
5 lesenswert
nicht lesenswert
Adam P. schrieb:
> Wenn man doch alles mit Timern und IRQ regeln kann,
> wozu dann der Aufwand mit einem RTOS in einer Firmware
> die eh nur auf ein Device mit fixer Funktion programmiert wird?

Programmierung ohne RTOS läuft bei grösseren Aufgaben gerne auf etliche 
state machines, interrupt handler und timer handler hinaus, auf die sich 
die Aufgaben häppchenweise verzetteln. Ohne gut gepflegte Doku neigen 
solche Konglomerate zum write only programming sobald jemand anderes 
dran sitzt als derjenige, der das Design im Kopf hat. Denn man hat eine 
grössere Schachtel von Codefetzen vor sich, aus denen man nicht wirklich 
leicht erkennt, in welcher Ordnung sie ausgeführt werden und miteinander 
zusammenhängen.

Demgegenüber sind Abläufe in RTOS Tasks wesentlich leichter erkennbar. 
Aus den vielen Codefetzen werden wenige Threads in konventioneller 
strukturierter Programmierung. Wird irgendwo auf ein Ereignis oder den 
Ablauf einer Zeit gewartet, dann steht das an im Quelltext genau dieser 
Stelle drin und danach geht es direkt weiter. Ohne RTOS sind das 2 
getrennte Codefetzen, einer davor, einer danach.

: Bearbeitet durch User
von Lothar (Gast)


Bewertung
-5 lesenswert
nicht lesenswert
A. K. schrieb:
> Ohne RTOS sind das 2 getrennte Codefetzen, einer davor, einer danach

Ohne RTOS bekommt jeder "Codefetzen" seine eigene Datei mit Header mit 
Parameterdefinition, Abhängigkeiten und Doku. Eventuell wurde sogar die 
Terminiertheit vorher auf Papier skizziert :-)

> Demgegenüber sind Abläufe in RTOS Tasks wesentlich leichter erkennbar

Wenn RTOS eingesetzt wird, kommt meist ohnehin alles von der 
automatischen Code Generierung ...

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Da es Dir primär darum geht, etwas dazu zu lernen könntest du einen 
ESP8266 mit dem RTOS SDK programmieren. Dann hast du schon eine 
halbfertige Anwendung vom Hersteller, der du deine eigenen Tasks 
hinzufügst.

von Markus (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Lothar
>Dafür bekommst Du dann Race-Conditions, Starvation, keine harte
>Echtzeit, Priority-Inversion und Ausreden vom RTOS Lieferant:
https://space.stackexchange.com/questions/9178/how-did-nasa-remotely-fix-the-code-on-the-mars-pathfinder

Also am besten gefällt mir dieser Ausschnitt aus der Antwort was für 
Soft- und Hardware ein Marsrover eingebaut hat:

" (Sojourner rover that Pathfinder deployed used a custom cyclic 
executive OS not too unlike today's Arduino platform, Curiosity uses 
RAD750 PowerPC,...). "

Die Antworten scheinen wissenschaftlich fundiert mit Quellenverweisen.

Meine persönliche Philosphie: Multitaskingsysteme vernebeln den Blick 
auf die Systemarchitektur und führen zu den erwähnten Problemen. Deshalb 
sind sie nach Möglichkeit so lange zu vermeiden wie es geht.

Adam P. (adamap)
>Ich bin wissbegierig und mehr nicht, will einfach nur was neues
>ausprobieren und Designfehler meinerseits erkennen...

Das finde nachvollziehbar. Es ist immer gut, mal andere Softwaresysteme 
auszuprobieren. Es steckt meist überall etwas drinnen, was man lernen 
kann.

von Alex G. (dragongamer)


Bewertung
1 lesenswert
nicht lesenswert
Adam P. schrieb:
> Lieber selber schreiben (programmieren) und man(n) weiß, dass es
> funktioniert wie es soll aufs System zugeschnitten.
Im Prinzip ja, aber man muss auch wissen was exakt man tut bzw. vorallem 
muss man wissen was das gesamte Programm tut.

Wenn man mit einem OS und Threads arbeitet muss man gewiss einige Dinge 
beachten, aber diese sind relativ gut abgesteckt.
Der große Vorteil ist eben dass man viel individuellere Code-Stücke 
entwickeln kann, die für sich arbeiten.
Das ist nicht zuletzt dann extrem hilfreich wenn mehrere Entwickler, an 
einem Projekt arbeiten.

Adam P. schrieb:
> Aber das kann es doch irgendwie nicht sein - immer das Rad neu erfinden.
Das ist in der tat der Fall wenn man so spezifiziert für den 
Mikrocontroler entwickelt und das maximumim an Optimierung rausholen 
will.
Auf die Projektgröße kommt es an. Im Hobbybereich kommt man sicher gut 
mit der nativen Lösung zurecht.

Es ist aber verständlich dass man beim Mars Rover eine andere Route 
eingeschlagen ist. Man hat es vieleicht bereut, aber wer weiss ob ein 
anderer Ansatz wirklich bugfrei geworden wäre?
Projekte solcher Größenordnungen sind leider fast nie bugfrei, egal wie 
man es macht...
Das wird sich erst ändern sobald wir KIs mitschicken welche den Code 
selbst ändern können :D

Bis dahin kann man halt nur selbst lernen und versuchen nicht die Fehler 
der Vergangenheit zu wiederholen. Leider bringt auch jedes Projekt neue 
Elemente mit sich die das Risiko wieder erhöhen.

Markus schrieb:
> " (Sojourner rover that Pathfinder deployed used a custom cyclic
> executive OS not too unlike today's Arduino platform, Curiosity uses
> RAD750 PowerPC,...). "
Was hat die CPU mit dem OS genau zutun?

: Bearbeitet durch User
von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
Alex G. schrieb:
> Was hat die CPU mit dem OS genau zutun?

Viel!
(würde ich mal sagen)

z.B. der Protected Mode des 80286 war so ein Quantensprung im PC 
Bereich.
Das hat die Möglichkeit geschaffen, dass sich Prozesse/Tasks nicht mehr 
gegenseitig in den Speicher spucken können.

Bei meinen AVR Zwergen, ist es egal, ob Rtos, oder nicht.
Da kann ein verirrter Zeiger das Ganze ruinieren.

: Bearbeitet durch User
von Til S. (Firma: SEGGER) (til_s)


Bewertung
0 lesenswert
nicht lesenswert
MAN RTOS schrieb:
> Kuckt man RTOS:
> Beispiel:
> https://www.freertos.org/

Anstatt FreeRTOS würde ich embOS empfehlen (hach wie überraschend, wenn 
ich mein Geld damit verdiene ;-) ). 
https://www.segger.com/products/rtos/embos/

Es ist für den nicht kommerziellen Einsatz genauso frei wie FreeRTOS 
aber hat den Vorteil, das es kommerziell entwickelt wird.
Ob man jetzt generell ein RTOS einsetzen möchte hängt von der 
Applikation ab. Wer aber einfach mal mit einem RTOS rumspielen möchte, 
dem kann ich die folgenden Links empfehlen:
https://www.segger.com/downloads/embos/UM01001
https://www.segger.com/downloads/embos/embOS_CortexM_EmbeddedStudio_Trial
https://www.segger.com/products/development-tools/embedded-studio/

Weiterer Vorteil:
Bei Fragen könnt ihr euch direkt an mich wenden ;-). Entweder hier oder 
einfach per Email (Support Emailadresse steht in dem User Manual).

von Christopher J. (christopher_j23)


Bewertung
9 lesenswert
nicht lesenswert
Adam P. schrieb:
> Mein Ansporn war es, Infos zu erhalten, ob sich das eine oder andere
> RTOS eher lohnt (um sich einzuarbeiten)... nicht ob es ohne geht und ob
> ich eins benötige.
>
> Ich bin wissbegierig und mehr nicht, will einfach nur was neues
> ausprobieren und Designfehler meinerseits erkennen...

Hier mal eine Kurzzusammenfassung von den RTOSen welche ich bisher 
selber mal benutzt habe:

Nuttx:
+ quasi POSIX-konform
+ sehr gut integrierte Netzwerk- und Dateisystemtreiber
+ bringt direkt eine Shell mit
+ läuft auf verschiedensten Architekturen (auch Hardware-Treiber)
+ für die gelieferte Funktionalität relativ kompakt
+ richtiger tickless-Betrieb möglich
+ komplett BSD-lizenziert
= Doku ist gut aber nicht so mächtig wie Nuttx selbst
- aufwendige Treiberentwicklung
- absolut gesehen nicht gerade schlank (>= 32kB Flash minimum)
- erfordert relativ viel Einarbeitung (umso mehr, wenn keine 
Unix-Erfahrung vorhanden)

ChibiOS RT/NIL:
+ sehr schlank (NIL läuft problemlos mit 16kB Flash und 4kB RAM)
+ sehr schnell
+ läuft auf verschiedenen Architekturen
+ HAL ist schlank und schnell und sehr gut mit OS integriert
+ richtiger tickless-Betrieb möglich
+ simple Shell ist vorhanden (wenn auch nicht vergleichbar mit NSH)
= Doku ist sehr detailliert aber nicht gerade für RTOS-Einsteiger 
geeignet
= Netzwerk- und FS-Treiber vorhanden aber eher halbherzig integriert
= dual GPLv3/kommerziell lizensiert
- HAL nur für STM32 komplett

Keil RTX/ mbed-OS
+ als Teil von mbed Einrichtungsaufwand ~0
+ mbed HAL läuft auf sehr vielen MCUs
+ FS- und Netzwerktreiber vorhanden
+ BTLE-Stack vorhanden
+ Apache lizensiert
+ sehr einsteigerfreundliche Doku des OS
+- tickless-Betrieb (aber erst seit v5.6)
- Doku nicht sehr detailliert
- läuft nur auf ARM
- für die gelieferte Funktionalität sehr fett, benötigt viel RAM

FreeRTOS
+ läuft quasi überall
+ Lizenz GPL mit static linking exception
+ sehr gute Doku in Form eines Buches von Richard Barry (mittlerweile 
kostenlos)
+- Integration von FS und Netzwerk (gibt es glaube ich mittlerweile aber 
nur im Betastadium)
- alles wird dynamisch alloziert
- keine HAL-Integration
- kein "richtiger" tickless-Betrieb

Es gibt garantiert hundert Dinge die ich hier nicht berücksichtigt habe, 
z.B. den (professionellen) Support, den Bus-Faktor, etc. Ich würde 
allgemein einfach vorschlagen sich die verschiedenen Systeme mal 
anzusehen und damit meine ich auch die, die ich hier nicht gelistet 
habe. Dümmer wird man davon sicherlich nicht und die Grundkonzepte sind 
ohnehin immer gleich ("Kennt man eines kennt man alle"). Ist man ohnehin 
mit einem ARM unterwegs empfiehlt sich ein Blick auf mbed samt RTOS, 
weil das mit gefühlt drei Klicks auf einem Dev-Board läuft. Für Doku 
siehe https://os.mbed.com/docs/latest/reference/rtos-api.html. Ansonsten 
finde ich auch FreeRTOS zum Einstieg nicht schlecht, weil die 
Wahrscheinlichkeit, dass es den MCU unterstützt, den man kennt bzw. den 
man benutzen möchte, sehr groß ist. FreeRTOS läuft natürlich auch auf 
jedem Cortex-M und die Doku von Richard Barry finde ich sehr 
einsteigerfreundlich 
(https://www.freertos.org/Documentation/161204_Mastering_the_FreeRTOS_Real_Time_Kernel-A_Hands-On_Tutorial_Guide.pdf).

Meine persönlichen Favoriten in der Liste sind aber ganz klar Nuttx und 
ChibiOS. Die eierlegende Wollmilchsau gibt es natürlich nicht und beide 
sind quasi komplett verschieden. Nuttx ist eher groß und mächtig, dafür 
nicht so schnell und ChibiOS ist klein und flink, dafür nicht so 
mächtig. Als bestes Beispiel für die unterschiedliche Verwendung der 
beiden Systeme dient das Pixhawk-Projekt von der ETHZ. Der 
Flightcontroller hat (unter anderem) Nuttx als Unterbau 
(https://github.com/PX4/Firmware), während der Pixhawk-ESC mit ChibiOS 
läuft (im Übrigen wie der VESC: https://github.com/vedderb/bldc).

Lothar schrieb:
> Adam P. schrieb:
>> Multitasking benötige ich. Präemptiv
>
> Dafür bekommst Du dann Race-Conditions, Starvation, keine harte
> Echtzeit, Priority-Inversion und Ausreden vom RTOS Lieferant:
>
> 
https://space.stackexchange.com/questions/9178/how-did-nasa-remotely-fix-the-code-on-the-mars-pathfinder

Um diese ganzen "Schmankerl" zu bekommen braucht man kein RTOS. 
Race-Conditions bekommt man ganz allgemein mit Interrupts. Starvation, 
sowie Priority-Inversion gibt es dann mit Interrupts unterschiedlicher 
Priorität gratis dazu. Im Gegenteil gibt es bei jedem vernünftigen RTOS 
Priority-Inheritance, was einen Deadlock verhindern kann. Durch 
geschicktes Design kann man auch das Starvation-Problem damit 
eliminieren. Das Problem mit der "harten Echtzeit" (wie auch immer man 
das definiert) lasse ich zum Teil gelten aber man hat normalerweise 
immer die Möglichkeit einen Interrupt "am OS vorbei" laufen zu lassen, 
selbst wenn das OS per Design (z.B. wegen Hardware-Treibern) 
normalerweise alle Interrupts bedient (z.B. Nuttx oder ChibiOS). Das 
Beispiel mit dem ESC zeigt, dass "harte Echtzeit" auch mit OS machbar 
ist. Jedenfalls so "hart", dass es für einen ESC reicht.

von Adam P. (adamap)


Bewertung
0 lesenswert
nicht lesenswert
Christopher J. schrieb:
> Hier mal eine Kurzzusammenfassung von den RTOSen welche ich bisher
> selber mal benutzt habe:

Vielen Dank für diesen ausführlichen Einblick.
Genau so einen kleinen "Aufhänger" habe ich gesucht, DANKE!

von Christian (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Christopher J. schrieb:
> FreeRTOS
> ...
> - alles wird dynamisch alloziert

Das ist mittlerweile zum Glück nicht mehr so.
https://www.freertos.org/Static_Vs_Dynamic_Memory_Allocation.html

von XC68000 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Christopher J. schrieb:
> ChibiOS RT/NIL:
..
> + sehr schnell

Was ist denn eigentlich hier schnell und langsam?

So eine Cortex MCU braucht ja so ~20 Zyklen bis der Interrupt-Code 
ausgeführt wird.

Bei 200 MHz sind das 100 ns (+Wait-states?)

Wieviele Zyklen genemigt sich das nuttx/ChibiOS wenn ich den Interrupt 
nicht direkt selbst bediene, und somit die OS-Funktionen nutzen darf?

von Adam P. (adamap)


Bewertung
0 lesenswert
nicht lesenswert
Christopher J. schrieb:
> Hier mal eine Kurzzusammenfassung von den RTOSen welche ich bisher
> selber mal benutzt habe:

Nuttx hatte ich mir vorgestern/gestern mal genauer angeschaut, jedoch 
hat es da bereits beim "make menuconfig" irgendwelche Fehler geworfen.

Habe mit "./tools/configure.sh sam4e-ek/nsh" die Konfig. erstellt.
Dann ein "make menuconfig" versucht und folgendes bekommen:
1
parusel@vbox-ap ~/ARM/Nuttx/nuttx-7.22 $ make menuconfig
2
LN: include/arch/board to /home/parusel/ARM/Nuttx/nuttx-7.22/configs/sam4e-ek/include
3
LN: arch/arm/src/board to /home/parusel/ARM/Nuttx/nuttx-7.22/configs/sam4e-ek/src
4
make[1]: Entering directory '/home/parusel/ARM/Nuttx/nuttx-7.22/configs'
5
make[1]: Nothing to be done for 'dirlinks'.
6
make[1]: Leaving directory '/home/parusel/ARM/Nuttx/nuttx-7.22/configs'
7
make: the '-C' option requires a non-empty string argument
8
make: *** Eine leere Zeichenkette ist als Dateiname ungültig.  Schluss.
9
Makefile.unix:331: recipe for target 'dirlinks' failed
10
make: *** [dirlinks] Error 2

Leider habe ich dazu nichts im Inet gefunden.

---
Und bei FreeRTOS, da kann ich mich irgendwie nicht mit dem "camelcase" 
anfreunden :-D
---

Hoffe mir kann einer bzgl. dem Nuttx Problem behilflich sein.

---
Edit:
Habe dafür lieber einen neuen Beitrag eröffnet:

Beitrag "Nuttx: "make menuconfig" Fehler"

: Bearbeitet durch User
von Christopher J. (christopher_j23)


Bewertung
1 lesenswert
nicht lesenswert
XC68000 schrieb:
> Christopher J. schrieb:
>> ChibiOS RT/NIL:
> ..
>> + sehr schnell
>
> Was ist denn eigentlich hier schnell und langsam?
>
> So eine Cortex MCU braucht ja so ~20 Zyklen bis der Interrupt-Code
> ausgeführt wird.
>
> Bei 200 MHz sind das 100 ns (+Wait-states?)
>
> Wieviele Zyklen genemigt sich das nuttx/ChibiOS wenn ich den Interrupt
> nicht direkt selbst bediene, und somit die OS-Funktionen nutzen darf?

Bei einem F407 mit 168MHz liegt die Zeit für einen context-switch bei 
~390ns, d.h. etwa 66 Zyklen (Quelle: 
http://www.chibios.com/forum/viewtopic.php?t=2745). Bei Nuttx habe ich 
keine genauen Zahlen aber ich meine wir reden hier von ~2µs, eventuell 
etwas mehr oder weniger 
(http://thread.gmane.org/gmane.comp.embedded.nuttx/8365 bzw. 
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.706.4565&rep=rep1&type=pdf). 
Solche Angaben sind natürlich immer mit großer Vorsicht zu genießen, 
damit man nicht Äpfel mit Autos vergleicht und wenn man es wirklich 
"schnell" haben will, dann lotst man den Interrupt halt einfach komplett 
am OS vorbei, macht das was dringend erledigt werden muss und 
synchronisiert danach erst mit dem OS. Außerdem sieht man an dem ChibiOS 
Benchmark sehr schön, was sonstige Parameter für einen Einfluss haben. 
Ein STM32F7 mit 216MHz erledigt den context-switch in 217ns, einfach 
weil der besseres Flash-prefetching hat. Auf der Seite von Segger wird 
gar der Code direkt aus dem RAM ausgeführt 
(https://www.segger.com/products/rtos/embos/technology/performance/) 
aber immerhin schreiben sie es dazu.

Das was ich an ChibiOS so sehr schätze ist aber weniger die 
Interrupt-Latenz, als viel mehr der wirklich sehr kompakte Code und die 
nähe zur Hardware. Man hat da definitiv auch als einzelne Person noch 
die Chance jede einzelne Zeile Quelltext zu verstehen, die man sich da 
herein holt und der HAL ist auch eher "low-level" aber dafür ist man 
dann auch viel flexibler als beispielsweise bei Nuttx.


Edit:
Christian schrieb:
> Christopher J. schrieb:
>> FreeRTOS
>> ...
>> - alles wird dynamisch alloziert
>
> Das ist mittlerweile zum Glück nicht mehr so.
> https://www.freertos.org/Static_Vs_Dynamic_Memory_Allocation.html

Wusste ich noch nicht aber für mich sind das wirklich gute Nachrichten. 
Die ganze dynamische Speicherverwaltung war für mich persönlich immer 
ein Hauptargument gegen FreeRTOS.

: Bearbeitet durch User
von Mehmet K. (mkmk)


Bewertung
0 lesenswert
nicht lesenswert
Was ich früher sehr gerne benutzt habe war scmRtos. Sehr schlank und man 
hat sofort ein Aha-Erlebnis.
http://scmrtos.sourceforge.net/ScmRTOS
Diese Seite wird sehr halbherzig gepflegt und es existiert nur ein 
russisches Forum. Z.Zt. ist 5.1.0 released
https://github.com/scmrtos/scmrtos/releases

Weil die Weiterentwickling eine zeitlang völlig zum Erliegen gekommen 
war, bin ich auf CMSIS RTX umgestiegen. Dort war es aber (solange man 
nicht die Keil-IDE benutzte) sehr schwierig, den Stack der einzelnen 
Threads im Auge zubehalten.

Zur Zeit evaluiere ich Crossworks, der gleich ein RTOS onboard hat.
http://www.rowley.co.uk/arm/
Macht bis anhin einen sehr guten Eindruck. Und auch die Preise sind 
durchaus akzeptabel.
(Aber natürlich kein Vergleich zum Umfang von Nuttx und ChibOS)

von top-up (Gast)


Bewertung
0 lesenswert
nicht lesenswert
BTW,
gibts es bei den 'fetteren' Systemen sowas wie 'top' (Table of 
Processes?),
wo man den Status (Stack, CPU-Zeit, Priorität, etc) der einzelnen Tasks 
anzeigen kann?

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
FreeRTOS hat Statistikfunktionen dabei um solche Infos abzurufen. Das 
geht dann auch bei einigen IDEs mit PlugIns über den Debugger, wenn man 
den Resourcen Namen gibt werden die auch angezeigt und das ist eine gute 
Hilfe.

In einer NXP Werbung für IoT Kram habe ich heute zum erstenmal etwas von 
'Amazon a:FreeRTOS' gelesen, Amazon scheint das für seinen IoT Krempel 
zu benutzen, oder war das bei Alexa auch schon drin? Habe keine Alexa 
die ich fragen könnte...

https://www.nxp.com/support/developer-resources/reference-designs/lpc54018-iot-solution-with-amazon-freertos:IoT-Solution-with-Amazon-FreeRTOS?tid=vanLPC-AWS-Module

: Bearbeitet durch User
von Til S. (Firma: SEGGER) (til_s)


Bewertung
0 lesenswert
nicht lesenswert
Christopher J. schrieb:
> Auf der Seite von Segger wird
> gar der Code direkt aus dem RAM ausgeführt
> (https://www.segger.com/products/rtos/embos/technology/performance/)
> aber immerhin schreiben sie es dazu.

Bei der Context Switch Time gibt es Marketingwerte und wirklich 
technische Werte. Ich gebe lieber letztere an, d.h. wir messen die 
komplette CST von einer Task bis in die andere Task. Das schließt die 
kompletten API Aufrufe, den Scheduler und das Speichern/Restaurieren der 
Task Kontexte mit ein. Viele andere messen nur die Zeit für das 
Speichern/Restaurieren der Register.

Ich messe die CST im RAM, um Werte unabhängig von Flash Wait States zu 
bekommen. D.h. ich bekomme einen Wert in CPU Cycles, den ich auf jede 
CPU Frequenz umrechnen kann. Bei anderen Architekturen kann die CST 
natürlich wieder leicht anders sein aber damit bekommt ein Gefühl in 
welchem Bereich die CST liegt.

Das schöne bei uns ist, das uns keiner solche Werte glauben muss sondern 
Sample Applikation zum Messen der CST in jedem Board Support Package 
enthalten sind. Damit kann jeder selber messen und die CST für sein 
Device bestimmen.

Mehmet K. schrieb:
> Zur Zeit evaluiere ich Crossworks, der gleich ein RTOS onboard hat.
> http://www.rowley.co.uk/arm/
> Macht bis anhin einen sehr guten Eindruck. Und auch die Preise sind
> durchaus akzeptabel.

Das wäre dann CTL. Wenn du Fragen dazu hast kann ich auch gerne weiter 
helfen. Die Rowley Jungs sind ja quasi meine Arbeitskollegen ;-). 
Alternative dazu wäre natürlich (Achtung Werbung ;-)) Embedded Studio 
und embOS. Embedded Studio hat den Vorteil, dass es für nicht 
kommerzielle Anwendungen kostenlos ist. Der "Nachteil" ist aber, dass 
nur der J-Link unterstützt wird.

von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
top-up schrieb:
> BTW,
> gibts es bei den 'fetteren' Systemen sowas wie 'top' (Table of
> Processes?),
> wo man den Status (Stack, CPU-Zeit, Priorität, etc) der einzelnen Tasks
> anzeigen kann?

Bei Nuttx gibt es ein procfs, womit dann ps als Befehl in der Shell 
funktioniert http://nuttx.org/Documentation/NuttShell.html#cmdps . top 
müsstest du dann wohl selber oben drauf setzen. Ich bezweifle allerdings 
ob das so sinnvoll wäre.

ChibiOS hat wie FreeRTOS eine Statistikfunktion eingebaut:
http://www.chibios.org/dokuwiki/doku.php?id=chibios:book:kernel_debug

von Martin S. (strubi)


Bewertung
1 lesenswert
nicht lesenswert
Moin,

da es noch keiner genannt hat, tu ich es noch: Zephyr RTOS 
(https://www.zephyrproject.org/). Wurde vor einem Jahr an der Embedded 
recht aktiv beworben, der erhoffte Senkrechtstart ist vielleicht noch 
ausgeblieben, aber es macht bei auf IoT Safety eingestellten 
Architekturen schon mal eine gute Nummer. Immerhin steht es auf etwas 
stabilen Beinen (und dem Rücken der Linux Foundation, dementsprechend 
auch die Filestruktur, ähnlich wie NuttX)
Ansonsten kann würde ich grösstenteils die Auflistung von Christopher 
unterschreiben (Keil RTX kenne ich allerdings nicht).
Kritischer Punkt ist 'kmalloc' versus Objekt-Pools (für Baum-Knoten oder 
irgendwelche Objekte die recht volatil reserviert/freigegeben werden), 
da hatte ich mit FreeRTOS keinen Spass (vom ungarischen Symbolstil mal 
abgesehen).
Zu nennen wären noch eCos und RTEMS, die werden aber schnell mal ne 
grössere Nummer, dafür sind sie sehr robust und umfangreich. Ist aber 
auch bei mir ca. 10 Jahre her.
Letztlich stellt sich den meistern RTOS-Hackern die Frage, wie gut 
Anpassungen vornehmbar sind, und die div. APIs und Schnittstellen zu 
Nanokernels (Context-Switches, Zugriffsmodi) handhabbar sind. Sobald es 
in die Treiberentwicklung geht, fliegen die meisten closed-source-RTOS 
sowieso raus, insbesondere beim quälenden Thema zu performanten 
Netzwerk-Stacks (zu denen lwip/uip und Derivate nicht gehören) wird die 
Auswahl der brauchbaren RTOS recht klein. Und wenn dann noch ein 
malloc-Verbot herrscht, wird's wirklich knifflig.

von Christopher J. (christopher_j23)


Bewertung
1 lesenswert
nicht lesenswert
Martin S. schrieb:
> da es noch keiner genannt hat, tu ich es noch: Zephyr RTOS
> (https://www.zephyrproject.org/). Wurde vor einem Jahr an der Embedded
> recht aktiv beworben, der erhoffte Senkrechtstart ist vielleicht noch
> ausgeblieben, aber es macht bei auf IoT Safety eingestellten
> Architekturen schon mal eine gute Nummer. Immerhin steht es auf etwas
> stabilen Beinen (und dem Rücken der Linux Foundation, dementsprechend
> auch die Filestruktur, ähnlich wie NuttX)

Vom Konzept her hat mir das auf den ersten Blick auch zugesagt und ich 
hatte es kurz nach dem Release mal angetestet. Scheinbar ist Zephyr ein 
umgelabeltes VxWorks und nachdem Intel ja Windriver gekauft hatte kam 
mir das ein bisschen so vor, als ob Intel darüber versuchen würde seine 
bis dato eher mäßig erfolgreichen "IoT"-Prozessoren in den Markt zu 
drücken. Habe mir das aktuelle Projekt aber nochmal angesehen und bin 
überrascht wie lebendig es doch ist. Werde ich definitiv nochmal einen 
genauen Blick drauf werfen. Immerhin kommt Zephyr auch mit einem 
BLE-Stack daher.

Ein weiterer Kandidat der ebenfalls einen BLE-Stack mitbringt ist Apache 
Mynewt (https://mynewt.apache.org/), welches ich auch mal kurz 
angetestet hatte. Das Konzept ist ganz ordentlich, beispielsweise haben 
sich die Jungs ordentlich Gedanken über einen Bootloader zwecks 
Firmware-Updates gemacht und das OS ist von Grund auf als "tickless" 
designed. Es kommt außerdem mit einem CLI daher, was ein bisschen an npm 
erinnert. Das ist zwar deutlich besser als das mbed-CLI (was übrigens 
ein riesiger Mist ist) aber es macht die Sache zum Einstieg nicht 
unbedingt leichter. Ein simples BLE-Blinky hat man damit zwar schnell am 
laufen und für größere Teams und/oder Projekte mag das mit dem 
Package-Manager Vorteile haben aber so richtig überzeugt war ich davon 
nicht. Da präferiere ich persönlich doch eher kconfig und Makefiles.

von Guido Körber (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Warum steht die Nutzung von Betriebsystemen auf Microcontrollern immer 
noch nicht im StGB?

Dank dieses Unsinns, dass immer mehr Leute, die nicht die Bohne Ahnung 
von Microcontrollern haben, diese unbedingt programmieren wollen, werden 
die Entwicklungsumgebungen für Leute die wissen was sie tun immer 
schlechter. Das Ergebnis ist, dass wir aus 400 MHz 32 Bit Controllern 
kaum mehr raus holen als aus 10 MHz 8 Bit. Dafür sind die Dinger aber 
instabil wie ein alter Röhrencomputer.

von Georg A. (georga)


Bewertung
0 lesenswert
nicht lesenswert
Guido Körber schrieb:
> Warum steht die Nutzung von Betriebsystemen auf Microcontrollern
> immer noch nicht im StGB?

Weil dann auch Autos verboten sein müssten. Ebenso gefährlich, ist aber 
vereinzelt sinnvoll, und macht manchen sogar Spass...
1
$ telnet 192.168.2.66
2
...
3
# uname -a
4
Linux netceiver 2.4.32-uc0 #504 Mon Jun 6 22:54:08 CEST 2011 microblaze
5
# cat /proc/cpuinfo 
6
CPU-Family:  Microblaze
7
FPGA-Arch:  spartan3e
8
CPU-Ver:  7.00.b
9
CPU-MHz:   65.536000
10
BogoMips:  32.56
11
HW-Div:         yes
12
HW-Shift:       yes
13
Icache:        8kB
14
Dcache:       8kB
15
HW-Debug:       no
16
# cat /proc/uptime 
17
12912410.57 11168775.96
... und das auch nur, weil da wg. Erneuerung der Trafostation in der 
Gegend eine Stromunterbrechung war. Vorher war der wohl >1 Jahr up.

von Programmiersprachentheaterintendant (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Dank dieses Unsinns, dass immer mehr Leute, die nicht die Bohne Ahnung
> von Microcontrollern haben, diese unbedingt programmieren wollen, werden
> die Entwicklungsumgebungen für Leute die wissen was sie tun immer
> schlechter.

Du klassierst Dich damit implizit in erstere Gruppe, denn Makefiles & 
Editor (Emacs for the win) sind immernoch so schlank rank und effektiv 
wie eh und je. Noch eine pervasive Testautomation zwecks CI/CD dazu 
liefert beste Ergebnisse zu bester Effektivität.

Genausogut könnte man die Verwendung von (GUI-)IDEs im StGB verankern.
Ich lasse es nicht bei dieser/Pauschalplattitüde/ sondern untermaure die 
Aussage mit der Erkenntniss dass GUI-Tools wohl hilfreich sind in 
explizit explorativen Lernphasen (vwgd. Ausbildung), sich aber 
regelmässig als vermeidbares Hindernis herausstellen bei der Automation 
(CI/CD) im produktiven Alltag der nach Rationalisierung schreit.[1]

Bei mir (GUI-)IDEe erst wenn ich tatsächlich nach Mauskilometern 
entschädigt werde, anstatt nach brauchbarkeit der Ergebnisse.

[1] Basis der Erkenntnisse u.A. durch folgende Inhouse entwickelten 
Embedded-SBC-Zielplattformen geliefert (also vgl. m. STM32F4 gem. TO und 
indirekt auch tlw. meine BE ableitbar):
- MC68360 QICC, 8...16MB RAM, teils mit/ohne TCP/IP Connectivity, mit 
RT/Sprachverarbeitung & n*PCM30, VxW4.x
- PPC860 PowerQUICC, 32..64MB RAM, X-11/TCP/IP, Sprache via n*PCM30, 
Linux
- XScale PXA27x, 32MB RAM/Flash, http/TCP/IP, RT & Zeitbasierte 
Messdatenerfassung inkl. aufwändige Geometrieberechnungen im Raum, 
VxW5.x

von Dirk (Gast)


Bewertung
0 lesenswert
nicht lesenswert
HAL9k schrieb:
> Kann man größere µC inzwischen etwas 'abstrakter' programmieren?
>
> So wie auf einem PC, wo man sich nicht selbst um Interrupts und Co
> kümmern muß und ich mein Programm max. neu kompilieren muß wenn ich die
> Hardware wechsel (z.B. Intel-PC ->  ARM Board)
>
> Mit groß meine ich z.B. STM32H743ZI (2 MByte Fash, 1 MByte SRAM)
>
> (Ja, da läuft wohl auch Linux drauf, aber für das eigentliche Programm
> ist dann nicht mehr viel Platz)
>
> Also 'Linux in klein' mit vielen Treiber währe nett..

Nein, da läuft kein Linux drauf! Für Linux benötigt man eine MMU. Dieser 
Controller hat nur eine MPU. Es gibt uClinux, das hat aber mit 
Mainline-Linux eher weniger zu tun!

Ich selbst bin Fan von FreeRTOS. Um das Interrupt-Handling und HAL muss 
man sich trotzdem noch selbst kümmern (CubeMX kann hier vielleicht ein 
einen Beitrag leisten). Aber wenn du was ordentlich und effizient machen 
möchtest, solltest du schon genau wissen, was die Hardware macht!

von Alex B. (tecnologic) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Dirk schrieb:
> Nein, da läuft kein Linux drauf! Für Linux benötigt man eine MMU. Dieser
> Controller hat nur eine MPU. Es gibt uClinux, das hat aber mit
> Mainline-Linux eher weniger zu tun!

FALSCH! Der STM32F429 ist in der Mainline! und der H7 wird gerade von 
ST-Mitarbeitern mit Devicetrees usw. im Mainline Kernel versorgt.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Christopher J. schrieb:
> Das ist zwar deutlich besser als das mbed-CLI (was übrigens
> ein riesiger Mist ist)

warum das? Früher war es sehr kompliziert weil man die Python Module 
direkt aufrufen musste. Jetzt wird das Python virtualenv genutzt und die 
Kommandos können alle einfach mit 'mbed [command]' ausgeführt werden, da 
hat man mit Python erstmal nix zu tun.
Und auch die Installation ist (zumindest unter Windows) sehr einfach 
geworden mit dem Installer der alles nötige in einem Rutsch installiert. 
Hier mussten früher der ganze Sack voll Programme wie Toolchain, 
Python+Libs und Versionsverwaltungen git+hg installiert und konfiguriert 
werden.

von Georg A. (georga)


Bewertung
0 lesenswert
nicht lesenswert
Dirk schrieb:
> Nein, da läuft kein Linux drauf! Für Linux benötigt man eine MMU. Dieser
> Controller hat nur eine MPU. Es gibt uClinux, das hat aber mit
> Mainline-Linux eher weniger zu tun!

Doch, es hat sehr viel damit zu tun. Wenn man das kennt, ist sowohl 
Kernel, als auch System bzw. Anwendungsentwicklung unter uCLinux nur 
minimal mehr Aufwand. Man muss halt in seinem Code aufpassen, wohin man 
schreibt. Aber das hat jahrelang bei Apple, Atari, Amiga und DOS ohne 
MMU auch gut funktioniert.

von Bernd K. (prof7bit)


Bewertung
4 lesenswert
nicht lesenswert
Programmiersprachentheaterintendant schrieb:
> Du klassierst Dich damit implizit in erstere Gruppe, denn Makefiles &
> Editor (Emacs for the win) sind immernoch so schlank rank und effektiv
> wie eh und je.

Du vergisst dabei daß man sich neuerdings nur um an die Headerfiles für 
die Registerdefinitionen zu kommen schon gerne mal 200MB Müll 
installieren, dann ein leeres Demo-Projekt generieren und die zwei 
Headerfiles die man braucht dort rauskopieren muss und dann den ganzen 
überflüssigen Rotz wieder wegwerfen kann.

So wird das zum Beispiel bei STM32 gehandhabt.

Anstatt daß sie einfach die Headerfiles und vielleicht noch Linkerscript 
und Startup einfach so zum Download anbieten würden (oder Gott bewahre 
gar gleich ein fertiges minimales Makefile-Prokekt wo man gleich alles 
benötigte zusammen hat und direkt loslegen kann) damit man nicht den 
halben Tag damit verbringen muß sich den ganzen Kram mühsam selbst 
zusammenzukratzen.

Bei NXP/Freescale verkaufen sie USB-fähige ARM Controller in der 
billigsten Ausführung mit so wenig Flash (32kB) daß selbst das 
minimale Demo-Projekt der grenzdebilen IDE den Speicherbedarf sprengt! 
Das muß man sich mal geben!

Jedoch daß jemand (mangels benutzbarer IDE) auf die Idee kommen wollte 
diesen Controller trotzdem zu verwenden und sich seinen USB-Stack from 
scratch selbst zu schreiben (mangels Herstellertreiber), das ist auch 
nicht vorgesehen, da steht man ohne Unterstützung im Regen.

Wenn die ganze Manpower die in diese kranken unbrauchbaren 
Codegeneratoren und SDKs verschwendet wird stattdessen dazu verwendet 
würde die eigentlich vom Kunden gewünschte konkrete Verwendung der 
konkreten Hardware beispielhaft zu dokumentieren und das Material dafür 
zur Verfügung zu stellen wäre viel gewonnen.

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
Mein erstes Hello-World Projekt mit der Cube HAL schmierte schon bei der 
Taktkonfiguration ab. Für Anfänger ist das sehr hilfreich.

Denn es lehrt einen direkt von Anfang an, dem Cube MX nicht zu trauen 
und das Datenblatt zu lesen. Und siehe da, dann klappt das auch auf 
Anhieb.

Inzwischen ist der Fehler behoben worden, aber ich trauen diesem 
Bloat-Generator immer noch nicht.

: Bearbeitet durch User
von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Bei NXP/Freescale verkaufen sie USB-fähige ARM Controller in der
> billigsten Ausführung mit so wenig Flash (32kB)
>
> diesen Controller trotzdem zu verwenden und sich seinen USB-Stack from
> scratch selbst zu schreiben (mangels Herstellertreiber)

Verstehe ich nicht. Was brauchst Du genau? Die meisten LPC haben doch 
ein ROM mit den USB-Treibern für CDC, HID, MSC die kann man einfach 
aufrufen. Es braucht keinen USB-Stack. Und bei LPC ohne USB-Treiber wie 
z.B. LPC1700 passt sogar der LPCOpen Host-Stack für USB-Stick in 32kB

von Johann L. (gjlayde) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Wenn die ganze Manpower die in diese kranken unbrauchbaren
> Codegeneratoren und SDKs verschwendet wird stattdessen dazu verwendet
> würde die eigentlich vom Kunden gewünschte konkrete Verwendung der
> konkreten Hardware beispielhaft zu dokumentieren und das Material dafür
> zur Verfügung zu stellen wäre viel gewonnen.

+1

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> Bernd K. schrieb:
> Bei NXP/Freescale verkaufen sie USB-fähige ARM Controller in der
> billigsten Ausführung mit so wenig Flash (32kB)
> diesen Controller trotzdem zu verwenden und sich seinen USB-Stack from
> scratch selbst zu schreiben (mangels Herstellertreiber)
>
> Verstehe ich nicht. Was brauchst Du genau? Die meisten LPC haben doch

Nein, ich spreche vom KL26. Ich habe das Problem selbst gelöst indem ich 
den Treiber selbst geschrieben habe, der braucht jetzt nur noch 5k.

von Guido Körber (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> So wird das zum Beispiel bei STM32 gehandhabt.

Genau mit denen prügele ich mich grad rum...

Chip mit 16K FLASH und die Entwicklungsumgebung wirft einen leeren USB 
Stack raus der davon schon 11K belegt. Wenn man dann in die Details 
einsteigt um heraus zu finden wie man den Matschhaufen zur Mitarbeit 
bekommt, findet man so tolle Sachen wie Funktionen deren einziger Inhalt 
der Aufruf der nächsten Funktion ist, die dann exakt ein Register mit 
einem Wert schreibt.

Effizienz und Lesbarkeit? Wer braucht so was denn?

von Guido Körber (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> Verstehe ich nicht. Was brauchst Du genau? Die meisten LPC haben doch
> ein ROM mit den USB-Treibern für CDC, HID, MSC die kann man einfach
> aufrufen. Es braucht keinen USB-Stack. Und bei LPC ohne USB-Treiber wie
> z.B. LPC1700 passt sogar der LPCOpen Host-Stack für USB-Stick in 32kB

Na dann mach weiter, die Spielzeugabteilung ist hinten links im Laden…

Es soll auch Leute geben, die mehr machen als Dinge nach einem 
Standardschema zusammen zu klicken. Ich warte noch darauf mal einen 
USB-Stack von einem Chiphersteller zu sehen, der ohne massive 
Modifikationen für mehr als ein paar einfache Grundfunktionen geeignet 
ist.

von TUX (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Tec N. schrieb:

> FALSCH! Der STM32F429 ist in der Mainline! und der H7 wird gerade von
> ST-Mitarbeitern mit Devicetrees usw. im Mainline Kernel versorgt.

Cool, wie viele MByte SDRAM  braucht ein STM32 Linux um zu starten?

Das on-die SRAM reicht doch sicher nicht..

von Johnny B. (johnnyb)


Bewertung
0 lesenswert
nicht lesenswert
Guido Körber schrieb:
> Bernd K. schrieb:
>> So wird das zum Beispiel bei STM32 gehandhabt.
>
> Genau mit denen prügele ich mich grad rum...
>
> Chip mit 16K FLASH und die Entwicklungsumgebung wirft einen leeren USB
> Stack raus der davon schon 11K belegt. Wenn man dann in die Details
> einsteigt um heraus zu finden wie man den Matschhaufen zur Mitarbeit
> bekommt, findet man so tolle Sachen wie Funktionen deren einziger Inhalt
> der Aufruf der nächsten Funktion ist, die dann exakt ein Register mit
> einem Wert schreibt.
>
> Effizienz und Lesbarkeit? Wer braucht so was denn?

Das hat mit Abstraktion zu tun und wird benötigt, damit die Software 
nicht für jedes Derivat vom Mikrocontroller komplett neu geschrieben 
werden muss.

Natürlich kommt damit nicht ein so effizienter und speicherschonender 
Code heraus, wie wenn man das alles nur für ein einzelnes Derivat 
entwickeln würde.
Aber heutzutage kostet ein Entwickler nun mal deutlich mehr als eine 
etwas "überdimensionierte" Hardware, welche diesen Overhead bewältigen 
kann.

von guest (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Christopher J. schrieb:
> FreeRTOS
> ...
> + Lizenz GPL mit static linking exception
Nicht mehr, mittlerweile MIT-Lizenz.

von Guido Körber (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Johnny B. schrieb:
> Das hat mit Abstraktion zu tun und wird benötigt, damit die Software
> nicht für jedes Derivat vom Mikrocontroller komplett neu geschrieben
> werden muss.

Abstraktion kann man aber auch sinnvoll mit flacher Struktur machen. Das 
was ich in den HAL-Libraries sehe ist aber Schrott der zustande kommt, 
wenn Leute die nicht wirklich Microcontroller programmieren können das 
machen wovon sie glauben, dass es die richtige Methode sei.

> Natürlich kommt damit nicht ein so effizienter und speicherschonender
> Code heraus, wie wenn man das alles nur für ein einzelnes Derivat
> entwickeln würde.
> Aber heutzutage kostet ein Entwickler nun mal deutlich mehr als eine
> etwas "überdimensionierte" Hardware, welche diesen Overhead bewältigen
> kann.

Die tatsächlichen Kosten sind Instabilität und Sicherheitslücken, weil 
einfach nur Code aufeinander gestapelt wird. Das macht dann Spaß Fehler 
zu suchen.

von Alex B. (tecnologic) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
TUX schrieb:
> Cool, wie viele MByte SDRAM  braucht ein STM32 Linux um zu starten?
>
> Das on-die SRAM reicht doch sicher nicht..

8MB reicht. 16 ist schon sehr gut.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail ü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]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.