|
Anzeige
|
Ebenen im Programm
Gast
#4209733
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 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.
Gast
#4210056
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.
Gast
#4210190
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. 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. Antwort schreiben |
Anzeige
|
