Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site amdcad.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!amdcad!phil
From: phil@amdcad.UUCP (Phil Ngai)
Newsgroups: net.arch
Subject: Re: Bad devices (timing loops)
Message-ID: <10527@amdcad.UUCP>
Date: Tue, 11-Mar-86 21:42:32 EST
Article-I.D.: amdcad.10527
Posted: Tue Mar 11 21:42:32 1986
Date-Received: Thu, 13-Mar-86 07:47:19 EST
References: <374@mips.UUCP> <38@gilbbs.UUCP> <10526@amdcad.UUCP>
Reply-To: phil@amdcad.UUCP (Phil Ngai)
Distribution: net
Organization: AMD, Sunnyvale, California
Lines: 22


By the way, I think I've said this before but maybe some of the people
in this discussion didn't see it: I have designed several board level
products (Multibus) with the SCC and had no trouble using it. I was
able to hide the cycle recovery time from the programmer at no cost by
being clever in a state machine which was already needed for other
timing purposes. I do not consider the timing requirements of the SCC
to be unusually difficult to meet even without considering all the
*good* points of the SCC, something which seems to have been quite
overlooked in this discussion. How about two channels, two clock
generators, two programmable baud rate generators (up to 76.8 Kb
async), full modem control, vectored interrupts, byte synchronous, bit
synchronous, DMA, relatively large input fifo, and all in a 40 pin
package?
-- 
 "We must welcome the future, remembering that soon it will become the
  present, and respect the past, knowing that once it was all that was
  humanly possible."

 Phil Ngai +1 408 749 5720
 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil
 ARPA: amdcad!phil@decwrl.dec.com