I am trying to integrate lwip into my embedded system and am having issues using a high tick rate. I am using Xilinx SDK with a Zynq-7000 and have created my application project with OS Platform set to freertos10_xilinx so that lwip has scope of the OS and so I can make use of the sem_rx_data_available semaphore.
I have successfully integrated lwip and been able to communicate over the ethernet cable, however this was using a tick rate of 1000. Ideally I would like to use a higher tick rate as there are motors within the same system and they run much more smoothly with a higher tick rate (2000 is what has been used up to this point).
When running with a 2000 tick rate and lwip, the program ends up in freertos undefined handler as lwip is within the tcpip_init function. At some point during the creation of the tcpip_thread task the program fails, but only at a tick rate of higher than 1000.
I am wondering if I should instead use the RAW API and use a timer to service the tcp input instead?
Any help on this issue would be greatly appreciated.
One big question is does the SYSTEM TIC rate really need to be that high. Normally I have a motor controller working off some other interrupt that is handling the motor update at the precise time that the motor need them, with a much slower system tick. The high speed motor stuff may never hit any task, but be all ISR code. Aybe there is some low speed algorithm feeding from it.
I personally try to avoid having high speed critical timing based on the systick, as that tends to scale poorly. Normally high speed stuff needs tight control, and too much happens on the systick. Real tight stuff should be on another higher priority interrupt to really get low latency.
Thanks for the reply. I think I’m going to try and implement lwip using the RAW API and place the xemacif_input function within an interrupt tied to the XEMACPS_ISR_FRAMERX flag.
The reason we have such a high tick rate is we have many motors being controlled and they do really need to be as smooth as possible. The difference between 1000 and 2000 is very noticeable, so I’d like to try and keep it that way.
As I have said, I wouldn’t be having those operations being based on Tick timing in the first place, but on some higher speed interrupt, preferably without needing to run the scheduler for each operation. I have had motors with control loops running over 10,000 kHz update rate with a tick of about 100 Hz.
Hi! The problem is the macro portTICK_RATE_MS, which is zero for a tick rate greater than 1kHz. In the file xadapter.c and sys_arch.c (in Vitis there should be a warning), there are calculations with division by portTICK_RATE_MS. You can fix this (at my knowledge) only per hand with the macro pdMS_TO_TICKS(…) and everything should work.
Unfortunately, if you change anything in your bsp-config of your platform-project, the changes are undone and you have to do them again.