Hallo.
Ich bin seit 2 Jahren mit meinem Studium (Mechatronik, FH) fertig und
arbeite seit dem als Softwareentwickler bei einem mittelständischen
Unternehmen. Ich entwickle komplexe Prüfsoftware und bearbeite teilweise
hardwarenahe Aufgabenstellungen (z.B. Hardwaretreiber, etc..), alles
hauptsächlich unter C.
Die Programmiersprache C habe ich denk ich soweit im Griff um die an
mich gestellten Aufgabenstellungen gut und möglichst schnell lösen zu
können. Was mir aber noch fehlt ist irgendwo eine Art Hintergrund, was
die vom mir geschriebenen C-Programme „intern“ bewirken, wie sie also
mit dem Betriebssystem zusammen spielen, mit der PC-Hardware (z.B.
Speicher, CPU) zusammenarbeiten usw…
Hat hier jemand von euch einen Tipp für ein gutes Buch oder sonst etwas
wie ich mir hier weiterbilden bzw. einarbeiten könnte?
Danke euch schon mal im vorraus.
hmm, also irgendwie verstehe ich die Frage jetzt nicht so richtig: deine
Aussagen sind widersprüchlich!
Zum einen schreibst du, dass du seit 2 Jahren komplexe Software
implementierst und zum anderen Fragst du, wie die Programme
funktionieren (die du schreibst).
Ich frage mich, wie maan das machst (programmieren) ohne eine
Vorstellung davon zu haben, was man da überhaupt macht? Was lernt man
eigentlich im Studium heutzutage?
Paule
Dem Verständnis zuträglich ist normalerweise die Beschäftigung mit
Digitaltechnik (wie arbeitet der Rechner?), ein wenig hardwarenahe
Programmierung, ein wenig Assemblerprogrammierung. Nur durch Lesen
kriegt man das "Gespür" meiner Erfahrung nach weniger, aber das kann bei
anderen anders aussehen.
Assemblerprogrammierung auf Z80, mal auf einen nackten DOS-Rechner (in
C) die Grafikkarte direkt (ohne Betriebssystem und Treiber dazwischen)
ansprechen, Mikrocontroller programmieren, das hat mir damals am meisten
gebracht.
ich kann deiner Frage nicht ganz folgen, ich glaube aber das du wissen
willst dein Programm mit dem Betriebsystem zusammenarbeitet.
Dafür sollte man wissen auf welchem System deine Programme laufen,
Windows, Linux oder meinst du sogar AVR ? Beim letzteren sollte die
Frage nicht bestehen.
auch wenn' jetzt polemisch klingt: das ist eben der unterschied zwischen
uni und fh.
besorg' die ein einführungsbuch über microcontroller, das steht's
drinnen.
Ich denke mal, dass folgende Vorlesungen in einem Studium im
Zusammenhang das Gewünschte ergeben:
-Digitaltechnik
-Rechnerarchitektur
-Betriebssysteme
-Software Engineering
Wenn man die nicht oder nicht alle gehabt hat, dann kann man sich ja die
entsprecchenden Bücher von Autoren wie Tanenbaum etc. vornehmen.
zwieblum schrieb:
> auch wenn' jetzt polemisch klingt: das ist eben der unterschied zwischen> uni und fh.
Er hat Mechatronik studiert, da war der Anteil an Informatik womöglich
nicht allzu groß. Erst denken, dann posten...
zwieblum schrieb:
> auch wenn' jetzt polemisch klingt: das ist eben der unterschied zwischen> uni und fh.
Das ist nicht Polemik, es ist Bloedsinn. Gerade in der FH sollte sowas
vermittelt werden - und an einer guten wird es das auch. Aber vieleicht
ist Mechatronik das falsche Studium dafuer?
Als erstes würde ich dir ans Herz legen, irgendeinen Assembler zu
lernen. Muss nicht Pentium sein, AVR/PIC reichen da völlig.
Ansonsten kann man nur ankratzen:
Matze schrieb:
> Was mir aber noch fehlt ist irgendwo eine Art Hintergrund, was> die vom mir geschriebenen C-Programme „intern“ bewirken,
Ich weiß nicht, wie tief du eintauchen willst: Mach dir klar, dass C
auch 'nur' ein abstrakter Assembler ist. Deine Anweisungen in C werden
unmittelbar in Assemblercode übersetzt.
> wie sie also> mit dem Betriebssystem zusammen spielen, mit der PC-Hardware (z.B.> Speicher, CPU) zusammenarbeiten usw…
Interaktion mit der restlichen Hardware erfolgt über entsprechende
Assembler-Instruktionen und/oder Register mit besonderen Funktionen
('SFR').
Interaktion mit dem Betriebssystem kann auf vielerlei Weise geschehen:
- direkt mit 'syscalls'
- indirekt über 'iocontrol'
- ...
@Zwiebelchen
Bei uns an der FH (EIT) gehörten die internen Funktionen im Rechner
natürlich mit dazu. Microcontrollertechnik, Assembler,
Rechnerarchitekturen.
Wie Peter Stegemann schon richtig bemerkte - es kommt wohl nicht darauf
an Uni vs. FH (hatten wir schon zu genüge), es kommt vielmehr auf den
Studiengang an.
zwieblum schrieb:
>bitte lesen, auf der uni wird das thema behandelt.
Und an der FH auch. Aber nicht in jedem Studiengang (an der Uni
sicherlich auch nicht).
Dafür gibt es an der Uni so interssante und sinnvolle Pflichtfächer wie
Geschlechterforschung :-) (siehe PDF)
> (siehe PDF)
du meinst im Kapitel Wahlfächer?
;-)
Das Problem ist eher, das an allen Einrichtungen immer wieder mal eher
abstrakte Erklärungen gegeben werden oder man zu dem Zeitpunkt nicht das
nötige Hintergrundwissen hat, um manche Erklärungen zu verstehen.
Horst schrieb:
>> (siehe PDF)>> du meinst im Kapitel Wahlfächer?> ;-)
Nö, steht auf Seite 6 in Tabelle 2: Pflichtfächer. Ist vielleicht eine
Arbeitsbeschaffungsmaßnahme für eine habilitierende
Geisteswissenschaftlerin an der Uni dort ;-)
Mann, das Forum-Layout ist wirklich bescheiden bei so langen Wörtern :-(
Um mal zum eigentlichen Thema zurückzukommen:
Wenn du die Abläufe in der Hardware bzw. in den unteren Schichten des
Betriebssystems verstehen möchtest, wäre die Entwicklung eines
Messgerätes empfehlenswert.
Das muss für den Anfang nichts großes sein, z.B. ein Digital I/O USB
Messgerät. Einsehr interdiszoplinäres Projekt, daß alle interessanten
Themen abdeckt:
- Schaltplan/Layout/Digitaltechnik
- Microcontrollerprogrammierung
- Treiberprogrammierung
Die grundsätzliche Funktionsweise von USB, PCI oder Ethernet Messgeräten
ist ziemlich gleich, nur ist für USB das Interesse in Foren größer und
du bekommst folglich mehr Unterstützung/Literatur.
hi
Eigentlich hat sich an der Verarbeitung der Software nicht viel
geändert...
Nach wie vor adressiert die CPU Speicher, holt aus den Zellen die
Befehle oder Daten und legt die Daten nach Manipulation wieder ab. Die
Aussage, C wird in Assembler übersetzt ist nicht richtig, denn auch
Assembler versteht keine CPU. Allerdings ist Assembler äußerst
hardwarenah. Auch ist der Befehlsumfang nicht so immens wie in einer
Hochsprache.
Alle Compiler erzeugen letztlich für das Programm eine Liste mit binären
Signalen. Diese Codes (und nur diese) kann die CPU erkennen und
bearbeiten. Im einfachsten Fall gibt es eine Liste , die immer wieder
abgearbeitet wird. Wir kennen es unter Programmschleife. Interrupts sind
spezielle Programmteile, die auf Ereignise reagieren, so z. B. auf das
Ereignis der Tastatursignale oder der Maus. Ereignis kommt,
Hauptschleife verlassen und in ein Unterprogramm springen, Ereignis
bearbeiten und wieder zum Hauptprogramm. Diese Technologie ist soweit
ausgereift, das man in den heutigen Sprachen z.B. Delphi, VB oder C++
nur noch Elemente auf ein Formular zieht und ein paar Zeilen Code dazu.
(gut, auch da können's ein paar tausend werden...)
Im Kern läuft nun ein Prozeß, der sich im Kreise dreht, den Bildschirm
aktualisiert und auf Signale von "außen" hört. Kommt etwas, dan schaut
er in einer Tabelle nach, was zu tun ist. Wenn du also Programme
schreibst, in welcher Sprache auch immer, ist es nichts anderes als eine
Liste von Befehlen, die du abgearbeitet haben möchtest, immer und immer
wieder.
Gruß oldmax
