From: sritchie@cs.ubc.ca (Stuart Ritchie)
Subject: Re: MC68681 DUART help
Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
Date: Thu, 9 Apr 92 08:19:37 GMT

In article <1992Apr8.180456.25022@ucsu.Colorado.EDU> rainer@spot.Colorado.EDU (Rainer Malzbender) writes:
>I think some misinformation has been given out here: there is a big
>difference between disabling the transmitter and disabling the transmitter
>interrupts. The latter is all that is required in the case referred to by
>the original poster.
>
>-- 
>Rainer Malzbender 
>Post-doc, Physics
>U. of Colorado, Boulder (303)492-1366              rainer@shelley.colorado.edu

This succinct response certainly clears it up.  In fact, an
earlier version of my driver did try to disable the transmitter
directly after sending the last byte.  However, I was plagued
with bugs from somewhere else, and incorrectly removed the
transmitter disable code in a debugging effort.  After a few
frustrating hours, I decided to post.

I have implemented both solutions: disabling the transmitter, and
disabling the interrupt.  I agree with gcall@phx.mcd.mot.com (Glen Call)
and bruce@heather.pooh.com (Bruce Robertson)
who stated in a previous post, that disabling the interrupt is bad
because you might stomp on someone else's toes (or incurr overhead
in trying to avoid this).

Since the MC68681 also includes a programmable timer, this situation
might occur quite easily.  Suppose the code that manages the timer
knows nothing about the code that manages the UART.  What's worse,
suppose that the two pieces of code are in different address spaces!
This is exactly the case in my application.

In the case of the MVME188 Hypermodule, the timer interrupt is also
connected to the external output OP3.  So I use this nice alternate
means of controlling the timer interrupt, which doesn't intefere
with anything happening in the UART interrupt mask register (IMR).

Thad Floryan (thad@btr.com) writes:
>The MC68681 is a "Damn Fine Chip" (tm) and I've used tens of thousands of them
>in my commercial products.  Not one problem EVER.
>
>In fact, and this really blew away some Motorola engineers when they saw
>one of my designs, I've even used the MC68681 on MC6803- and MC6809-based
>systems at bauds up to 38400 (again, with not a single problem).
>
>Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]

Maybe my original posting had a tinge of whining in it, but it
was simply due to frustration and stress.  You were right, my
previous experience included Intel stuff.

So without giving away your design, what clock speeds are talking
about here?  Were you able to measure how much time was left over
from the interrupt handlers?

I'm working with the 88100 right now.  It's quite a different ball game.
My kernel handles all device servicing at the user level.  Low level
interrupts are vectored to the appropriate device handlers residing
in a user space task thread.  As an experiment, I vectored the
timer interrupt to a user space thread.  I cranked up the timer to
interrupt 10,000 times per second.  From severe back of napkin
calculations, I deduced that ~60% of CPU time was spent handling
the interrupt.  Working it through further (on another napkin) showed
that about 1,200 cycles were being consumed per interupt.

Hmmm, maybe I should be crossposting to alt.hackers...

...Stuart