rickc@agora.uucp (Rick Coates) (11/16/90)
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).
Any HELP! out there?
Many thanks in advance...
Rick Coates
...!tektronix!tessi!agora!rickc
(assembler listing follows...)
*
* test for input interrupt generation
* 90-11-14 R. Coates
*
*
< ... TPU equates omitted from listing for brevity ... >
00006200 ORG $6200
00006200 33fc 0008 00ff move.w #$0008,TPU_CFSR3 setup channel function: DIO on ch 0
fe12
00006208 33fc 0003 00ff move.w #$0003,TPU_CPR1 channel priority high for 0
fe1e
00006210 33fc 0007 00ff move.w #$7,TPU_PRAM0_0 Detect rising edges on 0
ff00
00006218 33fc 0540 00ff move.w #$0540,TPU_TICR Set for vector address of 0x100
fe08
* Vector priority 5
00006220 21fc 0000 624a move.l #doint,$100 Interrupt vector for ch 0
0100
00006228 33fc 0000 00ff move.w #$0,TPU_HSQR1 Host sequence update on transition
fe16
00006230 33fc 0001 00ff move.w #$1,TPU_CIER Enable interrupt for ch 0
fe0a
00006238 33fc 0003 00ff move.w #$3,TPU_HSRR1 HSR for 0
fe1a
00006240 4286 clr.l d6 clear event counter
start:
00006242 f800 01c0 2100 lpstop #$2100 Wait for interrupt
* (set interrupt level to 1)
00006248 60f8 bra start next interrupt
* interrupt handler
doint:
0000624a 5286 addq.l #$1,d6 increment event counter
0000624c 0c86 0000 0010 cmpi.l #$10,d6 test for equal to 16
00006252 6600 0022 bne.w morewait not yet
00006256 4286 clr.l d6 clear event counter
00006258 307c 6288 movea.w #text,a0 set up message registers
0000625c 327c 6294 movea.w #endtext,a1
* output message
sciloop:
00006260 0839 0000 00ff btst.b #$0,$fffc0c wait for SCI
fc0c
00006268 67f6 beq.b sciloop
0000626a 13d8 00ff fc0f move.b (a0)+,$fffc0f output character
00006270 b2c8 cmpa.w a0,a1 check for end of message
00006272 6600 ffec bne.w sciloop
morewait:
00006276 08b9 0000 00ff bclr.b #0,$fffe21 clear isr
fe21
0000627e 33fc 0001 00ff move.w #$1,TPU_CIER Enable interrupt for ch 0
fe0a
00006286 4e73 rte return from exception
text:
00006288 3136 2020 2045 DC.B '16 Edges'
6467 6573
00006292 0d0a DC.W $0d0a
endtext:
END
===== 0 Error(s)
===== 0 Warning(s)
--
Rick Coates
Consulting H/W - S/W engineermcmahan@netcom.UUCP (Dave Mc Mahan) (11/19/90)
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
gould@motcid.UUCP (Adam Gould) (11/21/90)
This is really Dan DeClerck of Motorola international Subscriber group in Arlington heights, Il. Do all the manipulation of the TPU registers (including HSRV's) before you set the priority, this will get it to work. To get more information mail to me at: uunet.uu.net!motcid!isdgsm!dand Thanks..