Showing results for 
Search instead for 
Did you mean: 

Cube Interrupts and C++

VLe R.1
Associate II

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)

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)
//On object_lib.h
#include "main.h"
#include "uart_LL.h"
#pragma once
#ifdef __cplusplus
extern "C"{
     void object_isr_wrapper();
#ifdef __cplusplus
//On object_lib.cpp
class Object{
Object object;
Object object_list = {&object};
void object_isr_wrapper(){

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.


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.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Pavel A.
Evangelist III

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

That's a good idea too.

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 🙂