Hardwareabstraktion und ISR

[Geri (Gast)]

Hallo

Ich möchte gerne soweit wie möglich und sinnvoll den 
controllerspezifischen Code (u.a. ISRs) vom controllerunabhängigen Code 
trennen.

Meine Überlegung: Hardwarefile (hal) anlegen und dort eine Funktion 
InitTimerISR codieren. Diese übernimmt während der Programmlaufzeit 
einen Timer-Handler. Der Timer-Handler wird mit hoher Frequenz 
aufgerufen.

hal.h und hal.c 
void InitTimerISR(uint32_t ISR_Handler)
{
...
...
  VICVectAddr1 = (uint32_t)ISR_Handler;
...
}


common.h, common.c

static ISR_Handler1(void) INTERRUPT;
{
  ..
}

static ISR_Handler1(void) INTERRUPT;
{
  ...
}


static void SetTimerISR(uint8_t Mode)
{
   if (Mode == 0) InitTimerISR(Addr(ISR_Handler1)); else
   if (Mode == 1) InitTimerISR(Addr(ISR_Handler2)); else
       ...
}

Hat es einen negativen Einfluss auf die Performance wenn das Programm so 
aufbaut ist bzw. wie könnte man es besser machen?
Meiner Ansicht dürfte es bei einer ARM7-Architektur nichts ausmachen....

Danke für eure Meinung

Geri

[(prx) A. K. (prx)]

Wird nur begrenzt funktionieren, das Interrupt meisten quittiert werden 
müssen und fast alle Device-Interrupts ausser vielleicht solchen Timern 
auf I/O zugreifen.

Was besser funktioniert: Für Kram wie solche Timer, RTCs, UARTs, I2C, 
1-Wire, ... Treiber schreiben. Die nach oben hin ein recht einheitliches 
Interface haben und so die Deviceabhängigkeit abstrahieren. Bei einer 
neuen Controller-Familie muss dann nur ein neuer Satz von Treiber gebaut 
werden.

Bei einem zyklischen Timer könnte das beispielsweise ein Treiber sein, 
in den sich Routinen der Anwendung als Callbacks einklinken können. Das 
ist geringfügig weniger effizient, aber trennt Hardware von Anwendung.

[Geri (Gast)]

Vielen Dank für deine Meinung!

>Wird nur begrenzt funktionieren, das Interrupt meisten quittiert werden
>müssen und fast alle Device-Interrupts ausser vielleicht solchen Timern
>auf I/O zugreifen.

In meinem Fall werden in der Timer-ISR auch Ausgänge gesetzt und 
gelesen. Es sind lauter einfache IO-Operationen. Ich hätte mir es aber 
so gedacht, dass ich IO-Routinen durch Defines ersetze. Wenn ich das 
Programm auf einem PC compilieren möchte, dann z.B. durch Funktionen

HAL.c

#define CLEAR_VEC_ADDR()          VICVectAddr = 0;
#define CLEAR_Timer0_ISR_FLAG()   T0IR  = 0x01;
#define DONE_TIMER0_ISR()         {CLEAR_Timer0_ISR_FLAG(); CLEAR_VEC_ADDR

// Beispiel setzten digitaler Ausgang
#define MODULE_LED_PIN    22
#define MODULE_LED_MASK    (1 << MODULE_LED_PIN)
#define MOUDLE_LED_PORT_ON   FIO0SET
#define MOUDLE_LED_PORT_OFF  FIO0CLR

#define MODULE_LED_ON        MOUDLE_LED_PORT_ON = MODULE_LED_MASK
#define MODULE_LED_OFF       MOUDLE_LED_PORT_OFF = MODULE_LED_MASK

Im Controllerspezifischen Code würde man dann am Ender der Timer0ISR das 
Define DONE_TIMER0_ISR(); aufrufen

Ist dieser Ansatz deiner Meinung nach eine Sackgasse?



>Bei einem zyklischen Timer könnte das beispielsweise ein Treiber sein,
>in den sich Routinen der Anwendung als Callbacks einklinken können. Das
>ist geringfügig weniger effizient, aber trennt Hardware von Anwendung.

Würde das deiner Ansicht dann ein sinnvolles Gerüst wenn es sich nur um 
einfache IO-Operationen handelt?

// file hal.c - controllerspezifischer Code
void (*Timer0ISR_CallBack )(void);

void Timer0ISR() INTERRUPT
{
   Timer0ISR_CallBack(); 
   VicVectAddr = 0;
}

// Aktiviere Timer 0 Interrupt
#define EnableT0ISR()     T0MCR = 3

// Deaktiviere Timer 0 Interrupt
#define DisableT0ISR()     T0MCR = 0   

();} 

// file common.c - controllerunabhängiger Code
#include "hal.h"

void InitmyTimer0ISR(void)
{
   Timer0ISR_CallBack = &myTimer0ISR;
   EnableTimer0ISR();
}

void myTimer0ISR(void)
{
   // führe hier controllerunabhängigen Code aus
   ..
   ..
}

Ein Vorteil der Treiber-Idee wäre meiner Meinung nach dann, wenn die 
IO-Routinen komplexer werden und viel controllerspezifischen Coder 
erfordern.


Wie gross ist denn die Einbusse eigentlich?
Könnte mir vorstellen:
1.) Einbusse für Aufruf einer Funktion in einer ISR
2.) Einbusse für das Sichern von Registern?
3.) ??

[(prx) A. K. (prx)]

Geri schrieb:
> Ist dieser Ansatz deiner Meinung nach eine Sackgasse?

Das ist nur begrenzt auf wenige Fälle sinnvoll. Also bei solchen 
einfachen Pin-Aktionen, ebenso kann ein 1-Wire Treiber so implementiert 
werden, weil nur 2 GPIO-Pins bedient werden.

Letztlich ist das eine Abwägung.

> Würde das deiner Ansicht dann ein sinnvolles Gerüst wenn es sich nur um
> einfache IO-Operationen handelt?

Es gibt keine universelle eierlegende Wollmilchsau. In sehr einfachen 
Fällen ist der Treiber-Ansatz komplexer als nötig. Andererseits hat man 
bei Controllern auch oft mehrere regelmässige Timer-basierte 
Aktivitäten, die man in einem Systick (oder wie immer der heisst) 
zusammenfassen kann. Dann kann es sinnvoll sein, einen generischen 
Systick zu definieren, in den man mehrere Handler einklinken kann, 
beispielsweise orientiert an Peter Danneggers Scheduler.

> Ein Vorteil der Treiber-Idee wäre meiner Meinung nach dann, wenn die
> IO-Routinen komplexer werden und viel controllerspezifischen Coder
> erfordern.

Exakt.

> Wie gross ist denn die Einbusse eigentlich?

Wenn man zeitlich knapp dran ist, beispiesweise weil ein Pin alle 100 
Takte getoggelt werden muss, dann ist das sehr relevant. Nicht hingehen 
wenn es um einen 1KHz Systemtimer geht.

[Geri (Gast)]

Vielen Dank für deine schnelle Rückmeldung. Das hilft mir mal schon sehr 
weiter!

Der Treiber-Ansatz ist zwar mehr Schreibarbeit (beim ersten mal), dafür 
sieht das Interface wahrscheinlich immer sehr ähnlich aus. Das 
erleichtert das Lesen des Programmes auch wieder. Ebenso dünkt mich die 
Trennung von Anwendung und hal eindeutiger weil Hardwareaufrufe 
vordergründig im HAL erfolgen.

Besten Dank nochmals!!!