ChibiOS Free Embedded RTOS

Dear Giovanni,

it seems that the mutex - usually used to control the access on a SPI channel device - is controlled by thread or kernel context.
I try to use the callback function to cleanup the use of the SPI device. Unfortunately the release of the controlled mutex (spiReleaseBus(&SPID2))
seems not to work calling from callback procedure due to it is in fact a interrupt routine.
It seems that the handle of this mutex is controlled by thread or kernel context - not by the SPI-Device context. However - is it possible to program this for the future ?

It is much complicated to set up other signaling mechanisms to signal the origin calling thread to wake up only to do the "release SPI - channel task" ?
The SPI channel are typically used to do much of things in background, signaling the end of operation in calling the callback function.
In my opinion its logical to allow the release of this device in the callback function too - isn't it ? (maybe you intend to do so and this is a misfunction ?)

with kind regards,
Thilo

Hi,

Releasing a mutex from ISR context (callback) is not possible because it would release a mutex of the current (random) thread, you could eventually release the semaphore if mutexes are disables (the driver falls back to semaphores in that case), use chSemSignalI() on the driver semaphore directly.

Of course you CAN'T take a semaphore/mutex from ISR context in any case, that is absolutely forbidden and the state checker would stop you.

Giovanni

Dear Giovanni,

i think about that your answer is pointing to a restriction like this.
However - what kind of signaling do you propose doing from callback function to let wakeup (next) thread(s) which are concurrently waiting about the protecting mutex or semaphore - without the use of boring polling mechanism ?

thank you in advance,
Thilo

A Semaphore, threads do chSemWait() on the sem, callback does chSemSignalI(), the semaphore must be initialized to 1. Also a binary semaphore would work.

Giovanni