Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!mips!pacbell.com!tandem!netcom!mcmahan
From: mcmahan@netcom.UUCP (Dave Mc Mahan)
Newsgroups: comp.sys.m68k
Subject: Re: any 68332 users out there???
Keywords: 68332 TPU
Message-ID: <17079@netcom.UUCP>
Date: 18 Nov 90 23:44:18 GMT
References: <1990Nov15.181309.19556@agora.uucp>
Organization: Dave McMahan @ NetCom Services
Lines: 74


 In a previous article, rickc@agora.uucp (Rick Coates) writes:
>
>Hello! Any 68332 users out there?
>
>I bought the 68332 EVS promo deal, and while it does work (unlike the
>last promo deal from Moto) I have some questions.  The '68332KIT 
>Exercise Manual' has some examples (as well as listing typos!) but
>although all the examples but one use the Time Processor Unit, not one
>seems to use the interrupt capability of the TPU.  Seems kinda strange,
>since TPU applications are probably going to rely on interrupts...

>Here is a listing: what I am trying to do is set up channel 0 as an
>input and interrupt on rising edges.  This works fine if I poll
>the interrupt status register, but fails if I try to use interrupts.
>I have successfully used the interrupt capability of the Programmable
>Interval Timer, so I have gotten the system interrupt to work (for
>example, the Vector Base Register is set to 0 by the debugger).

[  Listing deleted to save space   ]

Well, I managed to get the interrupts working for discrete I/O just last week.
I am looking for any transition instead of just a postive transition like you
are.  I looked at your init code, and it seems ok to me except for the following
things.

1.  You should give channel 0 TPU priority only after you have intialized it
    and requested service.  This ensures that you are really set up before
    actually trying to do something.  I asked Motorola, and they said that
    was the proper way.  I didn't like it either, as it seems a bit screwy.
    What can I say?

2.  You are not clearing the interrupt properly in your interrupt routine.
    As per the TPU manual, revision .9, you should first read the interrupt
    status register, clear the bit from the value you read, and then write
    the modified value back to the interrupt status register.  It should
    look something like this:
      move.w      TPU_ISR,D0
      and.w       #$fe,D0
      move.w      D0,TPU_ISR

    This is documented on page 2-11 of the TPU manual mentioned.  It works for
    me.  Note that as soon as you do your initialization, you will get an
    interrupt from the TPU, even though you haven't really gotten a transition.
    You are supposed to know that this interupt is caused by initialization and
    either ignore it or handle it specially.  I don't enable the interrupt
    until after intialization is complete because I want to ignore the first
    interupt that is caused by such initialization.  If you don't clear the
    interupt as documented, I'm not sure what will happen.  I see that you
    are using the bclr.b opcode.  I don't know if that does what you want, since
    you are only clearing the low order word of the ISR.  The manual talks
    about doing most things coherently, which I take to mean that you should
    operate on words, not bytes when dealing with the TPU.  It should take the
    same amount of time to clear the whole word as compared to the byte, so
    try it with the bclr.w instruction, or use the technique listed above.
    Sometimes those neat little instructions like bclr have side effects that
    are a bit nasty.

3.  You talk about moving the VBR around.  Does your interrupt vectoring take
    that into account?  I haven't played with the VBR at all, so am not sure
    exactly what you can and can't do with it. 

>Rick Coates
>...!tektronix!tessi!agora!rickc


   -dave




-- 
Dave McMahan                            mcmahan@netcom.uucp
					{apple,amdahl,claris}!netcom!mcmahan