From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2001-11-06 18:43:46
Hi!
On Tue, Nov 06, 2001 at 12:10:06PM +0100, groepaz wrote:
> no ;o) the current "driver" keeps RTS _always_ on, unless you want to
> get a byte from the serial line, for that matter it drops the RTS line
> to low for a few cycles (enough for a character to arrive) and then
> reads the character.
This does not sound very good either, since it places a high interrupt load on
the other side of the link. Real operating systems have an interrupt triggered
on a state change of CTS (which is connected to the RTS by the null modem
cable), so you effectively double the number of interrupts generated on the
remote side. And you will disable the transfer while your application is not
polling the UART so your effective transfer rate may be a lot slower than
necessary, even if the CPU would on average be able to keep up with the
incoming characters.
> yes, true.... well... like i said before, i have never ever used a
> different method in plenty of years doing that kinda datatransfer crap
> so i'd say, unless you are writing sth like a "real" high-performance
> driver for an operating system or so, you can get of with polling
> pretty well ;o) (and yes, for sth like a terminal-program its probably
> not the worst thing to use interupts either ;=))
I've written interrupt driven code for this chip on several platforms, so I do
of course believe that it's the only real way to do it:-)
The 16550 is quite friendly to the programmer and it is not very difficult to
use interrupts for sending and receiving, so - apart from the additional space
for the send and receive buffers - I see no real reason for polling.
Regards
Uz
--
Ullrich von Bassewitz uz_at_musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:44 CET