[En-Nut-Discussion] Time needed to get packet from RTL onATmega128

[Bengt Florin]

Dusan,

I'm sorry to say I never succeeded finding a clever solution to use IOCHRDY.
The 16 NOP's were inserted by pure experimenting.
Hook a scope or logic analyzer to IOCHRDY pin.
Then reduce the amount of NOP's until IOCHRDY is asserted. Then add one.
The 16 NOP's were tested for running at 16MHz so if you are running at lower
speeds you could cut some off.

However not much speed is gained in doing this. If your current interrupt
takes
50us or 735 cycles at 14.7MHz a cut of 8-10 cycles will not do the job.

If you dare to, you could try enabling nested interrupts in the nic
interrupt.
Then the uart interrupt may get a chance to run.
Things may easily and quickly go bad when doing this, but careful coding
normally
sorts it out.

God luck,
bengt

-----Original Message-----
From: en-nut-discussion-bounces at egnite.de
[mailto:en-nut-discussion-bounces at egnite.de]On Behalf Of Dusan Ferbas
Sent: den 10 januari 2005 21:44
To: en-nut-discussion at egnite.de
Subject: Re: [En-Nut-Discussion] Time needed to get packet from RTL
onATmega128


Hi Harald and Florin,

I think I need some info how to work with IOCHRDY signal (instead of those
16 NOPs). If you think that this can save some time ?

Then even if I tried to modify NutArpCacheQuery() (see below, w/o comments)
with fl_send I am still getting 2 ARPs for 1st UDP output packet which
confuses me.

Finally problem with ARP storm and lost USART Rx interrupts. This means
that for 2 ms there are so much RTL interrupts that there is no time to
handle USART interrupt. I cannot understand this. I think that interrupts
are maybe somewhere globally disabled. This is very easy to test I can send
a link to ARP traffic generator.

If preceding is true it means that ATmega128 is not able to handle more
than 20 RTL interrupts per ms so there is no time for USART int to occure.
I can't believe this because dev/nicrtl.c:NicInterrupt() is quite short. If
you think it can take 50us then the only solution will be to poll USART
state from RTL int and temporarily disable RTL ints.

Anyone else with more experience ?

---
>Date: Mon, 10 Jan 2005 14:10:33 +0100
>From: Harald Kipp <harald.kipp at egnite.de>
>
>Dusan,
>
>Now I understand the problem. It definitely requires
>some time to think about. I can confirm, that ARP
>showers hadn't been considered, but have to.
>
>In general, the current state of the driver is a result
>of the work done by Bengt Florin. He greatly enhanced
>the reliability during heavy traffic situations, reducing
>packet loss as well as the need for occasional controller
>resets to almost zero.
>
>Not yet sure, what's the best solution to fix your problem.
>I'll come back to you.
>
>Harald


-------------
int NutArpCacheQuery(NUTDEVICE * dev, CONST u_long ip, u_char * mac)
{
     volatile ARPENTRY *entry;
     NETBUF *nb = 0;
     int rc = -1;
     u_char retries = 4;
     u_char      fl_send;

     if ((entry = NutArpCacheLookup(dev->dev_icb, ip)) != 0) {
         if (entry->ae_flags & ATF_COM) {
             memcpy(mac, ((ARPENTRY *) entry)->ae_ha, 6);
             return 0;
         }
         else
             fl_send = FALSE;            //already sent, but still pending
     }

     else {
         if (entry == 0 && (entry = NutArpCacheNew(dev->dev_icb, ip, 0, 0))
== 0)
             return -1;
         else
             fl_send = TRUE;
     }

     if (fl_send) {
         if ((nb = NutArpAllocNetBuf(ARPOP_REQUEST, ip, 0)) == 0)
             return -1;
     }

     while (retries--) {
         if (fl_send) {
             if (NutArpOutput(dev, nb))
                 break;
         }
         if (entry->ae_flags & ATF_COM) {
             memcpy(mac, ((ARPENTRY *) entry)->ae_ha, 6);
             rc = 0;
             break;
         }

         NutEventWait(&((ARPENTRY *) entry)->ae_tq, 500);
     }
     if (fl_send)
         NutNetBufFree(nb);
     return rc;
}



Dusan

_______________________________________________
En-Nut-Discussion mailing list
En-Nut-Discussion at egnite.de
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion