*BSD-Linux-„Mischformen“

[rmoe]

Selbst RTOS ist ja ein recht weit gefasster Begriff; da ist ja von der (oft Hersteller-)library mit "Treibern", z.B. für USB, UART, usw., bis hin zum fetten "RT" Linux Moloch alles mögliche dabei. Obwohl ich Kamikazes Inkompetenz Argument zustimme, sehe ich auch Goblins Punkt, nicht alles selbst machen, nicht jedes Rad neu implementieren zu müssen und so ja auch Fehler zu vermeiden.

Nur, mal ehrlich, das ist ja eine ganz andere Dimension als Goblins ursprüngliches Auto Argument. Bei dem nämlich kommt nicht einfach Funktionalität dazu, sondern ganze (und ganz andere) Funktionalitäts-Dimensionen, die wenig bis nichts mit der ursprünglichen Funktionalität zu tun haben. Da ist inzwischen ja wirrer Mist wie "Funktionen mit ipad steuern" dabei.

Interessanterweise wird damit (meinem Empfinden nach) die "Ursünde" wiederholt, nämlich Knopfi-Bunti-Gaga, modern "user experience" in den Vordergrund zu rücken, sprich, Engineering Entscheidungen zunehmend in die Hände von Marketing Leuten zu legen.
Dabei habe ich eigentlich nichts gegen Bunti-Gaga und Styles für's Armaturenbrett, nur zeigt die Erfahrung leider, dass mit dieser Fokusverschiebung in aller Regel die eigentliche und wesentliche Funktionalität - und vor allem deren Qualität - in den Hintergrund rückt und irgendwann auch quasi als Belästigung empfunden wird. Andererseits, seien wir konstruktiv, können vermutlich deutlich mehr Frauen für Stylingfragen und Tachometer-Themes gewonnen werden ...

 

[Kamikaze]

Nun, die ganze iPad Bedien GAGA kann man auf einer x86- oder Smartphone-CPU ganz ohne RTOS machen. Das betrifft ja nicht dein ABS oder die Automatik-Schaltung. Das kann ein billiger 8-Bitter tun.

Auch Treiber-Bibliotheken setzen nicht zwangsweise ein OS voraus. Auch hier sehe ich die Kausalität nicht wirklich. Wenn ich an meine Rennautos erinnern darf. Da sind über 10000 Zeilen Bibliotheken, auf die jedes Steuergerät zurückgreift. CAN, Flash-Speichern, SPI, PWM, Pulsweitenmessung, AD-Wandlung, 7-Segment-Anzeigen etc.. Die eigentlichen Programme sind dann jeweils nur so 200 bis 1000 Zeilen Code.

 

[rmoe]

Nun sei nicht so pingelig, Kamikaze! *g
Du weisst so gut wie ich, dass manche library in dem Bereich noch schnell eine nano "Runtime" dazu kriegt und dann RTOS genannt wird. Aber im Grunde sehen wir beide das doch recht ähnlich, nämlich: a) Klappe nicht aufreissen, solange man nicht mal einiges ganz ohne fremdes Zubehör gemacht hat und b) Ein RTOS, was immer man en detail darunter verstehen mag, muss doch bitte zum Projekt passen.

Und mal ehrlich: Wir sind nicht alle in allem Gurus - und auch nicht jedes Projekt ist es wert. In vielen Fällen ist ein kleines RTOS schon praktisch. Mag ja sein, dass ich z.B. den 430er in und auswendig kenne, aber das heisst ja nicht, dass ich auch auf einem anderen MP alles locker und korrekt - und mit halbwegs angemessenem Aufwand! - händisch hinkriege.

Und da oben ging es mir eher darum, dass Goblin, so sehe ich es jedenfalls, mal eben die Latte zwischen zwei Beiträgen erheblich verschoben hat.

 

[goblin]

Selbst RTOS ist ja ein recht weit gefasster Begriff; da ist ja von der (oft Hersteller-)library mit "Treibern", z.B. für USB, UART, usw., bis hin zum fetten "RT" Linux Moloch alles mögliche dabei.

Okay, ich hab es wohl nicht deutlich genug ausgedrückt: ein kleines RTOS, das danach genannte FreeRTOS war als Beispiel dafür gedacht. RT-Linux habe ich absolut garnicht gemeint, dachte das wäre deutlich gewesen.

Obwohl ich Kamikazes Inkompetenz Argument zustimme, sehe ich auch Goblins Punkt, nicht alles selbst machen, nicht jedes Rad neu implementieren zu müssen und so ja auch Fehler zu vermeiden.

Ich halte das Inkompetenz-Argument für sehr gefährlich bis schlicht falsch. Damit macht man es sich zu einfach, dem zugrunde liegt die ingenieursmäßige Abwägung, was wirtschaftlicher ist:
ein größerer Prozessor mit Linux, wenn man weniger Arbeit hineinstecken muss, oder doch einen winzigen, billigen Prozessor für sehr große Stückzahlen. Es ist schlicht und einfach die Frage, ob auf Dauer die Arbeitszeit der Programmierer oder die Stückzahl der Hardware teurer kommt.

Nur, mal ehrlich, das ist ja eine ganz andere Dimension als Goblins ursprüngliches Auto Argument.

Das war nicht mein Argument, daher no comment.

Wenn ich an meine Rennautos erinnern darf. Da sind über 10000 Zeilen Bibliotheken, auf die jedes Steuergerät zurückgreift. CAN, Flash-Speichern, SPI, PWM, Pulsweitenmessung, AD-Wandlung, 7-Segment-Anzeigen etc.. Die eigentlichen Programme sind dann jeweils nur so 200 bis 1000 Zeilen Code.

Wenn ich an deine Rennautos erinnern darf, ihr habt da alle zu eurer eigenen Erheiterung daran gearbeitet und wurdet nicht von einer Firma bezahlt, wenn ich da richtig informiert bin.
Wenn die Arbeitszeit kostenlos ist, dann ist alles selbermachen natürlich unschlagbar billig. Das sieht aber komplett anders aus, wenn der Programmierer dafür bezahlt werden möchte, oder gleich ein ganzes Team. Wenn man dann nicht gleich Stückzahlen wie in der Automobilbranche fertigt, dann ist ein streng genommen viel zu fetter Prozessor mit viel zu viel Software dennoch weitaus wirtschaftlicher.

Ich persönlich finde es auch eine Unsitte, für alles mögliche einen Raspberry Pi hinzuklatschen, dessen GPIO-Pins nach Wunsch zu verdrahten und in zwei Stunden ein Python-Script hinbasteln, das die Dinger so ansteuert, dass es tut was man braucht. Aber wenn wir ehrlich sind: das ist unschlagbar schnell und billig, wenn ich nur am Endergebnis interessiert bin und bestenfalls nichtmal ein weiteres dieser Konstrukte fertigen muss, dann ist das für dieses Ziel genau die richtige Lösung.

 

[chaos]

Es ist allerdings bequemer, wenn man das Ding nicht komplett selber bauen muss, sondern wie eine Library reinlinken kann.
Ist dann auch leichter und schneller erweiterbar.

Genau. Und Betriebsystem darf man nicht mit einem POSIX-Betriebssystem verwechseln. Die Realtime-Betriebssysteme im Automotive Bereich stellen wohl nicht wirklcih viele Schnittstellen zur Verfügung. Andererseits will nicht jeder Programmierer eines MultiCore-µC alles selber bauen.

 

[Kamikaze]

Wenn ich an deine Rennautos erinnern darf, ihr habt da alle zu eurer eigenen Erheiterung daran gearbeitet und wurdet nicht von einer Firma bezahlt, wenn ich da richtig informiert bin.
Wenn die Arbeitszeit kostenlos ist, dann ist alles selbermachen natürlich unschlagbar billig. Das sieht aber komplett anders aus, wenn der Programmierer dafür bezahlt werden möchte, oder gleich ein ganzes Team. Wenn man dann nicht gleich Stückzahlen wie in der Automobilbranche fertigt, dann ist ein streng genommen viel zu fetter Prozessor mit viel zu viel Software dennoch weitaus wirtschaftlicher.

Ich persönlich finde es auch eine Unsitte, für alles mögliche einen Raspberry Pi hinzuklatschen, dessen GPIO-Pins nach Wunsch zu verdrahten und in zwei Stunden ein Python-Script hinbasteln, das die Dinger so ansteuert, dass es tut was man braucht. Aber wenn wir ehrlich sind: das ist unschlagbar schnell und billig, wenn ich nur am Endergebnis interessiert bin und bestenfalls nichtmal ein weiteres dieser Konstrukte fertigen muss, dann ist das für dieses Ziel genau die richtige Lösung.

Das niedrige Stückzahlen-Argument muss ich euch zugestehen. Bei uns waren Materialkosten natürlich das A und O.

Trotzdem war unsere Entwicklerzeit natürlich begrenzt (eine Person kann nur ca. 100h in der Woche arbeiten). Deshalb wurde auch möglichst viel Code in wiederverwendbare Bibliotheken gesteckt und überall der gleiche µC eingesetzt. Sonst hätte das nicht geklappt. Nur bei einem Steuergerät, das von jemand Anderem programmiert wurde, sollte ein 16-Bit µC rein. Das ging dann schief und wurde kurzfristig durch ein Eval-Board mit unserem Standard-µC ersetzt. Dank der Bibliotheken waren die wichtigsten Funktionen an einem Tag implementiert.

 

[kraileth]

Na, da habe ich ja etwas losgetreten! Hat sich zwar thematisch recht weit vom ursprünglichen Gegenstand entfernt, war aber ausgesprochen interessant. Insofern paßt das sicherlich.