rchampe@hubcap.clemson.edu (Richard Champeaux) (10/11/89)
What's the difference between the MC68661 and the MC68681. Both are serial drivers (UARTS). I have the data sheets for the 68661, but I know nothing about the 68681. The 68661, they say, is an enhanced Signetics 2651. I need an RS232 port, and this does everything I need to do it. It's got an internal baud rate generater with 16 baud rates to choose from (as high as 38400 baud), and has all of the necessary RS232 control lines. It has some disadvantages, however. They say it easily interfaces with the 68000, but I don't think I agree with their definition of easy. According to the example circuit they give, interfacing the 68661 to the 68000 without using the 6800 synchronous memory cycle mode (VPA cycle) takes 3 flip-flops, a 4 bit counter, a nor gate, 3 inverters, and an open-collector buffer. Half of the circuit is to insert a wait state, and the other half is to hold off the next access for the 600ns CE\ to CE\ delay time. My definition of easy to interface to the 68000 is that it would accept the 68000 control signals with a maximum of a few gates in between and that it would either generate it's own DTACK or be fast enough to merely use the chip select as the DTACK. I guess the interface circuitry isn't all that bad, but if the 68681 does the same stuff (or more) and is easier to interface, I'd rather use it. So, can anyone tell anything about the 68681? I don't need much info, unless you want to tell me a lot about it. I basically would like to know if it's easier to interface than the 68661, and if it's worth pursuing. Thanks for any help. Rich Champeaux (rchampe@hubcap.clemson.edu)
byron@pyr.gatech.EDU (Byron A Jeff) (10/12/89)
In article <6735@hubcap.clemson.edu> rchampe@hubcap.clemson.edu (Richard Champeaux) writes:
-What's the difference between the MC68661 and the MC68681. Both are
-serial drivers (UARTS). I have the data sheets for the 68661, but I
-know nothing about the 68681.
-
-[describes 68661]
-[describes difficulty interfacing 68661 to 68000]
-
-My definition of easy to interface to the 68000 is that it would accept
-the 68000 control signals with a maximum of a few gates in between and
-that it would either generate it's own DTACK or be fast enough to merely
-use the chip select as the DTACK.
-
-I guess the interface circuitry isn't all that bad, but if the 68681
-does the same stuff (or more) and is easier to interface, I'd rather
-use it.
-
-So, can anyone tell anything about the 68681? I don't need much info,
-unless you want to tell me a lot about it. I basically would like to
-know if it's easier to interface than the 68661, and if it's worth
-pursuing.
68681 is a Dual UART with 68000 async interface. The only control
circuitry you need to hook it up to a 68000 is an address decoder.
It generates it's own DTACK.
It nominally uses a 3.68 and change crystal but I've gotten 9600
using a 3.57 colorburst with no problem. Can't vouch for 19.2 and
38.4 however.
In addition to the 2 serial ports which can be driven by the internal
baud rate generator or by an external clock the chip also provides
an 8 bit output port and a 6 bit input port with edge sensitive
inputs that can generate interrupts. The 68681 supposedly can interface
with the 68000 interrupt vector fetch but to be honest I have never
gotten it to work (so I use autovector interrupts).
My last application with the 68681 was a MIDI sequencer where I used
one of the serial ports as a host port (9600 bps) and the other
as a MIDI port (31250 bps). The midi clock was derived from the system
clock. It worked like a charm (interrupt vector problems notwithstanding).
One caveat from the first time I used it: you must let it generate it's
DTACK in it's own good time. I put it in a 68008 test board that had
a grounded DTACK and the 68681 screwed up it's read FIFOs (4 byte
FIFO) when it didn't get it's DTACK.
Other than that I love it. I'm using 4 of them in my next midi box
(68010, 2 68008s, 1 Meg, 8 Midi ports) but that is another story.
Hope this info helps. Let me know if I can be of any assistance.
BAJ
-
-Thanks for any help.
-Rich Champeaux (rchampe@hubcap.clemson.edu)
--
Another random extraction from the mental bit stream of...
Byron A. Jeff
Georgia Tech, Atlanta GA 30332
Internet: byron@pyr.gatech.edu uucp: ...!gatech!pyr!byronehs@jumbo.dec.com (Ed Satterthwaite) (10/12/89)
In article <9306@pyr.gatech.EDU>, byron@pyr.gatech.EDU (Byron A Jeff) writes: ... > > One caveat from the first time I used it: you must let it generate it's > DTACK in it's own good time. I put it in a 68008 test board that had > a grounded DTACK and the 68681 screwed up it's read FIFOs (4 byte > FIFO) when it didn't get it's DTACK. > Just so if you're running the 68681 on an asynchronous bus, which is what the original poster wanted. But you don't have to wait for DTACK if you are running the '681 synchronously. Maybe everyone knows that, but the data booklet didn't make it entirely obvious to me. The footnotes do let you calculate how long to wait. If I recall correctly, two wait states worked fine for me in a 12.5 MHz system. I believe the bus cycle actually goes somewhat faster in this mode -- DTACK generation is done with the timing of the '681's clock and costs an extra synchronization delay inside the chip. Ed Satterthwaite ehs@src.dec.com {...}!decwrl!ehs
smit@.ucalgary.ca (Theo Smit) (10/12/89)
In article <9306@pyr.gatech.EDU> byron@pyr.UUCP (Byron A Jeff) writes: >.... >In addition to the 2 serial ports which can be driven by the internal >baud rate generator or by an external clock the chip also provides >an 8 bit output port and a 6 bit input port with edge sensitive >inputs that can generate interrupts. The 68681 supposedly can interface >with the 68000 interrupt vector fetch but to be honest I have never >gotten it to work (so I use autovector interrupts). >.... > >BAJ I built a 68000/68681/68440 based system for my thesis project. I used a pair of interrupt-driven circular buffers to handle serial input. The thing that got me the first time was the address decoding and the way the interrupt acknowledge cycle works. I was using the upper 8 address lines for device address decoding, and had a device decoded at 0xffxxxx. During an interrupt acknowledge cycle, the upper 20 address lines are forced high, which selected the device. This then clashed with the 68681 trying to put the vector on the data bus. I then changed the decoding to select nothing during the interrupt acknowledge cycle. Some of my circuit was based on the Motorola ap note, "A terminal interface, printer interface, and background printing for an mc68000 based system using the mc68681 DUART", Motorola application note AN899, 1984. I also used the one describing the 68008 minimum configuration system (AN897). Both of these, however, connect the RS-232 line receiver gates to -12 V - they should be connected to +5V. Have fun. Theo Smit (smit@enel.ucalgary.ca)
albaugh@dms.UUCP (Mike Albaugh) (10/14/89)
From article <14121@jumbo.dec.com>, by ehs@jumbo.dec.com (Ed Satterthwaite): > In article <9306@pyr.gatech.EDU>, byron@pyr.gatech.EDU (Byron A Jeff) writes: > > ... >> >> One caveat from the first time I used it: you must let it generate it's >> DTACK in it's own good time. I put it in a 68008 test board that had >> a grounded DTACK and the 68681 screwed up it's read FIFOs (4 byte >> FIFO) when it didn't get it's DTACK. >> > > Just so if you're running the 68681 on an asynchronous bus, which is what > the original poster wanted. But you don't have to wait for DTACK if you > are running the '681 synchronously. Maybe everyone knows that, but the Just a note here... 680x0's sometimes get _real_upset_ if you give them both DTACK and VPA. The fine print in the manual says "don't do that", but you sometimes end up doing it unintentionally, like adding just one synchronous peripheral to a system that has DTACK grounded or having a device at 0xFFF... that DTACKS, while your autovector stuff is looking at the FC lines and asserting VPA. One of the real bears about this is that _most_ of the time it doesn't seem to matter (works anyway), and then under certain (timing? temp?, phase of moon?) circumstances it just plain weeds the processor. Mike BTW: I personally feel that autovectors are "the way to go" in an "operating system" sort of environment, because interrupt entry/scheduler interactions usually end up sending you through the same place for at least a whole class of devices, but "de gustibus non est disputandum" :-) | Mike Albaugh (albaugh@dms.UUCP || {...decwrl!pyramid!}weitek!dms!albaugh) | Atari Games Corp (Arcade Games, no relation to the makers of the ST) | 675 Sycamore Dr. Milpitas, CA 95035 voice: (408)434-1709 | The opinions expressed are my own (Boy, are they ever)
dwg@bpdsun1.uucp (David W. Glessner) (10/16/89)
In article <6735@hubcap.clemson.edu> rchampe@hubcap.clemson.edu (Richard Champeaux) writes: >What's the difference between the MC68661 and the MC68681. Both are >serial drivers (UARTS). I have the data sheets for the 68661, but I >know nothing about the 68681. The 68681, which is available from Motorola or Signetics, is similar to the Signetics 2681. It is inexpensive and interfaces well with the 68000. Initializing the beast can be fun, but it's not too bad. Hint: We use a 3.6864 MHz crystal for baud rate. It won't always oscillate at the right frequency unless 10-20 pF capacitors are connected from the crystal to ground. See the 68681 and crystal data sheets for more information. -- David quintro!bpdsun1!dwg@lll-winken.llnl.gov uunet!tiamat!quintro!bpdsun1!dwg