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.
Da sollte eigentlich Lubuntu drauf laufen, das müsste dann von SD Karte in 20 Sekunden booten.
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.
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
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).
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.
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
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/thirdpartydevtoolfolder.tsp?actionPerformed=productFolder&productId=24320 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)
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?
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/raspberry-pi-3 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.
> 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.
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...
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 ;-)
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
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: (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.
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.
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.
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.
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.
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
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.
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
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.
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.
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.
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.
Als Einstieg: https://www.elektronikpraxis.vogel.de/das-rtos-der-zukunft-a-58361/ Ansonsten google, gibt etliche wissenschaftliche Abhandlungen zum Thema.
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.
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).
Bernhard R. schrieb: > Und es hat vielleicht 1% des Sofwarebestandes von Linux, "Linux" ist nur der Kernel. Die Programme gehören nicht dazu.
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.
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.
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.
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.
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
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 ;-)
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
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
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.
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.
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
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.
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.
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/thirdpartydevtoolfolder.tsp?actionPerformed=productFolder&productId=24320
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.
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.
Bernhard R. schrieb: > /boot defaultmaessig readwrite Nicht das /boot sondern die Bootloader Partition wo kernel.img drin ist. Da ist nur FAT zulässig.
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.
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.
Bitte 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.