Archiv verlassen und diese Seite im Standarddesign anzeigen : Der Weg vom Einschalten bis zum Laden des OS-Kernels
Hallo Leute,
heute ist mir einmal die Frage gekommen wie eigentlich ein OS funktioniert.
Wenn man das jetzt so ließt hört sich dies komisch und vielleicht lustig an, aber mich würde einmal Interessieren was dabei alles auf einem µC geschehen muss bis der Kernel des OS geladen werden kann.....
Dabei bin ich darauf gekommen, daß die "Schnittstellen" schon einmal im "BIOS" (welches beim µC der interne speicher wäre) voreingestellt werden sollten und somit auch in der Interrupt-Routine vorhanden sein sollten.
Somit sollte ich einmal wissen wie ein "BIOS" aufgebaut ist.
Weil ich habe mir einmal überlegt wenn ich das Prinzip verstanden und dann noch lust habe ein sehr einfaches OS (ne Shell art) für µC zu entwickeln.
Greez Marc
Du vermischt da mehrere Sachen,
Bios != Operating System
Was willst du denn genau wissen?
Hallo
Was soll den ein Kommandointerpreter (Shell) auf einem uC? Ein Real-Time OS, würde da viel mehr nützen, ein uC macht ja normalerweise keine Benutzerinteraktion.
Zum Thema OS gibt's ziemlich umfangreiche Vorlesungen und noch umfangreichere Bücher.
Was mir da gleich einfällt:
- Silberschatz et. al. : Applied Operating System Concepts
- von A. Tanenbaum gibts auch ein paar Bücher zu diesem Thema
Sonst zigtausend Artikel zu Linux
Für den AVR hab ich mal das gefunden: http://www.barello.net/avrx/index.htm
Aber ev. war das jetzt auch zu weit gegriffen (?)
Gruess
Fritzli
P.S: Eine "Shell" ist KEIN Betriebssystem, sondern nur ein Teil davon. Bei DOS kommt allerdings alles in einem "Programm".
Stimmt BIOS nicht gleich OS
aber ich finde die Trennung was beim BIOS Software und was Hardware ist ist ned so einfach.
Und/Oder/Aber wie au immer ... ich meine mit diesem Thread den kompletten weg vom Einschalten bis zum beginn des Ladens des Kernels der OS...
das ist mir alles noch nicht so ganz klar wie das verwirklicht wird.
hmm... stimmt habe da n bissle was durcheinander geworfen.....
Sagen wir es einmal so ich würde sowas in der Art machen wollen wie ein 386er mit DOS um des jetzt einmal ganz grob zu beschreiben... über den genaueren verwendungszweck habe ich mir noch keine gedanken gemacht...
Irgendwie fühle ich mich zurückversetzt ins Forum von Chip.de ;)
Dort tauchte auch ab und zu mal die Frage auf wie man ein OS programmiert.
Und das von totalen Anfängern.
Das ist nicht böse gemeint, aber wäre das gleiche wie wenn ich bei DSDS auftreten würde. Entweder man kann/versteht es oder nicht.
Wie schon geschrieben wurde, ist ein µC nicht geboren wurden um einen PC zu ersetzen.
Er arbeitet vorgegebene Schritte ab. Ein Highlight ist es, wenn er selbst erkennt, das er grade eine Pause macht und in der Zeit schonmal schaut, was er sonst noch so erledigen könnte bis er wieder gefordert wird.
Aber ein BIOS auch nicht im Ansatz gibt es für µC nicht. Es gibt da auch keine Teile die ähnliche Funktionen übernehmen. Alles muss programmiert werden.
Ich habe auch noch nicht so ganz verstanden, was du eigentlich bezwecken willst. Das du noch keine genaue Anwendung dafür hast, habe ich verstanden. Aber was soll das ganze bringen?
Das du eine Tastatur anschliessen kann und eingibst "Kaffee kochen" und dann wird welcher gekocht?
JA danke! Du bist echt mein Held.
Dann einmal eine andere Frage was ist an einem µC im vergleich zu einem µP noch alles anders, außer das z.B. Speicher, Peripherie und noch n paar dinge beim µC schon alles Integriert ist? Wenn man genauer schaut findet man den µP darin auch wieder.
Ich nehme jetzt einfach einmal an das das BIOS eines µP vom Hardware Teil einmal gesehen ist nichts anderes ist wie ein externer Speicher auf dem ein "Grundprogramm" abgelegt ist. Weil wie würde sonst ein MEMORY Check oder Eine Initialisierung der HDDs von statten gehen?
Ein sinn und zweck für diesen sehr leistungsschwachen "PC" ist mir auch einfallen. Man könnte daraus ja eine sehr sehr billige form eines "embedded pcs" machen. Ist zwar nich mächtig, aber würde immer noch reichen um kleinere Maschinen zu steuern.
einmal eine andere Frage warum ist es Möglich auf einem ARM9 (in meinen augen nichts anderes als ein 32Bit µC) Linux laufen zu lassen?
Und schoneinmal etwas von den µ embedded PCs gehört die wie ein 186er als WEBSERVER funktionieren?
http://www.beck-ipc.com/ipc/products/category/index.asp?cat=1&sp=de
das anwende specktrum wäre groß.
Ich denke mal bei einem µC ist der Bootloader sowas wie das BIOS (Basic Input Output System)...
Ein BIOS charakterisiert sich ja dadurch, dass:
- Enthält Software zum Auslesen von Hardware (z.B. Datenträger, Speicher, etc. auf/in dem sich ausführbare Software befindet)
- Bleibt ohne Stromzufuhr erhalten
- Enthält Treiber für Hardware
Als OS (Operating System) würde ich jetzt eher die Software bezeichnen, die man auf den µC läd. Zumindest den Teil, der sich in den (z.B. AVR-) Bibliotheken befindet, also sozusagen die "Grundfunktionen" des µCs.
Aber egal ob du ein OS oder ein BIOS selbst schreiben willst, du brauchst auf jeden Fall (vor allem bei einem BIOS) sehr konkrete Informationen und Kenntnisse über die Hardware, auf die deine Software laufen soll. Du musst die verfügbaren Maschinenbefehle kennen, und diese Stück für Stück erweitern und zu größeren Konstrukten zusammenfassen. Das ist ein sehr langwieriger Prozess und ist eigentlich nur von Wizards zu schaffen...
Oder was glaubst du, warum es so wenige gute / brauchbare Betriebssysteme gibt? Wenn es so einfach wäre, würde sich jeder halbwegs erfahrene Programmierer sein eigenes Betriebssystem schreiben...
Die wirklich brauchbaren Betriebssysteme, die auch überlebt haben, kannst du an ein, höchstens zwei Händen abzählen.
Klar, für einen µC ist das ganze etwas einfacher, da diese sehr viel beschränkter sind als eine CPU... Aber ich denke, es ist trotzdem mit einem erheblichen Aufwand verbunden.
Aber wenn du es schaffst: Respekt :)
Joa das stimmt...
Zu dem Thema mit den Brauchbaren OS habe ich mir folgende erklärung gemacht. Alle Betreibssysteme sind eher aus einem Zeitalter (zumindest die Grundzüge) als der PC als solcher noch nicht exestierte und daher nur von hobby bastlern verwendet wurde oder ein bisschen später als die HARDWARE noch nicht so fürchterlich kompliziert war.
Das ist Glaube ich auch ein Grund warum heutzutage nicht wirklich neue OS entwickelt werden, dazu müsste man nähmlich zunächst ein "einfaches System" haben und sich darüber hinaus mit diesem elektronisch voll auskennen. Damit man in der Lage ist ein OS für dieses zu Programmieren.
Dies ist heutzutage nicht mehr so der Fall, da ich kaum glaube jeder sich so im klaren ist was innerhalb der heutigen Hardware abgeht und dazu noch die nötigen Programmierkentnisse hat.
Die Programmierkenntnisse habe ich zwar auch nicht aber ich denke die kann man sich im Laufe der Zeit aneignen wenn man seine Hardware vom elektronischen Teil her erklären kann und über ihre funktionen sich auch im Klaren ist.
Außerdem will ich ja kein OS für µP entwickeln sondern für µC.
Aber nun einmal die Frage hat sich eigentlich von euch wirklich schon einmal einer die Gedanken gemacht was wirklich in einem PC im BIOS Bootvorgang abspielt?
OK jetzt denk warscheinlich jeder ja klar... Überprüfung der Hardware, erkennung der Laufwerke, usw.
Und gerade bemerke ich das es ziemlich schwer ist das was ich sagen will auszudrücken......*mist*
@maze2k: Ja ich glaube der Bootloader ist etwas vergleichbares wie das BIOS, aber ich denke das BIOS ist noch ein wenig mächtiger.
Klar ist es mächtiger, es war ja nur als ungefährer Vergleich gedacht.
Ok, was passiert jetzt, wenn ein PC gestartet wird?
- Zuallererst der "Power On Self-Test" (POST)... da überprüft das BIOS die CPU, den Speicher, Arbeitsspeicher, Grafikhardware, Tastatur + Peripherie
- Hardware initialisieren
- Bootloader bzw. in den Win-Dosen: Betriebssystem-Software starten
Ich denke mal, das wichtigste am BIOS ist Schritt 1. Wenn erst einmal sichergestellt ist, dass alle Komponenten funktionieren, kann man die Hardware initialisieren (also Register setzen, etc.) und dann die Betriebssystem-Software in den Arbeitsspeicher laden.
Dieser erste Schritt ist natürlich wieder hardwareabhängig...
Ich denke man kann BIOS und Bootloader nicht besonders gut vergleichen.
Ein Bootloader legt ja nur empfangene Daten in einen bestimmten Speicherbereich, und hat mit dem eigentlichen Bootvorgang herzlich wenig zu tun.
Die Frage ist doch wozu ein BIOS auf einem µC überhaupt gut sein soll...
- Hardwareerkennung
auf einem µC gibt es nichts zu erkennen, da sich die Hardware nicht ändern kann
(und externe Bauteile zu erkennen ist kaum möglich)
- Selbsttest
sicherlich möglich, und manchmal auch sehr sinnvoll.
Allerdings würde das kaum Jemand als BIOS bezeichnen
- Hardwareinitialisierung
möglich, nötig, in jedem Programm vorhanden...
aber BIOS ist wohl nicht die passende Bezeichnung dafür
Es sollte klar sein, daß ein PC und ein µC zwei grundlegend verschiedene Dinge sind.
Daher macht es auch nicht viel Sinn wenn man zwanghaft versucht, alles was es auf einem PC gibt auf einem µC nachzubilden.
Wenn erst einmal sichergestellt ist, dass alle Komponenten funktionieren, kann man die Hardware initialisieren (also Register setzen, etc.) und dann die Betriebssystem-Software in den Arbeitsspeicher laden.Und genau das ist der wichtigste Punkt in dem sich die beiden Systeme unterscheiden.
Ein "normaler" Prozessor z.B. von Intel ist reprogrammierbar, ein µC jedoch nicht.
Bei einem µC liegt das Programm in einem nichtflüchtigen Speicher, und wird von dort direkt ausgeführt.
Es ist zunächst mal nicht möglich während dem Betrieb irgendein anderes Programm zu starten.
Bei einem PC hingegen werden die Programme erst in den Arbeitsspeicher geladen und von dort ausgeführt.
Wenn du einen µC mit Spannung versorgst beginnt er sofort mit der Ausführung des im Flash gespeicherten Programms.
Es gibt nur dieses eine Programm, und man kann zur Laufzeit auch kein anderes starten.
d.h. man kann hier BIOS, OS und Anwendung nicht klar voneinander trennen, da letztendlich ein Programm alle Aufgaben übernimmt.
Du hattest einen Webserver als mögliches Anwendungsgebiet genannt...
aber was ist ein Webserver?
eigentlich ist es nur irgendein Programm das über ein bestimmtes Protokoll mit anderen Programmen kommuniziert.
Auf welcher Hardware dieses Programm läuft völlig egal, und ein Betriebssystem braucht man dafür auch nicht unbedingt.
linux_80
08.12.2005, 00:58
Hallo ihr beiden,
ich will auch was loswerden ;-)
meiner Meinung nach wäre ein BIOS bei einem µC nur eine Init-routine, die die IO-Ports je nach Verwendung einstellt, ADC, I2C, evtl. LCD usw. was man sonst braucht in einen definierten Zustand zu setzen.
Erst wenn das abgeschlossen ist, kann der µC auf externe Sachen reagieren, also Richtung OS (übertrieben).
Das ist beim µC aber alles in einem kleinen Programm zusammengefasst, denn normalerweise ändert sich an der Beschaltung des µC nix, deshalb muss es auch nicht flexibel sein wie ein BIOS eines PCs.
Das spart Platz im µC. Und der Sinn eines µC ist ja das er klein sein soll.
NumberFive
08.12.2005, 08:24
Nicht gleich er schlagen wenn die Idee grotten falsch ist.
Dachte nur eben bei durch lesen:
Also der µC macht doch beim einschalten nix Anderes als den Befehl der an der Adresse X (ich gehe jetzt mal von 0000 aus) steht aus zu führen.
Wenn da jetzt ein nini prg steht welches die COM initaliesiert und eine hand voll befehle kennt.
Könnte man doch wenn es µC gibt die Ihr flash beschreiben können doch andere prg ausführen. In dem man per RS232 das Prg in den Flash schreibt
der noch frei ist und dann einen Jump auf die erste Adresse im flash mach wo man das übertrage hin geschrieben hat.
Oder liege ich da jetzt föllig falsch.
bei einem Pc passiert im grunde ja auch nix anders man kopiert den code ins ram und sagt jump dahin wo der erste machine befehl steht.
Gruß
@Felix: Sorry, aber was Du geschrieben hast, ist völlig falsch.
Ich glaube, einige hier haben den Unterschied zwischen µC und µP nicht verstanden.
Im Prinzip unterscheiden sich µC und µP nicht sonderlich. Ein µP ist erst mal nichts anderes als eine Recheneinheit, die nach außen lediglich über Datenbus, Adressbus und Steuerbus mit anderen Baugruppen kommuniziert.
Jeder µC enthält auch einen µP. Der µC ist lediglich mit zusätlicher Peripherie ausgestattet, wie z.B. I/Os, ADC, UART.... Das ist der einzige Unterschied! Bei kleineren µC sind zudem Daten-, Adress- und Steuerbus nicht nach außen geführt.
Damit das BIOS im PC überhaupt eine Wirkung haben kann, muss man das gesammte System sehen. Also den PC mitsammt Prozessor, Speicher, Northbridge, Southbridge, Laufwerken und Schnittstellen. Das BIOS ist das Programm, mit dem der Prozessor alle Komponenten im System ansprechen kann. Das BIOS regelt also nach dem Einschalten die gesammte Kommunikation zwischen den einzelnen Komponenten eines PCs, lädt den Programmcode des OS vom Bootsektor der Festplatte ins RAM und führt ihn aus.
Wenn man für einen µC ein PC-ähnliches BIOS schreiben will, braucht man also erst mal Komponenten, die man mit diesem Bios ansprechen will. Also evtl. externen Speicher, Laufwerke, Grafikcontroller etc.
Und dann kann man hingehen und über die Laufwerke ein externes Programm einspeisen, wie z.B. ein Betriebssystem.
Die Aussagen von linux und NumberFive sind übrigens auch ziemlich zutreffend.
PS: Bei Wikipedia (www.wikipedia.de) sind Mikroprozessor, Mikrocontroller und BIOS relativ ausführlich erklärt.
askazo
@askazo
Es wäre hilfreich wenn du genau ausführen könntest was "völlig falsch" ist, denn der ganze post ist es sicherlich nicht
(Konstruktive Kritik ist in jedem Fall besser als der einfache Kommentar Irgendwas sei falsch)
Mag sein, daß das Unterscheidungskriterium der Reprogrammierbarkeit bei sehr großen µCs nicht mehr 100%ig zutrifft.
Aber zumindest alle ohne externes Speicherinterface sind einfach nicht reprogrammierbar.
Und bitte kommt jetzt nicht mit Bootloadern und Ähnlichem, denn auch das ändert nichts an der Tatsache,
daß man im laufenden Betrieb nicht einfach so ein anderes Programm ausführen kann als das welches im Flash steht
Könnte man doch wenn es µC gibt die Ihr flash beschreiben können doch andere prg ausführen. In dem man per RS232 das Prg in den Flash schreibt
der noch frei ist und dann einen Jump auf die erste Adresse im flash mach wo man das übertrage hin geschrieben hat.
Oder liege ich da jetzt föllig falsch.Nein, das siehst du absolut richtig...
jeder Bootloader macht genau das, aber eben nur nach einem Reset.
(PS: damit meine ich jede mögliche Form des Resets, nicht nur +Vcc am Reset-Pin)
Natürlich könnte man jetzt sagen man setzt das Betriebssystem in den Bootloader-Bereich,
und lässt es die eigentliche Anwendung von sonstwo laden (z.B. von einer SD-Karte oder so)
Aber dafür ist dieser Bereich einfach viel zu klein.
(auf einem ATmega32 z.B. nur maximal 2k)
Wenn man für einen µC ein PC-ähnliches BIOS schreiben will, braucht man also erst mal Komponenten, die man mit diesem Bios ansprechen will. Also evtl. externen Speicher, Laufwerke, Grafikcontroller etc.
Und dann kann man hingehen und über die Laufwerke ein externes Programm einspeisen, wie z.B. ein Betriebssystem.Wenn du das auf einem nicht reprogrammierbaren µC hinbekommst bin ich wirklich beeindruckt.
Mag sein, daß das Unterscheidungskriterium der Reprogrammierbarkeit bei sehr großen µCs nicht mehr 100%ig zutrifft.
Aber zumindest alle ohne externes Speicherinterface sind einfach nicht reprogrammierbar.
Und bitte kommt jetzt nicht mit Bootloadern und Ähnlichem, denn auch das ändert nichts an der Tatsache,
daß man im laufenden Betrieb nicht einfach so ein anderes Programm ausführen kann als das welches im Flash steht
Was ist ein sehr großer µC? Zählt da schon ein ARM7 wie zB ein µC der AT91SAM7S-Serie von Atmel dazu?
Eigentlich dürfte die Reprogrammierbarkeit doch bei jedem µC vorhanden sein, der Code aus einem externen Speicher oder auch dem internen RAM ausführen kann (also bei einer von-Neumann-Architektur).
Und sobald ein µC dies unterstützt, kann man doch auch während dem laufenden Betrieb ein anderes Programm ausführen.
@Felix: Genau diese Reprogrammierbarkeit, die Du ansprichst, stellst Du hier falsch dar. Man kann bei jedem µC, dem man von aussen in irgendeiner Weise Daten zukommen lassen kann, austauschbare Programme ausführen lassen. Das Programm, was im Flash abgelegt ist, könnte man in diesem Fall sogar als BIOS bezeichnen.
Man kann z.B. ohne Probleme ein hex-file über die serielle Schnittstelle des µC ins RAM laden, den Program-Counter auf die entsprechende Adresse im RAM setzen und schon läuft ein von extern geladenes Programm. Pascal hat da völlig Recht.
askazo
Stimmt, aber das geht nur wenn der µC auch Programme im RAM ausführen kann.
Und zumindest die hier sehr beliebten AVRs von Atmel können das nicht
(obwohl man ihnen von außen selbstverständlich Daten zukommen lassen kann)
Ich habe mich in meinem ersten post wohl zu sehr auf µCs mit Harvard-Architektur bezogen
Stimmt, aber das geht nur wenn der µC auch Programme im RAM ausführen kann.
Das kann aber jeder ARM und die sind inzwischen auch recht verbreitet, wenn auch nicht in diesem Forum.
Die 8051er dürften das auch können.
Und zumindest die hier sehr beliebten AVRs von Atmel können das nicht
Die AVRs sind ja auch sehr an die Harvard-Architektur angelehnt.
Ok, mir war bisher nicht so wirklich bewußt, dass die AVRs eine Harvard-Architektur haben. Dann geht das natürlich nicht, dass ein Programm im RAM ausgeführt wird, und somit ist's auch mit dem BIOS Käse...
Es sei denn, man schreibt sich ein kleines Bios als Bootloader und arbeitet damit, aber das ist ja auch nicht wirklich das wahre...
askazo
Hey Leute,
jaa des was ich hier jetzt so zu diesem Thread lese gefällt mir schon besser wie das was gestern abend war.
Mag sein, daß das Unterscheidungskriterium der Reprogrammierbarkeit bei sehr großen µCs nicht mehr 100%ig zutrifft.
Aber zumindest alle ohne externes Speicherinterface sind einfach nicht reprogrammierbar.
Und bitte kommt jetzt nicht mit Bootloadern und Ähnlichem, denn auch das ändert nichts an der Tatsache,
daß man im laufenden Betrieb nicht einfach so ein anderes Programm ausführen kann als das welches im Flash steht
Also zu dem Thema reprogrammierbarkeit habe ich nur eine frage, was soll das sein. Wenn ich das wort einmal wörtlich nehme dann verstehe ich darunter so etwas wie ein Programm auf ein EPROM zu schreiben und dieses wenn nötig wieder mit hilfe von UV-Licht zu löschen.
Aber der µP verarbeitet letzten endes ja nur vorhandene Daten.
Ich selber stelle mir die Grundfunktion eines µP so folgender maßen vor.
Dieser verarbeitet einfach nur die Daten, die er vom Cache bekommt (also somit auch von HDD, FDD, CD-ROM was ja erst im RAM zwischengelagert wird und dann zur weiterverarbeitung erst in den cache gelegt wird)
1. Was ist dabei nun Reprogrammierbar?
2. Wer oder Was ist dafür verantwortlich das er die DATEN bekommt?
Oder ist aber dem µP fest gesagt lese einfach die daten aus dem RAM aber dann muss ja noch irgend etwas anderes die daten von der HDD in diesen LADEN.....
Noch ein kleiner Gedanke von mir ich nenne es jetzt einfach einmal BIOSHybrid.
Eigentlich müssten BOOTLOADER und BIOS irgendwie in eine Einheit
gebracht werden. Weil die einen Funktionen vom einen und manche funktionen vom anderen wären bei einem "BOOT" des µC beide erforderlich.
reprogrammierbar bedeutet, daß man im laufenden Betrieb irgendein Programm laden und ausführen kann.
Das geht aber nur, wenn der Controller auch Programme ausführen kann die im RAM (oder einem externen Speicher) liegen.
Bei den AVRs z.B. ist das aber nicht der Fall, die können nur das Programm ausführen das man im Flash abgelegt hat.
Aha ich weiß von einigen PICs das diese in der Lage sind ihren Flash auch selbst zu beschreiben.
Die AVRs können das auch. Das ist jener besagte Bootloader.
Der dient aber normalerweise nur dazu, ein Firmwareupdate durchzuführen. Aber wie gesagt, man kann ihn im Prinzip auch als Bios verwenden.
askazo
µC-BIOS: Ein Problem bei diesem Vorhaben liegt darin, daß
die externen Anschlüsse bei µCs oft mehrfach belegt
sind, was hohe Flexibilität bezweckt.
Das heisst, es gibt nicht "die" Initialisierung,
sondern es gäbe verschiedene. Ein mögliches
BIOS müsste also verschiedene Varianten bedienen.
Da oft jeder Pin unabhängig von den anderen
konfigurierbar ist, gibt es ungeheuer viele
Permutationen. Bei nur 8 Pins, von denen jeder
nur zwei mögliche Konfigurationen besitzt,
gibt es bereits 256 Initialisierungsvarianten.
Natürlich könnte man ein Bios sehr flexibel
gestalten, indem man beispielsweise die 16-Bit-Nummer
der gewünschten Konfiguration mit übergibt.
Das kostet dann aber immens Speicherplatz,
was dem Konzept der µC zuwiderläuft.
Oder man machts mit bedingter Assemblierung,
hat dann aber ein BIOS im µC, das nur wenige
feste Konfigurationen benötigt.
Wenn man externe Hardware anschliessen will,
muss man diese ja auch initialisieren. Das
wäre eigentlich eine Aufgabe des BIOS, verbietet
sich aber aus naheliegenden Gründen...
Also müsste man "per Hand" ein bestehendes BIOS
dann immer noch erweitern... und dann Klemmts
vielleicht, weil das BIOS im Spezialfall doch nicht
so flexibel, oder in der speziellen Konstellation
buggy ist...
Nein, nach meiner Ansicht ist das ein Projekt,
das klar in eine Sackgasse führt. Je eher man das
erkennt, umso besser.
Ich meinte natürlich:
...
Oder man machts mit bedingter Assemblierung,
hat dann aber ein BIOS im µC, das nur wenige
feste Konfigurationen e r m ö g l i c h t.
...
Grüße an das Forum
TORO
JA danke! Du bist echt mein Held.
Hey Leute,
jaa des was ich hier jetzt so zu diesem Thread lese gefällt mir schon besser wie das was gestern abend war.
Kein Problem. Wenn du des lieber hören möchtest, dann sag es doch gleich!!!
Hi Leute,
ich hab im Internet eine Seite gefunden die sich mit diesem Thema auseinandersetzt.
http://www.uclinux.org/
Also so wie ich das seh, ist in jedem µC nicht nur ein µP sondern auch noch ein (µ)BIOS. Das Bios auf dem PC ist eigentlich nur eine Ansammlung von Routinen um über uralte Befehle (286-Zeit) eine nicht bekannte Hardware irgendwie anzusprechen.
Also beim PC siehst es ja so aus:
1.) POST-Abfolge
BIOS prüft ob Platte, RAM, Prozessor und Grafikkarte vorhanden sind und ob sie in einem vom BIOS ansprechbaren MODUS arbeiten können.
2.) Ausgabe von Statusinformationen vom System und Fehlermeldungen (das ganze ist wirklich lowlevel, da wird mit Interruptroutinen auf die Bridges zugegriffen und einfach Kommandos abgelegt, wie: wieviele Sektoren hast du, Hast du den Modus 320x240x1Bit)
3.) Abrufen von Informationen von der Platte (MBR) Einlesen der ersten Datei bis EOF und abarbeiten lassen durch den Prozessor.
Ab da, übernimmt der Prozessor die Arbeit und ruft weiter über BIOS-Interruptroutinen weitere Daten an, bis dann endlich mal spzifische Treiber geladen wurden für Speicher, MoBo, GraKa und was weiss der Teufel noch mal.
Im µC ist sowas sicherlich ähnliches nur hardcodiert in der Hardware selber (nix Chip zum Wechseln und flashen.) Dieses "BIOS" steuert nach einschalten des Stromes entweder die Ports nach einem vorkonfigurieten Muster an und arbeitet dann einfach dne ersten Befehl im Speicher ab. (Maschinencode muss ja nicht verstanden werden sondern wird stur abgearbeitet (von beiden Arten)), oder prüft zum Beispiel auch Strom an und Reset High, dann ISP-Modus.
Also ist bei beiden ein BIOS drin, ist nur unterschiedlich im Vorgehen, da bei dem PC das BIOS nicht weiss welche Peripherie um in herum ist, und er eigentlich nur ein Babbelfisch ist, beim µC weiss er genau was da ist, und kann dadurch einfach und schnell starten.
Deshlab starten alle PC und µC mit festen Code viel schneller, als die Windoof mühlen oder Linux, da nichts erst ümständlich geladen und analysiert werden muss bis alles genau funktioniert. Hard verdrahtet ist schneller als soft gecodet. *g*
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.