Can you use interrupts with hubexec?

Rayman

I'm having more interrupt issues...
Trying to merge two cogs into one by having one be interrupt driven.

But, it seems that having any hubexec calls in the non-ISR code breaks the interrupt system...
Not sure what's going on...

Update: Found the problem! Had nothing to do with interrupts... I had a rdfast in progress and the hubexec call trampled on it...

ozpropdev

Rayman
This code uses cogatn interrupts and hubexec.
Seems to work Ok.
Might be helpful

con
	#56,led0,led1,led2

dat	org

	drvh	#led1
	mov	ijmp1,##isr
	setint1	#14		'int on cpgatn
	loc	ptra,#@blink
	coginit	#1,ptra

main	waitx	##25_000_000 / 20
	call	#hub
	jmp	#main

	orgh	$1000
hub	drvnot	#led0
	ret

	orgh	$2000
isr	drvnot	#led1
	reti1

	orgh	$3000
	org

blink	waitx	##25_000_000 / 2
	drvnot	#led2
	cogatn	#%1	'trigger cog 0
	jmp	#blink

evanh

Beat me to it Brian. Interesting that there's no WAITATN or POLLATN. Shows my lack of experience with interrupts. The IRQ mechanism must somehow clear the event latch then. So they're more interconnected than I thought.

Rayman

Thanks ozpropdev, that should be helpful.

Rayman

I'm also surprised you don't need a WAITATN or POLLATN. Docs don't seem to specify what happens to atn flag...

Rayman

ozpropdev: Are you sure that ATN flag is being cleared?
It seems that interrupts do not activate during waitx instructions...
So, maybe it is possible the interrupt is constantly being called?

Peter Jakacki

Seems you're right about the waitx because out of curiosity I thought I'd try this with the serial rx interrupts in TAQOZ. I told it to do a 4 second WAITX during which time I typed "1234567890". Only the 0 was captured, and only because it was still sitting in the pin register.

TAQOZ# 250,000,000 4 * WAITX ---  ok
TAQOZ# 0 ---  ok

vs a non-waitx delay

TAQOZ# 32,000,000 FOR NEXT ---  ok
TAQOZ# 1234567890

ozpropdev

Rayman wrote: »

ozpropdev: Are you sure that ATN flag is being cleared?
It seems that interrupts do not activate during waitx instructions...
So, maybe it is possible the interrupt is constantly being called?

If the ATN flag was not being cleared the leds would all flash at the same rate.

Rayman

I added in a pollatn check on the atn flag in the ISR like this:

    orgh    $2000
isr 
    pollatn  wc
if_c drvl  #60
    drvnot  #led1
    reti1

This lights up P60 led on eval board.
I think that means that the interrupt does not clear the ATN flag...

Rayman

I just looked up the description of COGATN in the spreadsheet...
Says this:

Strobe "attention" of all cogs whose corresponging bits are high in D[15:0].

"Strobe" sounds to me like pulls ATN down (if up) and then raises it again.
Actually, doesn't "strobe" usually mean to pulse high and the bring low after?

Rayman

Also, I'm now wondering if the interrupt is only triggered by a change in state of the ATN flag from low to high.
I.e., if the ISR doesn't clear ATN flag and returns with flag still high, the interrupt is not triggered again.

cgracey

The ATN event is when that cog's ATN input goes from low to high. The event-flag system actually comes after the event circuitry. The interrupt triggers on just the event. So, if you're just interested in the interrupt, you don't need to worry about the state of the event flag.

Rayman

Ok, thanks. That's a clue as to what's going on here...

What does COGATN actually do? What do you mean be "Strobe" in the spreadsheet?

Rayman

There is something really strange going on with interrupts, waitatn and pollatn…

For example, I don't know why I need a waitatn in my ISR that is triggered by ATN, but I do.
This should have no affect because Chip is saying that the attention trigger of ISR is different than the attention flag.

Also, these two version of the beginning of my ISR should have identical results, I'd think, but they don't:
This one works fine:

ColorSetLoop   
            waitatn              
            modc _set wc  'This is here just to make result of carry identical to the next version that doesn't work right

This one seems to have occasional bad delays:

ColorSetLoop   
          pollatn wc
  if_nc   jmp     #ColorSetLoop

Even stranger, adding a nop before pollatn seems to fix that second version:

ColorSetLoop   
          nop
          pollatn wc
  if_nc   jmp     #ColorSetLoop

It is as if there is some delay between the atn interrupt ISR beginning and the ATN flag being set as seen by pollatn...

Rayman

Here's another clue...
This also works:

ColorSetLoop   
            setq #1
            waitatn

This shows that all the ISR needs to do is clear the ATN flag, it doesn't have to wait for anything.

I think there must be some hidden timeout on the interrupt attention mechanism...
If there are some low number of clocks between COGATN triggers (I think I have 256 clocks between calls), you must manually lower the ATN flag or it won't work...

cgracey

Rayman, I will look into this. I'm not sure what's going on.

Rayman

Thanks.

Seems that during the visible scan line, I'm calling COGATN every 256 clocks or so.
But, looks like my ISR needs about 200 clocks to complete.

So, there's only about 50 clocks between when ISR ends and COGATN is called again.

Rayman

BTW: This hubexec issue seems unrelated to the ISR issue...

My code goes haywire when I make a hubexec call even without any interrupts

Rayman

I see the hubexec problem now...
I've got a rdfast in there that must be getting trampled on by the hubexec call...

evanh

Rayman,
Your snippet had the RETI instruction positioned in ColorInterruptOnly, which appears to be outside the ISR. How was that meant to work? https://forums.parallax.com/discussion/171256/switching-a-cog-from-waitatn-triggered-to-attention-interrupt-triggered/p1