Running SMP on zynq7000 - my theory was that u might use QEMU. Kinsey Moore <kinsey.mo...@oarcorp.com> schrieb am Mo., 1. Apr. 2024, 16:35:
> 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 <berndmoessne...@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@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel >> > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
