lpc1768 / freertosdemo frame dupe question

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

lpc1768 / freertosdemo frame dupe question

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.

lpc1768 / freertosdemo frame dupe question

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

lpc1768 / freertosdemo frame dupe question

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.org Regards.

lpc1768 / freertosdemo frame dupe question

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

lpc1768 / freertosdemo frame dupe question

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.