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.
Natürlich kann man das! Aber du darfst nicht erwarten, dass das schon jemand für dich schluckgerecht vorgekaut hat.
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 | 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.
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
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>;
eCos (http://ecos.sourceware.org/about.html) ist auch weit verbreitet und läuft auf fast allem, was Register hat.
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)
ach was: da kommt ja noch FORTH hinzu, zur Vollständigkeit der Diskussion!
>NB: siehe auch noch bitlash f. Arduino) https://playground.arduino.cc/Code/Bitlash Hast Du es schon mal benutzt?
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.
:
Bearbeitet durch User
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.
> es gibt ja noch Java... python, javascript, micro .net.
Das sind keine Betriebssysteme, sondern Programmiersprachen
>Das sind keine Betriebssysteme, sondern Programmiersprachen
So gesehen kann ein Computer ohne Betriebssystem funktionieren. Hatte
der C64 ein Betriebssystem?
Micropython: Filesystem? Multitasking?
> So gesehen kann ein Computer ohne Betriebssystem funktionieren
Ja natürlich.
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
>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ß
:
Bearbeitet durch User
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".
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?
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...
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
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.
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
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.
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).
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: > FreeRTOS > ... > - alles wird dynamisch alloziert Das ist mittlerweile zum Glück nicht mehr so. https://www.freertos.org/Static_Vs_Dynamic_Memory_Allocation.html
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:
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
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
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?
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
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.
Christopher J. schrieb: > FreeRTOS > ... > + Lizenz GPL mit static linking exception Nicht mehr, mittlerweile MIT-Lizenz.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.