cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Studio Wi-Fi Combo

Anonymous
Not applicable

The documentation in rtos.h defined for ThreadX says the Networking worker thread  has a lower priority than that of the Hardware IO thread. However, when I look at wiced_defaults.h the priorities are flipped. Is there is a reason there is an inconsistency ? The documentation talks about allowing IO to preempt network activity on the network thread which may take longer or block.

0 Likes
4 Replies
Anonymous
Not applicable

I have the same question and nobody replied here, so ask this again.

In additional, I thought the all the usage should use

WICED_PRIORITY_TO_NATIVE_PRIORITY macro in the code.

But looking at the code in libraries/daemons, these daemons do not use

WICED_PRIORITY_TO_NATIVE_PRIORITY macro. Is this correct? Or does it need fix?

dns_redirect.c:

#define DNS_THREAD_PRIORITY                 (WICED_DEFAULT_LIBRARY_PRIORITY)

dhcp_server.c:

#define DHCP_THREAD_PRIORITY (WICED_DEFAULT_LIBRARY_PRIORITY)

http_server.c:

#define HTTP_SERVER_THREAD_PRIORITY (WICED_DEFAULT_LIBRARY_PRIORITY)

0 Likes
Anonymous
Not applicable

Looking at the WICED thread priority table.

priority 0 is Highest priority, priority 9 is Lowest priority.

If I use WICED_PRIORITY_TO_NATIVE_PRIORITY macro,

#define WICED_PRIORITY_TO_NATIVE_PRIORITY(priority) (uint8_t)(RTOS_HIGHEST_PRIORITY - priority)

Then the priority is reversed!!

I test with freeRTOS, so my test result shows lower priority value has higher priority.

Then the WICED_PRIORITY_TO_NATIVE_PRIORITY looks wrong to me.

I got totally confused with the priority and what WICED_PRIORITY_TO_NATIVE_PRIORITY does.

Can someone help to clarify this?

Thanks.

SeyhanA_31
Employee

Hi,

The FreeRTOS task defines the 0 is the lowest priority and priority increases as the priority value on thread creation increases.and ty abd priory increases.

The ThreadX implements the priorities as 0 being the highest thread priority level and the thread priority decreases as the priority value increases.

Wiced implements a wrapper for FreeRTOS and ThreadX. The thread priority for Wiced is 0 being the highest priority level. As the priority value increases on thread creation the actual thread priority decreases.

From the include/wiced_defaults.h file:

/************************************************************************

*   WICED thread priority table

* +----------+-----------------+

* | Priority |      Thread     |

* |----------|-----------------|

* |     0    |      Wiced      |   Highest priority

* |     1    |     Network     |

* |     2    |                 |

* |     3    | Network worker  |

* |     4    |                 |

* |     5    | Default Library |

* |          | Default worker  |

* |     6    |                 |

* |     7    |   Application   |

* |     8    |                 |

* |     9    |      Idle       |   Lowest priority

* +----------+-----------------+

*/

Since Wiced priority logic is 0 being the highest priority thread, it is reflected on the FreeRTOS and ThreadX with WICED_PRIORITY_TO_NATIVE_PRIORITY(priority) micro.

The FreeRTOS implementation is

     #define WICED_PRIORITY_TO_NATIVE_PRIORITY(priority) (uint8_t)(RTOS_HIGHEST_PRIORITY - priority)

The ThreadX implementation is

#define WICED_PRIORITY_TO_NATIVE_PRIORITY(priority) ( priority )

Consider the thread priories in terms of Wiced point of view not the actual RTOS implementation.

Hope it helps,

Seyhan

Anonymous
Not applicable

Hi Seyhan,

Thanks for your feedback, it's clear to me now.

I should not use WICED_PRIORITY_TO_NATIVE_PRIORITY macro in application code.

Just use thread priories in terms of Wiced point of view in application code.

0 Likes