The ‘OS’ never does things like that. The OS just schedules tasks and provide services for communication between tasks and between tasks and some interrupt.
The actual ‘work’ that your program does, is in. your code. The work you are talking about, with this sort of tight tolerances, needs to be done with minimal overhead and interference, so is best done at a ‘bare metal’ level. Running the scheduler could easily have costs on the order of a micro-second on this system (that’s only 100 assembly instructions), so at a 40 microsecond period that is several percent. Using high priority timer interrupts to trigger this functionality seems to be the best bet. Depending on exactly how little jitter you need, you may need to put the task above the level that FreeRTOS blocks in critical sections.
FreeRTOS does have a design parameter that critical sections that keeps the length of its critical sections ‘short’ and bounded, but because of hardware and compiler variations, it can’t provide a number in absolute time. You could instrument the critical sections (setting high a port bit when entering, and clearing it when re-enabling interrupt) so you could trigger a scope on the bit to see what the worse case time you can measure.
If that time is short enough for you, then you just need to make that interrupt above any interrupt that might take long enough to execute to cause a problem, but still low enough that it can use FreeRTOS primitives to signal tasks. If it isn’t then you need to put it above the level that FreeRTOS masks, and the ISR needs to trigger some lower priority interrupt to signal the OS.