Problem with ping delay has been solved! Not really.
I have discovered that when PC is connected directly with cable to my target, ping response is always very short.
When I connect board through cable to router (netgear) and PC is connected through wifi, this 60sec period delay appears.
Thanks for support
rum
Da: lwip-users [mailto:address@hidden Per conto di Noam Weissman
Inviato: venerdì 3 giugno 2016 09:04
A: Mailing list for lwIP users <address@hidden>
Oggetto: Re: [lwip-users] R: R: R: ping slow down
Hi Rastislav,
We talked about it before but let me summarize it once more.
Interrupt are triggered as they happen and disturb the application.
If you use a variable /array or some other data both from interrupt and application
you must synchronize the sharing.
Example: if you read data from an array (app side) and in the middle
you get an interrupt that writes to the same array you may have a problem.
To avoid the above the OS gives the user the ability to surround a small code with a
protecting "critical section". Critical section will mask interrupts for a short period
and assure that while handling that shared data it will not change from ISR.
The above is great, but !!! .... there is a big but. Under Cortext-M3 critical section will
only work if the OS runs at a higher interrupt priority then the that interrupt that the user
wants to mask.
That means that (priorities):
15 - highest
.
.
.
0 - lowest
If you set TCP interrupt to 3 and OS time tick interrupt to 5 the OS will not mask the TCP
interrupt when inside a critical section.
OS should be set to 3 and TCP to 5 etc...
BR,
Noam.
http://www.freertos.org/RTOS-Cortex-M3-M4.html
http://www.freertos.org/a00110.html
FreeRTOS is a portable, open source, mini Real Time kernel. A free RTOS for small embedded systems. This page describes and explains the constants used to configure ... |
Running the RTOS on a ARM Cortex-M Core [see also debugging Cortex hard fault exceptions]. Note: The information regarding interrupt nesting on this page applies when ... |
From: lwip-users <address@hidden> on behalf of Rastislav Uhrin <address@hidden>
Sent: Friday, June 3, 2016 12:17 AM
To: Mailing list for lwIP users
Subject: [lwip-users] R: R: R: ping slow down
Hi Greg,
Thank you for your contribution. But if from interrupt you want to signal semaphore its number must be “higher” than MAX_SYSCAL_INTERRUPT_PRIORITY.
If the slowdown exists with only lwIP probably problem will be in the driver. This is my thought.
Thanks
rum
Da: lwip-users [mailto:address@hidden] Per conto di Greg Smith
Inviato: giovedì 2 giugno 2016 15:51
A: Mailing list for lwIP users <address@hidden>
Oggetto: Re: [lwip-users] R: R: ping slow down
Hi, Rastislav and Noam.
Noam, thank you for those links. I used similar ones for the ST part and they were very helpful. I hope Rastislav finds them useful, too.
Rastislav, the approximate priorities of your tasks is very similar to how I have mine setup. I'm not an expert (I'm still learning lwIP myself), but it seems about right and is working for me.
About your task priorities: be careful not to mix together your hardware's (Infineon's) IRQ priorities and FreeRTOS' priorities -- they don't relate to each other. So 20 (out of 63) is approximately where I put my MAX_SYSCAL_INTERRUPT_PRIORITY. (Technically, I have mine as 7 out of 15). If the other task, the one at 25, is triggered by a hardware interrupt, then I think you have it set too low. It should probably be set to a higher priority (i.e. a lower numerical value, say 19).
If that "25" is a FreeRTOS task priority, then there is no relation and it will always get pre-empted by a hardware IRQ. (At least, that is my understanding of FreeRTOS.) I would also suggest using far fewer RTOS task levels -- maybe 5 or 7 at most. (That is set with configMAX_PRIORITIES.)
There's an art to interrupts and priorities, which makes it a little hard to describe in an E-mail. So please ask if you have more questions.
Good luck!
-- G
From: lwip-users [mailto:address@hidden] On Behalf Of Noam Weissman
Sent: Wednesday, 01 June 2016 02:40
To: Mailing list for lwIP users <address@hidden>
Subject: Re: [lwip-users] R: R: ping slow down
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: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
Da: lwip-users [mailto:address@hidden] Per conto di Greg Smith
Inviato: martedì 31 maggio 2016 16:47
A: Mailing list for lwIP users <address@hidden>
Oggetto: Re: [lwip-users] R: ping slow down
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-
> 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
This email has been scanned for email related threats and delivered safely by Mimecast.
For more information please visit http://www.mimecast.com