For ThreadX, the RTOS timers run in interrupt space, so it is very bad
What post are you referring to?
It looks like the porting of data from the old forum into the new site has lost some data.
Do you have a particular question about worker threads?
Yes, just curious about the two worker threads and how they can be used as mentioned in the sentence:
"Because of this limitation WICED provides two worker threads dedicated to doing asynchronous work."
I was trying to use a RTOS timer to run a periodic function (1 sec) but it was locking the system and I had to use a timed event instead.
The function you provide in the RTOS timer runs in the interrupt context which permits you to have very low latency however limits the actions you can perform.
If you use wiced_rtos_register_timed_event() it will create an RTOS timer that will pass a message to a worker thread to call your function. This adds latency but since it is called from a thread context it is free to call any function from the WICED API.
A worker thread is a thread that waits on a message queue to allow you to defer the execution of a function to another thread context. The SDK adds two worker threads to your project by default; the network worker thread which is used to deal with link notification changes and other asynchronous network or socket activity, and the hardware worker thread that is to be used as an offload thread for hardware interrupts that require further processing that you don't want to do from within the interrupt context.
Currently the hardware worker thread is only utilized by the temp_control demo app which uses it to process push button activity. In theory you can use a single worker thread however some of the asynchronous network activity may take seconds to complete which is not suitable for responding to button presses.