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..
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.
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 ;)
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.
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
DigitalOutled(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.
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.mdhttps://www.riscosopen.org/content/downloads
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.
> 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)
Ein kleines kompaktes Linux waere CentOS. Aber irgendwer wird's
portieren und konfigurieren muessen.
Irgendwann sollte man dann doch rausruecken was die Anforderungen sind.
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.
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.
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 ...
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).
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.
>Das sind keine Betriebssysteme, sondern Programmiersprachen
So gesehen kann ein Computer ohne Betriebssystem funktionieren. Hatte
der C64 ein Betriebssystem?
Micropython: Filesystem? Multitasking?
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.
>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?
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ß
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.
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".
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.
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...
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.
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.
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.
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)
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.
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.
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 ...
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.
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.
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?
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.
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.
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!
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?
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:
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"
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.
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)
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?
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.
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
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.
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.
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.
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.
> 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
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!
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.
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.
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.
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.
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.
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
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
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.
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?
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.
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..
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.
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.
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.
