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
Trying release SPI bus mutex in callback procedure
Moderators: RoccoMarco, lbednarz, tfAteba
- Giovanni
- Site Admin
- Posts: 14893
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: Trying release SPI bus mutex in callback procedure
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
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
Re: Trying release SPI bus mutex in callback procedure
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
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
- Giovanni
- Site Admin
- Posts: 14893
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: Trying release SPI bus mutex in callback procedure
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
Giovanni