I want to connect Windows threads which are not under my control with the tasks of the Windows freeRTOS simulator. These threads are part of the drivers that control the PC hardware.
One thread related to the audio system of the PC and calls user-define callback function (or event) each time the audio buffer needs to be reloaded (waveOutProc callback, see https://msdn.microsoft.com/en-us/library/dd743869%28v=vs.85%29.aspx). The goal of this project is to develop Windows based emulator of a freeRTOS based firmware project (ARM Cortex) where hardware of the embedded system are replaced by hardware/drivers resources of the PC.
I tried several ways of integrating this audio callback function/thread with the freeRTOS tasks but I did not find a working solution.
1) I have first tried to use semaphore in the audio callback (xSemaphoreGive) to wake up a freeRTOS task that would compute and fill-up the audio buffer. It did not work and the reason could be that it windows mutex in the waveOutProc callback function. Only a few limited system function calls are allowed but Windows feeRTOS semaphore implementation use mutexes. This is also true for the simulated interrupts (vPortGenerateSimulatedInterrupt).
2) A possibility would be to use Windows setEvent function in the audio callback (which is allowed) and to insert of Windows WaitForSingleObject in the freeRTOS task to block it until the event. This would replace the freeRTOS semaphore but I think that it will wreack havoc with the freeRTOS schedular since the task would be blocked by a primitive that is not managed by the scheduler.
We have found it very difficult, if not impossible, to mix Windows system calls with FreeRTOS task. Sometimes it can appear to work for a long time, but under heavy load, eventually the windows system calls with interfere with the working of the FreeRTOS scheduler.
I think we experienced a similar issue when creating some of the FreeRTOS+TCP demos - especially in the driver. To get around the issue there we used a thread safe circular buffer to pass data between Windows threads and FreeRTOS tasks - that didn't use any system calls but there was no easy way of signalling the destination thread/task that new data was available so we then had to introduce a 'polling' task the keep looking at the circular buffer to see if it contained new data. Not very elegant, but reliable. In the following link, which is otherwise unreleated, you will find some info on the "stream buffer" used for this purpose. Its implementation is in a source file in the FreeRTOS+TCP code.