Hallo @ alle erstmal. Da ich schon viel las über LCD und Mikrocontroller ( programmiert habe ich sowas nie zuvor, geschweige denn mir eine programmier-Einheit gelötet, aber ich sehe das als PRIMA einstieg) wollte ich mal hier anfragen, was ich denn tun müsste, um folgendes zu realisieren. - Eine 20*4 LCD anzeige, die mir CPU-Bezeichnung, CPU-Clock und Temperatur anzeigt. -Ich weiss, das wird zichfach beschrieben, aber ich will dafür keine 3rd-P software verwenden, um das LCD zu speisen. Ich hätte gerne ,dass sich das Ganze übers BIOS abfragen lässt, also, schon beim Power-on-self-test meines PC's ein code ausgeführt wird, der mir die erwünschten Resultate auf dem LCD präsentiert. (Sonst müsste ich ja auf das hochbooten des Os warten, damit erst die Software gestartet wird, und daraufhin das LCD gespeist wird). Aber ich möchte es gerne OS-unabhängig speisen und auf 3rd-p software verzichten. Und da weiss ich nicht,wie ich das anstellen soll. - Wie holt sich der controller diese Daten, oder wer holt sie sich überhaupt? - kann der Mikrocontroller überhaupt solche Anfragen stellen, wenn ich ihn per USB oder LPT mit dem System verbinde? - Wenn nicht, wie überhaupt? Zu meinem Stand: - Bstler, tüftler hobbymassig, auch casmodd(ell)ing. - C/C++-Programmierer, effektiv seit 2 Jahren, seit nem halben mit Assembler am beginnen, daher werde ich einges schon verstehen. Wäre echt dankbar für n kleinen Tipp.
Ich denke da wirst du kein Glück haben. Ohne OS wird soetwas wie Prozessor ID soweit ich weiß auf keinen Port rausgegeben.
Hallo, wenn Du gut bist, in den Bootcode der Systempartition hängen und von da erstmal anzeigen. Später dann per Software vom System aktuell halten. So wie es ein Bootselektor macht, vielleicht mal bei den Linuxern schauen, LiLo oder Grub sollten da zumindest Ansätze geben können. Gruß aus Berlin Michael
Denke auch nicht dass das geht. Du wirst wohl oder übel warten müssen bis dein OS hochgefahren ist und deine Ansteuersoftware (ob 3rd party oder selbstgeschrieben) ausführen kann. Warum sollte das BIOS auch irgendeinen Code dritter ausführen? Dazu ist es nicht gedacht, weswegen es dann auch die Kontrolle an ein Betriebssystem weitergibt. AFAIK funktionieren diese Dinger eher so, das deine auf dem PC laufende Software die entsprechenden Daten ermittelt und das LCD/µC nur als reines Ausgabemedium dienen. Deswegen funzen einige dieser Dinger ja auch ohne µC, sondern nur mit einem LCD am Parallelport ;) Plattformunabhängigkeit wird daher auch schwer werden, da es (glaube ich!) auch keine systemübergreifenden Verfahren gibt, um Systeminformationen auszulesen oder den Parallelport/USB anzusteuern. Unter Linux wird man da vermutlich auf die Infos aus /proc zugreifen können, unter Windows ka...
Bootloader (Lilo oder Grub) im Sourcecode nehmen, die benötigten Funktionen mit reinschreiben und das Ganze compilieren. Dann reicht theoretisch auch ein LCD am Parport ohne zusätzlichen Mikrocontroller aus. Gruß Jörg
Bootsektor ist noch viel zu spät. Das ist ja dann doch wieder betriebssystemabhängig :-) Du wirst nicht drum herumkommen, das PC-Bios zu modifizieren, und die gewünschten Daten über irgendeine Schnittstelle auszugeben. Und das ist für normale Hobbyprogrammierer, auch mangels passender Dokumentationen, jenseits aller Möglichkeiten. Ohne gebootetes OS geht es nicht. Und dann reicht für die Aufgabe ein x-beliebiges LCD, und z.B. der kleinste AVR, den du noch gelötet bekommst. Oliver
Einfache Lösung: Einfach das, was beim Hochfahren angezeigt werden soll im EEPROM des µC ablegen, bei Power-On anzeigen. Später, wenn das BS und die Software läuft, kann das ja aktualisiert werden. Klappt nur nicht, wenn du ständig den Prozessor wechselst. /Ernst
Dann muss er den Parallelport aber ohne Hilfe des Kernels ansteuern...befindet sich Grub bei seiner Ausführung eigentlich noch im Real Mode oder springt der gleich in den Protected Mode?
> Warum sollte das BIOS auch irgendeinen Code dritter ausführen? > Dazu ist es nicht gedacht, weswegen es dann auch die Kontrolle an ein > Betriebssystem weitergibt. Das ist nicht ganz korrekt. Es gibt die Technik der BIOS-Erweiterung, die beispielsweise von Graphikkarten und bootfähigen IDE/SCSI/RAID-Controllern genutzt wird. Bei ISA-Rechnern war das noch recht einfach gelöst, das BIOS überprüfte bestimmte Speicherbereiche im Adressraum des Rechners in 32-kByte-Schritten auf das Vorhandensein eines bestimmten Codes (0x55AA oder ähnlich) und auf Korrektheit einer an einem definierten Offset im 32-kByte-Block gespeicherten Prüfsumme. Stimmte alles, wurde zu einem bestimmten Zeitpunkt der Code in diesem 32-kByte-Block (Einsprung wiederum an einem definierten Offset) aufgerufen. So war das schon zu XT-Zeiten. Bei PCI-Karten ist das naturgemäß etwas komplizierter, dürfte sich vom Grundkonzept her aber ähneln. Nur wird hier die PCI-Karte selbst anmelden, daß sie ein ROM hat. Die genaueren Spezifikationen dafür dürften unter www.pci.org zu finden sein. Den Hardwareaufriss kann man sich möglicherweise durch Zweitverwertung einer bereits vorhandenen PCI-Karte sparen; ein geeigneter Kandidat dafür sind Netzwerkkarten, die oft sogar Sockel für BOOT-ROMs aufweisen. Nun muss man nur noch herausfinden, wie der Code darin gestaltet zu sein hat ... et voilà!
Brauchst Du das Floppy-Laufwerk noch? Vermutlich kannst Du auf dieses verzichten! Stelle das Bios auf "Booten ab Floppy" ein, entferne Das Floppy-Laufwerk und baue Dir eine uC Schaltung die Du an die Floppy-Schnittstelle anschliesst. Mit dem mC-Schaltung kannst Du den Bootvorgang abfangen, irgend was machen (z.B. eine Miniapplikation in den PC-Laden, welche Dir die gewünschten Daten liefert) und dann Schlussendlich mit dem Bootvorgang ab Harddisk weiterfahren... Infos, wie Du mit einem uC eine Floppy mit Bootsektor emulierst etc... bzw. wie die Floppy-Schnitstelle funkoniert und sich das ganze verhalten muss, darüber musst Du Dich am besten via Internet schlau machen... Wikipedia, Google, dieses Forum etc...
HAMMER! Bis her mehr an Info, als ich erwartet habe. Man sieht: Es gibt doch noch foren, die nicht nur n schönes D-Zign haben, und noobs beherbergen. Hier spricht die Quali.Da albert man nicht mit dem Board design, sondern lässtes schlicht und elegant. Geniales Forum. Werde mich anmelden. - So, zur sache: Ich nehme also keinen AVR am Parallel-port, sondern direkt ein LCD, WENN ich es per 3rd-p software anspreche? D.h. die software übernimmit die kommunikation mit dem LPT und die Steuerung der LCD? Das heisst,sie emuliert einen microcontroller? Oder wie geht sowas sonst? Weiterhin: Nehmen wir Rufus Beitrag: Die nic hält sockel bereit für eine hardware- Kommunikation? Ich habe mein LAN als on board interface. Ansonsten sitzen da noch onBoardound und ne PCI Express karte. Kann mir jemand das, was Rufus geschildert hat, genauer erklären? Ich meine: Wie kann ich denn ( er meint sicher Wake On Lan ) diesen Boot-rom nutzen (geht das mit on board? eher weniger, oder, muss schon ne eigene Karte sein , oder) und einen Code da rein bringen, der beim boot-up ausgeführt wird? - Oder anders: Nehmen wir an, ich flashe mein BIOS, ok? müsste gehen. und diese Flash-Bios version wurde von mir erweitert ( verdammt! Es ist doch binär! wie soll ich dass denn erweitern, ausser dissasemblen und dann meinen code dort unterbringen, SO DASS ER AUCH NICHTS STÖRT ) . Diese erweiterung im BIOS müsste doch in der Lage sein, da sie ja beim POST ausgeführt wird ( der boot-strap-loader läuft durch ) meinen Prozessor anhand seiner Bezeichnung zu erkennen? Erstmal das. Das mit dem LCD dann später. Was könnte ich denn da lesen, um das genauer zu raffen? Danke?
Ich würde dir davon abraten, ein manipuliertes BIOS auf dein Board zu flashen wenn du nicht exakt weißt was du tust. Und wenn du es wüsstes, würdest du nicht diesbezügliche Fragen stellen ;) Die Software, die das LCD via Parallelport ansteuert braucht keinen µC zu emulieren. Dem LCD ist es nämlich erstmal wurstegal, ob es von einem µC, einem PC-Parallelport oder einem Toaster angesteuert wird solange die elektrische Verbindung und die gesendeten Befehle korrekt sind. Sieh dir doch erstmal an, wie so ein HD44780 Standard LCD angesteuert wird (z.B. im AVR-Tutorial auf der Seite hier), dann siehst du vielleicht schon etwas klarer. @rufus: Das mit den BIOS Erweiterungen etc ist eine interessante Sache, danke für den Hinweis. Aber ich denke doch das der Aufwand für ein LCD, das nur ein paar Systeminformationen anzeigen soll recht hoch wäre (jaja ich weiß, hier gilt die "geht nicht-gibts nicht" Direktive ;))
Nur graue Theorie: Aber kann man solche Informationen nicht auch u.U. über den SMBus abfragen?
Kann man zwar, aber die Bausteine, die am SMBus hängen und die diversen Daten liefern sind i.d.R. komplett undokumentiert. Daher ist man auf Reengineering oder die Nutzung der den Motherboards beiliegenden grauenerregenden Software angewiesen. Auch weisen Motherboards i.d.R. keine Anschlüsse für den SMBus auf, die müsste man sich irgendwo selber dranlöten (DIMM-Sockel). Die von mir beschriebene Methode, eigenen Code auf dem PC vor dem eigentlichen Booten auszuführen löst natürlich dieses Problem überhaupt und gar nicht; wenn das BIOS nicht über eine definierte Programmierschnittstelle zur Abfrage der von ihm selbst angezeigten Informationen verfügt, müsste diese selbstgestrickt werden, was aufgrund der dürftigen Dokumentationslage ähnlich kompliziert werden dürfte wie der Versuch, unter einem OS an diese Informationen zu gelangen. Gut, sowohl die Taktfrequenz als auch der CPU-Typ lassen sich auf andere Art und Weise feststellen, damit wären 66% des geforderten Funktionsumfanges erfüllt. Die CPU-Temperatur muss eh laufend ermittelt werden, was sowieso den Einsatz von unter einem OS laufender Software vorschreibt. BIOS-Code ist nach dem Starten üblicher OS eh inaktiv. Der Nutzen einer Messung der CPU-Temperatur in der ersten Sekunde nach dem Einschalten des Rechners erscheint mir außerdem nur eingeschränkt sinnvoll.
Der SMBus ist bei manchen Mainboards auch auf einer Stiftleiste herausgeführt. Bei Asus wird das für irgend ein Infopanel, das ich aber noch nie gesehen habe, verwendet. Für ein paar Sensoren gibt der Source von lm_sensors (Linuxprogramm) auskunft. Im Linuxkernel hat es auch noch einige Treiber drin. Wäre aber sowieso mal cool, ein LCD an den SMBus zu pfriemeln. Ob da jetzt ein µC dran ist, der Abfragen durchführ oder ob der Bus nur Text zum LCD bringt ist da erstmal zweitrangig. Wenn das Interface tut, kann man sich immer noch weiter vorantasten. Man muss aber vorsichtig sein, was man auf dem SMBus treibt. Es gibt da einige IBM-Laptops, die nach einem SMBus-Scan nicht mehr funktionieren, weil da irgendwas komisches im Bios steckt.
> Kann man zwar, aber die Bausteine, die am SMBus hängen und die diversen > Daten liefern sind i.d.R. komplett undokumentiert. Daher ist man auf > Reengineering oder die Nutzung der den Motherboards beiliegenden > grauenerregenden Software angewiesen. Das stimmt bedingt... Zum einen gibt es diverse Tools im INet, die das ja auch können. http://www.almico.com/sfscreenshots.php Ich habe mich zwar bisher nicht wirklich mit I2C auseinander gesetzt aber ich vermute mal, dass die Zahl hinter dem Dollar im ersten Screenshot eine Adresse ist, mit der man den entsprechenden Sensor ansprechen kann. Ausserdem gibt es hier im Forum doch irgendwo einen I2C-Sniffer. Den kann man doch mal dran hängen und vielleicht kommt was sinnvolles dabei raus. > Auch weisen Motherboards i.d.R. keine Anschlüsse für den SMBus auf, die > müsste man sich irgendwo selber dranlöten (DIMM-Sockel). PCI Express führt die beiden Leitungen anscheinend und da könnte man auch noch schön +12V abgreifen. http://www.interfacebus.com/Design_PCI_Express_1x_PinOut.html Eine Einsteckkarte! Das wäre doch genial! Sieht auf jedenfall professioneller aus als Kabel vom USB/RS232/LPT Anschluss wieder in den PC reinzulegen. ;)
Ok. Mit anderen Worten: Es ginge tatsächlich, ein LCD zu speisen, was angeht, wenn der Rechner hochfährt und etwaige Info schon vorm Start des OS ausliest. Wenn es Sensoren auf dem ASUS board gibt, senden die doch sicher digitale signale, die ich irgendwie decodieren müsste, das Panel würde es ja auch tun. An dem Board rumlöten will ich ungern, die Methode mit der Neztkerkkarte, die sich beim BIOS anmeldet und Code reinschreibt und ausführt.... sowas wäre schon eher mein Fall, oder aber: Diese Sensoren für das Panel abchecken.Gut. Dann fangen wir ganz simpel an: Ich brauch son Teil, womit ich mein Mikrocontroller programmiere. Das Löttutorial dazu gibt es hier, ne? Ok.Dann baue ich das mir bald. Dann brauche ich ein LCD, was das anzeigt, was ich auf meinem Mikronontroller ( ich würde Assembler-programmierung bevorzugen) programmiere. So ein Tut, um so eine Platine für ein LCD und einen Steckplatz für den Mikro-C zu löten gibt es auch hier, oder? Jemand noch GENIALE links , wo ich nützliche Info zu beidem bekomme? Danke schonmal!
Hallo, der SM-Bus ist ein I2C-Abkömmling, meines Wissens nur auf 5V festgelegt und anderer Taktratenbereich zulässig. Gruß aus Berlin Michael
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.