Ich habe mal eine Verständnisfrage zu Prozessoren.
Bei einem uC z.B. einem 8051 Derivat ist ja meistens Ram mit drin und ein bischen Flash-ROM für das Programm.
Wie muss man sich das vorstellen im Vergleich zu einem herkömmlichen PC-Mainboard. Ist dann, der RAM-Speicher wie integriert und ist das Bios quasi der Programmspeicher?
Könnte man im ROM nicht auch komplette Programme fürs Mainboard unterbringen, so dass man ohne Festplatte und Betriebssystem auskommt?
Gibt es Programmierumgebungen/Programmiersprachen/Compiler, um BIOsse zu programmieren? Wenn nein, wie macht man es sonst, wenn man z.B. eine Intel-CPU für etwas einsetzen möchte, weil die uC-Prozessoren mit max. 300MHz einfach nicht ausreichen?
Kann man natürlich, allerdings ist das ROM nicht besonders groß im Vergleich zu einer Festplatte und man muss die ganze Hardwareinitialisierung und -ansteuerung halt selber machen.
Assembler, C mit geeigneten Bibliotheken, jede Programmiersprache, die nicht zwangsläufig ein Runtime und ein Betriebssystem voraussetzt...
Es gibt bei dem Zeug normalerweise kein BIOS. Oft noch nicht mal das, was man ein Betriebssystem nennen würde. Bei dem Kleinzeug ist meistens eine monolithische Anwendung drin; d.h. der Prozessor springt nach dem Reset an der vordefinierten Stelle ein, belegt programmgesteuert oder auch per Hardware-Reset-Config-Leitungen seine Register vor, und ab geht die Luzie. Bei etwas "dickeren" Embedded-µControllern (wie wir sie verwenden ;) )wird dann idR aus einem Flash ein Bootloader gestartet, bei uns z.B. U-Boot von Denx/Sourceforge. Der bietet eine einfache Shell, ist per Environment-Variablen konfigurierbar und unterstützt schon eine gewisse Menge Hardware (je nach Prozessor: IDE/CF-Karten, I2C, Netzwerk, etc.). Ferner Befehle zum direkten Schreiben und Lesen von Speicherinhalten, zum Flash-Löschen etc. und einen einfachen Speichertest. Also alles, was man braucht, um ein Betriebssystem-Image oder eine Anwendung herunterzuladen, ggf. ins Flash zu verfrachten und an einer bestimmten Adresse zu starten. Ursprünglich gedacht ist U-Boot eigentlich für (Embedded) Linux, aber auch fast alle anderen gängigen Sachen lassen sich damit starten.
Hm, ein On-Chip-ROM *in*einer*MCU ist meistens für aufwendigere Sachen nicht groß genug. Aber auf heute gängigen Embedded-Modulen ist meistens genug externes Flash drauf (Größenordnung: 32-64 MB), um z.B. einen Embedded-Linux-Kernel (kompiliert ca. 600-700 kB) und eine Ramdisk mit Anwendungsprogrammen (etliche MB), oder bspw. ein VxWorks samt dessen Bootloader abzulegen. Zusätzlich zu U-Boot, der ungefähr 200 kB braucht.
Stinknormales C, teilweise Assembler. Such Dir eine Entwicklungsumgebung Deines geringsten Misstrauens aus.
Man nimmt einen Freescale (vormals Motorola) 8540 oder 8560 mit bis zu 800 MHz? (Die verheizen dann aber auch schon ein paar Watt und brauchen ordentliche Kühlung...) Oder ein existierendes PC104- oder Embedded-CompactPCI-Board mit Pentium-M? ;) Da gibt es schon Lösungen für (fast) jeden Bedarf. Du kannst z.B. auch ein kleines Modul mit Intel PXA255 (XScale) mit 400 MHz, 32 MB Flash und 64 MB SDRAM drauf bekommen... ist grob gesagt so groß wie 2x2 Standardbriefmarken...
Ein maßgeschneidertes BIOS zu bauen ist entweder richtig mühsam (wenn man selber bei Null anfängt) oder ordentlich teuer (wenn man bei einem BIOS-Hersteller ein SDK einkauft - der Preis richtet sich dann nach der Menge der benötigten Module). Wenn es irgendwie geht, erspart man sich beides am liebsten.
So, bevor ich jetzt noch mehr Schleichwerbung mache, höre ich lieber auf.
Ansgar
--
Mails an die angegebene Adresse erreichen mich - oder auch nicht! Gültige
Adresse gibt's bei Bedarf!
Mails to the given address may or may not reach me - valid return address
will be given when required!
Ein "nichtkompatibles" kann jeder basteln. Ein "kompatibles" wo die handelsübliche Software aufsetzen soll wird eventuell schwieriger. Es gibt eine Firma ( Kontron ) die seit 20 Jahren kontinuierlich jammert, daß sie keine Bios-Programmierer einstellen könnten, verfügbares Personal am teutschen Arbeitsmarkt täten das nicht können. Liegt halt daran, daß man sich Spezialitäten als knowhow teuer erarbeiten muß und nicht erwarten kann, daß man sie billig von der Stange zukaufen kann. Soweit ich mich erinnere war ehedem bei PCs auch das Problem, daß die ersten BIOS-Cloner wegen Copyright-Verletzung erfolgreich vor Gericht gezerrt wurden und erst als clean-room entwickelte Versionen entstanden die gerichtsfest waren wurde der Markt entmonopolisiert. MfG JRD
Ein PC unterscheidet nicht zwischen Programm und Datenspeicher und das BIOS wird in einem Speicherbereich eingeblendet, wo der Prozessor nach dem Power-Up mit der Bearbeitung beginnt. Da er aber nicht beschreibbar ist, passt das schon.
Das geht, z.B. ist das BIOS ein solches Programm.
Im Prinzip jeder gaengige Compiler und Assembler, der Programme erzeugen kann, die ohne Betriebssystemumgebung auskommen. Das setzt eine Menge an Grundwissen ueber die Hardware und deren Funktionsweise voraus, oder eine gute Library.
Google mal nach Linux Bios, das hilft Dir vielleicht weiter - ansonsten ist die Lektuere von den Kernelsourcen empfehlenswert.
Groesstes Problem dabei wird sei die Hardware anzusprechen - da gibt es ja eine Menge an verschiedenen Zusammenstellungen und Moeglichkeiten.
Ein Embedded System mit entsprechender CPU nehmen, dass mit einem Minimal-Betriebssystem auskommt und darunter programmieren.
Aber wenn solche Leistung notwendig wird ist es auch immer ratsam, etwas genauer ueber das Problem nachzudenken.
Eine x86 CPU ist nicht sonderlich auf eine Anwendung spezialisiert, vielleicht gibt es bessere Alternativen? Gibt es Optimierungspotential? Ist vielleicht ein FPGA besser geeignet?
Oder noch dickere Brocken nehmen, hatte letztens mal was von SoC von Freescale gelesen, Dual-Core mit 866MHz RISC oder sowas in der Kante. Das ist eine Menge Rechenleistung.
RAM ist bei den PCs an vielen Stellen enthalten. Hauptsächlich im Prozessor als Cache und auf dem Mainboard als Speichermodul.
Als ich zu C/PM Zeiten mit der Computerei anfing, war es noch sauber getrennt. Es gab ein BIOS, das z.B. dafür zuständig war, Zeichen auf dem Bildschirm auszugeben und Daten von der Tastatur einzulesen. Es enthielt (bis auf eine Laderoutine) keine Programme, sondern nur Routinen.
Und es gab ein BDOS, das für die Disketten- bzw. Festplattenverwaltung zuständig war. Die Zeichenausgabe wurde einfach über das BIOS abgewickelt.
Für jedes der damals nahezu unendlich vielen verschiedenen Mainboards gab es ein eigenes BIOS. Jede BIOS Implementierung war auf das Mainboard abgestimmt, hatte aber einheitliche Einsprungadressen, so dass das BDOS mit nur geringen Anpassungen auf jeder noch so exotischen Hardware recht schnell in Betrieb genommen werden konnte.
Dieses Konzept wurde auf dem IBM PC zunächst übernommen. Die ersten DOS-Versionen wie auch C/PM 86 & Co. haben ebenfalls viele Ein- und Ausgaben über das BIOS abgewickelt. Im Laufe der Zeit wurde die Hardware zunächst immer stärker standardisiert. Die Bedeutung des BIOS wurde daher geringer und Ein- und Ausgabe wurde aus Geschwindigkeitsgründen stärker von den Programmen direkt oder später vom Betriebssystem übernommen. Als sich dann später die Hardware (z.B. durch Einsteckkarten) wieder von Gerät zu Gerät unterschiedt, hat man für die Zugriffsfunktionen Treiber entwickelt.
Aha, daher.... Ich hab mich vor einiger Zeit bei so einem Kontron Hutschienen-PC über das verf***** BIOS geärgert. Und die Doku/Handbuch zu dem Teil war übrigens auch nicht das Papier wert, woraus es gedruckt wurde. Gruß Andy
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.