AW: [En-Nut-Discussion] UART looses Bytes

[Toennies Kai]

Hello Harald!

There are interrupts inside the ethernet device 
or TCP/IP stack which block the uart receive interrupt for more than 60µs.
Can you give me an overview which files belong to this theme?
I found till now: lanc111.c  and tcpsock.c
Maybe I can change the timeouts, so that a telnet still works and 
I won't loose more than 60µs.  

Regards,
Kai

> -----Ursprüngliche Nachricht-----
> Von: en-nut-discussion-bounces at egnite.de
> [mailto:en-nut-discussion-bounces at egnite.de]Im Auftrag von Harald Kipp
> Gesendet: Mittwoch, 24. November 2004 19:17
> An: Ethernut User Chat (English)
> Betreff: Re: [En-Nut-Discussion] UART looses Bytes
> 
> 
> Hello Kai,
> 
> Gosh, good question. That very much depends on what's going
> on else in the system. For example, timer processing disables
> interrupts and the duration depends on the number of times
> to process.
> 
> 20us is a lot of time and the UART hardware can buffer 2 bytes.
> But still...roughly calculated, context switching takes about
> 7us on a 16 MHz ATmega with interrupts disabled almost all
> the time.
> 
> You are receiving limited length telegrams, right? Wouldn't
> it be better then to receive the full telegram in a single
> interrupt call? This will block all other interrupts,
> which is usually acceptable for Ethernet and Timer processing.
> 
> But I agree that this may not solve the problem for the
> first two bytes of the telegram.
> 
> We had similar problems MP3 streaming and solved it by
> explicitly disabling the MP3 interrupt and re-enabling
> the global interrupt within the MP3 interrupt routine,
> which takes quite long to process. This allows nesting
> interrupts, which were required to continuously receive
> PPP characters from the serial port. In this case you
> should make sure, that the separate interrupt stack feature
> is disabled.
> 
> One last idea: If you're using Ethernut 1 (with RTL8019),
> then the interrupt routine in the driver can become
> quite slow during overflow processing:
> 
> #if !defined(__AVR_ATmega128__) && !defined(__AVR_ATmega103__)
>          cbi(EIMSK, RTL_SIGNAL_IRQ);
>          sei();
> #endif
>          NicOverflow();
> #if !defined(__AVR_ATmega128__) && !defined(__AVR_ATmega103__)
>          cli();
>          sbi(EIMSK, RTL_SIGNAL_IRQ);
> #endif
> 
> The part for allowing nested interrupts had been disabled
> for AVR, because when this was done, Oliver's code didn't
> allow interrupt nesting to that time. Try to remove the
> #ifs.
> 
> Any other Nut/OS drivers you're using in your app?
> 
> Harald
> 
> At 17:51 24.11.2004 +0100, you wrote:
> >Hi!
> >
> >I try to receive data at 1MBaud on the UART using the 
> receive interrupt.
> >I changed the oszillator, it is now 16MHz.
> >I do not use the Nut-OS routines for UART communication.
> >It all works fine, but sometimes(too often) I loose one or 
> more bytes.
> >Something from the Nut-OS delays the uart receive interrupt.
> >This I could see on the oscilloscope.
> >The thing is, now I send byte after byte with no delay.
> >Later I will have 20µs between the startbits of two following bytes.
> >Will that be enough?
> >My receive interrupt routine takes no more than 5µs.
> >
> >I would like to know, what is interfering me and how long it 
> will take.
> >And if it might be disabled, for a period of time(complete 
> telegramm).
> >
> >Thanks in advance,
> >Kai Tönnies
> 
> _______________________________________________
> En-Nut-Discussion mailing list
> En-Nut-Discussion at egnite.de
> http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
>