Subject: Re: SCN driver
To: Ian Dall <Ian.Dall@dsto.defence.gov.au>
From: Jon Buller <jonb@metronet.com>
List: port-pc532
Date: 12/03/1996 19:10:27
Ian wrote:

> Yep. The only way I can think of doing this is to toggle the RTS line
> from software. This could be made to work except for the other problem
> I mentioned - that rxintr's can be blocked out due to scsi activity
> and so you couldn't rely on being able to toggle RTS in time. (And I'd
> sooner have a few serial port overruns than a corrupted disk!)
> 
> The only total solution is *really* on the nose. Control RTS in
> software and when the scsi IO starts its block transfer, pre-emptively
> de-assert RTS for all open serial lines. I told you it stank :-).
> Actually, if it weren't for the violation of modularity, this wouldn't
> be so bad. A routine to write to one register in each of 4 duarts would
> run pretty quick, especially if you put pre-calculated addresses and mask
> values in some table. If you want to test for lines being open and
> CRTSCTS then that would slow it down a bit...

Well, that total solution can only be described as YUCK!  Would it
be hard (or even possible) to allow the UART to toggle RTS when,
say 10 bytes were left in the buffer, and then have the interrupt
manually set RTS, and empty the fifo into the buffer, to accept 2
or 3 (or even 13 or 14) more chars from slow responders?  Then when
the buffer drops down to 20 or 30 bytes free, let the UART deal
with RTS again.  That would cut down on most overruns while not
entailing all the pain of dealing with RTS manually and disabling
it during disk activity.  Or is that the obvious thing that's
already being done?

Jon