lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Problems with sending UDP packets in FreeRTOS


From: Mike Fleetwood
Subject: Re: [lwip-users] Problems with sending UDP packets in FreeRTOS
Date: Thu, 28 Jul 2016 12:24:24 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

Hi Simon,

Thanks for this - looks like getting closer! I thought the problem must be happening at a low level, otherwise why should it stop all LWIP function?

I'm using F427, initial code generated by CubeMX, including ethernet.c. I hadn't got around to looking at what ethernet.c did (really didn't want to wade through all the "HAL" nonsense!).

I'm sending data packet every 4mS. Packet transmission time is, I think, about 80uS for the test snippet. It was about 300uS for a decent audio packet. At the moment, it's running on a fairly slow (10Mbit) network segment, so obviously the packet times would be faster at 100Mbit. There's not much other traffic on the network, so I don't see that this should tax the DMA too much.

I wrote a previous version of this application a couple of years ago, running on F107 (I think), but all raw-api, no RTOS. That worked fine with a similar packet size and rate (although I can't remember the exact details).

1, I'll have a look at ethernet.c and see what's going on. I'll report the bug to ST, but I know from experience they don't exactly respond quickly!

2, I'll have a play with different packet sizes and rates to explore where the limits are!

Many thanks,

Mike.


On 28/07/2016 12:02, Simon Goldschmidt wrote:
Mike Fleetwood wrote:
If, by "low level netif driver" you mean the ethernet adaptor interface driver
That's it.

- that was provided by ST, and is the latest version they offer - I'm not aware 
of any reported problems with it.
I've had a quick look at the ethernetif.c file generated by CubeMX: at least 
for the F439, it returns
ERR_USE when no more TX DMA descriptors are available. This is clearly a bug as ERR_USE 
means "Address in use"
(and it has been like that since the beginning of the universe). ERR_MEM would 
be a better return value.

[You might want to report that bug back to STM]

In any case, you try to send faster than the chip or the cable can...

Simon

_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users


--
FACE Systems Ltd
The Old Boat House
Cadgwith
Cornwall TR12 7JX
T:01326 291031
M:07831 401464




reply via email to

[Prev in Thread] Current Thread [Next in Thread]