Hallo uC-ler. Welches der beiden Varianten würdet ihr einem Newbie zur Anwendung auf einem ausreichend schnellen Einplatinencomputer empfehlen? Embedded Linux soll wohl sehr aufwendig anzupassen sein um harte Echtzeitfähigkeit zu gewährleisten und bringt viel Overhead mit sich. Andererseits gibt es dazu viele Tutorials und viel Support in Foren. FreeRTOS oder auch kommerzielle RTOS-Varianten sind sehr schlank, allerdings muss man sich doch auch erst in diese Technologie einarbeiten und es gibt nicht so viele Treiber, Libraries etc. Auf dem Einplatinenrechner soll eine GUI laufen und er soll per Maus und Tastatur bedient werden. Meine Linuxkenntnisse sind definitiv noch ausbaufähig, einen eigenen Kernel habe ich noch nie kompiliert, sondern nur fertige Distributionen auf normalen PC's verwendet. Was ist eure Meinung dazu?
Moin, sowie's der Speicher zulaesst wuerd' ich ganz klar Linux bevorzugen. Wenn die "Echtzeitfaehigkeiten" nicht ausreichen, oder die RT-Patcherei losgeht, bin ich sowieso schon weg. Das ist dann imho Mumpitz. Da ist's viel simpler den zeitkritischen Teil auf einen eigenen Prozessor oder FPGA auszulagern, als sich da einen Wolf mit Priorisierungen, Locks etc. zu programmieren. Und dann gehts erst noch schief... Gruss WK
Für "harte" Realtime-Anwendungen braucht man eine Art Realtime-Hypervisor der zwischen Hardware und Linux liegt. Die Realtime-Applikation läuft dann nicht unter Linux und Kommunikation mit Linux-Anwendungen ist je nach System mehr oder weniger umständlich. Der "rt-preempt" Kernel Zweig ermöglicht "normalen" Linux-Prozessen auch eine Art Realtime mit besseren Garantien als der Standard-Kernel kann, kann aber mEn doch auch einige zig µs an Jitter haben. Möglicherweise ist es nicht verkehrt 2 CPUs zu verwenden, eine unter FreeRTOS für das realtime Zeug und eine unter Linux für Gui und den ganzen Rest.
Robert S. schrieb: > Der "rt-preempt" Kernel Zweig ermöglicht "normalen" Linux-Prozessen auch > eine Art Realtime mit besseren Garantien als der Standard-Kernel kann, > kann aber mEn doch auch einige zig µs an Jitter haben. Die preempt_rt Patches sind meines Wissens nach mittlerweile komplett im Mainline Kernel. Ob es für einen persönlich von der Echtzeitanforderung "hart genug" ist, muss jeder für sich entscheiden.
Echtzeitneuling schrieb: > Welches der beiden Varianten würdet ihr einem Newbie zur Anwendung auf > einem ausreichend schnellen Einplatinencomputer empfehlen? Das hängt erstmal schlicht vom zu lösenden Problem ab. Ich weiß ja nicht, was du damit machen willst... Netzwerk (insbesondere WLAN) und Grafikausgabe (möglichst mit Compositing), dazu noch Audio und Videobeschleunigung würden eindeutig auf ein Linux schließen lassen, unabhängig vom Aufwand dafür. Eine kleine Heizungssteuerung eher nicht.
S. R. schrieb: > Echtzeitneuling schrieb: > Welches der beiden Varianten würdet ihr einem Newbie zur Anwendung auf > einem ausreichend schnellen Einplatinencomputer empfehlen? > > Das hängt erstmal schlicht vom zu lösenden Problem ab. Ich weiß ja > nicht, was du damit machen willst... Hi. Es geht um eine kleine Regelung, dabei werden 4 Sensorwerte einer Messgröße eingelesen und 2 Aktoren gesteuert. Ein weiterer Sensor überprüft den Zustand von einem der Aktoren und bildet somit die Rückkopplung. Dafür wird die Echtzeitfähigkeit benötigt. Damit der Aktor nicht in einen unerwünschten Zustand gerät. Auf dem Einplatinencomputer läuft eine GUI mit der die gewünschten Zustandsänderumgen der Aktoren eingestellt werden kann, sowie die Messwertdatei der 4 Sensoren angelegt wird.
Das blanke FreeRTOS ist kein mit dem Linuxkernel vergleichbares Betriebssystem sondern macht nicht viel mehr als Prozessverwaltung -und Synchronisation. Abgesehen davon bietet es keinen Abstraktionslayer zwischen Hard- und Software wie z.B. Linux.
Keep it simple... Wenn nicht die folgenden Features gebraucht werden, würde ich von Linux abraten: - TCP/IP/Netzwerk/IoT Stacks aller Arten - Multi-User-Sicherheit Brauchbare Echtzeit mit möglichst wenig Jitter ist zwar mit Xenomai/IPIPE zu schaffen, aber dazu müssen die entsprechenden Treiber neu geschrieben werden. Eklig wird es, wenn virtuelles Memory ins Spiel kommt, darum würde ich (auch als betagterer Kernelhacker/uClinux Fanboy) eher zum RTOS greifen, wenn nicht sogar bare metal. Manchmal ist in der Tat ein weiterer uC billiger.. Von RT_PREEMPT würde ich nicht prinzipiell abraten, aber man muss sich im Klaren sein, dass es eine Menge potentieller Hänger geben kann, an dem das System vielleicht einmal im Monat eine Latenzzeit bis zu einigen ms aufweisen kann. Vorher kann einem aber auch das Linux-Speichermanagement einen Strich durch die Rechnung ziehen.
Ich vergass noch: Falls du ein RTOS mit etwas linuxartiger Struktur bevorzugst: NuttX ist nicht schlecht designt und bringt eine Menge Treiber mit.
Kommt drauf an, wie komplex die Anforderungen sind. Ganz einfache Regel - man soll die Dinge nicht ohne triftigen Grund verkomplizieren. So ist die erste Frage: Wird es in Summe trotz der Abstraktionslayer und der zusätzlichen Echtzeitprozessoren weniger kompliziert? Zweite Frage: Lassen sich mit dem komplizierten System zusätzliche geile Features realisieren.
Wie häufig muss dein Regelkreis laufen? 1Hz, 100Hz, 1000Hz oder mehr. Und wie komplex ist die eigentliche Regelung. Einfach PID oder Modellbasiert, nichtlinear? Muss noch Sensorfusion oder ähnliches durchgeführt werden? Wie aufwendig ist die Sollwertvorgabe über die GUI: - Einfache 2 Werte eintippen? - Oder zusätzlich Regelbasiert, z.B. abhänig der Tageszeit? - Nur lokale Einstellungsmöglichkeit, oder auf absehbare Zeit auch übers Netz? Messwertedarstellung: - Einfache Darstellung. - Vergleichmöglichkeiten, Skalierbar, ... usw.
Echtzeitneuling schrieb: > Es geht um eine kleine Regelung, dabei werden 4 Sensorwerte einer > Messgröße eingelesen und 2 Aktoren gesteuert. [...] Klingt nach "nimm kein Linux". > Auf dem Einplatinencomputer läuft eine GUI mit der die gewünschten > Zustandsänderumgen der Aktoren eingestellt werden kann, sowie die > Messwertdatei der 4 Sensoren angelegt wird. Klingt nach "nimm kein Linux". Neben FreeRTOS, mit dem ich mich irgendwie noch nie anfreunden konnte, gibt es auch andere Echtzeitbetriebssysteme. Oder man lässt die auch weg (Echtzeitkram in die Interrupt-Handler, GUI und Rest in die Hauptschleife). Wenn der Einplatinenrechner vorgegeben ist und mangels sinnvoller Dokumentation nur mit Linux benutzbar ist, dann nimm Linux. Aber in dem Fall bräuchtest du hier auch nicht fragen, weil du dann eh keine Wahl hast.
Moin, S. R. schrieb: >> Es geht um eine kleine Regelung, dabei werden 4 Sensorwerte einer >> Messgröße eingelesen und 2 Aktoren gesteuert. [...] > > Klingt nach "nimm kein Linux". Naja - wenn die 4 Sensoren z.b. an den 4 Raedern eines Waegelchens haengen, vor das 2 Schildkroeten gespannt sind, eine rechts, eine links und die 2 Aktoren den Schildkroeten Salatblaetter servieren, sollte das schon noch mit Linux gehen. Will ich damit die Optik eines Blueray-Laufwerks nachfuehren, koennt' es etwas eng werden... Gruss WK
Fitzebutze schrieb: > Keep it simple... > > Wenn nicht die folgenden Features gebraucht werden, würde ich von Linux > abraten: > > - TCP/IP/Netzwerk/IoT Stacks aller Arten > - Multi-User-Sicherheit Das wird beides definitiv nicht gebraucht. Das ist nicht so einfach schrieb: > Kommt drauf an, wie komplex die Anforderungen sind. Ganz einfache > Regel > - man soll die Dinge nicht ohne triftigen Grund verkomplizieren. Das möchte ich auch gar nicht. Ich ging davon aus: Linux = bereits Bekanntschaft gemacht und gut dokumentiert. War dem Feedback des Forums nach wohl eine Falschannahme :) mukel schrieb: > Wie häufig muss dein Regelkreis laufen? 1Hz, 100Hz, 1000Hz oder > mehr. Ca. 100 Hz mukel schrieb: > Und wie komplex ist die eigentliche Regelung. Einfach PID oder > Modellbasiert, nichtlinear? Muss noch Sensorfusion oder ähnliches > durchgeführt werden? Ein einfacher PID wird ausreichend sein. mukel schrieb: > Wie aufwendig ist die Sollwertvorgabe über die GUI: > - Einfache 2 Werte eintippen? > - Oder zusätzlich Regelbasiert, z.B. abhänig der Tageszeit? > - Nur lokale Einstellungsmöglichkeit, oder auf absehbare Zeit auch übers > Netz? 2 Werte eintippen trifft es sehr gut. Keine gewünschten Abhängigkeiten von Umgebungstemperatur, Tageszeit und co. mukel schrieb: > Messwertedarstellung: > - Einfache Darstellung. > - Vergleichmöglichkeiten, Skalierbar, ... usw. Einfache Darstellung und Abspeicherung in einer Datei. S. R. schrieb: > Echtzeitneuling schrieb: >> Es geht um eine kleine Regelung, dabei werden 4 Sensorwerte einer >> Messgröße eingelesen und 2 Aktoren gesteuert. [...] > > Klingt nach "nimm kein Linux". > >> Auf dem Einplatinencomputer läuft eine GUI mit der die gewünschten >> Zustandsänderumgen der Aktoren eingestellt werden kann, sowie die >> Messwertdatei der 4 Sensoren angelegt wird. > > Klingt nach "nimm kein Linux". > > Neben FreeRTOS, mit dem ich mich irgendwie noch nie anfreunden konnte, > gibt es auch andere Echtzeitbetriebssysteme. Oder man lässt die auch weg > (Echtzeitkram in die Interrupt-Handler, GUI und Rest in die > Hauptschleife). "Nimm kein Linux" weil die simplen Aufgaben den Einsatz des mächtigen Linuxes nicht rechtfertigen würden? S. R. schrieb: > Wenn der Einplatinenrechner vorgegeben ist und mangels sinnvoller > Dokumentation nur mit Linux benutzbar ist, dann nimm Linux. Aber in dem > Fall bräuchtest du hier auch nicht fragen, weil du dann eh keine Wahl > hast. Der Einplatinenrechner ist nicht vorgegeben und Embedded Linux auch nicht. Ein linuxartiges Betriebsystem ist allerdings erwünscht. Dergute W. schrieb: > Naja - wenn die 4 Sensoren z.b. an den 4 Raedern eines Waegelchens > haengen, vor das 2 Schildkroeten gespannt sind, eine rechts, eine links > und die 2 Aktoren den Schildkroeten Salatblaetter servieren, sollte das > schon noch mit Linux gehen. > Will ich damit die Optik eines Blueray-Laufwerks nachfuehren, koennt' es > etwas eng werden... Mein Projekt mit den 100 Hz fällt also vermutlich eher unter Schildkröten?
Echtzeitneuling schrieb: > "Nimm kein Linux" weil die simplen Aufgaben den Einsatz > des mächtigen Linuxes nicht rechtfertigen würden? Das ist nicht meine Entscheidung. Komplexität ist der Feind, und wenn du die Fähigkeiten von Linux nicht brauchst, dann gibt es eigentlich keinen Grund, sich dessen Komplexität einzutreten. Echtzeitneuling schrieb: > Der Einplatinenrechner ist nicht vorgegeben und Embedded Linux auch > nicht. Ein linuxartiges Betriebsystem ist allerdings erwünscht. Du hast also die Antwort bereits vor der Frage gekannt. Warum fragst du überhaupt? Echtzeitneuling schrieb: > Mein Projekt mit den 100 Hz fällt also vermutlich eher unter > Schildkröten? Ziemlich sicher ja. Wenn du da keine besonderen Anforderungen verschwiegen hast, dann würde ich das mit einem AVR (oder Arduino + Shield) lösen und fertig.
S. R. schrieb: > Echtzeitneuling schrieb: >> "Nimm kein Linux" weil die simplen Aufgaben den Einsatz >> des mächtigen Linuxes nicht rechtfertigen würden? > > Das ist nicht meine Entscheidung. > > Komplexität ist der Feind, und wenn du die Fähigkeiten von Linux nicht > brauchst, dann gibt es eigentlich keinen Grund, sich dessen Komplexität > einzutreten. Ich wollte damit nur sicherstellen dass ich dich so richtig verstanden habe :) S. R. schrieb: > Echtzeitneuling schrieb: >> Der Einplatinenrechner ist nicht vorgegeben und Embedded Linux auch >> nicht. Ein linuxartiges Betriebsystem ist allerdings erwünscht. > > Du hast also die Antwort bereits vor der Frage gekannt. > > Warum fragst du überhaupt? Es ist auch ein anderes, richtiges RTOS vorstellbar. Falls der Aufwand mit Embedded Linux viel zu groß dafür wäre und mit einem geeigneten RTOS nicht, dann ist es kein Problem wenn ich mich für das RTOS zu entscheiden. Deswegen habe ich gefragt, da die Informationsflut bei der selbstständigen Suche erst einmal überwältigend war und ich das alles noch nicht so richtig einschätzen konnte. Eure Antworten haben mir schon mal einen viel besseren Überblick verschafft und ich konnte erfolgreich nach Schlagworten wie "preempt_rt" suchen. S. R. schrieb: > Echtzeitneuling schrieb: >> Mein Projekt mit den 100 Hz fällt also vermutlich eher unter >> Schildkröten? > > Ziemlich sicher ja. > > Wenn du da keine besonderen Anforderungen verschwiegen hast, dann würde > ich das mit einem AVR (oder Arduino + Shield) lösen und fertig. Der Einplatinenrechner kommuniziert mit den Aktoren über gängige Busprotokolle, aber ich denke das sollte klar sein. Ansonsten habe ich nichts verschwiegen :) Danke für eure Antworten.
S. R. schrieb: > Neben FreeRTOS, mit dem ich mich irgendwie noch nie anfreunden konnte, geht mir auch so. > gibt es auch andere Echtzeitbetriebssysteme. Welches würdest du empfehlen? Echtzeitneuling schrieb: > Es geht um eine kleine Regelung, dabei werden 4 Sensorwerte einer > Messgröße eingelesen und 2 Aktoren gesteuert. > Ein weiterer Sensor überprüft den Zustand von einem der Aktoren und > bildet somit die Rückkopplung. > Dafür wird die Echtzeitfähigkeit benötigt. Echtzeit hast du wenn dein System schnell genug auf die Anforderungen reagiert. Reine Definitionssache, für die Aufgeben oben reicht auch eine Schleife. Wenn die nicht schnell genug ist schafft das auch ein RTOS oder ein Linux nicht. Vom Prinzip her hast du mit einem Betriebssystem nur zusätzlichen Aufwand. Lohnt sich also erst wenn das Teil dir mehr abnimmt als Arbeit macht. Bei mir schafft Free Rtos nicht mal 19200 GPS Nmea ohne Klimmzüge einzulesen. Selber geproggt braucht das nur sehr wenig.
Ich mache beides. Meist eine kleine Arm-A Architektur mit Linux drauf. Dann geht GUI, Netzwerk, Filesystem etc. Wenn ich Echtzeit brauche, dann kommt ein eigener Echzeitprozessor über TTY oder USB daran. Sowas wie Arduino oder ein Arm-M. Da ist dann nur ein Free-Rtos oder ähnliches drauf.
Robert S. schrieb: > Für "harte" Realtime-Anwendungen braucht man eine Art > Realtime-Hypervisor der zwischen Hardware und Linux liegt. Die > Realtime-Applikation läuft dann nicht unter Linux und Kommunikation mit > Linux-Anwendungen ist je nach System mehr oder weniger umständlich. Deshalb gibt's xenomai. Das hat einen eigenen Echtzeit-Scheduler, in dem der Linux-Scheduler quasi als einer der Threads läuft, und Interrupts werden auch erstmal von xenomai behandelt und dann erst ggf. an die non-realtime-Schicht weitergegeben. Aber es ist trotzdem eng genug mit dem klassischen Linux verknüpft, um komfortabel zu kommunizieren. Ein Thread kann sogar - sofern man das will - jederzeit zwischen Echtzeit- und Linux-Modus hin und her wechseln. Der Pferdefuß bei xenomai sind die Treiber. Für jede Hardware, auf die man in Echtzeit zugreifen können will, muss man einen xenomai-fähigen Treiber haben. Ein Echtzeit-Thread kann auch auf Hardware zugreifen, für die es nur einen normalen Linux-Treiber gibt, aber muss dafür temporär den Echtzeitkontext verlassen, was natürlich dann auch nicht viel bringt. > Der "rt-preempt" Kernel Zweig ermöglicht "normalen" Linux-Prozessen auch > eine Art Realtime mit besseren Garantien als der Standard-Kernel kann, > kann aber mEn doch auch einige zig µs an Jitter haben. Das hängt denke ich auch au stark von der verwendeten Hardware ab. > Möglicherweise ist es nicht verkehrt 2 CPUs zu verwenden, eine unter > FreeRTOS für das realtime Zeug und eine unter Linux für Gui und den > ganzen Rest. Ich finde, es kommt stark drauf an, was man konkret machen will. Der Begriff "Echtzeit" alleine sagt nicht viel aus, wenn die konkreten Timing-Anforderungen nicht bekannt sind. Hyper Mario schrieb: > Vom Prinzip her hast du mit einem Betriebssystem nur zusätzlichen > Aufwand. Lohnt sich also erst wenn das Teil dir mehr abnimmt als Arbeit > macht. Das sehe ich eigentlich gerade umgkehert. Ohne Betriebssystem habe ich mehr Aufwand, deshalb nutze ich das eher dann, wenn aus irgendeinem Grund mit Betriebssystem nicht praktiabel ist (z.B. weil eine lange Bootzeit für den Anwendungsfall nicht erwünscht ist, oder eben wenn damit die Timing-Anforderungen nicht erfüllt werden können).
:
Bearbeitet durch User
Für den RTKernel kannst du dir Linuxcnc installieren. Das ist einfach zu installieren und aktuell zu halten. Gruss Bernd
4 Sensoren + 2 Aktoren? Dafür braucht kein Mensch ein RTOS oder Linux, das programmiert man bare metal - das sind nur wenige Zeilen Code und passen sogar in einen Attiny. Ist quasi wie die PI Jünger, die einen solchen nehmen, um einen LED Streifen anzusteuern oder ein paar LEDs blinken zu lassen ... RTOS erst wenn es anfängt unübersichtlich zu werden und Linux erst, wenn Speicher, GUI, WLAN/LAN oder Bluetooth dazu kommen sollen. Ansonsten: Wenn es --unbedingt-- sein muss, nimm freeRTOS. Sind 400 Seiten Doku, kann man in drei Tagen durchackern.
Du hast von gänigen Busprotokollen für die Ansteuerung der Aktoren/Sensoren gesprochen. Meist du damit klassiche uC Busse wie SPI, I2C, CAN. Oder Feldbussysteme wie Profibus/Profinet/Ethercat... Bei Feldbussystemen auf Ethernetbasis würde ich mindestens einen Cortex M3 verbauen, und ein RTOS mit passenden Stack verwenden. Bei den restlichen Systemen reichen für deine Anforderungen alle uC aus, auch ein kleiner AVR
Nachtrag: Für Feldbussysteme bietet sich auch z.B. ein Raspi an, mit installierten Codesys, da wird sämtliche Protokollunterstüztung mitgliefert. Das wäre dann Linuxbasiert.
Oder nimm einen µC, der deiner Sensoren / Aktoren auswertet/steuert. Ganz klassisch mit Interrupts. Dahinter hängt dann über z.B. SPI ein Linux dran, welches LAN/WLAN/GUI zur Verfügung stellt und wiederm über SPI auf die Daten vom µC zugreifen kann.
Wie groß ist denn deine GUI? Vielleicht 1024x768? Und für Tastatur und Maus brauchst du USB-Host. Da fallen die 8-Bitter raus. Ein kostengünstiges Orange Pi ist für dieses Projekt vom Preis her ziemlich attraktiv. Bleibt das Problem mit dem Regelkreis. Wobei 100Hz nicht so dolle sind. Hier kannst du dein Arduino&co einbringen. Auch per USB angebunden. Als Single-Board geht das mit den BBB. Der Cortex A8 für mainline-linux und die pruss für Sensoren/Regelkreis.
Moin, Mit meiner Meinung, sowas recht schnell auf 2 Prozessoren (1x GUI & Gedoens, 1x nur Realtime) aufzuteilen, steh' ich ja nicht so ganz alleine auf weiter Flur. Um rauszufinden, obs fuer salatbetriebene Schildkroetenautos und aehnliche Regelungen nicht doch auch mit nur 1 Prozessor geht, wuerd' ich mal sagen: Solange die komplette Regelung incl. ihrem I/O in einen (Ticker)Interrupthandler passt, ohne das restliche System dabei komplett lahmzulegen, kann man das riskieren. Aber das geht dann auch auf einem Feldwaldwiesenlinux mit einem selbstgebastelten Kerneltreiber. Was, selbst wenn man schonmal einen Kernel gebaut hat, trotzdem auch umfangreich werden kann... Aber sowie's da dann mal um µsec oder Taktzyklen geht, sind z.B. alle Prozessoren deren Programm aus Cache und/oder dyn. RAM gelesen wird, schon mal problematisch, denn die Ausfuehrungszeit fuer einen definierten Sack voller Befehle ist dann nicht mehr zwingend konstant. Gruss WK
Hyper Mario schrieb: >> gibt es auch andere Echtzeitbetriebssysteme. > Welches würdest du empfehlen? Ich habe mal im Studium mit Keil RTX gearbeitet, das lief gut und ist schon lange her. FreeRTOS, NuttX oder ChibiOS habe ich zwar aus der Ferne (und ein bisschen im Code) begutachtet, bin aber nie in die Tiefe eingestiegen. Funktionieren tun sie alle, mehr kann ich nicht sagen.
Dergute W. schrieb: > Mit meiner Meinung, sowas recht schnell auf 2 Prozessoren (1x GUI & > Gedoens, 1x nur Realtime) aufzuteilen, steh' ich ja nicht so ganz > alleine auf weiter Flur. Ne, definitiv nicht. Ich schließe mich hier ebenfalls an. Meiner Meinung nach ist das die sinnvollste Vorgehensweise. GUI, Maus und Tastatur brauchen nicht Echtzeitfähig zu sein. Der Mensch der vor der Kiste sitzt ist es ja schließlich auch nicht. Ein Rechner für die GUI und Bedienung und ein Mikrocontroller für die Regelung, beides per UART/RS232/RS422/RS485 verdrahtet und fertig ist der Lack. Man kann sich da natürlich beliebig ausspielen.
Robert S. schrieb: > Für "harte" Realtime-Anwendungen So wie es geschildert wird, ist das weit weg von harter Echtzeit. Echtzeitneuling schrieb: > Ca. 100 Hz Echtzeitneuling schrieb: > 2 Werte eintippen trifft es sehr gut. > Keine gewünschten Abhängigkeiten von Umgebungstemperatur, Tageszeit und > co. Echtzeitneuling schrieb: > Mein Projekt mit den 100 Hz fällt also vermutlich eher unter > Schildkröten? Ich fürchte schon. Da du in Linux keine Erfahrung hast (außer als Anwender) fürchte ich auch, du wirst dir die Zähne ausbeißen. Es sei denn, du nimmst so was wie den Rasperry Pi. Da hast du alles in einem. Und mit dem RT-Patch ist dessen Jitter bei knappen 100us. Also ein 32-bitter (ARM CM3?) sollte das locker ohne OS schaffen. Da allerdings in einigen RTOS schon ein GUI-Layer implementiert ist, würde ich soetwas nehmen weil da alles in einem Guß ist. Nuttx wurde schon genannt. Aber es gibt noch viele andere. S-gger hat ein OS auch mit GUI, uc-OS meine ich auch. Bei S-gger würde ich einen guten Support erwarten. Oder halt klassich eine Grafik-Lib und eine Main-Loop. Aber alles andere schießt wahrscheinlich weit übers Ziel hinaus. Ein FATFS für SD-Karte haben viele auch integriert. Dafür 2 Prozessoren zu nehmen.... ja kann man machen, erscheint aber eher mit Kanonen auf Spatzen geschossen :) Es sei denn dein Grafikschirm hat Full-HD Auflösung.
:
Bearbeitet durch User
mukel schrieb: > Du hast von gänigen Busprotokollen für die Ansteuerung der > Aktoren/Sensoren gesprochen. > Meist du damit klassiche uC Busse wie SPI, I2C, CAN. > Oder Feldbussysteme wie Profibus/Profinet/Ethercat... > > Bei Feldbussystemen auf Ethernetbasis würde ich mindestens einen Cortex > M3 verbauen, und ein RTOS mit passenden Stack verwenden. > > Bei den restlichen Systemen reichen für deine Anforderungen alle uC aus, > auch ein kleiner AVR Ich meinte die klassischen wie SPI, I2C, CAN und UART. Bimbo. schrieb: > Oder nimm einen µC, der deiner Sensoren / Aktoren > auswertet/steuert. > Ganz klassisch mit Interrupts. > > Dahinter hängt dann über z.B. SPI ein Linux dran, welches LAN/WLAN/GUI > zur Verfügung stellt und wiederm über SPI auf die Daten vom µC zugreifen > kann. So möchte ich das jetzt auch machen. Haben jetzt ja einige vorgeschlagen und ich kann eure Einwände gut nachvollziehen. Also: Einplatinencomputer (PI oder ähnliches) welcher über RS232 den bare metal Controller einstellt. Der regelt dann interruptgesteuert über einen Timer den Regelkreis. Mein Plan ist es nun dass die Sensorwerte die zum Regeln benutzt werden an den uC geleitet werden, aber gleichzeitig auch direkt an den Einplatinenrechner der die Messwerte dann in der GUI anzeigt und loggt. Letzteres muss natürlich nicht in harter Echtzeit erfolgen. Daher würde ich dafür auch eine stinknormale Embedded Linux Distribution auf den Einplatinenrechner packen, ohne Echtzeiteinstellungen. Der bare metal Controller würde also im Optimalfall nur Daten vom Einplatinenrechner empfangen. Nur bei einem Absturz bzw. Watchdog-Überlauf (was natürlich nicht auftreten sollte) würde er die Aktoren in einen sicheren Zustand bringen und dem Einplatinenrechner mitteilen, dass was schiefgelaufen ist. neuer PIC Freund schrieb im Beitrag #5796666: > Wie groß ist denn deine GUI? Vielleicht 1024x768? Und für Tastatur > und > Maus brauchst du USB-Host. Da fallen die 8-Bitter raus. Ein > kostengünstiges Orange Pi ist für dieses Projekt vom Preis her ziemlich > attraktiv. 1024 x 768 wäre ausreichend, etwas besser würde auch nicht schaden, aber FULL HD muss es definitiv nicht sein. Christopher J. schrieb: > Ein Rechner für die GUI und Bedienung und ein Mikrocontroller für die > Regelung, beides per UART/RS232/RS422/RS485 verdrahtet und fertig ist > der Lack. > > Man kann sich da natürlich beliebig ausspielen. Wenn ich am Ende noch Zeit übrig habe wären ein paar Extrafeatures sicher nicht verkehrt :) 900ss D. schrieb: > Da du in Linux keine Erfahrung hast (außer als > Anwender) fürchte ich auch, du wirst dir die Zähne ausbeißen. Es sei > denn, du nimmst so was wie den Rasperry Pi. Da hast du alles in einem. > Und mit dem RT-Patch ist dessen Jitter bei knappen 100us. Du beziehst dich damit auf echtzeitfähiges Linux und nicht generell auf Embedded Linux, richtig? Wie gesagt ich brauche eine GUI, Plug and Play für Maus und Tastatur, ein Dateisystem und einen USB-Treiber. Ich gehe mal davon aus dass das mit einem nicht echtzeitfähigen Embedded Linux leichter zu realisieren ist als mit einem speziellen RTOS? Vielen Dank an euch alle!
Echtzeitneuling schrieb: > Du beziehst dich damit auf echtzeitfähiges Linux und nicht generell auf > Embedded Linux, richtig? Nein, ich meine ein ganz normales embedded Linux. Da würdest du dir schon die Zähne ausbeißen wenn du es auf einem eigenen Board laufen lassen wolltest. So ein BSP schreibt man nicht mal eben. Gehe ein paar RTOS durch und sammel Infos. Erfüllen Sie deine Kriterien? Falls du keines findest, kannst du es ja mit Linux versuchen.
900ss D. schrieb: > Echtzeitneuling schrieb: >> Du beziehst dich damit auf echtzeitfähiges Linux und nicht generell auf >> Embedded Linux, richtig? > > Nein, ich meine ein ganz normales embedded Linux. Da würdest du dir > schon die Zähne ausbeißen wenn du es auf einem eigenen Board laufen > lassen wolltest. So ein BSP schreibt man nicht mal eben. Hmm. Ich weiß ja nicht. Hängt davon ab in wie weit das eigene Board von anderen Boards abweicht. Ich hab sowas z.b. mal mit OpenWRT gemacht. Ein eigenes Board, aber für den Prozessor gab es schon Unterstützung im OpenWRT. Die Toolchain vom OpenWRT ist richtig gut gemacht, das war von Lesen der Wiki-Seite bis Start des Compilierens keine halbe Stunde. Dann die passenden Optionen setzen und den DeviceTree anpassen war so nen Nachmittag rum. Danach lief es wie ich wollte. Hat mich selber überrascht wie einfach das war. Mit Yocto hab ich selbst noch keine Erfahrung gesammelt, was ich aber gehört habe sollte das nicht viel schwieriger als das OpenWRT sein wenn der Prozessor- oder Modulhersteller da passenden Support für im Yocto hat. Bei nem RasPi oder BeagleBone geht es noch einfacher, da muss man nur eine fertige Distribution installieren und ein paar Pakete zuinstallieren oder rauslöschen. Das ist auch schnell gemacht. Ich würde daher auch die ganzen GUI-Geschichten mit einem Linux-Board machen. Das ist da viel schneller gelöst als in nem RTOS. Für die GUI kannst Du bei nem Linux-Board Qt verwenden, damit kann man das bequem entwicklen. Die Abstraktionsebene von Grafikbibliotheken für RTOSse war das letzte Mal als ich mir das angeschaut hab (vielleicht 1-2 Jahre her) erschreckend niedrig. So auf der Ebene "Zeichne Linie", "Zeichne Text",... etc. - keine komplexeren Widgets, komplette Dialoge etc. Für den Regler-Teil dann einen gängigen Mikrocontroller. Verbindung zwischen beiden per UART. Das dürfte meiner Meinung nach das einfachste sein.
:
Bearbeitet durch User
Echtzeitneuling schrieb: > Wie gesagt ich brauche eine GUI, Plug and Play für Maus und Tastatur, > ein Dateisystem und einen USB-Treiber. Ich gehe mal davon aus dass das > mit einem nicht echtzeitfähigen Embedded Linux leichter zu realisieren > ist als mit einem speziellen RTOS? Jein. All das bringt etwa Nuttx von Haus aus mit. Nuttx nutzt unter anderem auch kconfig als Build-System, wie der Linux-Kernel und Nuttx mit all diesen Features für ein eigenes Board zu bauen ist mit Sicherheit einfacher als einen Linux-Kernel für ein eigenes Board zu stricken. Am Ende ist ja aber ein System immer mehr als die Summe der Einzelteile und es stellt sich doch immer die Frage wie schnell du ans Ziel gelangst und eine embedded GUI ist, gerade wenn Maus und Tastatur zur Bedienung vorrausgesetzt werden, definitiv aufwändiger als wenn du dir das z.B. mit QT-Creator zusammenstrickst und auf einem "normalen" Prozessor (x86/Cortex-A) laufen lässt. Im Prinzip wurden ja hier schon drei Möglichkeiten genannt: 1. embedded Linux mit entsprechenden Treibern für (mehr oder weniger) "harte Echtzeit". Geringer Aufwand für Hardware und GUI. Hoher Aufwand für Treiber. 2. "dicker" Mikrocontroller: Mittelmäßiger Aufwand für Hardware (Display) und Treiber (USB), hoher Aufwand für GUI. 3. embedded Linux mit kleinem Mikrocontroller: Geringer Aufwand für Treiber und GUI auf Linux-Seite. Geringer Aufwand für "harte Echtzeit" auf Mikrocontrollerseite. Bisschen zusätzlicher Hardware- und Softwareaufwand (Verkoppelung der beiden Systeme). Im einfachsten Fall flanscht man einen auf Lochraster (nebst zusätzlicher Hardware verlöteten) Arduino per USB ans Linux-System und fertig. Ich würde hier noch eine vierte Möglichkeit einwerfen: kleiner Mikrocontroller für Regelung, Webserver als GUI (kann auf Linux laufen, muss aber nicht), ein Gerät mit Webbrowser für die Bedienung (kann Maus und Tastatur haben, muss aber nicht). Diese Variante habe ich selber schon mal für einen Prototyp/Demonstrator so umgesetzt. Eine Weboberfläche als GUI kann schon sehr sexy sein, weil man dadurch absolut frei in der Wahl des Endgerätes ist. Kommt auf den Einzelfall an ob das sinnvoll oder überhaupt gewünscht ist. Es kommt vor allem immer auf die einzelne Person an ob eine GUI schneller mit z.B. C++/QT oder als Weboberfläche umgesetzt werden kann.
Echtzeitneuling schrieb: > S. R. schrieb: >> Echtzeitneuling schrieb: >> Welches der beiden Varianten würdet ihr einem Newbie zur Anwendung auf >> einem ausreichend schnellen Einplatinencomputer empfehlen? >> >> Das hängt erstmal schlicht vom zu lösenden Problem ab. Ich weiß ja >> nicht, was du damit machen willst... > > Hi. > Es geht um eine kleine Regelung, dabei werden 4 Sensorwerte einer > Messgröße eingelesen und 2 Aktoren gesteuert. > Ein weiterer Sensor überprüft den Zustand von einem der Aktoren und > bildet somit die Rückkopplung. > Dafür wird die Echtzeitfähigkeit benötigt. Damit der Aktor nicht in > einen unerwünschten Zustand gerät. > Auf dem Einplatinencomputer läuft eine GUI mit der die gewünschten > Zustandsänderumgen der Aktoren eingestellt werden kann, sowie die > Messwertdatei der 4 Sensoren angelegt wird. Ist das ein bereits bestehender "Einplatinencomputer" (z.B. kommerzielles SOM) oder eine Eigenentwicklung? Welche Footprintgrenzen bestehen, insbesonders RAM? Linux ist recht RAM hungrig, d.h. es kann sein, dass Du nur für das OS soviel RAM einplanen musst, dass deine eigentliche Applikationssoftware vielleicht nur <10% des RAMs beansprucht. "Atombomben auf Spatzen?" Wenn die Platine bereits aus Dritter Hand kommt, würde ich erstmal gucken, für welche Middleware der Hersteller bereits BSPs und Beispielcode anbietet, dann musst Du nicht komplett von 0 aus anfangen. Unter den RTOS hat FreeRTOS den Vorteil einer recht breiten Drittherstellerunterstützung, d.h. für viele Controller und Middleware gibt es bereits Codebeispiele für FreeRTOS, also auch wieder: Du musst nicht von 0 aus starten. Nischenprodukte haben ihren Charme, erfordern aber oft, dass Du die komplette Codebasis selbst erstellen musst. Win some, lose some.
Hallo, ich würde auch die 2-Komponenten-Lösung mit "passendem" Controller für den Regler vorschlagen. Aber die Rückmeldung - von was auch immer - zum Host ist auch bei 100Hz nicht unbedingt trivial! Ich meine damit, dass dir alles, was nicht zum eigentlichen Regelungsprogramm gehört, deine "Echtzeit" gnadenlos zerstören kann. Wenn du so etwas noch nicht programmiert hast, dann hast du noch einen langen Weg vor dir :-) Mein Vorgehen wäre, erst einmal mit einem Controller die Reglung aufbauen und dann schaun, was an "Nebenaufgaben" möglich ist. Das kann man sogar erst einmal mit einem PC als Host starten. Viel Spass und Gruß, Rainer
John Doe schrieb: > https://www.st.com/en/microcontrollers-microprocessors/stm32mp1-series.html Der STM32MP1 wäre zwar eine sehr elegante Lösung, allerdings ist der leider noch nicht wirklich verfügbar. Rainer V. schrieb: > Hallo, ich würde auch die 2-Komponenten-Lösung mit "passendem" > Controller für den Regler vorschlagen. Aber die Rückmeldung - von was > auch immer - zum Host ist auch bei 100Hz nicht unbedingt trivial! Ich > meine damit, dass dir alles, was nicht zum eigentlichen > Regelungsprogramm gehört, deine "Echtzeit" gnadenlos zerstören kann. Es kommt natürlich immer darauf an, was man alles in 10ms erledigen will aber ich denke, dass ein simpler PID-Regler mit 100Hz noch genug Luft lassen sollte um da nebenbei ein paar Daten rauszuschieben, selbst auf einem ganz kleinen Controller. Man muss ja höchstwahrscheinlich nicht mit 100Hz die Daten raushauen. Für gewöhnlich packt man doch einfach den Regler in einen Timerinterrupt und lässt die Main-Loop Daten rein- und rausschaufeln. Sollte selbst auf einem Attiny noch gehen, kommt aber natürlich auf den Einzelfall an.
Christopher J. schrieb: > dass ein simpler PID-Regler mit 100Hz noch genug Luft > lassen sollte um da nebenbei ein paar Daten rauszuschieben, selbst auf > einem ganz kleinen Controller Ja Ja, aber der Teufel liegt im Detail! Habe das schon "hundertfach" miterlebt. Nicht auf die leichte Schulter nehmen :-) Und ganz solide checken.... Gruß Rainer
Christopher J. schrieb: > Man muss ja höchstwahrscheinlich nicht > mit 100Hz die Daten raushauen Man, wenn du deinem Host auch nur annähernd zeitnahe Daten rüberbringen willst, dann bist du doch schon in der Klemme! Und dann sind 100Hz nix! Für mich macht es jedenfalls keinen Sinn, dem Host alle paar Stunden zu vermitteln, was das geregelte System macht :-) If you see what I mean... Gruß Rainer
Rainer V. schrieb: > Man, wenn du deinem Host auch nur annähernd zeitnahe Daten rüberbringen > willst, dann bist du doch schon in der Klemme! Und dann sind 100Hz nix! > Für mich macht es jedenfalls keinen Sinn, dem Host alle paar Stunden zu > vermitteln, was das geregelte System macht :-) If you see what I mean... Naja, mehr als 25Hz Updaterate für die Visualisierung der Daten (in Echtzeit) kann ein Mensch doch sowieso nicht warnehmen. Aus dem Bauch heraus würde ich sagen, dass man 10 Hz in einer GUI immer noch als sehr flüssig warnimmt. Es ist ja kein Egoshooter ;)
Christopher J. schrieb: > Aus dem Bauch > heraus würde ich sagen, dass man 10 Hz in einer GUI immer noch als sehr > flüssig warnimmt. Es ist ja kein Egoshooter Ja ,ja , das stimmt so, aber Echtzeit ist ein Begriff...auch wenn du in 100mS deine Daten nich rüber bekommst, dann ist Echtzeit für die Katz! Offensichtlich fehlen, wie immer, Infos... Gruß Rainer
Rainer V. schrieb: > aber Echtzeit ist ein Begriff Echtzeit hat nichts mit "schnell" zu tun, sondern mit "garantiert". Wenn die Regelung mit 100 Hz garantiert läuft, dann heißt das noch lange nicht, dass man auch mit 100 Hz (oder schneller) die Daten rausvisualisieren muss.
S. R. schrieb: > dann heißt das noch lange > nicht, dass man auch mit 100 Hz (oder schneller) die Daten > rausvisualisieren muss Ja, aber wenn du Reglung und Sprechen mit dem Host irgendwie zusammenhalten willst/mußt, dann wird es schon wieder eng. Ich will doch nur verhindern, dass dem TO Flausen in den Kopf gesetzt werden! Gruß Rainer
Ruediger A. schrieb: > Ist das ein bereits bestehender "Einplatinencomputer" (z.B. > kommerzielles SOM) oder eine Eigenentwicklung? Es handelt sich um einen bestehenden Einplatinencomputer dessen Hersteller bereits ein vorkonfiguriertes Linux-Image anbietet, wie ich heute herausgefunden habe. Rainer V. schrieb: > Hallo, ich würde auch die 2-Komponenten-Lösung mit "passendem" > Controller für den Regler vorschlagen. Aber die Rückmeldung - von was > auch immer - zum Host ist auch bei 100Hz nicht unbedingt trivial! Ich > meine damit, dass dir alles, was nicht zum eigentlichen > Regelungsprogramm gehört, deine "Echtzeit" gnadenlos zerstören kann. > Wenn du so etwas noch nicht programmiert hast, dann hast du noch einen > langen Weg vor dir :-) Mein Vorgehen wäre, erst einmal mit einem > Controller die Reglung aufbauen und dann schaun, was an "Nebenaufgaben" > möglich ist. Das kann man sogar erst einmal mit einem PC als Host > starten. Du hast recht es ist das erste mal dass ich etwas derartiges programmiere. Deinen Vorschlag finde ich gut, erst den Regler zu coden und danach mal die Kommunikation mit dem Programmier-PC zu testen. Eine Info habe ich euch wohl tatsächlich noch vorenthalten: Die Daten sollen ebenfalls mit einer Frequenz von ca. 100 Hz auf dem Einplatinenrechner mitgeloggt werden, also in eine Datei mit Zeitstempel geschrieben werden. Die durchgeführten Messungen dauern nur wenige Minuten, daher wird auch der verwendete Datenspeicher auf dem Einplatinenrechner ausreichend sein. Bei einer Frequenz von 100 Hz muss also alle 10 ms eine Nachricht per RS232 gesendet werden. Der ADC hat angenommen (steht noch nicht fest) 12 bit Auflösung, also müssten die Daten in zwei RS232 8-Bit-Pakete aufgeteilt werden. Mit einer Bitrate von >= 50.000 Bit/s sollte das doch drinnen sein?
Also, bitte nicht böse sein! Der T0 sollte schleunigst so was wie ein "Pflichtenheft" machen !!! Rainer
Rainer V. schrieb: > Also, bitte nicht böse sein! Der T0 sollte schleunigst so was wie > ein > "Pflichtenheft" machen !!! > Rainer Ach quatsch ich bin doch nicht böse. Zur Zeit bin ich noch am planen und Informationen sammeln, eine Art Pflichtenheft wäre wohl strukturierter, das stimmt.
Echtzeitneuling schrieb: > Es handelt sich um einen bestehenden Einplatinencomputer dessen > Hersteller bereits ein vorkonfiguriertes Linux-Image anbietet, > wie ich heute herausgefunden habe. Aha, die gesamte Diskussion war also tatsächlich nutzlos, die gegebenen Informationen grob unvollständig bis falsch. So schafft man sich Freunde. Wenn man keine Wahl hat, ist die Entscheidung natürlich wesentlich einfacher. Mach, was du willst, ich bin dann raus.
S. R. schrieb: > Echtzeitneuling schrieb: >> Es handelt sich um einen bestehenden Einplatinencomputer dessen >> Hersteller bereits ein vorkonfiguriertes Linux-Image anbietet, >> wie ich heute herausgefunden habe. > > Aha, die gesamte Diskussion war also tatsächlich nutzlos, die > gegebenen Informationen grob unvollständig bis falsch. So schafft man > sich Freunde. > > Wenn man keine Wahl hat, ist die Entscheidung natürlich wesentlich > einfacher. Mach, was du willst, ich bin dann raus. FreeRTOS wird von dem Board ebenfalls unterstützt und ein anderer Einplatinenrechner wäre auch möglich gewesen. Für mich war die Diskussion jedenfalls nicht nutzlos, warum willst du mir ständig unterstellen dass ich schon genau weiß was ich vorhabe? Ich wollte eine allgmeine Frage stellen: Welche Art von RTOS für einen schnellen Einplatinenrechner. Dann kamen viele Fragen dazu was ich genau vorhabe und dann heißt es: Du bist ja schon völlig festgefahren usw. Aber selbst wenn es so wäre: was ändert das an dem Thema des Threads? -> nichts. Trotzdem danke.
Dann sind wir also jetzt bei der grundsätzlichen Entscheidung, kann die vorgegebene Platine das Problem "alleine" lösen oder muß ein zusätzlicher Controller her?! Dass kann allerdings nur der TO entscheiden...und wie gesagt, "Echtzeit" ist relativ :-) besser ist die Überlegung, unter allen Umständen schnell genug?! Gruß Rainer
Echtzeitneuling schrieb: > FreeRTOS wird von dem Board ebenfalls unterstützt und ein anderer > Einplatinenrechner wäre auch möglich gewesen. Ersteres glaube ich dir. Zweiteres glaube ich dir spontan nicht. Die meisten linuxfähigen Einplatinenrechner sind ohnehin nicht ausreichend dokumentiert, um damit sinnvoll bare-metal entwickeln zu können. Die erste Analyse deiner Anforderungen machte das nämlich zur - aus meiner Sicht - sinnvollsten Lösung. Darauf folgte: Salamitaktik. > Für mich war die Diskussion jedenfalls nicht nutzlos, warum willst du > mir ständig unterstellen dass ich schon genau weiß was ich vorhabe? Nun, wenn du nicht weißt, welches Problem zu lösen möchtest, dann ist jede Antwort auf die Frage nutzlos. > Ich wollte eine allgmeine Frage stellen: > Welche Art von RTOS für einen schnellen Einplatinenrechner. "Welches Auto für Straßen benutzen?" Nun, das hängt davon ab, was du damit machen willst. Und welche Randbedingungen gelten. > Dann kamen viele Fragen dazu was ich genau vorhabe und dann heißt es: Du > bist ja schon völlig festgefahren usw. Aber selbst wenn es so wäre: was > ändert das an dem Thema des Threads? -> nichts. Es macht den Thread nutzlos.
Echtzeitneuling schrieb: > FreeRTOS wird von dem Board ebenfalls unterstützt und ein anderer > Einplatinenrechner wäre auch möglich gewesen. Um welchen Controller handelt es sich denn genau bzw. was ist da auf der Platine denn drauf? Ein "Einplatinenrechner" kann ja im Prinzip alles sein, vom ATTiny13 auf Lochraster bis zum Servermainboard mit vier dicken Xeons. Nur weil sich das so eingebürgert hat, dass man unter einem "Einplatinenrechner" (aka SBC) so etwas in der Kategorie Raspberry Pi versteht, muss das ja noch lange nicht ein solcher sein. Genauso wie die meisten Menschen beim Begriff "motorisiertes Fahrzeug" zuerst mal an ein Auto denken, aber der Begriff vom Moped bis zum Panzer alles einschließt.
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.