mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Embedded OS für GUI Entwicklung


Autor: Peter (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Mal eine Frage an die Gemeinde,

welches OS auf z.B. Raspberry Pi oder Beaglebone könnt ihr für eigene 
GUI Entwicklung empfehlen und bitte das -warum- empfehlenswert, mit 
angeben.

Es sollte kein Schnick Schnack mitführen und somit schnell booten 
können.
Wie schnell würde das genannte OS in möglicher fast Boot konfiguration, 
sofern möglich, hochlaufen und die eigene GUI Applikation starten?

GUI wollte ich mit C# (VS) oder C++ (Qt) realisieren.

Danke.

Autor: THOR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da sollte eigentlich Lubuntu drauf laufen, das müsste dann von SD Karte 
in 20 Sekunden booten.

Autor: holger (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Beitrag "Windows core iot"

Jetzt ist aus Nino ein Peter geworden;)

Autor: Stefan Us (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Linux natürlich.
Warum? Weil es die vom Board Hersteller unterstützte Lösung ist. Und 
weil es nichts kostet. Und weil es sich seit vielen Jahren bewährt hat.

Autor: Harry L. (mysth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Linux - was sonst?
Der Systemstart lässt sich gegenüber dem Standard Raspbian stark 
beschleunigen - je nachdem, was man wirklich braucht.

Für die GUI-Entwicklung solltest du dir QT Embedded anschauen.
http://doc.qt.io/qt-5/embedded-linux.html

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter schrieb:
> Es sollte kein Schnick Schnack mitführen und somit schnell booten
> können.

Nimm einen nackten Linux-Kernel, ein BusyBox als Userland und starte 
deine Anwendung relativ direkt aus /etc/rc. Schalte Timeouts im 
Bootloader ab und miss nach, wo deine Zeit verschwindet.

Deine SD-Karte wird relativ langsam sein (große Binaries laden dauert, 
Squashfs hilft), und große C++-Bibliotheken können ihre Zeit brauchen, 
bis sie geladen sind.

Es gibt ein paar Tutorials, wie man mit Qt Embedded auf 
Sub-Sekunden-Bootzeiten kommt (allerdings nicht fürn Raspberry).

Autor: Christopher Johnson (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
holger schrieb:
> Beitrag "Windows core iot"
>
> Jetzt ist aus Nino ein Peter geworden;)

Ja, verrückt diese Ähnlichkeit beim Thema :D

Die Antwort hast du doch im anderen Thread schon von Clemens bekommen:
Beitrag "Re: Windows core iot"

Boot2QT benötigt nicht mal einen X-Server, weil das direkt über OpenGL 
läuft. Daher auch die extrem flotten Bootzeiten.

Bei der Frage nach dem OS ist natürlich die Antwort von Stefan die 
einzig richtige. Falls die Frage nach der "richtigen" Distribution 
aufkommen sollte lautet die Antwort "deine eigene". Für den Anfang 
kannst du aber ruhig ein Debian oder was auch immer nehmen, was eben so 
standardmäßig für das jeweilige Board vorgesehen ist.

Autor: Harry L. (mysth)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Christopher J. schrieb:
> Boot2QT benötigt nicht mal einen X-Server, weil das direkt über OpenGL
> läuft. Daher auch die extrem flotten Bootzeiten.

Nicht zwangsläufig.
Das geht auch mit /dev/fb*

Zitat:

EGLFS_DEVICE_INTEGRATION entry: the name of the preferred backend for 
that particular device. This is optional, but very useful to avoid the 
need to set this environment variable in case there are more than one 
plugins present in the target system. In a desktop environment the KMS 
or X11 backends are prioritized, depending on the presence of the 
DISPLAY environment variable. Note that on some boards the special value 
of none is used instead of an actual plugin. This indicates that no 
special integration is necessary to use EGL with the framebuffer and so 
no plugins must be loaded.

: Bearbeitet durch User
Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan U. schrieb:
> Linux natürlich. Warum? Weil es die vom Board Hersteller
> unterstützte Lösung ist.

Für Embedded in Echtzeit empfiehlt der "Board Hersteller" aber was 
anderes mit Boot-Zeit 1 sec:

https://www.raspberrypi.org/blog/risc-os-for-raspberry-pi/
https://www.riscosopen.org/content/downloads

Und weil das auf Industrie-Boards komplett in den eMMC Flash passt:

http://www.ti.com/devnet/docs/catalog/thirdpartyde...

Abgesehen davon kommt es auf den Einsatz an. Wenn es sicherheitskritisch 
ist, sollte immer GUI und Steuerung getrennt sein. Also ein Pi für die 
GUI und ein anderes Pi ohne Desktop für die Steuerung (oder eben uC oder 
SPS)

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> Wenn es sicherheitskritisch ist, sollte immer GUI und Steuerung getrennt
> sein

Wie stellt man im sicherheitskritischen Bereich fest ob das tft Display 
brav refresht und nicht eingefrohren ist?

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter schrieb:
> Es sollte kein Schnick Schnack mitführen und somit schnell booten
> können.
Archlinux fuer den RPi 3:
https://archlinuxarm.org/platforms/armv8/broadcom/...

Da hast du erstmal nichts bei, kein X, keine Desktopoberflaeche, etc. 
Was du brauchst musst du selbst installieren, somit ist kein unnoetiger 
Balast vorhanden. Bootzeit (bis zum login in der Konsole) liegt bei ca. 
10 Sekunden. Ob man es noch schneller bekommt hab ich nie ausprobiert.

Du kannst dir auch mal Python3 und PyQt5 anschauen. Finde ich einfacher 
als Qt mit C++, und schneller in der Entwicklung ist es auch.

Autor: Stefan Us (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wie stellt man im sicherheitskritischen Bereich fest ob das tft Display
> brav refresht und nicht eingefrohren ist?

Indem man die anzuzeigenden Daten mit einem Zeitstempel versieht und 
diesen mit anzeigt.

Autor: Georg A. (georga)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Stefan U. schrieb:
> Indem man die anzuzeigenden Daten mit einem Zeitstempel versieht und
> diesen mit anzeigt.

(verstaubte-Erinnerung-ausgrab): Gab es bei frühen elektronischen 
Stellwerken nicht den Trick, die Anzeige pro Frame aktiv vom gerade 
anzeigenden auf den jeweils anderen Computer zu wechseln? Dazu gab es 
noch ein Indikator-Zeichen irgendwo im Eck, der eine macht - der andere 
|. Wenn dann kein + da steht, ist was eingefroren...

Autor: Bernhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich verwende als Programmiersprache Vala und Gtk+3 fuer meine 
Applikationen auf dem Raspi, die ich direkt auf einem per startx 
gestarteten X-Server (automatisch) starte.

Das booten von uSD-Karte bis in GUI der Applikation dauert ungefaehr 
20s.

Das kann man sehr fein erst mal direkt auf dem PC entwickeln und 
debuggen und dann nochmal auf dem Raspi uebersetzen. Die Kombination der 
(C# aehnlichen) Sprache Vala mit Gtk/GLib ist meiner Erfahrung nach 
optimal.

Vor etwa 3 Jahren sind wir hier in unserer Bude entgegen dem ueblichen 
Trend mit unserer Applikation (ein paar 100.000 Zeilen) von Qt auf 
Gtk/Vala gewechselt und sind seither sehr zufrieden damit.

Hier noch ein paar Links:
 wiki.gnome.org/Projects/Vala/Tutorial
 wiki.gnome.org/Projects/Vala/GTKSample
 wiki.gnome.org/Projects/Vala/Documentation#Sample_Code
 valadoc.org

P.S.: Bitte hier keinen Glaubenskrieg ala "Qt ist super, Gtk ist bloed" 
enfachen, daran habe ich kein Interesse. Aus meiner Erfahrung heraus ist 
Vala+Gtk fuer MICH (!!) die bessere Variante. YOUR mileage may vary ;-)

Autor: Embedded User (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
https://github.com/rsta2/circle

schneller kann man kaum booten.

Autor: Autor: (Gast) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhard schrieb:
> Vor etwa 3 Jahren sind wir hier in unserer Bude entgegen dem ueblichen
> Trend mit unserer Applikation (ein paar 100.000 Zeilen) von Qt auf
> Gtk/Vala gewechselt und sind seither sehr zufrieden damit.

Soweit ich weiß ist Vala tot und wird nicht mal mehr von den 
GNOME-Entwicklern empfohlen (siehe 
https://twitter.com/ebassi/status/827482509982195712). Schon 'ne Idee 
worauf ihr jetzt portiert? :P

Autor: Frank Lorenzen (florenzen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Georg A. schrieb:
> Stefan U. schrieb:
>> Indem man die anzuzeigenden Daten mit einem Zeitstempel versieht und
>> diesen mit anzeigt.
>
> (verstaubte-Erinnerung-ausgrab): Gab es bei frühen elektronischen
> Stellwerken nicht den Trick, die Anzeige pro Frame aktiv vom gerade
> anzeigenden auf den jeweils anderen Computer zu wechseln? Dazu gab es
> noch ein Indikator-Zeichen irgendwo im Eck, der eine macht - der andere
> |. Wenn dann kein + da steht, ist was eingefroren...

Gab es. War aber nicht pro Frame, sondern pro 1s (IIRC). Wenn die 
Rechner unterschiedliche Ausgaben produzierten sah man das als "Blinken" 
auf dem Monitor -- und war die Umschaltung eingefroren blieb der Wechsel 
aus - und | stehen (Im Normalbetrieb sieht das aus als ob es sich 
dreht).
Es gab in frühen ESTW auch mal Röhrenmonitore, die ihre eigene 
Bildschirmdarstellung zurücklesen konnten und wieder an den Rechner 
zurückmeldeten.


Gruß,
f

Autor: Bernhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Autor: (Gast) schrieb:
> Soweit ich weiß ist Vala tot und wird nicht mal mehr von den
> GNOME-Entwicklern empfohlen (siehe
> https://twitter.com/ebassi/status/827482509982195712). Schon 'ne Idee
> worauf ihr jetzt portiert? :P

Bitte vorher umfassend informieren, bevor man was nachplappert.

Vala ist alle andere als tot, guckst Du hier bei der Release-History:
https://wiki.gnome.org/Projects/Vala/Release

Und Vala hat eine entscheidenden Vorteil, den alle anderen Sprachen 
nicht haben: es compiliert zu C und ist damit automatisch ABI 
kompatibel. Das kann man gar nicht hoch genug einschaetzen, wieviel 
Arbeit das spart.

Es gibt viele Applikationen, die "heimlich" in Vala implementiert sind 
(z.B. der Gnome Calculator) und es gibt sogar einen recht bekannten 
Desktop, guckst Du hier: https://elementary.io

Vielleicht wuerde Unity auch noch leben, wenn sie nicht von Vala/Gtk auf 
Qt gewechselt waeren? Na egal.


Was aber stimmt ist, dass die Gnome-Leute Vala aus diversen (fuer mich 
durchaus NICHT nachvollziehbaren) Gruenden Vala nicht mehr lieb haben, 
und das schon seit laengerem.

Trotzdem steht es nach wie vor bei 
https://www.gtk.org/language-bindings.php als eine der vier "Official 
GNOME Binding" Sprachen und wird es zukuenftig auch bleiben. Komisch, 
oder?

Wie auch immer, die Vala Entwicklung haengt NICHT von den Gnome-Leuten 
ab, daher ist das voellig egal, ob die Vala moegen oder empfehlen oder 
nicht. Obwohl es natuerlich einen zusaetzlichen Boost fuer Vala gegeben 
haette, wenn die Gnome-Dep.... sorry ;-) Gnome-Leute nicht JavaScript 
(WTF?) als Hauptsprache fuer den Gnome-Desktop gewaehlt haetten.

Aber sollen sie, WIR haben Vala+Gtk+GLib fuer unserer kommerziellen 
Applikationen (nicht nur eine) im Einsatz, fahren seit 3 Jahre sehr gut 
damit und es gibt ueberhaupt keinen Grund, davon abzugehen, ganz im 
Gegenteil.

Autor: Bernhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Embedded User schrieb:
> https://github.com/rsta2/circle
> schneller kann man kaum booten.

Eh klar, ohne den ganzen "Ballast" von Linux. Auf jeden Fall ein 
wirklich tolles Projekt!

Aber: Gerade der "Ballast" von Linux hat uendlich viele Vorteile.

Ich komme ja (u.a.) aus der Microcontroller-Ecke. Das ist schon eine 
andere Nummer, wenn man nicht jedesmal alles selber erfinden muss. Die 
Produktivitaetssteigerung durch Linux ist enorm.

In den allermeisten Faellen sind 10 oder 20 Sekunden Bootzeit kein 
Problem.

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
RiscOS bootet so schnell wie Circle oder ultibo und kann alles was Linux 
kann und ist auch noch sicher. Wird auch von der Pi Foundation als 
Alternative empfohlen.

Autor: Stefan Us (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ohne RiscOS jetzt schlecht machen zu wollen:
Wenn etwas schneller kleiner billiger und zugleich besser sein soll, 
werde ich immer sehr skeptisch. Denn das ist selten der Fall. Wenn es so 
wäre, müsste das System sehr viel weiter verbreitet sein und der 
Firmenchef wäre bekannter als Bill Gates und Tim Cook zusammen.

Autor: Mr. Big (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> RiscOS bootet so schnell wie Circle oder ultibo und kann alles was
> Linux
> kann und ist auch noch sicher. Wird auch von der Pi Foundation als
> Alternative empfohlen.


RiscOS hat nicht mal preemptives Multitasking. Damit fällt es für viele 
ernst zu nehmende Aufgaben aus. Insofern gebe ich Stefan Us völlig 
recht.

Autor: Rolf Magnus (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan U. schrieb:
> Wenn es so wäre, müsste das System sehr viel weiter verbreitet sein

Spätestens seit VHS weiß man doch, dass sich nicht zwangsläufig das 
beste durchsetzt.

Mr. Big schrieb:
> Lothar schrieb:
>> RiscOS bootet so schnell wie Circle oder ultibo und kann alles was
>> Linux
>> kann und ist auch noch sicher. Wird auch von der Pi Foundation als
>> Alternative empfohlen.
>
> RiscOS hat nicht mal preemptives Multitasking.

Ist bei Echtzeit-Systemen auch nichts so ungewöhnliches. Da will man das 
manchmal auch gar nicht, da man volle Kontrolle darüber braucht, wann 
welcher Thread läuft.

> Damit fällt es für viele ernst zu nehmende Aufgaben aus.

Für welche denn? Zum Vergleich: Windows 3.1 hatte auch kein präemptives 
Multitasking.

: Bearbeitet durch User
Autor: Johannes S. (jojos)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Für welche denn? Zum Vergleich: Windows 3.1 hatte auch kein präemptives
> Multitasking.

Das war auch immer spassig wenn irgendein Programm das ganze System 
lahmlegen konnte...

Ein System mit Prioritäten hat schon Vorteile wenn z.B. GUI + 
Messtechnik auf einer CPU laufen.

Autor: Rolf Magnus (rmagnus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Johannes S. schrieb:
> Rolf M. schrieb:
>> Für welche denn? Zum Vergleich: Windows 3.1 hatte auch kein präemptives
>> Multitasking.
>
> Das war auch immer spassig wenn irgendein Programm das ganze System
> lahmlegen konnte...

Wir sprechen hier allerdings nicht von einem normalen Desktop-System, 
sondern von einem Embedded-System. Da laufen nicht alle möglichen 
Programme von sonstwo, sondern genau eins, das man selbst geschrieben 
hat.
Ob das Programm bei einem Fehler das System lahmlegt oder nicht, macht 
auch nicht viel unterschied, da das Gesamtsystem ohne das Programm eh 
nutzlos ist.
Außerdem kann zumindest im Echtzeit-Systemen bei präemptivem 
Multitasking ein Programm genauso das ganze System lahmlegen, sofern 
seine Priorität entsprechend hoch ist.

> Ein System mit Prioritäten hat schon Vorteile wenn z.B. GUI +
> Messtechnik auf einer CPU laufen.

Ja, das schon. Wenn die GUI irgendwo zuviel Zeit braucht und dann von 
wichtigeren Dingen unterbrochen werden kann, ist das sicher von Vorteil. 
Bei mehreren Cores kann man die beiden Sachen aber entsprechend 
verteilen.

: Bearbeitet durch User
Autor: Johannes S. (jojos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Bei mehreren Cores kann man die beiden Sachen aber entsprechend
> verteilen.

Ich kenne das RiscOS nicht, hat es MultiCore Support? Das wäre natürlich 
gut, aber MultiCore macht ein OS auch komplexer. Es gibt ja trotzdem 
gemeinsam genutzte Resourcen die gegeneinder geschützt werden sollten.
Habe mal kurz nach QNX und Raspberry gegoogelt, da gab es wohl auch mal 
Ansätze. Die verlaufen aber in nicht mehr existierende Seiten, gibts das 
noch?
Dann finde ich noch TouchGFX recht cool, gibts aber auch nicht für den 
Raspberry. Nur für die 'fetteren' NXP+STM Cortex-M.
Warum dann eigentlich nicht das gut unterstützte Raspian? So langsam 
bootet das ja auch nicht.

: Bearbeitet durch User
Autor: Mr. Big (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Außerdem kann zumindest im Echtzeit-Systemen bei präemptivem
> Multitasking ein Programm genauso das ganze System lahmlegen, sofern
> seine Priorität entsprechend hoch ist.


Nur bei sehr einfachen Systemen mit statischen Prioritäten. Ein 
vernünftiger Scheduler verhindert das.

Autor: Rolf Magnus (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mr. Big schrieb:
> Rolf M. schrieb:
>> Außerdem kann zumindest im Echtzeit-Systemen bei präemptivem
>> Multitasking ein Programm genauso das ganze System lahmlegen, sofern
>> seine Priorität entsprechend hoch ist.
>
> Nur bei sehr einfachen Systemen mit statischen Prioritäten. Ein
> vernünftiger Scheduler verhindert das.

Ja, bei Desktop-Systemen. Bei Echtzeit-Systemen will man das nicht.

Autor: Mr. Big (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Ja, bei Desktop-Systemen. Bei Echtzeit-Systemen will man das nicht.

Doch, genau da.

Insbesondere der Deadline Scheduler wurde ja in Hinblick auf Echtzeit 
wissenschaftlich intensiv untersucht.

Autor: Mr. Big (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Als Einstieg:
https://www.elektronikpraxis.vogel.de/das-rtos-der...

Ansonsten google, gibt etliche wissenschaftliche Abhandlungen zum Thema.

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mr. Big schrieb im Beitrag #5259848

>
> RiscOS hat nicht mal preemptives Multitasking. Damit fällt es für viele
> ernst zu nehmende Aufgaben aus. Insofern gebe ich Stefan Us völlig
> recht.

So richtig spassig, wenn dann mal einfach irgenwann ein unbefriedigter 
Watchdog das System neustartet, wie im berüchtigten Espressif-OS-Murks. 
Für die meisten einfachen Anwender eines OS das Totschlagargument. Mit 
Kombis aus einfacher Mainloop, meinetwegen auch mit 
protothread-Konstrukten verunstaltet und einem deadline-scheduler fährt 
man IMHO am sichersten für die meisten Zwecke wo Linux aussen vor ist 
oder pthreads und Semaphorengefuddel verboten sind.

Autor: B. R. (bero)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:

> RiscOS bootet so schnell wie Circle oder ultibo und kann alles was Linux
> kann und ist auch noch sicher.

Das stimmt so nicht. Zum einen mal kooperatives Multitasking, das ist 
ein nogo (zumindest bei mir).

Und es hat vielleicht 1% des Sofwarebestandes von Linux, vor allem an 
Bibliotheken fuer alles und jedes. Beispiel gefaellig? MariaDB, 
Gtk/GLib, Qt, ....

Ein anderer Vorteil von Linux ist, dass ich auf dem PC alles KOMPLETT 
FERTIG entwickeln kann, mit den identischen Bibliotheken und mit 
brauchbaren Entwicklungsumgebungen und mit schneller Compilierung. Auf 
dem Raspi ist dann nur ein einfaches neuebersetzen noetig, fertig und 
laeuft identisch (oder gar cross-compiling auf dem PC, aber das ist je 
nach Fall nicht immer so einfach).

Nicht falsch verstehen: Ich will das RiscOS keineswegs schlechtmachen 
(und habe es mir auch schon angeschaut - ein coole Sache), aber als 
Ersatz fuer Linux ist es nur in ganz bestimmten Faellen brauchbar.

P.S.: Schade, dass es kein wirklich natives AmigaOs (oder AROS), das 
waere noch interessanter (jaja, ich weiss, das wurde in grauer Vorzeit 
glaube ich sogar vom RiscOS abgeleitet).

Autor: Brummbär (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhard R. schrieb:
> Und es hat vielleicht 1% des Sofwarebestandes von Linux,

"Linux" ist nur der Kernel. Die Programme gehören nicht dazu.

Autor: Alex Ge (dragongamer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zum Thema bootgeschwindigkeit weise ich mal auf die interessanten Daten 
eiens Users hier hin: 
Beitrag "Re: zuverlässige SD-Karte für Raspberry Pi"
Verwende das richtige Dateisystem!

Ansonsten habe ich im Kopf, dass Bootzeiten von ~8s beim Raspberry mit 
abgespecktem, GUI-losen Linux realistisch sind. Die GUI dann zu starten 
dürfte noch eine Hand voll Sekunden dauern.

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhard R. schrieb:
> Ein anderer Vorteil von Linux ist, dass ich auf dem PC alles KOMPLETT
> FERTIG entwickeln kann

Und wie simulierst du auf dem PC die Embedded Hardware am Pi?

Bei RiscOS braucht man normalerweise 2x Pi - eines mit Desktop zur 
Entwicklung und eines mit pico - dafür hat man an beiden dieselbe 
Hardware.

Es gibt auch preemptive und RT Threads aber die nutzen wir gar nicht. 
Das embedded programm muss in Echtzeit laufen, der Rest ist erst mal 
egal. Dann steht halt die GUI mal 1 sec mit hourglass.

Die Entwicklung hat mehr Ähnlichkeit mit uC - daher für Linux Nutzer 
gewöhnungsbedürftig.

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan U. schrieb:
> Ohne RiscOS jetzt schlecht machen zu wollen:
> Wenn etwas schneller kleiner billiger und zugleich besser sein soll,
> werde ich immer sehr skeptisch. Denn das ist selten der Fall. Wenn es so
> wäre, müsste das System sehr viel weiter verbreitet sein und der
> Firmenchef wäre bekannter als Bill Gates und Tim Cook zusammen.

Schau mal in Wikipedia unter NCOS dann wird klar warum RiscOS heute 
nicht so verbreitet ist.

Autor: B. R. (bero)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brummbär schrieb:
> "Linux" ist nur der Kernel. Die Programme gehören nicht dazu.

Das ist mir wohl bewusst, aber 99% aller Leute meinen mit "Linux" den 
Kernel+Treiber+Userspace-Programme, also nutze ich den Begriff in der 
gleichen Weise auf die Gefahr hin, dass mich die 1% Haarespalter 
absichtlich missverstehen koennen ;-)

P.S.: Ich arbeite mit Linux seit "Ygdrassil Linux" 
(https://de.wikipedia.org/wiki/Yggdrasil_Linux), der Oberlehrer bringt 
also wenig.

Autor: Marian M. (mrhat2010)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier findet sich eine Sammlung an Dokumenten und Vorträgen zum Thema 
Embedded Linux, unter anderem zur Boot time Optimierung.
https://free-electrons.com/docs/

: Bearbeitet durch User
Autor: B. R. (bero)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Lothar schrieb:

> Und wie simulierst du auf dem PC die Embedded Hardware am Pi?

Die zusaetzliche Hardware ist per RS232 angebunden, hauptsaechlich eine 
Sub-CPU (ein Cortex M3), der auch den ganzen Echtzeit-Kram macht und 
weitere serielle Schnittstellen zu weiterer Hardware bereitstellt (quasi 
als UART/SPI Bridge) sowie ein bisschen PWM macht und ein paar Inputs 
auf Aenderungen prueft. Die Dinger kosten ja kaum noch was (in meinem 
Fall < 1 Euro).

Das mag anachronistisch klingen, hat aber einige Vorteile, z.B. muss ich 
eben gar nichts simulieren und ich kann den CM3 direkt vom Raspi aus mit 
neuer Firmware beladen. Und auf die paar cm kriegt man auch ordentlich 
Baudraten hin.

> Bei RiscOS braucht man normalerweise 2x Pi - eines mit Desktop zur
> Entwicklung und eines mit pico - dafür hat man an beiden dieselbe
> Hardware.

Auch eine Moeglichkeit, aber der PC ist eben schon eine andere Nummer. 
Wir lassen z.B. auf dem Raspi auch eine groessere (selbstentwickelte 
natuerlich) Software laufen, die braucht > 12 Minuten zum compilieren 
auf dem Raspi. Auf dem PC nur 30 Sekunden. Das laeppert sich zusammen, 
wenn man alles erst mal auf einem PC fertig entwickeln kann.

> Es gibt auch preemptive und RT Threads aber die nutzen wir gar nicht.
> Das embedded programm muss in Echtzeit laufen, der Rest ist erst mal
> egal. Dann steht halt die GUI mal 1 sec mit hourglass.

Ich verstehe, kann ich mir gut vorstellen das das gut funktioniert. In 
der Praxis brauchbares Echtzeitverhalten auf einem Raspi mit Linux ist 
schon ein Aufwand.

> Die Entwicklung hat mehr Ähnlichkeit mit uC - daher für Linux Nutzer
> gewöhnungsbedürftig.

Oh, ich mache beides seit langer Zeit und springe im Abstand von Minuten 
oder auch Tagen oder Wochen dazwischen hin und her (also PC - Raspi - 
Mikrocontroller). Und dazwischen noch zum "Ausruhen" ;-) die 
Elektronikentwicklung. Nur bestuecken machen wir nicht (mehr) selber 
(ausser Prototypen und vielleicht hie und da 0-Serien).

Das ist jedesmal sowas wie ein Kulturschock ;-)

Autor: Patrick B. (p51d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan U. schrieb:
> Linux natürlich.
> Warum? Weil es die vom Board Hersteller unterstützte Lösung ist. Und
> weil es nichts kostet.

Lothar schrieb:
> Abgesehen davon kommt es auf den Einsatz an. Wenn es sicherheitskritisch
> ist, sollte immer GUI und Steuerung getrennt sein. Also ein Pi für die
> GUI und ein anderes Pi ohne Desktop für die Steuerung (oder eben uC oder
> SPS)

Ok, ist zwar schon länger her, aber da würde mich mal noch ein paar 
Dinge interessieren:
- Soweit ich weiss muss man bei Linux Lizenzgebühren zahlen, wenn man 
das ganze verkaufen möchte, also nix mit gratis.
- Im Sicherheitsbereicht kann man dann auch nicht irgend ein Linux 
nehmen, sondern man braucht schon geprüfte und freigegebene Kernels, 
Compilers, IDE... dazu kommt, dass der eigene Code ebenfalls abgenommen 
werden muss. Da denke ich ist ein Rasperry mehr als falsch
- Darf man Rapserry etc. überhaupt in eigenen Geräten verkaufen? Ich 
kann mich errinnern, das dies einmal verboten war. Also nur zu 
Bastelzwecke und eigenbedarf einsetzbar ist.

Noch meine persönliche Meinung zu Boot-Zeiten:
Mich interessiert selten ob ein Gerät nun 1sec oder 10sec zum booten 
hat. Hautpsache es läuft im Anschluss flüssig. Selbst ein Smartphone 
oder ein Tablett hat >20sec zum booten (also bis man damit arbeiten 
kann). Wieso also hier so viel Optimierungsaufwand reinstecken?

Gruss

Autor: B. R. (bero)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Marian M. schrieb:
> Hier findet sich eine Sammlung an Dokumenten und Vorträgen zum Thema
> Embedded Linux, unter anderem zur Boot time Optimierung.
> https://free-electrons.com/docs/

Sehr schoen. Das erste ist natuerlich immer ein "systemd-analyze" und 
"systemd-analyze blame" bzw. "systemd-analyze plot > boot.svg", damit 
man mal einen Ueberblick bekommt, was sich lohnt.

Damit bin ich von 22.5s auf 8.1s runtergekommen mit ein paar einfachen 
Massnahmen, die sich aus den obigen Ausgaben von selbst ergeben. Das 
reicht erst mal fuer mich (da geht sicher noch was, wenn man Aufwand 
betreibt).

: Bearbeitet durch User
Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Georg A. schrieb:
> (verstaubte-Erinnerung-ausgrab): Gab es bei frühen elektronischen
> Stellwerken nicht den Trick, die Anzeige pro Frame aktiv vom gerade
> anzeigenden auf den jeweils anderen Computer zu wechseln? Dazu gab es
> noch ein Indikator-Zeichen irgendwo im Eck, der eine macht - der andere
> |. Wenn dann kein + da steht, ist was eingefroren...

Ja, und die Systeme haben dann auch alles was die gezeichnet haben 
gleich zurückgelesen. Und im Eck waren auch Felder an denen man schnell 
sehen konnte, ob eine Farbe ausgefallen war. Und natürlich alles 
redundant mit ständigem Umschalten, so dass man Störungen schnell als 
"Blinken" merkt.

Irgendwie schade, dass man das nicht mehr macht. Die Aufgaben sind ja 
damals wie heute eher trivial, so dass selbst ein simpler 
"Selbstbau"-Rechner nicht viel teurer sein muss als einer von der 
Stange.

Autor: B. R. (bero)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Patrick B. schrieb:
> - Soweit ich weiss muss man bei Linux Lizenzgebühren zahlen, wenn man
> das ganze verkaufen möchte, also nix mit gratis.

Das ist definitiv falsch.

> - Im Sicherheitsbereicht kann man dann auch nicht irgend ein Linux
> nehmen, sondern man braucht schon geprüfte und freigegebene Kernels,
> Compilers, IDE... dazu kommt, dass der eigene Code ebenfalls abgenommen
> werden muss. Da denke ich ist ein Rasperry mehr als falsch

Vermutlich. Wobei in Deutschland und Oesterreich ja der 
Zertifizierungspilz wuchert, das es eine Freude ist (und das nicht nur 
im Sicherheitsbereich). Aus der Erfahrung kann ich sagen: I.a. sind die 
Sachen, die von Enthusiasten entwickelt wurden, wesentlich besser als 
das Zeugs von Firmen, die die halbe Zeit kiloweise Papier produzieren 
(muessen).

Und die ganzen Zertifizierer sind eine Klasse fuer sich. In der Regel 
haben die von den zugrundeliegenden technischen Details der Sache, die 
sie da zertifizieren, nur sehr wenig Ahnung. Sie besorgen sich halt die 
Normen und ueberlegen dann, was sie in den teuren Bericht schreiben.

Sorry wenn sich jetzt jemand auf den Schlips getreten fuehlt, aber das 
ist nun mal meine Erfahrung. Und ich habe das noch viel zu freundlich 
geschrieben ;-)

> - Darf man Rapserry etc. überhaupt in eigenen Geräten verkaufen? Ich
> kann mich errinnern, das dies einmal verboten war. Also nur zu
> Bastelzwecke und eigenbedarf einsetzbar ist.

Das ist sicher falsch. Z.B. das CM3 (ComputeModule3) ist im Prinzip 
nichts anderes als ein Raspi3 ohne Stecker, das ist explizit fuer die 
Industrie gedacht. Ich habe auch vor einigen Monaten (?) gelesen, dass 
irgend ein bekannter Fernseherhersteller (NEC?) einen Raspi in einen 
seiner Fernseher einbauen will? Finde den Link nicht mehr.

Es ist ja auch fuer den RaspiZero (und /W) nicht explizit verboten, das 
Teil in einem zu verkaufenden Geraet einzubauen. Nur verhindert man de 
facto eine professioneller Verwendung, indem die Abgabe auf 1 Stk. pro 
Bestellung limitiert und Mehrfachbestellungen storniert.

Das war fuer den Zero und Anfangs fuer den ZeroW natuerlich sinnvoll, 
damit die privaten Bastler (das beschschschschEIDENE Wort "Maker" 
vermeide ich) auch mal an so ein Ding kommen.

Inzwischen (fast ein Jahr nach dem Start) ist es fuer den ZeroW wohl nur 
mehr Beutelschneiderei des Haendlerpacks (sorry), weil sie am ZeroW 
alleine "zuwenig" verdienen. Schade eigentlich, da waeren schnell mal 
ein paar 100.000 zusaetzliche Stueck zu verkaufen denke ich.

> Noch meine persönliche Meinung zu Boot-Zeiten:
> Mich interessiert selten ob ein Gerät nun 1sec oder 10sec zum booten
> hat. Hautpsache es läuft im Anschluss flüssig. Selbst ein Smartphone
> oder ein Tablett hat >20sec zum booten (also bis man damit arbeiten
> kann). Wieso also hier so viel Optimierungsaufwand reinstecken?

Prinzipiell korrekt. Trotzdem schadet es nicht, wenn man es mit sagen 
wir 1h Aufwand schafft, die Bootzeit von 22s auf 8s druecken kann. Es 
gibt Leute (Kunden), fuer die das auch ein Kaufargument ist.

Autor: Alex Ge (dragongamer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhard R. schrieb:
> Inzwischen (fast ein Jahr nach dem Start) ist es fuer den ZeroW wohl nur
> mehr Beutelschneiderei des Haendlerpacks (sorry), weil sie am ZeroW
> alleine "zuwenig" verdienen. Schade eigentlich, da waeren schnell mal
> ein paar 100.000 zusaetzliche Stueck zu verkaufen denke ich.

War es nicht mal so dass man den Zero, für 5$ ja an Afrika und Indien 
vertreiben wollte? Also für Schulen, etc.
Weiss nicht so ganz was daraus geworden ist, aber wenn das zutrifft, 
werden die Händler die Teile auf jeden Fall in Massen los und das 
Problem sind die Fertigungskapazitäten.

Bundles sind in der tat in den shops meist die "default" Einstellung, 
aber man kann auch ohne Bundle kaufen.
Allerdings so ab ~10€.
Immer noch recht günstig für einen ARM mit GPU und fertiger 
Spannungsversorgung sowie GPIOs...

: Bearbeitet durch User
Autor: Patrick B. (p51d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhard R. schrieb:
> Vermutlich. Wobei in Deutschland und Oesterreich ja der
> Zertifizierungspilz wuchert, das es eine Freude ist (und das nicht nur
> im Sicherheitsbereich). Aus der Erfahrung kann ich sagen: I.a. sind die
> Sachen, die von Enthusiasten entwickelt wurden, wesentlich besser als
> das Zeugs von Firmen, die die halbe Zeit kiloweise Papier produzieren
> (muessen).

Ich denke es kommt stark auf den Sicherheitsbereich an: 
sicherheitskritische Teile bei Auto-, Bahn-, Flug- und Medizintechnik 
war das zumindest vor 3 Jahren so.

Bernhard R. schrieb:
> Es ist ja auch fuer den RaspiZero (und /W) nicht explizit verboten, das
> Teil in einem zu verkaufenden Geraet einzubauen. Nur verhindert man de
> facto eine professioneller Verwendung, indem die Abgabe auf 1 Stk. pro
> Bestellung limitiert und Mehrfachbestellungen storniert.

Ok, das ist interessant. Aber ich denke die Verfügbarkeit wird der 
Ausschlaggebende Punkt sein.
Wir haben schon Probleme unsere Ersatzteilgarantie von 10 Jahren zu 
gewährleisten. Wie es mit ursprünglich für Bastler designte Boards 
aussieht, weiss ich nicht. Denke, dass man diese aber spätestens nach 5 
Jahren nicht mehr in dieser Form und Menge bekommt.

Autor: Alex Ge (dragongamer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Patrick B. schrieb:
> Ok, das ist interessant. Aber ich denke die Verfügbarkeit wird der
> Ausschlaggebende Punkt sein.
> Wir haben schon Probleme unsere Ersatzteilgarantie von 10 Jahren zu
> gewährleisten. Wie es mit ursprünglich für Bastler designte Boards
> aussieht, weiss ich nicht. Denke, dass man diese aber spätestens nach 5
> Jahren nicht mehr in dieser Form und Menge bekommt.

Ja, für richtig seriöse Produkte ist das Compute Module gedacht:
>Raspberry Pi garantiert die Verfügbarkeit von CM3 und CM3 Lite mindestens bis 
>Januar 2023.
Wer damit solch wichtige Geräte baut, wird sich wohl ein paar auf Halde 
legen - ist aber kein großer Kostenfaktor.

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhard R. schrieb:
> CM3 (ComputeModule3) ist im Prinzip nichts anderes als ein Raspi3
> ohne Stecker, das ist explizit fuer die Industrie gedacht

Damit haben wir aktuell Probleme. Das hat ja ausreichend eMMC Flash um 
RiscOS oder auch Stretch Lite ohne SD Karte oder USB SSD laufen zu 
lassen. Irgendwie verhält sich der Flash aber doch anders beim 
beschreiben so dass nach einiger Zeit Probleme im Dateisystem der FAT 
Boot Partition auftreten.

Bei diesem Industrie Board gibt es das Problem nicht. Keine Ahnung was 
der Unterschied bezüglich Flash ist. Dieses Board ist allerdings 
wesentlich teurer. Hat dafür nativ SATA und einiges mehr.

http://www.ti.com/devnet/docs/catalog/thirdpartyde...

Autor: B. R. (bero)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex G. schrieb:
> Bundles sind in der tat in den shops meist die "default" Einstellung,
> aber man kann auch ohne Bundle kaufen.
> Allerdings so ab ~10€.

Man kann den Zero auch fuer Eur 5,-- kaufen (ohne Versand), aber eben 
immer nur EIN Stueck pro Bestellung, teilweise werden sogar 
Mehrfachbestellungen storniert, obwohl man da ja bereit waere, bei JEDEM 
Stueck 1x Versand zu bezahlen.

Wie gesagt kann ich das beim Zero verstehen, da werden (immer noch) nur 
geringe Stueckzahlen produziert und es soll ja jeder der will wenigstens 
einen bekommen.

Beim ZeroW, der mit VIEL hoeheren Stueckzahlen produziert wird, halte 
ich das, fast ein Jahr nach dem Start fuer reine Geschwaeftemacherei.

Etliche Leute (ich will jetzt nicht schreiben "Wichtigtuer"...) haben 
beim ZeroW Start damals auch ihre Meinung kundgetan, man solle sich doch 
nicht aufregen ueber die Begrenzung auf 1 Stueck, das werde nach ein 
paar Wochen sowieso fallen. Na, das war wohl nix.

Ich bin mir recht sicher, dass es an den Haendlern liegt. Hier sollte 
die Raspberry Foundation mal ordentlich Druck machen, indem einfach mehr 
Haendler zugelassen werden, dann erledigt sich das Problem von selbst.

Autor: B. R. (bero)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:

> Irgendwie verhält sich der Flash aber doch anders beim
> beschreiben so dass nach einiger Zeit Probleme im Dateisystem der FAT
> Boot Partition auftreten.

Auf der BOOT Partition? Das wundert mich sehr! Habt Ihr Stromausfaelle?

Es ist naemlich so, dass wegen moeglicher Kernel updates /boot 
defaultmaessig readwrite gemountet ist.
Vielleicht wuerde es helfen, /boot erst mal generell ro zu mounten? 
Hierzu einfach in /etc/fstab bei /boot das "defaults" durch 
"defaults,ro" ersetzen.

Vor einem Kernel-Update muesste man dann /boot eben kurzfristig wieder 
rw mounten:

sudo mount -o remount,rw /dev/mmcblk0p1 /boot

Fuer root wuerde ich auch auf dem CM3 jedenfalls F2FS empfehlen wollen, 
obwohl ich damit noch keine echten Erfahrungen vorweisen kann, aber in 
einem halben oder ganzen Jahr kann ich dazu dann was berichten.

Autor: Lothar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhard R. schrieb:
> /boot defaultmaessig readwrite

Nicht das /boot sondern die Bootloader Partition wo kernel.img drin ist. 
Da ist nur FAT zulässig.

Autor: B. R. (bero)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar schrieb:
> Nicht das /boot sondern die Bootloader Partition wo kernel.img drin ist.
> Da ist nur FAT zulässig.

Da gibt es wohl ein Missverstaendnis.

Die Bootpartition /dev/mmcblk0p1 wird eben beim Hochfahren auf /boot 
gemountet, das IST also quasi die Bootpartition (jedenfalls das 
FAT-Filesystem, das da drauf ist). Und zwar "readwrite", weil man ja hie 
und da ein Kernelupdate macht und dabei das kernel.img ueberschrieben 
wird.

Wenn Du sie nun ueber /etc/fstab readonly mounten laesst, schuetzt Du 
sie vor Schreibzugriffen und sie geht Dir nicht mehr so leicht kaputt.

Autor: B. R. (bero)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Patrick B. schrieb:
> Bernhard R. schrieb:
>> Es ist ja auch fuer den RaspiZero (und /W) nicht explizit verboten, das
>> Teil in einem zu verkaufenden Geraet einzubauen. Nur verhindert man de
>> facto eine professioneller Verwendung, indem die Abgabe auf 1 Stk. pro
>> Bestellung limitiert und Mehrfachbestellungen storniert.
>
> Ok, das ist interessant.

Kuerzlich gefuehrte "Gespraeche" ueber Email usw. mit der Raspi 
Foundation ergeben nun ein etwas anderes Bild bezueglich der 
Stueckzahlen.

Es ist offenbar die Foundation Politik, nur 1 Stueck pro Kunden fuer 5$ 
(Zero) bzw. 10$ (ZeroW) abzugeben. Groessere Stueckzahlen kann man 
offenbar durchaus kaufen, aber zu deutlich hoeherem Preis und man muss 
der Raspi Foundation auch genau erlaeutern, fuer welchen Einsatzzweck.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

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