Cube Interrupts and C++

[VLe R.1]

I am trying to port C libraries I made using LL Libraries generated from STM32CubeMX to C++ under STM32CubeIDE and I am looking for advice on how to accomplish the following:

I Created and object wich uses USART_LL Libraries and wanted to have something simillar to:

#include "main.h"
#include "stm32l1xx_it.h"
#include "object_lib.h"
 
extern object_type object;
 
void USART1_IRQHandler(void)
{
	object.usart_ISR();
}

But since the it file is a "C" one I cannot use this OOP style.

So I've beeng thinking about creating a wrapper-like structure so I can call one function with no parameters where somehow the ISR will be called, but I got the feel the implementation won't be as portable as I would like considering we always stepped aside from dynamic memory allocation.

//On interrupt C File
 
#include "main.h"
#include "stm32l1xx_it.h"
#include "object_lib.h"
 
void USART1_IRQHandler(void)
{
    object_isr_wrapper();
}
 
//On object_lib.h
 
#include "main.h"
#include "uart_LL.h"
 
#pragma once
 
#ifdef __cplusplus
extern "C"{
#endif
     void object_isr_wrapper();
#ifdef __cplusplus
}
 
//On object_lib.cpp
 
class Object{
   ...
};
 
Object object;
 
Object object_list = {&object};
 
void object_isr_wrapper(){
    for(every_object...){
            object_list[index]->isr();
     }
}

Ideally I would like to use OOP wherever I can as my objective is to port everything to C++ but I am still unaware of all the musts and dont's when using the STMCubeMX C generated libraries in this context.

Maybe I sould just go with dyncamic memory allocation so I don't have to manually fill the array on static memory... Maybe should I stop and continue with C before I get too far?... Any advice will be much appreciated.

Thanks, VL.

[Tesla DeLorean]

Couldn't you just have the handler code in IT.CPP or similar?

1. extern "C" void USART1_IRQHandler(void)
2. {
3. object_isr_wrapper();
4. }

That way the name mangling and linkage/binding would work directly out of the vector table.

[Pavel A.]

> Maybe should I stop and continue with C before I get too far?.

That's a good idea too.

[VLe R.1]

I decided for this,

I'd rather work with C as it is fully supported on STM32CubeIDE, everything is generated in C and the logic behind how things works just keeps making sense in C 🙂