Hi
I’m curious if something changed and I can call now OS functions from freeRTOS tasks (Windows/MinGW port)?
For example, blocking I/O like console/sockets.
fprintf, etc.
Thanks
Nothing has changed in the FreeRTOS code, although there are many variables that will determine whether you get away with calling Windows system calls. For example, the version of Windows probably has an impact, but more likely whether the call blocks or not. The scheduler suspends and resumes Windows threads so always expects the Windows thread it wants to run will be the thread that is running. If Windows blocks that thread from running there is basically as logic error as far as the scheduler is concerned. In our examples we will print to the console from one task only and then only slowly - printing quickly or from multiple threads increases the risk of a call blocking. Likewise I have found I can write to a disk, normally, and suspect that is because the caching means the write won’t block - but I’m not sure what the threshold is.
I’m asking because we have 2 problems
1st Known: task blocked in console input is considered as running
2nd : sprintf from 2 different threads causes a deadlock. If I remove one, no deadlock. probably task is suspended in the middle of Windows system call. Maybe not that good.
For #1, one thing you can do is periodically call kbhit() to see if a key has been pressed without blocking for the input. This can still cause issues, but it will be better. You may play with the buffering options for the input to see if that helps. A more complex way of doing it is to have a Windows thread outside the control of the FreeRTOS kernel block to wait for key presses then pass the keys to the kernel using some shared memory.
For #2 you can supply your own simple sprintf() function that allows you to control how it behaves. In sub-directories off FreeRTOS/Demo you will find many copies of a file called printf-stdarg.c which we use for this purpose. Disclaimer: printf-stdarg.c is a third party file and there are various different incarnations of it in the demos, some better than others. Ok for demos, but use your judgement as to whether it is suitable for your use.
#1 i tried different options, including kbhit. the biggest disadvantage is that I lose line editing options. I did not find anything usable. If would be great if in windows port it could be possible to hint freeRTOS that program enters blocking function and task is actually blocked. It would allow portable usage of keyboard, sockets, serial ports, etc.
#2 I’ll try to wrap sprintf with critical section, or disable context switch to avoid suspension of task in the middle of system call.
Here you find a recent versions of “printf-stdarg.c”. It is interrupt safe, and it can be used without a critical section within the WinSim project.
It wants _NO_CRT_STDIO_INLINE to be defined globally.
In stead of using stdin ( kbhit() ), I wonder if you can use a telnet connection and use e.g. puTTY as a console?
Sometimes telnet works on the same laptop, sometimes it doesn’t and you will need a second console to talk with the WinSim application.
We use console and telnet ( mingw sockets). In both cases read/receive is blocking and FreeRTOS consider it as “running”, as result we have to throw all this to low priority where they can somehow share/burn CPU. another problem is that idle thread is “blocked”.
It would be great if we can wrap blocking “read”/“write” with a pair of freeRTOS calls that tell FreeRTOS that section between them does not consume CPU.
In this case blocking call would “yield” to tasks at lower priority.