hardwarenah...aber wie?
-
Das ist eigentlich überhaupt nicht das, was man mit hardwarenaher Programmierung meint.
Die zwei von dir angesprochenen Sachen sind auch sehr unterschiedlich: Hardwareinfos auslesen ist eine relativ abstrakte Aufgabe und fern von der Hardware. Falls du kein Betriebssystem hast, dass du nach der Hardware fragen kannst, wendet man sich an das Bios:
http://www.dmtf.org/standards/smbios
Aber das willst du nicht wirklich machen, wenn es sich vermeiden lässt.Spannungen ändern: Das geht nicht auf der Ebene, auf der Programme laufen. Nur indirekt. Programme die gezielt Spannungen ändern, nennt man Prozessor. Die werden von den Leuten bei Intel, AMD & Co programmiert und dann zu Hardware compiliert. Wobei die Zeiten, wo die dort noch auf dem Niveau von Spannungsänderungen programmiert haben auch schon seit Jahrzehnten vorbei sind. Wenn du dich für so etwas interessierst, gibt es Übungschips, wo man seinen eigenen Prozessor programmieren kann und hinterher auf den Chip brennen kann. Die Informatiker hier im Forum können dir sagen, wie die Dinger heißen - die verwendet man in Hardwarepraktika im Informatikstudium.
Hardwarenahe Programmierung bei C heißt nur, dass fast jede Anweisung in C hinterher in nur sehr wenige Maschinenbefehle umgesetzt wird, oftmals entspricht eine C Anweisung sogar nur einem Maschinenbefehl. Dadurch kann man sehr genau bestimmen, wie das compilierte Programm hinterher aussieht. Bei abstrakteren Sprachen hat man dagegen keine Ahnung, was hinter den Kulissen abläuft.
-
sowas nennt man fpga .
z.B. spartan 3E .
da gibts auch ein relativ günstiges board mit usb, ethernet , rs232 , ps2 ...
da kann man schon ein bisschen spielen.
-
wow...danke für die vielen Antworten, ich war gerademal 20min weg^^
Also ist es empfehlenswert, sich näher mit AVR und
Assembler zu befassen, richtig? Dauert es da nicht richtig lange bis man komplexe Dinge auf dem Steckbrett bauen kann, oder ist das nur eine falsche Vermutung?
C in Kombination mit Assembler hat mir mal ein Taxifahrer empfohlen, der früher in einem Großrechenzentrum gearbeitet hat...lange Geschichte
Hardwarenahe Programmierung bei C heißt nur, dass fast jede Anweisung in C hinterher in nur sehr wenige Maschinenbefehle umgesetzt wird, oftmals entspricht eine C Anweisung sogar nur einem Maschinenbefehl. Dadurch kann man sehr genau bestimmen, wie das compilierte Programm hinterher aussieht. Bei abstrakteren Sprachen hat man dagegen keine Ahnung, was hinter den Kulissen abläuft.
Du sprichst jetzt von bitsets und ähnlichem, richtig?
Habe die noch nie wirklich gebrauchtPS: Und wie arbeiten dann Tools wie AMD OverDrive oder CPU-Z ?
-
n0stradamus schrieb:
Also ist es empfehlenswert, sich näher mit ARM und
Assembler zu befassen, richtig?Was heißt empfehlenswert? Entweder interessiert es dich als Hobby oder nicht. Praktische Verwendung hat das eher nicht, wenn du nicht gerade beruflich in den sehr spezialisierten Bereichen arbeitest in denen das noch benutzt wird (Treiber- ,Viren-, Microcontroller-Programmierung).
Dauert es da nicht richtig lange bis man komplexe Dinge auf dem Steckbrett bauen kann, oder ist das nur eine falsche Vermutung?
C in Kombination mit Assembler hat mir mal ein Taxifahrer empfohlen, der früher in einem Großrechenzentrum gearbeitet hat...lange GeschichteEmpfohlen wofür? Und von einem Taxifahrer? Frag doch lieber deinen Frisör!
Aber jain: Man kann C und Assembler in der Tat gut mischen, wenn man will. Fragt sich aber nur, wozu? Die Antwort habe ich oben schon gegeben: Spezielles Hobby oder spezieller Beruf.
Hardwarenahe Programmierung bei C heißt nur, dass fast jede Anweisung in C hinterher in nur sehr wenige Maschinenbefehle umgesetzt wird, oftmals entspricht eine C Anweisung sogar nur einem Maschinenbefehl. Dadurch kann man sehr genau bestimmen, wie das compilierte Programm hinterher aussieht. Bei abstrakteren Sprachen hat man dagegen keine Ahnung, was hinter den Kulissen abläuft.
Du sprichst jetzt von bitsets und ähnlichem, richtig?
Habe die noch nie wirklich gebrauchtNein, Bitsets sind extrem abstrakte Gebilde. Das C++ Bitset ist eine komplexe Klasse. In C gibt es Bitsets noch nicht einmal eingebaut, die muss man selber programmieren.
Was Hardwarenahe ist bei Sprachen wie C und C++ ist das Alltägliche: Variablen, Funktionen, Operatoren, Schleifen, bedingte Anweisungen, Sprünge, Pointer, Speichermanagement. All das was in einem C Buch in den ersten 5-10 Kapiteln behandelt wird. Bis auf Ein-/Ausgabe - das sind Befehle bei denen sehr komplexe Dinge geschehen.
-
Empfohlen wofür? Und von einem Taxifahrer? Frag doch lieber deinen Frisör!
Für nichts, er hat von seinem Beruf erzählt. Programmieren ist ein Hobby von mir, als Schüler kann man halt noch nicht viel mehr machen. Würde ich das als Beruf wählen wollen, würde ich mich schon durch jemand kompetenteres beraten lassen(auch wenn die Wahl ohnehin schon getroffen ist)
Danke für die vielen Hinweise, das hat mir schon weitergeholfen.
Aber irgendwie ist das nichts für mich, ist (vllt noch) nicht mein Fall.
Kannst du, SeppJ, oder jmd anderes mir die entsprechenden Bibliotheken empfehlen?
Die hier erwähnten:Spannungen auslesen - da wird wohl eine Bibliothek notwendig, mit der du die entsprechende Hardware ansteuern kannst. Microcontroller über nen SerialPort, oder USB, usw.
Hardwareinfos auslesen geht eigentlich nur über das Betriebssystem. Genauso wie dann auf USB oder SerialPort zuzugreifen.
-
Für Windows kannst du dir mal WMI anschauen.
Unter Linux kann man sich mal das /dev und /proc Filesystem anschauen...
Ansonsten sind wohl die Bücher Windows Internals | ISBN: 0735625301 und Understanding the Linux Kernel | ISBN: 0596005652 sowie Linux Device Drivers zu empfehlen...
Grüße
Tobi
-
Genial, dankeschön
Genau sowas suche ich
-
SeppJ schrieb:
Was Hardwarenahe ist bei Sprachen wie C und C++ ist das Alltägliche: Variablen, Funktionen, Operatoren, Schleifen, bedingte Anweisungen, Sprünge, Pointer, Speichermanagement.
Das ist überhaupt nicht hardwarenah. Nicht umsonst wird in den Standards die "abtrakte Maschine" erwähnt, auf der diese Dinge arbeiten. C++ könnte auch interpretiert werden.
Hardwarenahe Programmierung ist vielmehr der direkte Zugriff auf irgendwelche Chips, z.B. um Zeichen von einer Tastatur zu lesen und ähnliches. Geht mal in Erhard Henkes' Unterforum, der kann euch was darüber erzählen. :p
-
Z schrieb:
SeppJ schrieb:
Was Hardwarenahe ist bei Sprachen wie C und C++ ist das Alltägliche: Variablen, Funktionen, Operatoren, Schleifen, bedingte Anweisungen, Sprünge, Pointer, Speichermanagement.
Das ist überhaupt nicht hardwarenah. Nicht umsonst wird in den Standards die "abtrakte Maschine" erwähnt, auf der diese Dinge arbeiten. C++ könnte auch interpretiert werden.
Hardwarenahe Programmierung ist vielmehr der direkte Zugriff auf irgendwelche Chips, z.B. um Zeichen von einer Tastatur zu lesen und ähnliches. Geht mal in Erhard Henkes' Unterforum, der kann euch was darüber erzählen. :p
Der Punkt ist aber, dass diese Abstraktion sehr nahe an der Hardwareebene ist. Alle diese Dinge haben direkte Äquivalente in den gängigen Maschinensprachen. Das heißt man muss gar nichts über die Hardware wissen, kann aber trotzdem sehr effiziente Programme schreiben. Und man muss dafür nur eine einzige Sprache lernen. Nicht umsonst nennt man C auch portables Assembler.
-
SeppJ schrieb:
Spannungen ändern: Das geht nicht auf der Ebene, auf der Programme laufen. Nur indirekt. Programme die gezielt Spannungen ändern, nennt man Prozessor. Die werden von den Leuten bei Intel, AMD & Co programmiert und dann zu Hardware compiliert. Wobei die Zeiten, wo die dort noch auf dem Niveau von Spannungsänderungen programmiert haben auch schon seit Jahrzehnten vorbei sind. Wenn du dich für so etwas interessierst, gibt es Übungschips, wo man seinen eigenen Prozessor programmieren kann und hinterher auf den Chip brennen kann. Die Informatiker hier im Forum können dir sagen, wie die Dinger heißen - die verwendet man in Hardwarepraktika im Informatikstudium.
Hardwarenahe Programmierung bei C heißt nur, dass fast jede Anweisung in C hinterher in nur sehr wenige Maschinenbefehle umgesetzt wird, oftmals entspricht eine C Anweisung sogar nur einem Maschinenbefehl. Dadurch kann man sehr genau bestimmen, wie das compilierte Programm hinterher aussieht. Bei abstrakteren Sprachen hat man dagegen keine Ahnung, was hinter den Kulissen abläuft.
Entschuldigung SeppJ, aber das was Du geschrieben hast ist totaler Quatsch.
Natürlich kann man Spannungen ändern (Ansteuerung eines DACs), oder Spannungen einlesen (Auslesen eines ADCs). Und natürlich kann man das auch ohne einen FPGA machen. Hängt halt von der zu Grunde liegenden Hardware ab.
Hardwarenahe Programmierung heißt eigentlich nur, dass das was man programmiert eine direkte Auswirkung auf die Hardware hat.Nur ein Beispiel:
Mit Hilfe eines Mikrocontrollers will ich eine analoge Spannung steuern, welche von einem I2C DAC ausgegeben wird.
Jetzt hängts halt vom Mikrocontroller ab ob der z.B. einen I2C Master Controller enthält (was wahrscheinlich ist). Dieser I2C Master Controller hat eine meist nicht geringe Anzahl an Registern welche den Controller parametrisieren.
Für den Hardwarenahen Programmieren heißt das nun sich im User Guide des Prozessors das Kapitel über den I2C Controller genau durchzulesen und zu verstehen wie man diesen über seine Register ansteuert. Dann muss man als hardwarenaher Programmieren sich das Datenblatt des I2C DACs genau durchlesen um auch hier zu verstehen wie denn der DAC angesteuert werden will.
Das Ergebnis des hardwarenahen Programmiers sollten nun ein paar komfortable Funktionen sein, die die Ansteuerung des DACs für den Anwendungsentwickler praktikabel machen. Dies kann im einfachsten Fall nur eine Funktion sein, oder aber auch ein Linux Kernel Treiber.Dieses Forum hier www.mikrocontroller.net ist für dieses Thema das bessere.
Ich hoffe das hilft ein wenig.
-
Alles klar...so wie ich es verstanden habe,
sollte ich mich zum Auslesen spezifischer Hardwareinformationen näher mit der jeweiligen Systemumgebung (Windows oder unix) befassen. Jaaa, dann wird das mit dem systemunabhängig schon schwierigerMein nächstes Problem betrifft das (denke ich mal^^) auch, insofern schreibe ich das mal in diesen Thread:
Ein Programm bekommt über das Netzwerk einen Befehl zum Ausführen einer Anwendung. Nun ist nicht sichergestellt dass das Netzlaufwerk auf dem das Setup liegt, auch auf dem Rechner auf dem das Programm läuft, denselben Laufwerksbuchstaben hat.
Die Anwendung ist in Verbindung mit dem Qt-Framework entstanden, natürlich könnte ich in einfach alle Verzeichnisse, die QDir mir ausgibt, durchgehen und prüfen ob die Datei dort liegt.
Es wäre doch aber auch möglich, die Festplatte über ihre ID (oder die MAC-Addresse) zu identifizieren. Und das könnte mir eine Funktion aus der WMI liefern, richtig?
-
Ja. Das etwas plattformunabhäniges zu finden ist nicht ganz einfach. Aber ich denke der Aufwand das selbst einigermassen unabhänig zu implementieren sollte schon gehen. (Musst dich halt wirklich mit den Systemen beschäftigen, welche du unterstützen willst..)
