Hi Hauke,

"User for realtime audio" <audiodev@ind.rwth-aachen.de> wrote in message
news:4056AA2E.1020104@ind.rwth-aachen.de...
> Hello Community,
> I am writing software for a sharc DSP, 21065L that uses the serial port
> 16550D connected to a PC-serial adapter.
> I have full access to the serial port.
>
> My question now is the following:
>
> How exactly does the transmission work?
>
> In my routines I wait for the CTS signal to be set once at the beginning
> and that shows me that a device is generally connected.
> After that I wait for the interrupts for receiver data available and
> transmitter empty. Whenever such signal occurs I do obtain a byte or
> write back a byte.
>
> This works unless I do not load the transmission with high traffic.
> In these cases after a while the transmission stops to work.
>

The 16550 has receive and transmit FIFOs and variable interrupt thresholds
(e.g., it will generate an interrupt when it has received 1, 4, 8, or 14
bytes). For optimum performance you should enable the FIFOs and set the
thresholds high. Then after you get the receive interrupt you should execute
a tight loop that polls the status (to see if there is more data) and
receives it. Thus you receive (and send) bursts of data on each interrupt.

> My impresion is that one of the two sides can not follow the other and
> therefore the transmission receives internal overflows.
> So the question is: Do I have to cope with line signals such as
> CTS or DSR also during the transmission?
>
> WIll the far end somehow tell me that the receiving FIFO is close to
> overflow condition by setting a line?

Oftern the RTS/CTS or DTR/DSR lines are used for flow control. Given the
standard 115kbps rate and a decent PC with properly written software the PC
side should not overflow. If the software is running on Windows you can
specify the type of input/output flow control in the call to the
SetCommState() function. Also make sure you allocate large enough buffers
with SetupComm() and you set appropriate timeouts with SetCommTimeouts(). It
is also a good idea to have a separate thread handle the communication while
other threads run the user interface and the data processing.

If appropriate, consider framing the data (e.g, start byte, length, data,
crc, stop byte) so you can detect when something goes wrong and possibly
resynchronize.

Regards,
-- Georgi

"User for realtime audio" <audiodev@ind.rwth-aachen.de> wrote in message
news:4056AA2E.1020104@ind.rwth-aachen.de...
>
> My impresion is that one of the two sides can not follow the other and
> therefore the transmission receives internal overflows.
> So the question is: Do I have to cope with line signals such as
> CTS or DSR also during the transmission?
>
> WIll the far end somehow tell me that the receiving FIFO is close to
> overflow condition by setting a line?

CTS means "clear to send" does that help?  It seems that would suggest an
answer both of these questions.  RTS "request to send".......

Maybe check out a serial port driver in the open source world??  There's
lots of information on the web.

Fred

On Tue, 16 Mar 2004 08:18:06 +0100, User for realtime audio
<audiodev@ind.rwth-aachen.de> wrote:

>Hello Community,
>I am writing software for a sharc DSP, 21065L that uses the serial port 
>16550D connected to a PC-serial adapter.
>I have full access to the serial port.
>
>My question now is the following:
>
>How exactly does the transmission work?

It works differently with different application software.

>In my routines I wait for the CTS signal to be set once at the beginning
>and that shows me that a device is generally connected.
>After that I wait for the interrupts for receiver data available and 
>transmitter empty. Whenever such signal occurs I do obtain a byte or 
>write back a byte.
>
>This works unless I do not load the transmission with high traffic.
>In these cases after a while the transmission stops to work.
>
>My impresion is that one of the two sides can not follow the other and 
>therefore the transmission receives internal overflows.
>So the question is: Do I have to cope with line signals such as
>CTS or DSR also during the transmission?

That depends.  There is no standard on how these control lines are
used.  Some systems expect immediate response (i.e. stop sending) when
a control line is turned off.  Others allow up to 16 characters more.
You need to examine the particular systems involved and determine what
sort of handshaking they are using.  We can't do it for you because it
is done differently in so many places.


>WIll the far end somehow tell me that the receiving FIFO is close to 
>overflow condition by setting a line?

Maybe, maybe not.


-Robert Scott
 Ypsilanti, Michigan
(Reply through this forum, not by direct e-mail to me, as automatic reply address is fake.)

Hello Community,
I am writing software for a sharc DSP, 21065L that uses the serial port 
16550D connected to a PC-serial adapter.
I have full access to the serial port.

My question now is the following:

How exactly does the transmission work?

In my routines I wait for the CTS signal to be set once at the beginning
and that shows me that a device is generally connected.
After that I wait for the interrupts for receiver data available and 
transmitter empty. Whenever such signal occurs I do obtain a byte or 
write back a byte.

This works unless I do not load the transmission with high traffic.
In these cases after a while the transmission stops to work.

My impresion is that one of the two sides can not follow the other and 
therefore the transmission receives internal overflows.
So the question is: Do I have to cope with line signals such as
CTS or DSR also during the transmission?

WIll the far end somehow tell me that the receiving FIFO is close to 
overflow condition by setting a line?

It is not easy to debug this stuff because I have written everything in 
assembly language and the complete system only has the described problem 
with high traffic and thus while working in full speed.

Thanks in advance and best regards,
Hauke