[Bugfix rtems-lwip 3/4] Correct the task prio of link_detect_thread

[Kinsey Moore]

You might be seeing different behavior than I have if you're running
single-core. Almost all my lwIP usage has been on 4 cores on the ZynqMP.

Kinsey

On Sun, Mar 31, 2024 at 5:49 PM Bernd Moessner <berndmoessner80 at gmail.com>
wrote:

> On my side, the link_detect_thread never gets to running state.
> I assume that the issues with the FreeRTOS tick rate and delay
> definitions have never been observed as the associated thread
> was never running / no one requied it to run. Previously, the
> link_detect_thread was set to RTEMS_MAXIMUM_PRIORITY (255).
> As far as I understand the docs, this should have worked out
> (why didnt it?). Using sched_get_priority_max (returns 254),
> the thread becomes active.
> ---
>  rtemslwip/xilinx/xlwipopts.h | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/rtemslwip/xilinx/xlwipopts.h b/rtemslwip/xilinx/xlwipopts.h
> index 8befd67..0f4316f 100644
> --- a/rtemslwip/xilinx/xlwipopts.h
> +++ b/rtemslwip/xilinx/xlwipopts.h
> @@ -27,8 +27,10 @@
>  #ifndef __XLWIPOPTS_H__
>  #define __XLWIPOPTS_H__
>
> +#include <sched.h>
> +
>  /* These macros allow RTEMS to pretend to be FreeRTOS for Xilinx drivers
> */
> -#define tskIDLE_PRIORITY RTEMS_MAXIMUM_PRIORITY
> +#define tskIDLE_PRIORITY sched_get_priority_max(SCHED_RR)
>  #define portTICK_RATE_MS (1000 / rtems_clock_get_ticks_per_second())
>  #define vTaskDelay(x) rtems_task_wake_after(x)
>
> --
> 2.34.1
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20240401/57066c86/attachment.htm>