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

[Toennies 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.

I do receive limited length telegramms, but not a constant length.
I have to detect a gap of at least 50+11(one byte)µs after the last byte.

More about my application. 
Hardware is 2.1B.
It is based on the rs232d.c example. 
It has to transfer data from ethernet back and forth to UART.
It needs to behave as slave, the master is connected to the UART.
I have to use the Nut-OS for ethernet communication, I do know nothing about
TCP/IP stack programming.
My first guess was, that system timer TCNT0 and or LAN controller steal my
time.
So, at the first receive interrupt, I disabled the timer 0 and 1 interrupts
in the TIMSK.
After detecting the last byte, they were enabled.
But that leeds to a reset of the board after receiving the first complete
telegramm. 
So I wonder if it is possible to get the whole telegramm in one single
interrupt, ok I will try that. 
Do I need to trigger the watchtdog?

First I will try to read the receive buffer twice, not so much code to
change. :) 
> 
> But I agree that this may not solve the problem for the
> first two bytes of the telegram.

Well the problem usually occurs after severel bytes and not at the very
beginning of the telegramm. 

Thanks a lot,
Kai Tönnies