8051 RS232 with RTS/CTS?
Doug Wendelboe
controls (RTS/CTS and maybe also the DSR/DTR lines) on an 8051-based device.
The 8051 must communicate with a much faster host, and therefore must hold
off received data when the input buffer is nearly full. I remember reading
about suggested buffer % levels for hold-off and restart (e.g. hold-off at
90% full, restart data when buffer empties to 20%).
Any information or examples appreciated.
Steve Fairhead
news:rw8j9.122$mP2....@news.uswest.net...
Erm... ok, I'll bite. For reception:
- Use a circular buffer (of whatever size you can afford).
- Use two indexes, both incrementing: one for where to put received data,
and the other for where to get data from the buffer. Both rollover to 0, and
both start at 0.
- Maintain a count of how many characters are in the buffer (i.e. received
but not retrieved from the buffer). Limit the count to the size of the
buffer.
- Enable hardware flow control signals at startup. Monitor the chr count;
if above a high threshold turn off the flow control signals; if below a low
threshold turn 'em back on again. I'd suggest 75% and 25% (defined as
constant counts), but calculate thresholds according to data rate and flow
control signal recognition latency (also note that some devices transmit in
packets and monitor the flow control signals only periodically).
- Optionally transmit software flow control signals as well (XON/XOFF) on
transitions.
For transmission, it's easier: you probably wouldn't want a tx buffer anyway
(the task generating data should probably be sensitive to whether or not
transmission is appropriate).
Yell if I've missed the point of your question :).
Steve
--
http://www.sfdesign.co.uk - SFD: Solutions by Design
http://www.fivetrees.com - ecommerce for independent musicians
bh
Many async comms between micros and hosts (at least in my work) do not use
either HW or XON/XOFF flow control. I would first determine if flow control
is necessary. Next step is software flow control. Hardware flow control is
dead last. You do not want to waste I/O pins on HW flow control.
If you have control over the high level protocol, you may want to consider
doing something where all commands are acknowledged somehow. This is a form
of software flow control. Make sure the rx buffer is big enough for one
command, and then that command is acknowledged, indicating the buffer is
free again.
Charles Ader
implement it with an embedded processor.
Because universal standards have never been adopted by the people using
asynchronous serial communications it is impossible to know how to
make a generic choice between the various methods.
For this discussion lets call your 8051 design the "target" and
what you connect it to the "host".
Most of the hosts you will connect to will offer from none to full
status line support. If we limit you hosts to just IBM-PC serial ports
then you get all the status lines. If we further limit the OS to
Windows then the standard drivers support both hardware (RTS/CTS) and
software (XON/XOFF) flow control.
Flow control using software makes the smallest demands on the hardware
of an embedded system. But this comes at the price of a more complex
serial port handler. If you need to send non-ASCII (binary) you will
need to implement a protocol that can "escape" the XON and XOFF codes
for the binary payloads.
Flow control using hardware (RTS/CTS) will require at least two
pins from the 8051. This will allow a simpler serial port handler.
Sending non-ASCII data is not affected by this flow control method.
The high and low water marks used to manage the flow control depend
in a lager part on just how much through put you 8051 can manage.
If you 8051 has high through put the buffers can be small and the
trip points can be set a very close to full and empty.
If you 8051 has low through put the buffers must be large and the
trip points should be set far from full and empty.
Through put is really just what bit rate you need to run at and
how fast your 8051 can process the input and respond.
The flow control method you use depends on what your 8051 needs to
do, what kind of data needs to be processed, and what kinds of
responses are required.
You can get a feel for where to set your buffer size and trip
points by looking the number of bytes per second your 8051 can
process verses how many bytes per second the host can send.
To get a more specific answer you may need to offer a more
detailed description of what you need to accomplish.
Charles.
"Doug Wendelboe" <d...@penn-micro.com> wrote in message
news:rw8j9.122$mP2....@news.uswest.net...
Everett M. Greene
> will be doing, I would suggest at least a 1k receive buffer always
> free, i.e. set the handshake signal to BUSY when there is <1k bytes
> space left in your buffer.
This seems quite excessive, especially if one has only 512
bytes total of RAM available.
> A lot of equipment out there has been designed on the assumption that
> it can overrun the signal by 512 bytes without the other end losing
> data.
It would be best to avoid having anything to do with equipment
making any such ridiculous assumption.
Charles Ader
news:20020923.7...@mojaveg.iwvisp.com...
It's not really that bad an assumption. The 16C950 class UART seems
to be getting popular and it has a 512 byte FIFO.
Matthew S. Staben
You might try offloading to a different UART+FIFO chip, and tying an
external IRQ to the RS-232 chip. This way, you're free to keep
processing other stuff and letting the external chip monitor the flow
levels -- and also, you can allow the communications throughput to be
set at 115,200 even though you can't possibly receive, or send at this
rate with the lowly 8051, but since you'll be using the UART's FIFO
mode it is possible. Unfortunately however, data will "spurt" but
it'll still be highly compatible with all your other processes and the
flexibility achieved helps.
Matt
Ulf Samuelsson
"Doug Wendelboe" <d...@penn-micro.com> skrev i meddelandet
news:rw8j9.122$mP2....@news.uswest.net...
To be PC compatible, any unit must have at least 16-17 bytes left when
they try to deassert the RTS/CTS, since the PC16550 will ignore the
flow control until the 16 byte transmit FIFO is empty.
--
Best Regards
Ulf at atmel dot com
These comments are intended to be my own opinion and they
may, or may not be shared by my employer, Atmel Sweden.
Jan-Hinnerk Reichert
Remember that the host can not send faster than the bitrate (even it is a
Petium IV 2GHz).
So the worst case is 115.200Baud 8N1, i.e. you get at most 11520 Bytes per
second. This gives you 694 cycles at 8MHz per byte. Depending on the type
of your processor this is something between 57 and 694 instructions.
That could be enough for your application.
The easiest way to buy you time is to decrease the bitrate, but this is also
increasing data latency.
Jan-Hinnerk Reichert
> To be safe, and without knowledge of exactly what the other device
> will be doing, I would suggest at least a 1k receive buffer always
> free, i.e. set the handshake signal to BUSY when there is <1k bytes
> space left in your buffer.
>
> A lot of equipment out there has been designed on the assumption that
> it can overrun the signal by 512 bytes without the other end losing
> data.
You are missing an important point here. The buffer is not filled at input
rate, but at (input rate minus processing rate).
So, if the device is almost capable of processing the data in real time, a
much smaller buffer is needed.