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

[Bernd Moessner]

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