Ebenen im Programm

[Mark (Gast)]

Hallo,
ich habe mal eine frage
ich habe ein Programm geschrieben.
In der main-funktion rufe ich funktionen auf, um sachen zu 
initialisieren (z.b. CAN_INIT() )
in CAN_INIT() rufe ich wiederum funktionen auf (z.B. CAN_Baudrate(250))
in CAN_BAUDRATE() beschreibe ich dann die Register.
gibt es noch eine tiefere Ebene? also das was die register beschreibein? 
wie würde das heissen?

Mark

[Karl H. (kbuchegg)]

Mark schrieb:
> Hallo,
> ich habe mal eine frage
> ich habe ein Programm geschrieben.
> In der main-funktion rufe ich funktionen auf, um sachen zu
> initialisieren (z.b. CAN_INIT() )
> in CAN_INIT() rufe ich wiederum funktionen auf (z.B. CAN_Baudrate(250))
> in CAN_BAUDRATE() beschreibe ich dann die Register.
> gibt es noch eine tiefere Ebene? also das was die register beschreibein?

Der µC, der die Funktionen dann letzten Endes ausführt, wird seine 
OpCodes sehr wahrscheinlich auch nicht direkt ausführen, sondern im µC 
läuft ein Mikroprogramm welches dann die Schaltvorgänge macht.

> wie würde das heissen?

Sowas hat keinen wirklichen Namen.
Aus wievielen Softwareschichten ein Programm definiert ist eine 
Designsache und ja nachdem werden in komplexeren Programmen schon auch 
mal viele Schichten übereinander gestapelt. Maximal kann man in diesem 
Stapel von Schichten irgendwo Grenzlinien ziehen, die Zuständigkeiten 
voneinander trennen. Eine 'Treiberebene' ist meist für alle Low-Level 
Manipulationen zuständig, was aber nicht bedeutet, dass die Treiberebene 
nur aus 1 Schicht bestehen kann. Je nach Komplexität können das durchaus 
auch schon mal mehr sein.

[lrep (Gast)]

Mark schrieb:
> gibt es noch eine tiefere Ebene?

Wahrscheinlich die Interrupt-Handler, die während des Betriebes ja 
jederzeit, auch in organisatorische sehr tief liegenden 
Programmschichten aufgerufen werden können.

[Oldie (Gast)]

Die Frage wirkt auf Leute mit gepflegtem Halbwissen etwas
philosophisch. Philosophen suchen aber nach Erkenntnissen,
die der Menschheit bisher nicht klar sind.

Bei Prozessoren und dem Programmaufbau, der sie zum Laufen
bringt, ist den Bibliotheks-Erstellern aber schon klar, was
sie da mit Funktionsaufrufen und eingelagerten Unterprogramm-
aufrufen fabriziert haben.

Sauber programmierten Bibliotheksfunktionen, wie CAN_BAUDRATE()
ist es daher wurscht, ob sie sich gerade 3, oder 11 Ebenen
unterhalb der Ebene der main() Funktion befinden, wenn sie
vielleicht - oder mal nicht - eine weitere Unterfunktion
aufrufen, um direkt auf die Hardware-Register des µC, oder
Prozessors zugreifen.

Hauptsache der Stack ist groß genug, um wieder zum Befehl
nach ihrem Aufruf zurückzufinden...

Das gilt auch für rekursive Algorithmen. Trotz Abstieg in
immer tiefere Ebenen kommen die normalerweise der
Hardware-Ebene keinen Deut näher.

Interrupt-Handler sind OFT dicht an der Hardware des µC
angesiedelt, um schnell auf Zeit- oder Signalereignisse zu
reagieren. - Das MUSS aber nicht sein.
Außerdem "wühlen" sie sich nicht auf die hardware-nächste
Ebene hinunter, sonder unterbrechen den normalen Programmablauf,
um ungestört (eventuell hardware-nahe) Operationen auszuführen.

[Peter D. (peda)]

Man kann (und sollte) Programme soweit modularisieren, wie es sinnvoll 
ist.
Eine Grenze gibt es nicht.
Z.B. Funktionen, die >=2 mal benötigt werden.
Oder Funktionen, die in sich abgeschlossen sind.