Hallo,
ich möchte mich gerne in Embedded Linux einarbeiten und komme aber aus
der Windows-Welt. Jetzt weiss ich nicht so richtig, wie ich einsteigen
soll.
Wäre es hilfreich zuerst mal Linux auf nem Rechner zu installieren und
damit zu spielen oder direkt ein Eva-Board kaufen, auf dem ein Embedded
Linux läuft?
Wie sind da eure Erfahrungen bzw wie seid ihr das Thema angegangen?
Grundlagen in Embedded Systems sind da (Programmierung in C, Atmel AVR,
Elektronikgrundlagen).
Gruß Mattes
Moin,
es läuft deutlich schmerzfreier ab wenn du dich erstmal mit Linux auf
einem normalen Rechner auseinander setzt. Alternativ kannst du auch
Linux in einer virtuellen Maschine unter Windows installieren und damit
die ersten Schritte machen.
Gruss,
Tobi
Es ist zum entwickeln sowieso von Vorteil auf dem Host auch ein Linux
laufen zu haben (aber kein Muss).
Ah ja kannst erstmal auch VirtualBox verwenden.
Hab mich jetzt etwas mit Ubuntu beschäftigt und würd jetzt gern mal
eigene Applikationen einbringen. Jetzt stellt sich natürlich die Frage
wie ich das mache. Ich habe mal einen Roboter programmiert, auf dem ein
portiertes OSEK lief. Da konnte ich meine Applikation schreiben, neu
compilieren und den Roboter bzw den Prozessor neu flashen.
Diese Vorgehensweise wird wohl eher schwierig bei Ubuntu. Wie stelle ich
das nun an?
Für nicht in den Repositories verfügbare Programme mit dem Programm
Checkinstall. Selbstgeschriebene einfache Programme braucht man zu
Testzwecken nicht wirklich zu installieren sondern kann sie einfach so
ausführen.
blubb schrieb:> Selbstgeschriebene einfache Programme braucht man zu> Testzwecken nicht wirklich zu installieren sondern kann sie einfach so> ausführen.
Wow ! ;-)))
Auch wenn ich Ubuntu nicht schlechter reden will als es ist: Ubuntu ist
für den Einstieg in die Linux-Welt sicherlich großartig, aber, ich
denke, sobald man wirklich am System "herumfrickeln" möchte gibt es
bessere Distributionen, welche das Ganze einfacher gestalten und bei
denen sich die vom Macher betriebene Politik nicht ganz so stark in den
Weg stellt wie es z.B. bei Ubuntu der Fall ist.
Nennen möchte ich: Arch Linux, Gentoo und LFS (Linux From Scratch). Ganz
klar: Alle drei sind "fortgeschrittene" Distributionen, die einen
Anfänger bzw. Umsteiger sicherlich überfordern. Hat man aber das nötige
Know-How, dann bieten sie einfach genau das was man will: Möglichst
unverfälschte Software (Stichwort: Upstream), welche möglichst zeitnah
bereit gestellt wird. Vor allem der "Build Process" also das Erstellen
von Packages aus den ursprünglichen Quellen ist bei Arch und Gentoo sehr
viel einfacher (und mächtiger) als bei Debian Derivaten à la Ubuntu.
Übrigens: Wenn du wirklich im Embedded Bereich anfangen willst eignet
sich LFS ganz hervorragend dazu herauszufinden wie die einzelnen
Komponenten bei einem System zusammenarbeiten. Dieses Wissen lässt sich
dann auch relativ einfach auf Embedded Devices ummünzen. Idealerweise
hantierst du damit aber "bloß" in einer virtuellen Machine herum, dann
hast du über das Hostsystem nämlich immer die Möglichkeit dir
Informationen zum aktuellen Schritt/Problem zu beschaffen ;).
Welche Vorteile bietet eigentlich ein OS auf eine Mikrocontroller ?
Programmieren kann ich den ja auch direkt in C oder Assembler. Dinge
wie Benutzerverwaltung, Zugrifsrechte oder ein Filesystem sind für
normale Anwendungen ja eigentlich kaum notwendig. Bei komplexeren
Systemen (zB Fritzbox) sehe ich das ein ... Was bringt das gegenüber
einer "direkten" Programmierung ?
Ich habe mir am WE mal Fedora eingerichtet, auch im Bezug auf den
Raspberry Pi den ich mi evtl kaufen möchte.
Also mir gehts am Anfang halt nur darum auf einem Embedded Linux Board
eine LED zu schalten und Taster einzulesen
Zum Einstieg in embedded Linux kann ich dir das hier empfehlen:
http://cross-lfs.org
Es gibt auch fertige Distributionen speziell für embedded Linux:
http://www.angstrom-distribution.org
Ich würde das CrossLFS empfehlen. Ohne ein komplettes Verständnis, wie
ein Linux eigentlich funktioniert, kommst du bei Problemen nicht weiter.
Joachim Drechsel schrieb:> Welche Vorteile bietet eigentlich ein OS auf eine Mikrocontroller ?
Ein OS bietet mehr als die von dir genannten Feature. Insbesondere halt
auch eine (hoffentlich) vernünftige Prozessverwaltung. Durch
Time-Slicing und Scheduler wird scheinbare Parallelität (bei 1-CPU
Systemen) oder eben sogar echte Parallelität (bei
Mehrkern-Architekturen) gewährleistet.
Bei Mikrocontrollern hat man halt das Problem, dass ein vernünftiges
Betriebssystem komplex und groß ist. Das findet auf gewöhnlichen
Mikrocontrollern halt nur bedingt Platz. Außerdem lassen sich solch
komplexe System auch nicht unbedingt einfach testen.
Übrigens sind Filesysteme bei Mikrocontrollern doch öfter von Nöten als
gedacht. Zumindest gibt es hier mehr als nur ein Projekt, bei welchem
man FAT und ähnliches nachimplementiert.
Mattes schrieb:> Also mir gehts am Anfang halt nur darum auf einem Embedded Linux Board> eine LED zu schalten und Taster einzulesen
Klar, damit kann man anfangen, aber letztendlich braucht es dafür kein
Linux ;). Das geht auch mit einem Mikrocontroller (bzw. sogar ohne ;)).
Unlucky2012 schrieb:> Ein OS bietet mehr als die von dir genannten Feature. Insbesondere halt> auch eine (hoffentlich) vernünftige Prozessverwaltung. Durch> Time-Slicing und Scheduler wird scheinbare Parallelität (bei 1-CPU> Systemen) oder eben sogar echte Parallelität (bei> Mehrkern-Architekturen) gewährleistet.
Ab welcher Hardware lohnt sich der Aufwand ?
Windows, Linux etc. sind ja als EWS ausgelegt, also Mädchen für Alles.
Zentraler Bestandteil eines OS ist ja Starten und Verwalten von
Prozessen - auf einem ATTiny2313 macht das im Prinzip ja der Reset-
Vektor.
Mit einer Maschine mit viel Speicher etc. brauche ich ja noch kein
Filesystem, bekomme aber einiges drauf (auch ein einfaches OS).
Wo wäre da die Grenze ab der sich ein OS lohnt ? Oder gibt es da
feste Kriterien ?
(Sorry. Ich kenne nur den Tiny und 6502, sonst nur PC-Erfahrung. Linux
kann ich installieren - das war's dann aber auch ;)
Ich definiere mal OS im embeded bereich für mich so. Eine lose sammlung
von rotinen für die Mehrläufige Programmierung und deren
Synchronisationsmittel.
Mehrläufig: Threads, Prozesse, ... je nach dem wie man sie nennen will.
In Kleinen systemen eher Threads vergleichbar, da es keine MMU gibt die
die Prozesse vor gegenseitigen Speicherzugriffen schützt. Jeder Thread
hat zugriff auf den ganzen speicher.
Synchronisationsmittel: Maseges, Semaphoren, Queues, ... alles was man
so braucht um die threads synchron zu halten und zwischen ihnen zu
kommunizieren. Je nach OS können das verschiedene sachen sein. teilweise
auch sehr spezielle dinge die es so nicht grossen os gibts.
wozu man sowas braucht? es gibt aufgaben da braucht man sowas nicht
problem wird durch eine einfache loop erschlagen, in irgendwelche irqs
ausgelagert. und es gibt sachen da währe es sinvoll, bzw vorteilhaft
sowas zu verwenden.
z.B. auf Tasten input warten, auf dem display irgend was animieren,
zusätzlich noch nen stepper drehen, auf der RS232 auf input warten, über
SPI zyklisch irgend was wegschreigen, ...
Ich glaube kaum, dass dir jemand genaue und konkrete Werte liefern kann,
ab wann sich ein Betriebssystem lohnt. Das kann man wohl nur allgemeiner
beantworten. Und eine solche Antwort würde wohl eher lauten: Es kommt
auf die Anforderungen an.
Spontan und kaum durchdacht würde ich sagen, dass man über den Einsatz
eines Betriebssystems erst nachdenken sollte, wenn man weiß, dass man
mehrere Prozesse benötigt, welche sich nicht auf unterschiedliche
Mikrocontroller aufteilen lassen, beispielsweise ein multimediales
System.
Und diverse Projekte hier im Forum zeigen, dass auch solche Systeme sich
mit den klassischen Formen der Mikrocontroller-Programmierung in den
Griff bekommen lassen.
Übrigens gibt es hier im Forum schon den ein oder anderen Ansatz für
Betriebssysteme auf Mikrocontrollern. Meiner Einschätzung nach handelt
es sich aber mehr oder weniger um Proofs-of-Concept bzw. "Just for Fun"
Projekte. Produktiv einsetzen würde ich wohl keines davon.
Deinen Vergleich zwischen Betriebssystem und dem Reset-Vektor verstehe
ich nicht so ganz. Der "Reset-Vektor" ist ja bloß eine Adresse, welche
beim Neustart "angesprungen" wird. Da wäre wohl eher ein Vergleich mit
dem MBR (Master-Boot-Record) bei einem klassischen PC richtig.
Ein Betriebssystem, welches "echte" Prozessverwaltung anbietet, bietet
viel mehr als nur die Möglichkeit das komplette System neu zu starten.
Hier kann man - je nach Implementierung - einzelne Prozesse starten,
stoppen, auslagern, einlagern, warten lassen, etc. Im Idealfall gibt es
dann noch ein Threadkonzept, sodass einzelne Prozesse zum Teil auch
parallelisiert werden können. Ein Betriebssystem bietet dann auch noch
die Möglichkeit der Kommunikation zwischen den Prozessen an, z.B.
Speicher- bzw. Nachrichtenbasiert.
Wie schon gesagt: Bei den typischen Mikrocontrollern wäre ein
vernünftiges Betriebssystem einfach nicht unterzukriegen. Weder vom
Flash her, noch vom Arbeitsspeicher. Außerdem fehlt Hardware, welche
sich bei anderen Architekturen etabliert hat, wie z.B. ein Interrupt
Controller, um das Ganze brauchbar implementieren zu können.
Des Weiteren ist es ein um Größenordnungen komplexeres Problem, sobald
man Echtzeit-Anwendungen hat. Während man bei einem Mikrocontroller
"recht" einfach sicherstellen kann, dass die Verarbeitung schnell genug
passiert, ist das bei einem (komplexen) Betriebssystem nicht mehr der
Fall, weil im Hintergrund haufenweise andere Prozesse laufen, die für
das Wohl des Systems sorgen. I.d.R. lässt sich die Reihenfolge, in
welcher diese bearbeitet werden nicht vorher bestimmen. Hier sind dann
die Worst-Case Szenarien (nämlich das so ziemlich alles dazwischen
funkt, was dazwischen funken kann) einfach viel schlimmer, als bei einem
"einfachen" Mikrocontroller, wo man i.d.R. mit einigen an einer Hand
abzählbaren Interrupts arbeitet.
Unlucky2012 schrieb:> Deinen Vergleich zwischen Betriebssystem und dem Reset-Vektor verstehe> ich nicht so ganz.
Er hinkt auch ein wenig. Prinzipiell startet der Reset-Vektor aber
auch einen Task.
Zusammenfassend liegt die Grenze, ab der sich ein OS lohnt (zB um die
Komplexität der HW/SW in den Griff zu bekommen bzw die Programmierung
zu vereinfachen) bei einer Mindesthardware.
Ich vermute, da gibt es dann eine finanzielle Abwägung (zusätzliche
HW-Kosten für den Einsatz eines OS gegenüber den Mehrkosten für die
Programmierung) bei Einsatz billigerer Hardware.
Kleine OS systeme brauchen nicht wirklich viel an resourcen. ein paar KB
flash und ein paar kB ram.
Nach kurzem Google, für die AVRs z.B. FemtoOS 1-4K Flash 2K ram
Es gibt ja jetzt einige Antworten aber wir sind etwas vom Thema
abgekommen.
Der Grund warum ich in Embedded Linux einsteigen will ist, dass es mich
zu einem interessiert und ich gern später in diesem Bereich arbeiten
würde. Daher ist es sicherlich nicht verkehrt, wenn man ein paar
Projekte vorzeigen kann.
_\|/_ schrieb:> Ohne ein komplettes Verständnis, wie> ein Linux eigentlich funktioniert, kommst du bei Problemen nicht weiter.
Ja, genau, mann muss den gesamten Kernel, alle Programme und Daemons bis
auf das letzte Byte genau kennen, ansonsten kommt man unter Linux nicht
weiter.
Sorry, aber das ist einfach nur unsinniges, elitäres Gehabe. So fern er
nicht gerade einen Server ins Internet stellen will, reichen auch ein
paar Grundlagen, so dass er prinzipiell klar kommt. Und bei echten
Problemen ist die Community mehr als hilfsbereit.
Wooog schrieb:> Sorry, aber das ist einfach nur unsinniges, elitäres Gehabe.
Naja, so abwegig finde ich das gar nicht. Klar muss man nicht "jedes
Byte" kennen, aber man sollte schon wissen wie die einzelnen Systeme und
Komponenten funktionieren und miteinander kommunizieren.
Das Installieren bzw. Betreiben einer Distribution wie Ubuntu jedenfalls
vermittelt dieses Wissen wohl nicht. Daher wurde ja oben auch auf LFS
(bzw. CrossLFS) verwiesen.
und es geht hier weder um Desktop noch um server.
Bei embedded sollte man schon wissen was man da tut. wie man bootet, was
man an diensten braucht, in welcher reihenfolge diese zu starten sind,
...
und embedded heist zumindest sehr oft auch am kernel hand anlegen zu
müssen.
Welche treiber brauch ich will ich muss ich haben. als modul oder im
Kernel, ggf an welchem pin hängt was dran, fehlende featers
nachimplementieren / anpassen, ...
Mattes schrieb:> Der Grund warum ich in Embedded Linux einsteigen will ist, dass es mich> zu einem interessiert und ich gern später in diesem Bereich arbeiten> würde. Daher ist es sicherlich nicht verkehrt, wenn man ein paar> Projekte vorzeigen kann.
Du könntest auch mit dem Gnublin anfangen.
Beitrag "GNUBLIN www.gnublin.org"
Da wird auch aktiv hier im Forum entwickelt. Der Raspberry
Pi/Beagle-Board/Panda-Board/Mini6410/STM32-Discovery/weiß-der-Geier kann
auch noch später kommen. ;-)
Lies dir den Thread mal durch und wann es den Raspberry Pi gibt, weiß
wohl keiner. Und vor allem weiß man nicht wann man ihn bekommt.
Ja das habe ich schon alles gelesen. Wie gesagt ich arbeite gerade etwas
mit Fedora um mir die Grundlagen im Umgang mit einem Linux-System zu
erarbeiten.
Joachim Drechsel schrieb:> Welche Vorteile bietet eigentlich ein OS auf eine Mikrocontroller ?
Erstmal gar keinen Vorteil... es sei denn:
a) das betreffende BS bietet Dienste, die man sonst nur mühselig zu
implementieren imstande ist, bzw. die mehr Mannstunden erfordern, als
man selber hat. Beispiele: ein Filesystem bieten, ein GDI bieten das mit
komplizierter Grafikhardware umgehen kann, komplizierte Dinge für einen
erledigen wie TrueType skalieren, Jpeg dekodieren und skalieren, ein
Menü mit Z-Ordnung bieten, eine Eventverwaltung bieten, Standardhardware
(V24, USB usw.) verwalten und so weiter. Das sind alles Dinge, die man
auch selber machen kann, aber die in Form eines sauber auf die
betreffende Hardware abgestimmten BS einem sehr viel Arbeit abnehmen, so
daß man sich auf sein eigentliches Problem konzentrieren kann.
b) wenn man zu blöd ist, seine Firmware so zu planen und so zu
schreiben, daß sie funktioniert ohne sich selber zu blockieren, dann ist
so ein Scheduler mit preemptivem Multitasking offenbar hilfreich.
Man kann dabei aber auch kapitale Böcke schießen und darauf sogar noch
stolz sein. Lest euch mal Adam Dunkels (Contiki et. al.) tolle Erfindung
der "Protothreads" durch. Ein Tollhaus.
Und nochwas speziell zu Linux:
_\|/_ schrieb:
> Ohne ein komplettes Verständnis, wie> ein Linux eigentlich funktioniert, kommst du bei Problemen nicht weiter.
Deshalb ist ja auch Windows CE besser, weil eben besser durchdacht: Man
braucht eben nur das API zur Kenntnis zu nehmen, also die dokumentierte
Schnittstelle zur Anwendungssoftware. das "komplette Verständnis" wie
das BS eigentlich funktioniert, also wie es all die Aufgaben erledigt,
die dahinter stecken, braucht man nicht zu pauken. Es gibt das API,
worauf man sich verlassen kann. Das ist bei Linux alles anders, da wird
vom Anwendungsprogrammierer verlangt, daß er sich um die Innereien des
BS Gedanken machen soll. Eigentlich ne Dreistigkeit, sowas. Ein BS
sollte seinem Benutzer (wozu vor allem erst mal der
Anwendungsprogrammierer zählt) Dienstleistungen und Sicherheit in Form
eines verläßlichen API bieten - und ihn nicht dazu auffordern, erstmal
alle Innereien verstehen zu sollen.
W.S.
W.S. schrieb:> Es gibt das API,> worauf man sich verlassen kann. Das ist bei Linux alles anders, da wird> vom Anwendungsprogrammierer verlangt, daß er sich um die Innereien des> BS Gedanken machen soll.
Ich lehne mich mal ein wenig aus dem Fenster: Warum sollte sich ein
Anwendungsprogrammierer im Falle von Linux "Gedanken um die Innereien
des BS" machen? Ich behaupte ja mal, dass dies z.B. im Falle von Android
nicht der Fall ist. Und mir ist klar, dass hier noch Java (bzw. eine
Abwandlung davon) mit von der Partie ist.
Aber ich glaube du hast hier den Fehler gemacht und den
Anwendungsprogrammierer mit demjenigen verwechselt, der das Ganze System
zusammenbaut und das Betriebssystem darauf zum Laufen bringt. Der
Threadersteller ist aber genau daran interessiert. Da muss man wohl auch
auf Seiten von Windows CE entsprechendes Vorwissen mitbringen. Und ich
behaupte jetzt einfach mal, dass es nicht unbedingt transparenter als im
Falle Linux ist.
Der Unterschied für den Anwendungsprogrammierer liegt höchstens darin,
dass man im Falle von Linux (bzw. *nix) halt direkt mit den
entsprechenden System Calls arbeitet, während man bei Windows CE über
die von Microsoft bereitgestellt API auf Ressourcen, die das
Betriebssystem verwaltet, zugreift. Wie diese API letztendlich
implementiert ist, spielt dann keine Rolle mehr. Diese kann sich sogar
problemlos von Zeit zu Zeit (bzw. von Version zu Version) ändern ohne
das Verhalten von Anwendungen (fundamental) zu beeinflussen. Dem
Anwendungsprogrammierer dürfte das wohl ziemlich egal sein, solange es
eine vernünftige Dokumentation gibt. Hinzu kommt, dass viele
Anwendungsprogrammierer sowieso weder mit der von Windows
bereitgestellten API noch mit System Calls im Falle von Linux zu tun
haben. Das wird bei entsprechenden Hochsprachen einfach
"wegabstrahiert".
Karol Babioch schrieb:> Dem> Anwendungsprogrammierer dürfte das wohl ziemlich egal sein,
Wie bitte?
Du hast ne seltsame Sichtweise, die ich nicht teile. Vielleicht liegt
das an deiner Auffassung davon, was ein Anwendungsprogrammierer ist.
Vielleicht meinst du Leute, die im Wesentlichen nur Scripte schreiben -
oder etwas mit den in diverse Anwendungen eingebauten
Programmiermöglichkeiten machen, wie z.B. VBA für MS-Office-Programme
oder ULP für Eagle oder LUA und so weiter.
Ich rede hier von Anwendungen wie z.B. die Betriebssoftware für nen
Spektrumanalyser oder ein Industriemeßgerät irgendeinen speziellen Zweck
und dergleichen. Vor etwa 10 Jahren gab's mal ne Austauschaktion bei
Agilent: Da konnte man sich seinen Oszillografen updaten lassen: von
Win98 auf WinXP. Bloß damit du mal nen Eindruck bekommst, wo überall
Windows drin ist und was die dort aufsetzende Anwendungsprogrammierung
beinhaltet.
Es ist hier zwar offtopic, aber ich erwähne es doch, damit du verstehst,
was ich meine: Ich hatte vor vielen Jahren mir eine Applikation mit EVC
für meinen Jornada geschrieben (WinCE3) und exakt dieses Programm -
auf linuxisch dasselbe Binary, also exakt dieselbe EXE läuft anstandslos
auf dem Colibri-Board (mit embedded Windows 7 drauf) von der letzten
Messe. Auf allen Versionen zwischendurch (WinCE 4.2, 5.0, WinMobile 6.5)
läuft es auch. Der Grund dafür ist, daß das API von Windows CE bzw.
Mobile eben ein verläßliches API ist, egal wie sehr sich das Innere des
BS inzwischen weiterentwickelt hat. Naja, sowas setzt natürlich einen
gewissen Weitblick bei der Definition des API voraus - bei Microsoft
vorhanden, bei der Linuxgemeinde nicht.
Ich versuche es nochmal ein bissel zugespitzt und provokativ:
Zeig mir doch bitte mal die Datei "linux.h", mit deren Einbindung ich
dann eine - selbstverständlich grafische - Anwendung schreiben kann, die
auf allen Linuxen gleichermaßen gut läuft, egal ob dieses Linux nun 10
Jahre alt ist oder brandneu oder ob grad KDE oder Gnome oder ne andere
Oberfläche dabei ist. Geht nicht? Richtig, geht nicht!
Natürlich hat man es als Anwendungsprogrammierer mit dem API
(Application Program Interface) des BS zu tun - und zwar sehr. Selbst
wenn man mit Delphi oder Visual Basic Anwendungen schreibt, kommt man
nicht um das API herum - es sei denn, man schreibt nur sehr simple
Dinge, die kaum über das "Hello World" hinauskommen. Das Framework nimmt
einem ne Menge an Oberflächengestaltung und Ereignisbehandlung ab, aber
nicht den eigentlichen Nutzinhalt.
Aber zurück zum Thema der embedded (RT)OS'se:
Entweder ist ein Betriebssystem sehr viel mehr als nur so ein
jämmerlicher Scheduler, dann bietet es dem Schreiber der Firmware für
das betreffende Gerät auch Leistungen, die den Einsatz lohnend machen
- oder -
es ist eben nur ein mehr oder weniger jämmerlicher Scheduler, der mehr
an Aufwand erzeugt als er an Nutzen bringt. Ich denke, wir hätten's
damit abgehandelt, was die RTOS'se betrifft.
Tja, und zum eigentlichen Thema von Mattes: wenn es ne klare und
überschaubare Sache wäre mit dem Embedded Linux, dann würde ich mich
auch dafür interessieren. Klar heißt in diesem Fall: Läßt sich mit Keil
für ARM's oder Softune für Fujitsu's unter Windows compilieren und kommt
mit dokumentiertem API und ner Doku über das zu schreibende BSP nebst zu
schreibendem Loader - eben so wie WinCE. Auf den Platformbuilder könnte
man ja notfalls verzichten und alles zu Fuß tun (wie unkomfortabel!)
aber sowas wie Shellskripte oder gar zwangsweise Benutzung von GNU sind
außen vor. Ich hatte diese bescheuerte Diskussion schon mal mit den
Jüngern von ECOS, die auch die große Klappe hatten, aber es immer noch
nicht fertig gebracht haben, die Compiler von Fujitsu benutzen zu
können.
W.S.
Mit dem Windows-API habe ich genug zu tun.
Es dürfte, sollten da mal die Quellen offengelegt werden, den Tod
der Open-Source-Bewegung begründen (die Junks lachen sich tot).
Was MS da zusammenstoppelt ist schlicht ein Witz.
Soweit es irgendwie geht vermeide ich Windows-API-Aufrufe, den
irgendwann einmal fälligen Umstieg auf Linux oder ein andereres OS
verbaue ich mir möglichst nicht.
Zum Thema IDE ist eigentlich nur zu bemerken, ein makefile tut es
völlig. Ähnlich der Compiler, er hat den Code zu übersetzen - sonst
nichts. Ich verwende C als Werkzeug um meine Ideen maschinenkompatibel
zu machen, mehr macht das nicht.
Das ganze Bling-Bling drumherum, wer's mag ...
Richtig nervig sind allerdings falsche bis sehr lässige Dokus über
APIs. Da tut sich MS auch nicht gerade hervor.
Mit Linux habe ich mal gespielt, bin aber da (leider) noch nicht so
weit da mitreden zu können. Es ist aber Opensource, dh ich habe
zumindest die theoretische Chance mal nachzusehen was ein Aufruf
überhpaut macht. Ich finde, die MS-Sources sollten zwangsweise
veröffentlicht werden (schon aus Sicherheitsgründen. Weiß wer, was
so in der "Cloud" passiert ?).
W.S. schrieb:> Vielleicht liegt> das an deiner Auffassung davon, was ein Anwendungsprogrammierer ist.
Ich gebe zu, dass dieser Begriff sehr weit gefasst werden kann.
Allerdings wirst du nicht von der Hand weisen können, dass eben auch der
"typische" Android-App-Entwickler ein Anwendungsprogrammierer ist. Und
der muss nun mal nicht wirklich etwas vom Betriebssystem verstehen, um
eine "Standard"-App zu schreiben. Klar kann man den
Anwendungsprogrammierer auch am anderen Ende ansiedeln und als jemanden
definieren der Bibliotheken für Hochsprachen schreibt. Spätestens dann
bedarf es Wissen um das Betriebssystem.
W.S. schrieb:> Der Grund dafür ist, daß das API von Windows CE bzw.> Mobile eben ein verläßliches API ist, egal wie sehr sich das Innere des> BS inzwischen weiterentwickelt hat.
Ich formuliere es mal ein wenig produktiv und als Frage: Vielleicht hat
sich das Innere des BS gar nicht so viel weiter entwickelt ;).
W.S. schrieb:> Naja, sowas setzt natürlich einen> gewissen Weitblick bei der Definition des API voraus - bei Microsoft> vorhanden, bei der Linuxgemeinde nicht.
Das ist der Satz in deinem Beitrag mit dem ich meine größten Probleme
habe. Auch bei Linux verändert man nicht aus Spaß an der Freude die API
(sofern man das so nennen mag). Allerdings ist man nicht so versteift
darauf, die Welt als Konstante zu definieren wie es eben Microsoft tut.
Die Leute aus Redmond sind doch tatsächlich der Meinung, dass sie
plattformübergreifend (Windows, Windows CE und was es noch so für
Auswüchse im Laufe der Geschichte Microsofts gab) jedem eine in Stein
gemeißelte API anbieten können.
Das ist - zumindest meiner Erfahrung nach - einfach nicht möglich sobald
ein System komplexer wird. Und ein Betriebssystem ist nun mal verdammt
komplex. Klar kann man durch entsprechende Weitsicht unnötige Änderungen
auf ein Minimum begrenzen, aber ab einem gewissen Punkt hindert es
einfach nur noch den Fortschritt. Ich denke, wenn man sich die
Entwicklung von Windows im Vergleich zu Linux ansieht (und ich rede
jetzt bloß vom Kernel), dann kann Linux in puncto unterstützte
Architekturen und angebotene Features über die Zeit hinweg ganz getrost
als Gewinner bezeichnen. Klar geht damit ab und zu ein Bruch der API
einher.
Dafür gibt es im Vergleich zu Windows aber echten und schnelllebigen
Fortschritt innerhalb des Kernels. Als Beispiel sei das Dateisystem
genannt. Während Windows nach wie vor auf NTFS als Standarddateisystem
setzt, welches laut Wikipedia bereits 1993 (!) eingeführt worden ist,
hat sich bei Linux einiges getan. Erst mit Windows 8 wird es ein neues
Dateisystem geben. Und man mag es kaum glauben: Damit einher geht ein
Bruch in Sachen Kompatibilität. Und das sogar bei einem "stinknormalen"
Dateisystem, welches sich über VFS
(https://en.wikipedia.org/wiki/Virtual_file_system) wunderbar
abstrahieren lässt.
Und zum Thema Microsoft und Weitsicht. Microsoft hat es in seiner
unendlichen Weitsicht doch tatsächlich geschafft, dass das komplette
Grafiksystem im Kernel-Modus läuft, um sein damals schon langsames
Betriebssystem "aufzupeppen". Die Moral von der Geschichte: Jede Menge
Exploits in Form von "manipulierten" Grafikdateien. Durch die simple
Darstellung eines Icons kann der komplette PC "übernommen" werden. Nicht
zuletzt wurde das z.B. von Stuxnet ausgenutzt. Gerade in Bezug auf
Security kann man Microsoft wohl keine besondere Weitsicht zuschreiben.
Auch wenn du hier versuchst uns Konstanz als das Beste überhaupt unter
zu jubbeln und ich zugeben muss, dass eine gewisse Konstanz eine gewisse
Attraktivität ausstrahlt, kann eben niemand (nicht einmal Microsoft) in
einem so schnelllebigen Umfeld wie der Informatik (insbesondere unter
dem Aspekt der Betriebssysteme) eben jene Konstanz gewährleisten ohne
sich lächerlich zu machen. Dafür bräuchte man Glaskugeln um in die
Zukunft blicken zu können. Und selbst das würde nicht viel bringen.
Viele der heute eingesetzten Techniken wären noch vor einigen Jahren
überhaupt nicht denkbar gewesen. Unter anderem aufgrund von fehlendem
Arbeitsspeicher, fehlender Rechenkapazität und vielem mehr.
Wer hätte schon vor 20 Jahren darauf gesetzt, dass jeder x-beliebige
Rechner etliche Gigabyte an RAM mitbringt und eine einzige Applikation
mehr als 4 Gigabyte an Arbeitsspeicher in Anspruch nehmen möchte.
Microsoft jedenfalls nicht, sonst hätten sie nicht 2 Gigabyte pro
Prozess für das Betriebssystem reserviert, sodass dem eigentlichen
Prozess nur 2 Gigabyte übrig bleiben. Erst durch einen nachträglichen
Eingriff lässt sich dieses Verhältnis auf 3 zu 1 reduzieren. Inwiefern
also nennst du das Weitsicht?
Da gefällt mir der evolutionäre Verlauf von Linux deutlich besser.
Manchmal kommt es eben zu Änderungen. Die lassen sich - davon bin ich
fest überzeugt - auch gar nicht verhindern. Sonst behauptet man etwas
von sich, dem man nicht gerecht werden kann.
W.S. schrieb:> Zeig mir doch bitte mal die Datei "linux.h", mit deren Einbindung ich> dann eine - selbstverständlich grafische - Anwendung schreiben kann, die> auf allen Linuxen gleichermaßen gut läuft, egal ob dieses Linux nun 10> Jahre alt ist oder brandneu oder ob grad KDE oder Gnome oder ne andere> Oberfläche dabei ist. Geht nicht? Richtig, geht nicht!
Vermutlich hast du recht. Das könnte schwierig bis unmöglich werden. Auf
der anderen Seite: Wieso sollte man aktuelle Systeme und "uralte"
Systeme gleichermaßen unterstützen. In den zehn Jahren hat sich in
Sachen Hardware eben einiges getan. Ich z.B. finde Entscheiden
"Altbalast" abzuwerfen i.d.R. gut. So unterstützt das neuste GNOME bzw.
KDE eben nicht mehr alle Grafikkarten. Dafür kann ich
Designentscheidungen treffen, die mir sonst verwehrt blieben. Unter
anderem eben 3-D Funktionen von Anfang an.
Übrigens ist es im Falle Windows doch nicht anders. Jede halbwegs
aktuelle Anwendung benötigt mindestens Windows XP. In vielen Fällen dann
auch noch in gepatchter Form, SP 2 aufwärts. Wenn alles so utopisch
wäre, wie du es uns hier aufzeigst, dann müssten doch auch sämtliche
Vorgänger unterstützt werden ;).
W.S. schrieb:> Natürlich hat man es als Anwendungsprogrammierer mit dem API> (Application Program Interface) des BS zu tun - und zwar sehr.
Wie gesagt: Es kommt wohl auf die Sichtweise bzw. Definition eines
Anwendungsprogrammierers an. Sobald man Sprachen wie Java und
Skriptsprachen wie z.B. Python nutzt, wird eben vieles (bzw. alles)
verborgen. Und gerade mit diesen beiden Sprachen lässt sich doch einiges
anstellen.
Übrigens möchte ich noch anmerken, dass Linux das mir einzig bekannte
Betriebssystem ist, welches von "ganz klein" bis "ganz groß" eingesetzt
wird. So hat es seinen festen Platz in der Welt der eingebetteten
Systeme gefunden. Unter anderem eben in unseren Smartphones und Routern.
Platz hat es gefunden auf unseren PCs. Weiter geht es über "normale"
Server bis eben hin zum High-Performance Computing (HPC). Und das alles
mit der selben Codebasis, im Prinzip ganz ungewollt und vor allem ohne
Zwang.
Das nenne ich persönlich Erfolg! Vor allem aber sagt es mir, dass Linux
genau das richtige Entwicklungsmodell umsetzt.
Windows hingegen hat seinen Stammplatz auf PCs. Selbst bei "normalen"
(d.h. typischen) Servern wird Windows schon stark (bis komplett) von
anderen dominiert (hauptsächlich eben Linux). Im HPC Bereich hat
Microsoft absolut gar nichts zu bieten. Windows HPC Server ist im Besten
Fall ein Witz. Ernst nehmen kann man es jedenfalls nicht. Und selbst das
von dir so gelobte Windows CE teilt mit dem "großen" Windows nicht
wirklich etwas - zumindest aber keine gemeinsame Codebasis.
Und ich will jetzt hier Linux gar nicht besonders toll und super
aussehen lassen. Aber deine Aussagen bedurften einfach einiger
Gegenargumente.
Was die Vielfalt von Werkzeugen in der Open-Source Welt angeht: Gerade
das ist doch das Schöne. Mag sein, dass es den Einstieg erschwert, aber
dafür bieten sich halt Möglichkeiten, die man mit "Schema F" nicht
hinbekommt. Ich jedenfalls halte den o.g. Umstand, dass man Linux
"überall" findet für keinen Zufall!
wer linkt den unter linux direkt gegen die linux.h / pardo includiert
diese?
vermutlich die wenigsten. ausser du willst wirklich irgend welche hw
mehr oder weniger direkt ansprechen. dann sind vermutlich noch einige
andere header files notwendig sowie kentnisse darüber was der treiber da
eigentlich haben will.
unter linux heist das zauberwort posix.
und das Programme von vor 10 jahren ohne murren laufen spricht auch
nicht gerade für sich. kann nur zwei (drei) sachen bedeuten. Die API hat
sich in der zeit nicht weiterentwickelt, und nichts neues ist
dazugekommen. Es wurden immer nur dazugepackt und versucht auf teufel
komm raus an den alten ggf mitlerweile total überholten verkorksten
schnittstellen am laufen zu halten. oder deine Anwendung setzt nur auf
den teil der API auf der sich in der zeit nicht verändert hat.
und die schnittstellen M$ kenn ich nur vom Desktop. aber dort gibt es
teils kleine aber feine unterschiede zwischen den Versionen (z.B. Vista
W7 bzw 32 64)
Joachim Drechsel schrieb:> Es dürfte, sollten da mal die Quellen offengelegt werden, den Tod> der Open-Source-Bewegung begründen (die Junks lachen sich tot).> Was MS da zusammenstoppelt ist schlicht ein Witz.
Auch wenn ich mich mit Windows und der API viel zu wenig auskenne,
gefällt mir die Vorstellung doch recht gut ;).
Joachim Drechsel schrieb:> Richtig nervig sind allerdings falsche bis sehr lässige Dokus über> APIs. Da tut sich MS auch nicht gerade hervor.
Wie gesagt: Ich habe kaum Erfahrung mit Windows und der dazugehörigen
API. Aber ich habe kein Problem damit Microsoft einzugestehen, dass ihre
Dokumentation brauchbar ist. Jedenfalls habe ich keine negativen
Erfahrungen damit gemacht. Ganz im Gegenteil.
Joachim Drechsel schrieb:> Ich finde, die MS-Sources sollten zwangsweise> veröffentlicht werden (schon aus Sicherheitsgründen. Weiß wer, was> so in der "Cloud" passiert ?).
Das ist aber ein fundamental anderes Problem. Was in der "Cloud"
passiert weißt du sowieso nicht. Ob da nun Open-Source-Software
eingesetzt wird oder nicht. Aus dieser Perspektive betrachtet ist das
Modewort "Cloud" sowieso höchst problematisch.
Wobei ich die Grundidee für absolut richtig halte. Gerade bei Behörden
und ähnlichen Institutionen sollte Open-Source-Software verpflichtend
sein. Zum Glück gibt es Bestrebungen wie LiMux, welche sich hoffentlich
über kurz oder lang bezahlt machen und dafür Sorge tragen, dass das
ganze Thema breiter und öfter diskutiert wird. Die Vorstellung das
unsere Daten über Systeme laufen, welche nicht überprüft werden können
(und vor allem dürfen) halte ich in gewissem Maße für angsteinflößend.
zur Docu M$: solange es sich um Sachen handelt die jeder braucht kann
ich da durchaus zustimmen.
sobald es aber exotisch wird fangen die Lücken an. da dient dann nur
noch ein Kommentar in einer Header file aus dem DDK als hinweis was das
"ding" bedeuten könnte, bis zu nicht dokumentierten wegen aus dem netz
irgend ein Problem zu lösen, bis zu kommentaren im netz das man das was
sich m$ an der stelle gedacht hat leider nicht so funktioniert und man
das doch am besten gleich vergessen sollte.
Es gibt seit Jahren ja einige böse Zungen, die wagen zu behaupten, dass
Windows gar kein OS ist. Wie auch immer, es gibt bei Windows (inkl. CE
und Konsorten) einige Dinge, die nicht ins Kernel gehören.
Im Konzept eines Kernels gibt es keine "linux.h". Genau die klare
Trennung von Userspace und Kernel verbietet das. Wie ja schon jemand
gesagt hat: Stichwort Posix, Filesysteme und ioctls. Meinetwegen auch
Erweiterungen wie /proc, sys, usw. Ist alles gut dokumentiert, und
funktioniert seit Jahren um vielfaches portabler als der Microsoft-Kram.
Ich muss auch nicht anfangen, irgendwelche Plattform Kits zu
installieren, mit denen der Compiler dann doch nicht richtig tut, nur um
eine andere ARM-Architektur zu unterstützen.
Es mag geunkt werden, dass unter Linux ein gewisser Wildwuchs an
grafischen Oberflächen herrscht. Dem gegenüber steht aber wiederum
Android mit einer sehr klaren API. So kann sich auch jeder entscheiden,
welches Toolkit für ihn das beste ist und muss sich nicht durch
Windows-Geschlurf wie MFC einschränken lassen.
Wenn es um Design stabiler Systeme geht, die nicht abstürzen sollen,
kann ich von WinCE einfach nur abraten. Das Konzept ist aus vieler Sicht
"broken by design". Vielleicht für einen PC-User nicht von Bedeutung,
aber für ein medizinisches Gerät schon...
> Wenn es um Design stabiler Systeme geht, die nicht abstürzen sollen,> kann ich von WinCE einfach nur abraten. Das Konzept ist aus vieler Sicht> "broken by design". Vielleicht für einen PC-User nicht von Bedeutung,> aber für ein medizinisches Gerät schon...
Da muss ich aber erst recht von Linux abraten.
Mattes (Gast) - wenn es nicht sein muss, dann mache diskret weiter oder
spiele etwas mit VM herum. Davon bekommst Du keine grauen Haare...
Embedded Linux als Einstieg - viel Spaß.
Strubi schrieb:> Wenn es um Design stabiler Systeme geht, die nicht abstürzen sollen,> kann ich von WinCE einfach nur abraten.
Nanana, mein Lieber. Mein steinalter Organizer mit WinCE 3.0 drauf läuft
nun schon seit Jahren ohne Unterbrechung durch und das mit täglicher
Nutzung einschließlich Ausprobieren von selbstgeschriebenen Anwendungen.
Die blöde DSL-Box hingegen, wo angeblich ein Linux drin werkelt, muß ich
gelegentlich mal von der Steckdose trennen, weil sie schlichtweg
abgestürzt ist. Soviel zum Thema Stabilität.
Ist aber hier nicht das Thema. Wir reden doch eigentlich über das
Entwickeln von Anwendungen - oder nennen wir es mal lieber Firmware für
Mikrocontroller. Sowas kann man selten bis nie nativ auf dem Zielsystem
tun, sondern man benutzt zumeist einen PC, wo die Firmware für das
Zielsystem geschrieben und übersetzt wird, um dann in das Zielsystem
"gebrannt" zu werden. Gelle?
Sachlich ist es dabei völig wurscht, ob man dafür nen MAC, nen Windows
PC, ne HP-Unix-Station oder nen Linux-Rechner benutzt. Hauptsache, man
hat den/die Compiler für den eigentlichen Code, Linker nebst
Bibliotheken für das Zielsystem, Ressourcen-Zeug für alles Grafische
usw. auf der betreffenden Entwicklunsplattform vorhanden. Also, auf
meinem hier nicht näher bezeichneten Rechner habe ich das alles (von
Fujitsu) vorhanden. Es müßte also ausreichen, das dokumentierte API des
gewünschten Betriebssystemes in den Quellen der Anwendung zu benutzen.
Solche Beiträge wie:
_\|/_ schrieb:> Ohne ein komplettes Verständnis, wie> ein Linux eigentlich funktioniert, kommst du bei Problemen nicht weiter.
sind eigentlich nur ne Offenbarung des Pfusches. Wenn ich z.B. auf dem
Screen ein Rechteck mit Farbe füllen will, dann brauche ich dazu den
passenden (dokumentierten) API-Aufruf. Wie der im Inneren des BS
funktioniert, ist Obliegenheit des Betriebssystem-Schreibers. Pfusch
ist, wenn man ein BS in die freie Wildbahn entläßt, ohne eine saubere
Schnittstelle nebst deren Doku vorzuhalten.
Kurzum: Aus meiner Sicht ist nicht das "komplette Verständnis", sondern
nur die verläßliche API-Doku das Wesentliche.
Je mehr Meinungen zu diesem Thema ich hier in diesem Forum sehe, desto
mehr komme ich zu dem Schluß, daß typische Linuxer die Dinge zu sehr aus
der Sicht des Rechner-Sklaven sehen. Sagen wir lieber "Administrator"
dazu, das klingt netter, ist aber exakt dasselbe. Oft wird sogar von
"Userland" geredet, als ob dies ein ferner Kontinent sei, mit dem man
nix zu tun hat. Mir ist klar, daß diese Befindlichkeiten aus der
Unix-Historie kommen, wo zwischen den zahlenden Usern und den (von den
Usern angeschnarrten) Admis "Legen sie mir mal Band 17 auf" eine dicke
Betonwand war. Und so wie die User sich einen Dreck scherten darum, wie
die Admis den Mainframe am Laufen hielten (das hat gefälligst zu
funktionieren, ist ja teuer genug..) haben die Admis sich nicht um die
Anwendungen der User gekümmert. Und dieser Geist steckt immer noch drin.
90% aller Linux-Beiträge in diesem Forum handeln von Innereien des BS,
aber nicht von Anwendungen. Eigentlich ein trauriges Kapitel.
W.S.
W.S. schrieb:> Pfusch> ist, wenn man ein BS in die freie Wildbahn entläßt, ohne eine saubere> Schnittstelle nebst deren Doku vorzuhalten.
Du Scheinst wohl ein verzerrtes Bild von dem zu Haben was ein
Betriebssystem ist. Linux ist ein Betriebssystemkern, mehr aber auch
nicht. Coreutils, Shell, *libc, Toolkits sind gewissermaßen nur
schmückendes Beiwerk. Dein Beispiel 'Rechteck Malen' hat mit dem OS an
sich nichts zu tun, es ist auch nicht dessen Aufgabe, Funktionen zum
Malen von Rechtecken anzubieten. Darum haben sich Grafikbibliotheken zu
kümmern.
Auf die Qualität der Windows-API wurde hier ja schon mehrfach
eingegangen.
Wenn http://de.wikipedia.org/wiki/Winapi#Programmbeispiel für dich eine
gelungene API ist... (OK, ist Win32, CE wird auch nicht besser sein)
Vergleiche das mal mit dem GTK+-Hallowelt.
Wenn man sich die OS-Sprösslinge der letzten Jahre ansieht:
Android : Linux
WebOS : Linux
Bada : Linux
Meego : Linux
iOs : OS X (BSD)
Blackberry Tablet OS: QNX
WP7 : Windows CE
Fällt was auf?
Auf der anderen Seite der Datenverbindung sieht die *NIX / nicht
*NIX-Verteilung ähnlich aus. Wohl nicht ganz ohne Grund.
W.S. schrieb:> Soviel zum Thema Stabilität.
Da habe ich aber ganz andere Erfahrungen gemacht. Meine beiden Windows
CE Geräte (Dell Axim x51v sowie HTC Blackstone) waren beide "relativ"
häufig neu zu starten. Zum Einen wurden sie unerträglich langsam, sofern
man sie mal einige Tage laufen hat lassen, zum Anderen haben sie sich
auch gerne mal aufgehängt. Beide Geräte hatten übrigens einen
Reset-Button, welcher mit dem Stylus betätigt werden konnte. Mein
aktuelles Android Smartphone jedenfalls hat einen solche nicht. Und den
Akku musste ich auch noch nicht all zu oft herausziehen ;). Auch sind
meine Router und Access Points (und davon sind hier einige im Betrieb)
nicht tot zu kriegen. Die haben typische Laufzeiten von einigen hundert
Tagen. Unterbrochen wird die Laufzeit eigentlich nur durch das Flashen
von Firmware-Updates.
Wie du schon sagtest: Solche Aussagen sind i.A. nicht viel wert. Da
bringt jeder seine Vorurteile mit und bewertet das je nach favorisiertem
System wohl auch ein wenig anders. Angefangen uns Windows als besonders
stabil zu verkaufen hast aber du. Insofern wollte ich dem Ganzen mit
meinen Erfahrungen entgegenwirken. Ich wäre mit Vergleichen bezüglich
der Stabilität ein wenig vorsichtiger. Einfach zu behaupten System "x"
ist stabiler bleibt genau das was es ist: Eine Behauptung. Dies unter
objektiven Gesichtspunkten zu beweisen ist dann nämlich gar nicht so
einfach. Außerdem sagt die Stabilität eines Systems nicht unbedingt
etwas über die Qualität des Designs aus. Wenn überhaupt, dann sagt es
etwas über die Qualität der konkreten Implementierung ab. Und ich glaube
hier braucht sich Linux im Großen und Ganzen nicht zu verstecken.
W.S. schrieb:> Wir reden doch eigentlich über das> Entwickeln von Anwendungen - oder nennen wir es mal lieber Firmware für> Mikrocontroller.
Naja, ursprünglich ging es um das Einarbeiten in Linux im Umfeld von
Embedded Devices. Das ist schon ein bisschen mehr als "nur" das
Programmieren von Mikrocontrollern.
W.S. schrieb:> Solche Beiträge wie:> _\|/_ schrieb:>> Ohne ein komplettes Verständnis, wie>> ein Linux eigentlich funktioniert, kommst du bei Problemen nicht weiter.>> sind eigentlich nur ne Offenbarung des Pfusches.
Das ist beim allerbesten Willen nicht nachzuvollziehen. Der
Threadersteller will wohl - eher oder später - mit eingebetteten
Systemen auf Basis von Linux umgehen können. Da muss man halt davon
ausgehen, dass man auch entsprechendes Wissen um Linux hat.
Das wäre im Falle von Windows nicht anders. Wenn ich ein eingebettetes
System auf Basis von Windows aufbauen will, dann muss ich mich genauso
mit dem Bootloader-Prozess auseinandersetzen, wissen wie ich Treiber
schreibe und mit dem Betriebssystem kommuniziere. Wenn ich weiß wie die
einzelnen Komponenten zusammenspielen, dann erleichtert es das Ganze
natürlich enorm.
Von reiner Anwendungsprogrammierung jedenfalls war hier nie die Rede.
Zumindest solange nicht bis du angefangen hast irrwitzige und zum Teil
falsche Aussagen zu treffen, um uns Windows CE als Wunderwerk der
Technik zu präsentieren.
W.S. schrieb:> Kurzum: Aus meiner Sicht ist nicht das "komplette Verständnis", sondern> nur die verläßliche API-Doku das Wesentliche.
Klar ist eine gute Dokumentation hilfreich. Aber ein Verständnis davon
zu haben was ganz grundsätzlich ablaufen muss, und wie dies im konkreten
Fall (zum Beispiel bei Linux) funktioniert hat auch noch niemanden
geschadet. Die Aussage ist wohl eher so zu verstehen, dass jemand der
noch nie etwas mit Linux am Hut hatte, ganz bestimmt in Probleme laufen
wird, wenn er sich an eingebettete Systeme wagt. Das ist im Falle
Windows auch nicht anders - Dokumentation hin oder her. Zur
Dokumentation von Microsoft hatte ich ja meinen Teil gesagt. Ich habe
kein Problem damit einzugestehen, dass diese gut ist. Microsoft hat eben
das nötige Kleingeld, um Leute dafür einzustellen, dass sie
Dokumentationen schreiben. Andere, die wohl mehr Erfahrung mit den von
Microsoft zur Verfügung gestellten Dokumentationen zu tun haben, haben
diese allerdings auch kritisiert. Dazu kann ich keine kompetente Meinung
abgeben.
W.S. schrieb:> Oft wird sogar von> "Userland" geredet, als ob dies ein ferner Kontinent sei, mit dem man> nix zu tun hat.
Also entweder du stellst gerade eindeutig unter Beweis, dass du nicht
einmal weißt was es mit "Userland" auf sich hat, oder aber du machst
hier einen Vergleich, den zumindest ich nicht verstehe. Userland
bezeichnet i.d.R. Programme, die nicht im Kontext des Betriebssystems
ablaufen (siehe https://en.wikipedia.org/wiki/User_space). Damit einher
gehen unter Anderem weniger Privilegien. Das Microsoft dieses Konzept
absolut falsch umgesetzt hat, habe ich ja hoffentlich oben anschaulich
an einem Beispiel erklärt. Dort wird nach wie vor (!) das komplette
grafische Subsystem im Kernel-Mode betrieben. Ursprünglich war dies so
strukturiert worden, um einen Geschwindigkeitsvorteil zu erhalten. Das
die Computer sowieso schnell genug werden würden, hat Microsoft in
seiner unendlichen Weisheit wohl nicht richtig einschätzen können.
Jedenfalls gehen damit Exploits einher wie ihn eben unter anderem
Stuxnet ausgenutzt hat. Die simple Darstellung von manipulierten
Grafikdateien reicht dann schon aus, um das System zu übernehmen.
W.S. schrieb:> Und dieser Geist steckt immer noch drin.> 90% aller Linux-Beiträge in diesem Forum handeln von Innereien des BS,> aber nicht von Anwendungen. Eigentlich ein trauriges Kapitel.
Das ist eine absolut nichtssagende Aussage. Wenn die Leute sich mit den
Innereien des Betriebssystems auseinandersetzen, dann ist doch daran
nichts auszusetzen. Wenigstens können sie das im Falle von Linux absolut
uneingeschränkt tun. Bei Windows ist dies zum Einen technisch kaum
machbar und zum Anderen wohl auch strafbar. Wenn überhaupt, dann ist
Letzteres ein trauriges Kapitel, aber ganz sicher nicht, dass sich Leute
mit Linux (und dessen Innereien) auseinander setzen.
Übrigens hat man nicht unbedingt das Gefühl, dass du oben stehende
Beiträge überhaupt gelesen hast. Oder aber du bist sehr schnell im
Verdrängen und Vergessen. Auf die o.g. Argumente eingegangen bist du
jedenfalls nicht!
W.S. schrieb:
> Kurzum: Aus meiner Sicht ist nicht das "komplette Verständnis", sondern> nur die verläßliche API-Doku das Wesentliche.
Die API ist unter Linux sehr viel stabiler als ihr Ruf. Lediglich im
Kernel/Treiber ändert es sich mal was. Wenn du aber z.B. den Zugriff auf
/dev/ttyS[0-999] ändern willst, wirst du das wohl nie in den
Vanilla-Kernel bekommen.
Dein Rechteck-malen erledigt sich über Toolkits, Qt, GTK usw. Klingt
ziemlich nach gefährlichem Halbwissen.
Win CE ist imho eine grausame Diva und wird von MS auch gerne
kleingehalten damit am große Win verdient werden kann. Den Desktop hat
MS, wohl auch noch recht lange, aber im Embedded-und
Industrie-PC-Bereich ist Linux mehr als nur schwer am Kommen. Würde MS
XP/WES 2009 weiterführen, hätte ich mir eher Sorgen um Linux und meinen
Job gemacht.
Nu ja die stabilität von Linux oder Win CE auf einer HW Steht und fällt
mit der qualität der Treiber. Bei Tragbaren Geräten spielt da noch das
Power Management eine rolle. Viele abstürtze hänger spielen dann gerade
mit dem Power Management und spezielen Ladezuständen zusammen, die
verdammt schwer zu reproduziehren sind.
und es gibt unterschiede in der windows CE entwicklung.
der erste setzt ein fix und fertig zusammengeschnürtes Windows CE Board
support Package für eine fix definierte HW ein. Er ist der reine
anwendungsentwickler, der nur über die WinAPI mit dem OS kommuniziert.
Will er auf eine neue HW wechslen braucht er eine HW für die auch ein
Windows CE Board support Packsage existiert und ausgeliefert wird.
Der 2. arbeitet bei dem HW Hersteller und baut so ein Windows CE Board
support Package zusammen. Stellt die Komponenten zusammen, schreibt die
Treiber, ...
Irgendwie hab ich den Eindruck, daß hier so langsam die Argumente
ausgehen und durch Anfeindungen ersetzt werden. Ist nicht hilfreich,
sondern stößt sowohl mich als auch eventuelle Mitleser eher ab. Meint
ihr, die ihr mich so wortreich zitiert haben, daß durch verstärkte
Rechthaberei und Prinzipienreiterei andere Leute animiert werden, sich
mit Linux zu befassen?
Ob nun die reine Torvaldsche Lehre besagt, daß ein Grafiksystem nicht in
den Kernel gehört oder in irgendeine Stelle im BS, ist mir herzlich
wurscht. Fakt ist, daß man das mit nem WinCE dabei hat und daß man mit
nem nackten Linux bzw. einem nackten Embedded Linux genau das nicht
dabei hat, was in allen Anwendungen, die mit nem menschlichen Wesen in
Kontakt kommen, von größter Wichtigkeit ist: Grafik und Oberfläche.
Aus Linux-Sicht gehört die grafische Obefläche also nicht ins Linux,
sondern hat über sonstige Software realisiert zu werden, ja? Nun denn.
Ich sehe das ganz anders: Wenn einer einen Router oder sonstwas baut,
was allenfalls ferngewartet wird, dann ist das Fehlen dieser
Betriebssystem-Leistungen ja OK, weil sowieso kein Display dran ist. Für
alle anderen Fälle ist aber Grafik angesagt und wenn sie nicht im BS
dabei ist, dann hat man 3 Probleme: OS und Grafiksystem und als drittes
ne Event-Verwaltung, die zwischen beiden vermitteln muß. (Nebengedanke
von mir: Linux weglassen und nur die Grafik implementieren, die ja per
oben nachlesbarer Definition ohnehin nicht zum BS dazugehört)
Mir kommt da sofort die Prinzipfrage hoch: Wozu braucht man in einem
Gerät überhaupt ein WinCE oder Linux oder QNX? Immerhin stellen die alle
ihre Hardwareanforderungen, die man erstmal löhnen muß. Im Gegenzug
erwartet man Leistungen, die den Aufwand rechtfertigen. Vielleicht ist
es hilfreicher, hier mal die von einem Embedded Linux erwartbaren
Leistungen zusammenzutragen, um wieder auf nen sachlichen Boden zu
kommen. Also, Leute, kommt auf den Anfang zurück:
Mattes schrieb:> ich möchte mich gerne in Embedded Linux einarbeiten und komme aber aus> der Windows-Welt. Jetzt weiss ich nicht so richtig, wie ich einsteigen> soll.
Was also bietet ein Embedded Linux an Leistungen und was nicht?
Ich versuche mal als Anfang ein noch leeres Gerüst:
- Scheduler ?
- virtueller Speicher ?
- Massenspeicher, Filesysteme ?
- Ethernet ?
- Event-Verwaltung ? (denkt an die Knöpfe am Gerät)
- Fonts ?
- Grafik ?
- Drucken und Gerätekontexte ? (denkt an den Kassenbon)
- Uhr, Kalender, Timer ?
- USB ?
- ...und was noch?
und die nächste Frage: Wie steigt man ein, also wie kriegt man ein
Embedded Linux zusammengebaut?
- wo läßt es sich bilden außer auf nem Linux-PC?
- läßt es sich mit anderen Toolchains als GNU überhaupt bilden?
- wie gestaltet sich die Konfiguration?
- gibt es sowas wie Board-Support-Packages für die uC, die hier in
diesem Forum am beliebtesten sind?
Ich denke mal, über diese Fragen zu diskutieren und hilfreiche Antworten
zu schreiben, macht mehr Sinn als Flames zu verfassen.
W.S.
W.S. schrieb:> - Scheduler ?
T'ürlich doch
> - virtueller Speicher ?
dito
> - Massenspeicher, Filesysteme ?
dito
> - Ethernet ?
selbstverständlich
> - Event-Verwaltung ? (denkt an die Knöpfe am Gerät)
Knopf->Eingabegerät
> - Fonts ?
$grafikbibliothek, z.B. cairo mit pango, das rendert auch für uns
Europäer seltsam anmutende Schriften
> - Grafik ?
$grafikbibliothek, z.B. cairo, UI dann mit GTK/QT Als Backend der
Framebuffer
> - Drucken und Gerätekontexte ? (denkt an den Kassenbon)
Bondrucker wird wohl RS232 oder so sein, kein Problem
> - Uhr, Kalender, Timer ?
klar doch
> - USB ?
host und device
> - ...und was noch?
Die gewohnte Umgebung.
W.S. schrieb:> nackten Embedded Linux genau das nicht> dabei hat,
Dann verwende eben eine der zahlreichen Embedded-Distros.
W.S. schrieb:> Aus Linux-Sicht gehört die grafische Obefläche also nicht ins Linux,
Nebenbei: Windows ist das einzige (Wenn man es mal von Museumsstücken
wie Mac OS Classic absieht) OS, bei dem die Grafik derart tief im Kernel
steckt. Microsoft hat ja auch 'ne halbe Ewigkeit gebraucht um einen
Windows Server ohne GUI rauszuhauen.
Joachim Drechsel schrieb:> Welche Vorteile bietet eigentlich ein OS auf eine Mikrocontroller ?
Vernünftige IP und USB Stacks, Speicherschutz, lokale und remote
Filesysteme, fertige Treiber und so weiter und so fort.
W.S. schrieb:> Irgendwie hab ich den Eindruck, daß hier so langsam die Argumente> ausgehen und durch Anfeindungen ersetzt werden.
Du hast noch auf so gut wie keines reagiert. Insofern sind wir noch weit
entfernt von dem Punkt an dem uns die Argumente ausgehen.
W.S. schrieb:> Ob nun die reine Torvaldsche Lehre besagt, daß ein Grafiksystem nicht in> den Kernel gehört oder in irgendeine Stelle im BS, ist mir herzlich> wurscht.
Und mit dieser Aussage hast du dich nun endgültig als jemand geoutet der
von Betriebssystemen und den zu Grunde liegenden Ideen und Konzepten
nicht wirklich eine Ahnung hat. "Das" Grafiksystem setzt sich - wie es
in der Informatik eben üblich ist - aus vielen kleineren Systemen
zusammen. Treiber für die Hardware z.B. gehören sehr wohl in den Kernel.
Das Problem ist nur, dass Microsoft eben auch andere Teile in den Kernel
gepackt hat, welche da nicht unbedingt hingehören.
Und das ist weniger eine "Torvaldsche Lehre" als viel mehr gesunder
Menschenverstand. Ein Exploit in der Form wie ihn Stuxnet verwendet hat
(nämlich die simple Darstellung einer manipulierten Bilddatei) dürfte
unter Linux jedenfalls nicht zur System-Übernahme führen. Und ich
kritisiere hier nur den Umstand, dass hier Dinge im Kernel-Modus laufen,
die es nicht unbedingt müssen.
Ob mit dem Betriebssystem nun ein grafisches System mitgeliefert wird
oder nicht, hat damit absolut nichts zu tun. Da kann ich deine
Ausführungen sogar nachvollziehen und halte es aus Sicht von Microsoft
nicht für verkehrt, wenn sie ein einheitliches System mitliefern. Nur
kann man ein solches System eben genauso gut im Userland implementieren
und muss es nicht mit Kernel Privilegien betreiben! Microsoft hat sich
aber aus Geschwindigkeits-Gründen bewusst dafür entschieden. Ein Fehler
mit fatalen Folgen.
Aber auf diesen Punkt bist du nach wie vor nicht eingegangen. Vermutlich
auch deshalb nicht, weil deine Definition von "Userland" falsch ist
(siehe oben).
W.S. schrieb:> Ich denke mal, über diese Fragen zu diskutieren und hilfreiche Antworten> zu schreiben, macht mehr Sinn als Flames zu verfassen.
Ich sehe hier keine Flames. Ich sehe hier jemanden, der uns die Vielfalt
der Linux-Welt schlecht reden will und uns Windows CE als Non-Plus-Ultra
verkaufen will. Gleichzeitig aber stellt derjenige aber unter Beweis,
dass sein Verständnis von der dahinter steckenden Technik nicht
vorhanden bzw. falsch ist und auf jegliche Kommentare, welche die
Funktionsweise von Windows (CE) in Frage stellen nicht eingeht.
Lukas K. schrieb:> Microsoft hat ja auch 'ne halbe Ewigkeit gebraucht um einen> Windows Server ohne GUI rauszuhauen.
Und diesen in typischer Microsoft Manier als etwas verkauft, dass es
bisher noch nicht gegeben hat ;).
Rad neu erfinden schrieb:> Vernünftige IP und USB Stacks, Speicherschutz, lokale und remote> Filesysteme, fertige Treiber und so weiter und so fort.
Prinzipiell könnte ich das auch statisch hinzulinken.
"Torvaldsche Lehre": Ist auch nicht die reine Lehre ;)
Halt eine Sicht der Dinge unter vielen.
Sinn und Zweck eines OS ist die Verwaltung der Betriebsmittel,
Klickibunti gehört nicht dazu. MS hat die Definition einen OS
erweiter, nicht aus technischem, eher aus kaufmännischem Kalkül.
Ein BWLer mag das verstehen und nachvollziehen können ...
Mir persönlich ist das OS egal, es hat zu funktionieren und mir
Dinge bereitzustellen die mir das Leben erleichtern - nicht mehr
aber auch nicht weniger. Kann es das ist es ok. Kann es das nicht
gehört es in den großen Rundordner.
Bashing ? Egal in welcher Richtung, an Glaubensfragen werde ich
mich nicht aufreiben. Es würde auch zu nichts führen.
Grafik:
wie schon angesprochen der Framebuffer als schnittstelle zwischen der
reinen monitor representation und dem GUI framework. Was auch immer das
sein mag. von Komerziell bis open source bis zu was selbst gestrikten.
Font:
freeType
Eingabe:
über /dev/Input und den dazugehörigen Treibern. tsLib, ...
Es ist immer die frage gegen was vergleicht man Linux. gegen Windows CE
als bord Support Package oder gegen die selbstbau variante.
Linux hat sicher viele möglichkeiten irgend etwas zu realisieren. Es
gibt z.B. nicht nur ein GUI framework. sondern verschiedene. man hat
zwar dann die qual der wahl. aber man kann ggf das gleiche für linux,
win CE, tragbar / stationär verwenden. Bzw andere kriterien mit
ansetzen, Speicherverbrauch, Lizenz, Kosten, verbrauchte rechenleistung,
...
Ein Embedded Linux wird selten auf einem fix und fertig definierten
board betrieben, das man von der stange kaufen kann. es gibt hier immer
irgend welche anpassungen. z.B. LCD Farbtiefe, auflösung, wie sieht das
Interface aus, 8bit 16bit 20bit? VSync, Paralel, seriel, ... Was für
einen touch screen hab ich? resistiv oder kapazitiv? Ich habe da ich auf
die sourcen zugriff habe die möglichkeit hier einzugreifen und
anzupassen.
An diesem Thread kann man schön sehen: Je weniger Ahnung die Leute
haben, desto größere Töne spucken sie....
Wenn man sich in embedded Linux einarbeiten will, dann von Grund auf.
Ohne zu wissen wie der ganze Boot-Vorgang mit Einbindung der Hardware,
Filesysteme u.s.w. geht, wird das am Ende sowieso nichts. Und da wird
das Frustpotential schon ganz schön hoch. Man kann sich nicht nur an den
gedeckten Tisch setzen und auf die schimpfen die für Umsonst rackern.
Wer halt für embedded Linux zu blöd ist, der soll sich ce oder was
anderes vorgefertigtes kaufen und damit glücklich werden. Wer's drauf
hat, kann Zeit gegen Geld für Lizenzen aufwiegen und sehen was besser
ist. Und viele von denen, die auf eigener Hardware ein emb. Linux mit
Grafik u.s.w aufgesetzt haben, werden das nicht als Kochrezept nach
außen tragen.
Was seid ihr doch für oberflächliche Leute. Bei euren Beiträgen wird mir
schlecht. Ich greif mal 2 heraus:
Lukas K. schrieb:>> - Event-Verwaltung ? (denkt an die Knöpfe am Gerät)> Knopf->Eingabegerät
...kopfschüttel
Lukas K. schrieb:>> - Drucken und Gerätekontexte ? (denkt an den Kassenbon)> Bondrucker wird wohl RS232 oder so sein, kein Problem
So? Daß Druckdaten über irgendeine verdammte Verbindung zum Drucker
geschafft werden müssen, ist so was von low level und
selbstverständlich, daß ich das garnicht angesprochen habe. Guckt mal
auf den letzten Kassenbon und fragt euch wie das da draufkommt, was ihr
dort sehen könnt. Etwa printf nach stdout? Nee. Hier geht es um
Grafikdruck und nicht um ne RS232. "Bondrucker wird wohl RS232 oder so
sein" - was für eine ausgemachte Blindheit!
Also ich schließe mal, daß ein Embedded Linux nicht drucken kann.
Allenfalls kann es das, was woanders gedruckt wurde, weiterleiten.
Ganz offensichtlich habt ihr Linuxer immer noch keine Vorstellung von
dem, was ich hier mal als "Grafik" bezeichnet habe: also grafisches
Userinterface (Desktop auf'm Moni) und grafische Peripheriebedienung
(Kassenbon aus dem Drucker).
Beim Desktop sieht man bunte Kringels, aber das ist ja nicht der Kern
des Geschäftes. Hinter jedem Kringel steht ein Stück Programm, ein
Thread. All diese Threads müssen interagieren, dazu das Eventsystem. Und
sie müssen verwaltet werden. Das ist der Job des Schedulers, also des
innersten Kerns des BS. Genau deshalb ist die Verwaltung des Desktop
eine zentrale Aufgabe des BS-Kernels, die all das umfaßt, was man auch
für alle anderen Treads (Dienste bzw. Demons) tun muß und darüber hinaus
auch noch deren visuelle Darstellung und Wiederherstellung organisieren.
Und auch der hier versteht nix:
"Grafik:
wie schon angesprochen der Framebuffer als schnittstelle zwischen der
reinen monitor representation und dem GUI framework."
Der Framebuffer ist Nebensache, die Verwaltung der Elemente, sprich
Threads, ist der Kern der Sache.
Versucht doch endlich mal, so was einfaches zu begreifen!
Fazit: Von einem Embedded Linux kann man keinen grafischen Desktop
erwarten. Ist ja auch ne Aussage.
Aber mir wird das hier langsam zu blöd.
W.S.
W.S. schrieb:> . Etwa printf nach stdout? Nee. Hier geht es um> Grafikdruck und nicht um ne RS232.
Im Handbuch des Druckers werden wohl die Escapesequenzen des Druckers
beschrieben sein, dann passt das schon mit printf nach /dev/ttyS0.
W.S. schrieb:> Also ich schließe mal, daß ein Embedded Linux nicht drucken kann.
Gar kein Linux kann drucken. Dafür gibt es CUPS/lpr o.ä.
W.S. schrieb:> Fazit: Von einem Embedded Linux kann man keinen grafischen Desktop> erwarten. Ist ja auch ne Aussage.
Ich erwarte von keinem Embedded-System einen grafischen Desktop. Er
stört sogar.
W.S. schrieb:>> Knopf->Eingabegerät> ...kopfschüttel
-v, bitte
EDIT: Für einen zufällig ausgewählten Bondrucker von EPSON gibt es keine
Treiber für CE, für Linux auch nicht. Nur für Desktop-Windowse.
W.S. schrieb:> Ganz offensichtlich habt ihr Linuxer immer noch keine Vorstellung von> dem, was ich hier mal als "Grafik" bezeichnet habe: also grafisches> Userinterface (Desktop auf'm Moni) und grafische Peripheriebedienung> (Kassenbon aus dem Drucker).
Du scheint selber das ein oder andere Verständnisproblem zu haben. Auf
meine Punkte bist du jedenfalls nach wie vor nicht eingegangen. Ich
nehme mir mal das Recht heraus und behaupte, dass du damit akzeptierst,
dass ich zumindest nicht Unrecht habe ;).
Übrigens deuten deine Erläuterugen auf weitere Verständnisprobleme hin.
W.S. schrieb:> . Hinter jedem Kringel steht ein Stück Programm, ein> Thread. All diese Threads müssen interagieren, dazu das Eventsystem. Und> sie müssen verwaltet werden. Das ist der Job des Schedulers, also des> innersten Kerns des BS.
Ein Programm ist nicht mit einem Thread gleichzusetzen. Ein Thread ist
eine Abstrahierung eines Abhandlungsstranges innerhalb eines Prozesses
und wird unter anderem auch als "leichtgewichtiger Prozess" bezeichnet.
Von Threads zu sprechen macht eigentlich nur Sinn, wenn es davon mehr
als einen gibt. Und das ist absolut keine Notwendigkeit für ein
Programm.
W.S. schrieb:> Der Framebuffer ist Nebensache, die Verwaltung der Elemente, sprich> Threads, ist der Kern der Sache.
Siehe dazu meine obige Ausführung zu Threads. Wie die "Verwaltung der
Elemente" implementiert ist spielt überhaupt keine Rolle. Völlig egal,
ob das nun ein Thread innerhalb eines einzigen Prozesses ist, oder aber
eventuell mehrere Prozesse, welche mit einander kommunizieren. Das sind
in gewisser Maßen Freiheitsgrade bei der Implementierung, die es, wenn
überhaupt, in der Dokumentation zu vermerken gibt. Über die
Funktionalität des Systems sagt das noch nichts aus.
Um den "Kern der Sache" zu bestimmen, kommt es halt drauf an, was genau
man sich anschaut. Die "Verwaltung der Elemente" in der Form, die du
meinst, ist eben nicht im Kernel selbst unterzubringen, sondern im sog.
Userland. Demnach würde ich es nicht als Kern der Sache bezeichnen.
