Hi Rastislav,
Check the following link if they have some info that may help you.
http://www.freertos.org/Infineon-ARM-Cortex-M4-XMC4000-RTOS.html
http://www.freertos.org/FreeRTOS-for-Infineon-XMC4000-Cortex-M4.html
BR,
Noam.
From: lwip-users [mailto:lwip-users-bounces+address@hidden
On Behalf Of Rastislav Uhrin
Sent: Tuesday, May 31, 2016 11:26 PM
To: Mailing list for lwIP users
Subject: [lwip-users] R: R: ping slow down
Hi Greg,
Thanks for your thoughts. I am exactly on same configuration as you except I am using Infineon C4.
I want to ask about priorities of RTOS tasks
ETHRx - task which extracts frame fills pbuf and sends to tcpip, waits on semaphore from interrupt – RTOS priority is say “middle”
TCPIP - task of lwIP – RTOS priority “higher”
My application task working with sockets – RTOS priority “lowest”
Of course in real application there are more 12 other tasks with different priorities.
Is this arrangement correct?
About MAX_SYSCAL_INTERRUPT_PRIORITY this is 20 (of 63) and task which sends semaphore is 25 (“lowest interrupt priority” ). There are some other 10 interrupts
distributed, some bellow 20 which need to run always, other above 20 which need to be disabled by OS when needed.
But I have build simple application with only lwIP and nothing else and ping is delayed. I was puzzled by this regular behavior.
Thanks
rum
Hi, Rastislav.
I had a similar problem with ping times using PPP in the 2.0.0 Beta1 release and FreeRTOS 8.2.3 on an STM32F2xx part (Cortex-M3). I'm not using Ethernet (I'm using serial), but I eventually tracked it down to interrupt priority and interrupt levels.
For me, my USART IRQ was very, very low by default. Once I increased its priority (to about half way in the middle of all priorities), that really cut back on the latency and reduced ping times.
I also found I had the value of configMAX_SYSCALL_INTERRUPT_PRIORITY in FreeRTOSConfig.h set too high (which means a low priority). Once I increased the priority (by lowering the value) to a range that made sense -- I needed the priority high enough that the
interrupt would complete before RTOS functions I called would get handled -- then that was the final piece. I can now ping for hours and the total turnaround time is 5-6ms on my setup, which is right where I want it to be.
I don't know if any of that applies to your situation, but just a couple things to check.
-- G
> -----Original Message-----
> From: lwip-users
> On Behalf Of Rastislav Uhrin
> Sent: Monday, 30 May 2016 17:27
> To: Mailing list for lwIP users <address@hidden>
> Subject: [lwip-users] R: ping slow down
>
> Thank you for answering.
>
> This task waits on semaphore from interrupt routine which is invoked when Eth
> frame is received.
>
> The driver is form Infineon.
>
> Port to RTOS should be OK because I have compared many I found on internet and
> they are all the same.
>
> OK. I will investigate further.
>
> rum
>
> -----Messaggio originale-----
> Da: lwip-users [mailto:lwip-users-
> bounces+address@hidden] Per conto di Sergio R.
> Caprile
> Inviato: lunedì 30 maggio 2016 23:07
> A: address@hidden
> Oggetto: Re: [lwip-users] ping slow down
>
> And that task runs every...
> >> Most likely your code is polling at regular intervals and what you
> >> see as varying delay is the phase difference of your ping frequency
> >> and your poll frequency "signals".
> Try to move pins every time that task runs Try to move pins every time you see
> a packet, and check on a scope Read the wiki and see if you are doing things
> right for an RTOS-based port
>
http://lwip.wikia.com/wiki/Writing_a_device_driver
> http://lwip.wikia.com/wiki/Porting_for_an_OS
> Make sure you don't call low level routines from interrupt code, all non socket
> nor netconn calls must be on the same thread.
>
> No, it is not normal to have delays unless something is causing those delays.
> lwIP is mostly event driven, when a frame comes in and you notice that, you
> send it to lwIP and it peels protocol by protocol until it either calls you
> (RAW API)/delivers to netconn/socket (which I don't
> master) or responds itself (ping).
> If it does not responds itself asap is because you don't give it the frame or
> you don't let it run fast enough to do its job.
>
> You can also check for known caveats with your port to your RTOS.
>
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
>
https://lists.nongnu.org/mailman/listinfo/lwip-users
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
>
https://lists.nongnu.org/mailman/listinfo/lwip-users
This email has been scanned for email related threats and delivered safely by Mimecast.
For more information please visit http://www.mimecast.com