Hi everyone,
I'd like to ask for some clarification here, as I was studying the Bluetopia BTPSKRNL documentation, the BTPS_WaitEvent() specifies the following:
The following function is responsible for waiting for the specified Event to become signalled. It should be noted that signals have a special property, in that multiple threads can be waiting for the Event to become signalled and all calls to BTPS_WaitEvent() will return TRUE whenever the state of the Event becomes signalled.
However, the CC2564CSTBTBLESW 4.2.1.1 implements the Event as a binary semaphore, and uses FreeRTOS xSemaphoreTake() call to implement this method. xSemaphoreTake() always leaves the binary semaphore's status non-signalled, the signalled status is only preserved in the return value. So there's a direct contradiction between the abstract requirement of this API, and how it's implemented. As it seems this problem hasn't been uncovered yet, does this mean that the Bluetopia's internal behavior has been altered to adapt to the binary semaphore's different behavior? Or that this API is used in a way that it makes no difference in the end (e.g. BTPS_WaitEvent() is always followed by BTPS_ResetEvent() call)?
For the record FreeRTOS has a synchronization object that behaves as the documentation expects it, the event group (e.g. xEventGroupWaitBits(event, 1, pdFALSE, pdFALSE, DecrementWait)).