@jaza_tom, FreeRTOS doesn’t run on a thread as such in that it is the kernel and manages all aspects of the operating environment. The Cypress (aka Broadcom) WICED library uses FreeRTOS threads to run the communications stack and these run at some of the highest priorities. The Particle system firmware runs on a thread that is higher than the user application thread if enabled. Priorities allow for higher level threads to “preempt” lower level threads (thus the reason why user code can continue running while an OTA download is going on). Software Timers are run in a single FreeRTOS thread meaning all 10 allowable timers must play nice since they are “chained” and each one will not run until the previous timer’s callback has completed.
Below all this are hardware interrupts which are partially managed by FreeRTOS, the system firmware and (with low level programming) the user application. The fundamental hardware ‘tick’ timer which also drive the microseconds timer is always running.
On a single processor, threads don’t run in true parallel. Instead, they are “time sliced” by the FreeRTOS kernel, with each thread given runtime based on it priority level and a number of programmatic controls (eg waiting on a shared resource). The minimum time slice for FreeRTOS is 1ms or 1000us. So the minimum resolution for software timers is 1ms. Thus, the user loop() will be called every 1ms depending on what it’s doing and large delays will not stop the system firmware or FreeRTOS from running. So timer status is only updated every 1ms since both the timer thread and the user thread only run every 1ms.
Sorry for the long winded explanation. Real-time OS stuff is not always easy to explain. If you want to learn more about FreeRTOS, you can always did here!