STM32 Interrupt Handler in statischer Klasse

[Anonymous U. (gastt)]

Wie teile ich meiner lieben CubeIDE denn mit, dass der SPI Interrupt 
eine bestimmte Funktion einer Klasseninstanz aufrufen soll?

Mein erfolgloser Versuch bisher:

main.cpp

int main(void) {
    //...
    System system;
    //...
}

system.cpp

System::System(){
    //...
    HAL_SPI_Receive_IT(&hspi1, spi_interface_buffer, 1);
}
//...
extern "C" void System::Callback_SPI_Interface() {
  uint32_t dummy = 23;
  dummy++;
}

stm32l4xx_it.c

extern (*Callback_SPI_Interface)(void);
//...
void SPI1_IRQHandler(void)
{
    /* USER CODE BEGIN SPI1_IRQn 0 */
    Callback_SPI_Interface();
    /* USER CODE END SPI1_IRQn 0 */
    HAL_SPI_IRQHandler(&hspi1);
    /* USER CODE BEGIN SPI1_IRQn 1 */
    /* USER CODE END SPI1_IRQn 1 */
}

[oooops (Gast)]

Wenn du eine Klasse innerhalb von main() instanzierst dann
wird die wohl keine andere Funktion jemals zu sehen bekommen.

[Do (Gast)]

Ich weiß nicht ob man eine in C definierte Funktion in einer C++ Klasse 
implementieren kann. Bzw. stelle es mir nicht gerade schön und 
ungeeignet vor. Ansonsten nimm doch Pointer.

[Anonymous U. (gastt)]

Damit müsste die Funktion über ihren Pointer global erreichbar sein.

void (*Callback_ptr)(void);

void main(void){
  System system;
  Callback_ptr = &(system.Callback_SPI_Interface);
}

Funktioniert aber nicht, da folgender Fehler auftritt:
cannot convert 'void (System::*)()' to 'void (*)()' in assignment

[Vincent H. (vinci)]

Der Fehlermeldung nach zu urteilen ist deine Funktion nicht statisch.

[Johannes S. (Gast)]

Die Memberfunktion kann in der Klassendefinition als 'static' deklariert 
werden. Dann sind in der Funktion aber keine Zugriffe auf 
Membervariablen möglich weil der this pointer fehlt. Den kann die ISR 
auch nicht mitgeben, dafür ist dann eine Hilfsfunktion nötig.

[Anonymous U. (gastt)]

Johannes S. schrieb:
> Die Memberfunktion kann in der Klassendefinition als 'static' deklariert
> werden. Dann sind in der Funktion aber keine Zugriffe auf
> Membervariablen möglich weil der this pointer fehlt. Den kann die ISR
> auch nicht mitgeben, dafür ist dann eine Hilfsfunktion nötig.

Ok, dass funktioniert jetzt. Also es wird fehlerfrei kompiliert. Hier 
der aktuelle Code:

main.cpp

// global visible pointer to actual static member function of class
void (*Callback_SPI_Interface_Ptr)(void) = &(System::Callback_SPI_Interface);
//...
int main(void) {
    //...
    // initialisation of System object
    System system;
    //...
}

system.h

class System {
private:
  //...
public:
  System();
  // set function as a static member
  static void Callback_SPI_Interface();
};

system.cpp

System::System(){
    //...
    // enable receiving interrupt?
    HAL_SPI_Receive_IT(&hspi1, spi_interface_buffer, 1);
}
//...
// make funktion callable from C source code
extern "C" void System::Callback_SPI_Interface() {
  uint32_t dummy = 99;
}

stm32l4xx_it.c

// pointer to static member function is declared outside of this file
extern (*Callback_SPI_Interface_Ptr)(void);
//...
void SPI1_IRQHandler(void)
{
    /* USER CODE BEGIN SPI1_IRQn 0 */
    Callback_SPI_Interface_Ptr();
    /* USER CODE END SPI1_IRQn 0 */
    HAL_SPI_IRQHandler(&hspi1);
    /* USER CODE BEGIN SPI1_IRQn 1 */
    /* USER CODE END SPI1_IRQn 1 */
}

Eine Frage noch. Kann man das so machen. Oder gibt es da elegantere 
Möglichkeiten. Ich bin immer wieder am überlegen, ob nicht C doch 
sinnvoller wäre... Sehr unschlüssig...

[Felix U. (ubfx)]

Anonymous U. schrieb:
> Ich bin immer wieder am überlegen, ob nicht C doch
> sinnvoller wäre... Sehr unschlüssig...

Ich würde mal sagen wenn es schon an einem ISR scheitert, ist C 
vielleicht doch die bessere Lösung. Schlussendlich kannst du den Komfort 
von C++ eh nicht richtig genießen und musst dir wieder um jede 
Speicherallokation Gedanken machen. Das kannst du auch in C haben. Es 
gibt sicher Projekte, wo der zusätzliche Aufwand Sinn ergibt, aber oft 
ist es auch sinnvoll, einfach beim Bewährten zu bleiben.

[oooops (Gast)]

Anonymous U. schrieb:
> Eine Frage noch. Kann man das so machen. Oder gibt es da elegantere
> Möglichkeiten.

Warum krampfhaft in der main() eine Klasseninstanz anlegen und
einen globalen Pointer darauf? Gibt es dafür triftige Gründe?

[Johannes S. (Gast)]

Wenn man system global anlegt sind Zugriffe aus C++ so möglich:
https://isocpp.org/wiki/faq/mixing-c-and-cpp#call-cpp

[Anonymous U. (gastt)]

oooops schrieb:
> Anonymous U. schrieb:
>> Eine Frage noch. Kann man das so machen. Oder gibt es da elegantere
>> Möglichkeiten.
>
> Warum krampfhaft in der main() eine Klasseninstanz anlegen und
> einen globalen Pointer darauf? Gibt es dafür triftige Gründe?

Meine Klassen benötigen eine bereits initialisierte HAL. Ich könnte zwar 
eine init()-Funktion in die Klasse integrieren, aber wenn dieser Code im 
Konstruktor steht, finde ich es schöner.

Felix U. schrieb:
> Es
> gibt sicher Projekte, wo der zusätzliche Aufwand Sinn ergibt, aber oft
> ist es auch sinnvoll, einfach beim Bewährten zu bleiben.

Ich war lange am überlegen, ob ich C oder C++ verwenden sollte. Ich bin 
da eher erstmal zögerlich Neuem gegenüber. Aber dann dachte ich zurück 
an meine Anfänge mit ASM und wie ich mich erst gegen C gesträubt habe 
:-) So here we go..

[Johannes S. (Gast)]

ich benutze mittlerweile auch viel C++ und sehe darin keinen Nachteil. 
Dazu Mbed-os, das ebenfalls sehr konsequent C++ nutzt und auch das API 
bietet alles in Klassen an.
Die Interrupts kann man da auch bequem im Usercode abarbeiten:
Im RAM ist ein Bereich für die Kopie der Interrupt Vektoren reserviert. 
Die ISR kann fest in die Tabelle wenn sie zur Kompilierzeit bekannt ist, 
kann aber zur Laufzeit einfach mit

void NVIC_SetVector(IRQn_Type IRQn, uint32_t vector);

umgebogen werden.

Für den Fall das man eine Methode als ISR nutzen möchte gibt es einen 
Helfer names CThunk. Das ist eine Trampolin Funktion die sich einen 
Callback merkt und als ISR arbeitet. Kostet zusätzliche indirekte calls, 
aber die nehme ich für den Luxus in Kauf. Dafür spare ich mir die lange 
universelle Behandlung in der HAL ISR.
Der Vorteil ist, das ich meine Komponente schön kapseln kann und die bei 
Bedarf den ISR Kram implizit behandelt. Es muss keine ISR im Core vorab 
reserviert werden (Arduino) oder eine unübersichtliche 'ich kann alle 
Ints' (HAL) implementiert werden.

Benutzt habe ich das z.B. in einer Timerklasse. Der gebe ich den 
gewünschten Callback mit und intern wird die Interruptbehandlung 
gemacht.

Auszugsweise sieht das so aus, Timerkram weggelassen:

class HWTimer {
public:
    HWTimer(int id, chrono::microseconds  period, Callback<void()> cb, bool onePulseMode);

    ~HWTimer();
    void start(chrono::microseconds period = 0us);
    void stop();

private:
    void callTimerFn();

private:
    int _id;
    bool _onePulseMode;         
    Callback<void()> _cb;       // user callback on timeout
    CThunk<HWTimer> _irq;       // helper for setting static irq member function
    void *_pConfig;             // generic pointer, used for implementation dependent structures
};


HWTimer::HWTimer(int id, chrono::microseconds us_period, Callback<void()> cb, bool onePulseMode) :
    _id(id),
    _onePulseMode(onePulseMode),
    _cb(cb),
    _irq(this)
{
    // set IRQ ISR, use CThunk to handle member function call from static
     _irq.callback(&HWTimer::callTimerFn);

    // activate IRQ in NVIC
    NVIC_SetVector(TimIRQTab[id], (uint32_t)_irq);
    NVIC_EnableIRQ(TimIRQTab[id]);
}

void HWTimer::callTimerFn()
{
    if (__HAL_TIM_GET_FLAG((TIM_HandleTypeDef*)_pConfig, TIM_FLAG_UPDATE) == SET) {
        __HAL_TIM_CLEAR_FLAG((TIM_HandleTypeDef*)_pConfig, TIM_FLAG_UPDATE);

        _cb();
    }
}

Den CThunk könnte man auch aus dem OS rausoperieren, der setzt nichts OS 
spezifisches vorraus. Aber da habe ich keine Ambitionen, das OS hat ja 
noch mehr zu bieten das ich benutzen möchte.