Custom context in callback handlers

This has been requested before:

Recently (Oct 2024): https://community.st.com/t5/stm32-mcus-embedded-software/feature-request-pass-arbitrary-data-pointer-in-hal-callbacks/m-p/727806

Older (May 2021): https://community.st.com/t5/stm32-mcus-products/is-there-a-way-to-provide-context-pointer-to-hal-callback/m-p/182064

PS:

Apparently being "tracked internally" by @mƎALLEm:

https://community.st.com/t5/stm32-mcus-embedded-software/feature-request-pass-arbitrary-data-pointer-in-hal-callbacks/m-p/728270/highlight/true#M55730

> I have added it myself to the SPI driver, but if I regenerate its all gone 

To avoid losing your changes in the HAL libraries:

- When you use Cube to (re)generate code, select the option to create links to the libraries instead of copying all the files into your project. 

- Check your changes in the ST libraries into your version control (yes, make your private branch).

To minimize code differences, do not pass the UserContext as a new argument. Instead, add it to the SPI_HandleTypeDef struct. Then your callbacks will get this arg from the hspi pointer: hspi->UserContext.

I agree it should have been added to the function argument or to the handler struct.

Alternatively you can create a mapping table.

Some pseudocode:

typedef void (*usercallback_t)(SPI_HandleTypeDef *hspi, void* usercontext);

typedef struct
{
 void *peripheral;
 void *usercontext;
 usercallback_t function;
} usercontext_mapping_t;

static usercontext_mapping_t mappingtable[N];

void callback(SPI_HandleTypeDef *hspi)
{
 if (hspi == NULL) return

 for(int i=0;i<N;++i)
 {
 if(mappingtable[i].peripheral == hspi->instance)
 {
 if (mappingtable[i].function != NULL)
 {
 mappingtable[i].function(hspi, mappingtable.usercontext);
 } 
 break;
 }
 }
}

Create a wrapper function around HAL_SPI_RegisterCallback that automatically registers the function and adds user context to the table. You can also wrap the deregister function.

I prefer creating wrapping functions over rewriting part of the functions. While it adds some overhead in terms of stack and CPU time that usually is not a problem. Once it becomes a problem I would switch from HAL to LL and write my own library.