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@rtems.org http://lists.rtems.org/mailman/listinfo/devel
