Sprungtiefe verringern

[Nobbie (Gast)]

Hi,

Ich weiß nicht, ob ich im richtigen Unterforum gepostet habe. Falls 
nicht, bitte entsprechend verschieben.

Jetzt zu meinem Anliegen. Ich habe aktuell ein komplexeres 
Firmware-Projekt, in dem ich einen Hardware-Abstraction-Layer 
implementiert habe. Dieser dient zum softwareseitigen Verknüpfen der 
einzelnen Module.
Der Code sieht, wie nachfolgend dargestellt, aus:

/*----------------------------------------------*/
/* modul_1.c
uint16_t func1(uint16_t param1, uint16_t param2)
{
   ...
}

uint16_t func2(uint16_t param1, uint16_t param2)
{
   ...
}
/*----------------------------------------------*/

/*----------------------------------------------*/
/* Abslayer.c
uint16_t layer_func1(uint16_t param1, uint16_t param2)
{
   return func1(param1, param2);
}

uint16_t layer_func2(uint16_t param1, uint16_t param2)
{
   return func2(param1, param2);
}
/*----------------------------------------------*/

Wie man erkennt, wird im Abstraktionslayer nur die eigentliche Funktion 
aus dem Hardwaremodul aufgerufen. Dies hat aber zur Folge, dass sich 
dadurch die Sprungtiefe erhöht und somit die Stackbelastung steigt.

Meine Frage ist, kann man dies "eleganter" lösen und somit die 
Sprungtiefe reduzieren? Die Hardwareabstraktionschicht möchte ich aber 
belassen.

Danke Nobbie

[Jan S. (jan_s)]

Indem Du dir den überflüssigen Funktionsaufruf einfach sparst und das 
Ganze zur Compile-Zeit mit Macros löst.

[Mike R. (thesealion)]

Spontan würden mir da #define oder inline funktionen einfallen.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Nobbie schrieb:
> Die Hardwareabstraktionschicht möchte ich aber belassen.
Das ist das, was dein Nachfolger 10 Jahre später verfluchen und 
herausbasteln wird. Garantiert...
Und: du wirst dein Programm trotzdem nicht so abstrakt hinbekommen, dass 
du alle Hardwarebezüge gekapselt bekommst...

BTW:
> Ich habe aktuell ein komplexeres Firmware-Projekt, in dem ich einen
> Hardware-Abstraction-Layer implementiert habe.
Es kann nicht komplex sein, wenn du einen so kleinen Prozessor 
verwenden mußt, dass der Stack keinen Platz hat  ;-)

[Purzel H. (hacky)]

>... Hardwareabstraktionschicht ...

Ist ein Furz fuer Betriebssytemschreiber, die beliebig Rechenleistung 
und Resourcen haben. Bei Controllern gilt eher :
So komplex wie noetig, so einfach wie moeglich.

[Nobbie (Gast)]

Hi,

genau das sind die Sprüche, die ich von Kollegen auch höre und dann 
schaue ich manchmal in deren Code und schlage die Hände über den Kopf 
zusammen (Übrigens sind das auch die, die dann zur Fehlersuche Hilfe 
benötigen und von Dingen wie atomare Zugriffe, usw... höchstens mal was 
gehört haben).
Ich möchte und werde hier jetzt aber keine Grundsatzdiskussion über die 
Sinnhaftigkeit meiner Struktur durchführen.

Nur soviel, durch die Abstraktionsschicht kann und konnte ich sehr 
einfach Softwaremodule austauschen (z.T. auch durch Softwaretestmodule).

@Lothar:
naja, komplex ist relativ, da gebe ich dir Recht ;-). Aber für meine 
Verhältnisse ist dieses Projekt schon komplexer (manch anderer würde 
sicherlich drüber lachen)

@Jan und Mike:
inline wird meines Wissens nach nicht von allen C-Compiler unterstützt 
(kommt eigentlich von C++, C99-Standard)
mit dem #define funktioniert das super.

Danke an alle
Nobbie

[Oliver (Gast)]

A. K. schrieb im Beitrag #2121831:
> Die Chancen stehe nicht schlecht, dass der Compiler aus dem
> Unterprogrammaufruf einen schlichten Sprungbefehl macht.

Wenn die Funktionen, wie oben gezeigt, über drei Sourcedateien verteilt 
sind, hat der Compiler keine Chance.


Plan B wären Funktionspointer:

uint16_t (*layer_func1)(uint16_t, uint16_t)= func1;

Das geht aber nur, wenn die Parameter bei Layer- und Modulfunktion 
identisch sind.

Oliver