[Bugfix rtems-lwip 3/4] Correct the task prio of link_detect_thread
Kinsey Moore
kinsey.moore at oarcorp.com
Mon Apr 1 14:34:59 UTC 2024
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>
More information about the devel
mailing list