[En-Nut-Discussion] samples at 8kHz

[Harald Kipp]

Hi Christian,

UDP _may_ take that long. Thus it is required to add a buffer
between A and B.

In average it will probably not take 100ms and with buffering
it's not a question of how long each call takes but of how
many bytes of data can be transferred per second. That
should be 1MB at least.

However, a simple Request/Response scheme may be too slow.
The sender must be able to send datagrams in advance,
similar to the TCP sliding window.

Yielding to another thread _may_ take a very long time,
depending wether it yields the CPU and which thread
takes over control etc...

But as B and C are timer interrupts, why care? They
are not influenced by thread switching.

If you look to the dev/vs1001k.c, you'll get an idea
how interrupts access a global buffer implemented in
os/bankmem.c.

May be you can provide a line out of your code or post
a sample, if it's not too large for the list. We may
try to help.

Regards,

Harald

At 13:23 11.11.2004 +0200, you wrote:
>Hello Harald et al,
>
>we have done part "-B->" and "<-C-" successfully with native
>interrupts, and can send out packets at the required pace. However,
>calling NutUdpReceiveFrom takes around 80 to 100ms (on an Ethernut
>2.1).
>
>Is there a way to decrease the execution time of this function?
>
>We are also facing too long delays it we yield to another thread.
>
>Cheers,
>
>Christian
>
>
> > Christian,
> >
> > Well, I think in the first place it should be noted,
> > that UDP isn't reliable. There will be no fixed "clock"
> > for incoming or outgoing packets. Thus some buffering is
> > required:
> >
> > Ethernet -A-> InBuff -B-> DAC
> >
> > Ethernet <-D- OutBuff <-C- ADC
> >
> > The arrows may be viewed as tasks, reading from or writing
> > to buffers.
> >
> > Tasks B and C must be strictly time controlled, best
> > using a native timer interrupt. Nut/OS uses timer 0 only.
> > For example, timer 1 can be used:
> >
> > SIGNAL(SIG_OUTPUT_COMPARE1A)
> > {
> >      outb(TCNT1H, 0);
> >      outb(TCNT1L, 0);
> >      /* DAC or ADC work here */
> > }
> >
> > /* Timer initialization, see ATmega128 datasheet. */
> > void InitTimer1(void)
> > {
> >      NutEnterCritical();
> >
> >      outb(TCCR1A, 0);
> >      outb(TCCR1B, _BV(CS12));
> >
> >      outb(TCNT1H, 0);
> >      outb(TCNT1L, 0);
> >      outb(OCR1AH, 0x01);
> >      outb(OCR1AL, 0x00);
> >
> >      sbi(TIMSK, OCIE1A);
> >      NutExitCritical();
> > }
> >
> > However, interrupt latency might be too high to maintain
> > ADC/DAC frequency. Thus, extra hardware may be required.
> >
> > Tasks A and D are simple threads. Note, that it is impossible
> > to have UDP packets at exactly every 20 ms. Ethernet is non-
> > deterministic. Even switched Ethernets got some jitter, at least
> > caused by the CPU in the switching hardware.
> >
> > Harald
> >
> > At 16:55 14.10.2004 +0300, you wrote:
> > >Hello,
> > >
> > >I am not sure how to realize the following thing - a simple IP
> > >telephone. I have realized the Control Plane by adopting a simplified
> > >form of SIP (Session Initialization Protocol)
> > >
> > >But I come into troubles realizing the Media exchange.
> > >
> > >The phone should sample voice from ADC0 and makes out of it an RTP
> > >(Real Time Protocol) Stream (using G.711 encoding I have to send a UDP
> > >packet every 20ms). I have to get a sample every 125us (8kHz) and kick
> > >incoming RTP packets piece by piece to an PWM counter.
> > >
> > >My question now is: Can this be done using NUT/OS? What would be a way
> > >to do so?
> > >
> > >Cheers for any answers,
> > >
> > >Christian Wieser
> > >mailto:chwieser at ee.oulu.fi
> > >
> > >
> > >_______________________________________________
> > >En-Nut-Discussion mailing list
> > >En-Nut-Discussion at egnite.de
> > >http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
> >
> > _______________________________________________
> > En-Nut-Discussion mailing list
> > En-Nut-Discussion at egnite.de
> > http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
>
>Christian Wieser
>mailto:chwieser at ee.oulu.fi
>
>
>_______________________________________________
>En-Nut-Discussion mailing list
>En-Nut-Discussion at egnite.de
>http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion