FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [September 2010 Threads] lpc1768 / freertosdemo frame dupe questionPosted by Skashkash on September 24, 2010 Hi, I'm new to freertos and to these forums, so if this is not an approprate place to ask this questiom, could someone please direct me to the proper forum. Thanks. Using freertos v6.0.5 rtosdemo_rdb1768 (cortex_lpc1768_gcc_redsuite) on an nxp lpcxpresso1768 board. lpcxpresso compile and debug environment. I had to modify the freertos demo code to support the lan8720 phy on the lpcxpresso board. The code changes were limited to the phy init and link status routines. Code seems to be working pretty much as expected, the web server delivers pages properly. But I noticed some odd behaviour when pinging my device. I was getting two reply frames for every icmp request.
I see that the vSendEMACTxData function and the vEMAC_ISR seem to be set up to send each outgoing ethernet frame twice. After the frame goes out via DMA, it's sent yet again by the ISR and then usSendLen is cleared to prevent a third transmission. Is there a reason for this? Or is it just partial code waiting for some error handling. Thanks
RE: lpc1768 / freertosdemo frame dupe questionPosted by Richard on September 24, 2010 The biggest drawback of uIP is the fact that you can only have one packet outstanding on the network at any one time. This means communicating with a desktop machine is very slow because the desktop will wait 200ms between receiving a packet and acknowledging the packet. This is standard practice in non real-time TCP/IP stacks to minimise network traffic - it waits to see if any more packets come so it can acknowledge more than one packet at a time.
There are ways around this and so speed up communication without having to change the configuration of your desktop TCP/IP stack, but like everything in engineering - there are trade off's to be made. Gain in one place, loose in another. I have several schemes I'm working on (code named FreeTCPIP), but one easy way of speeding up uIP is to simply send each packet twice. This tricks the other end into thinking it has missed a packet, and this causes it to send the ACK immediately. The cost of this is more bits on the wire, but if you have a decent DMA the microcontroller hardly notices.
Regards.
RE: lpc1768 / freertosdemo frame dupe questionPosted by Skashkash on September 24, 2010 Thank you, That makes perfect sense, and explains why wireshark was seeing the extra frames. I don't know yet if the extra traffic on the wire will be an issue or not with my app. The lpc1768 seems to have the resources to handle other, more resource demanding stacks. I'll continue to research and experiment.
Again, thanks.
-carl
RE: lpc1768 / freertosdemo frame dupe questionPosted by Richard on September 24, 2010 I would be *very* grateful if you could post your LPCXpresso project to the FreeRTOS Interactive site. I think there would be a lot of interest in it. Even from me! http://interactive.freertos.orgRegards.
RE: lpc1768 / freertosdemo frame dupe questionPosted by Skashkash on September 24, 2010 I'm pretty new to this (at least ARM & FreeRTOS).
The hardware mods (adding the magnetics and RJ45 to the lpcxpresso1768) were simple. I designed a simple carrier PCB for the lpcxpresso1768. It really helps to not have to solder the CPU or the PHY chip.
Moding the example code (after FINALLY discovering that there was V1 and a V2 of the RDB1768 board schematic) to change from the DP83848 to the LAN8720 PHY was also pretty simple.
I can't easily post any of the hardware due to job conflicts. But the mods to the software are just early proof of concept tests. The software mods can be happily shared, and I'll try to post them after a bit of clean up.
BTW, The lpcxpresso1768 is an AMAZING value for doing ARM M3 development with networking. (I just hate to keep typing that name).
-carl
RE: lpc1768 / freertosdemo frame dupe questionPosted by Artem Pisarenko on April 4, 2011 What ???!!! I've broken my brain searching the cause of double sending of packets ! It turns out that this is not a bug but a feature ! I see most use TCP only. What's about UDP? It's problem here. How to remove this "feature" ?
P.S.: I think you should make this feature optional on some #define. Document this feature at least.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|