Using xQueueSend from raw thread in Posix/Linux Simulator

Kernel
1

I have a set of freeRTOS tasks and a raw thread (doing some system calls), and I would like exchanges messages through queues. But unfortunately when using xQueueSend from my raw thread, from time to time the program hangs.

So it is possible to do so? If yes, what is the best approach?

PS : I have created the raw thread and I also blocked the signal as recommanded in Common problems and solutions

2

@hea-lab You must be extremely careful when sending data from native threads to simulated FreeRTOS threads. Generally, this takes the form of using a FreeRTOS stream buffer or message buffer and a platform-specific notification mechanism.

The best reference I know of for this is the FreeRTOS+TCP MAC drivers targeted at the Posix simulator:
libpcap on linux driver
libslirp driver

wait_for_event.c is the api used to notify native threads (which just contains some pthread calls).

3

Thanks for your insights, for freeRTOS toward native thread case, I got it working as per your suggestion :ok_hand:.

From native to FreeRTOS way, I went through your references (libpcap on linux driver) and it does not fit very well with my expectations. The producer (native pthread) adds some data in the circular buffer and the consumer (freeRTOS thread) uses polling to check the availability of this data. Unfortunately, this mechanism may introduce latency and/or overhead.

I’m wondering if there’s a way for the native thread to tell the FreeRTOS thread when new data is ready. This could help reduce delays and resource usage caused by the repeated checks.

4

It is a funny problem:

  • “raw” threads are allowed allowed to use API’s to the Linux kernel, even native TCP-IP.
  • FreeRTOS tasks are allowed to use all API of FreeRTOS, semaphores, queues, whatever.

Although, there seems to be an exception:

    /* Kick the Tx task in either case in case it doesn't know the buffer is
     * full. */
    event_signal( pvSendEvent );

It is called by xNetworkInterfaceOutput().

When I worked on WinSim, I encountered the same problem. That is when I started using a circular buffer, without a mutex. All you can do is poll often, which is controlled by the macro configWINDOWS_MAC_INTERRUPT_SIMULATOR_DELAY (in units of ticks).
The macro configMAC_ISR_SIMULATOR_PRIORITY determines the priority of that task ( < configMAX_PRIORITIES ).

I would be very interested to hear a better solution.

5

That is true of the libpcap driver. The libslirp driver takes a slightly different approach by blocking when receiving from a message buffer and using the message/stream buffer’s built in signaling method. The code which sends to this message buffer calls xMessageBufferSendFromISR to simulate an interrupt service routine.

Similar to the libpcap driver, the libslirp driver also uses event_signal to signal the native thread. This approach should work for your use case as well.