16f886 oddity

[Mosaic]

This one cost me 12hrs:

call Gainctrl;  check if sample due, PIDcycleRef period, Tmp1 is unaffected.
	;bsf Beeptime,6 ; task a 50+ms beep
	[B][U]movf PIDcycle,f[/U][/B]
	btfss STATUS,Z ; test results of Gainctrl, skip if zero,else
	return ; if non zero.(sample period timer not done)

Gainctrl ; 
	movf PIDcycleRef,w ; set by PID process control
	subwf PIDcycle,w; this count is updated by ISR.
	btfss STATUS,C ; can compensate for code over 1 ms cycle
	return
	clrf PIDcycle; reset counter if count is met.
	return ;

The first bit of code executes a test of the Z flag. Works on the simulator just fine.
In the real 16f886 hardware, it fails....unless i include the movf PIDcycle,f.

As far as I can tell the Z flag test is supposed to work as there is just the 'return' before the test, yet it fails. I used the beeptask to trace it as ICD can't be used...the pins are occupied.

Can anyone shed any light on this?

 

[be80be]

movf buffer,F ;Force Z bit

 

[Mosaic]

Yes, but why is it required? The Microchip PIC instructions indicate that a clrf Buffer, is enough to set the Z flag.

 

[be80be]

Clrf The contents of register 'f' are cleared and the Z bit is set to 1 is what should happen

 

[be80be]

This is all I could find

29.3.1 STATUS Register as Destination
If an instruction writes to the STATUS register, the Z, C, DC and OV bits may be set or cleared
as a result of the instruction and overwrite the original data bits written. For example, executing
CLRF STATUS will clear register STATUS, and then set the Z bit leaving 0000 0100b in the register

 

[Mosaic]

Very odd....possible bug in the 16f886 firmware version then.

 

[blueroomelectronics]

Post the complete code. I doubt it's a microcode bug.

Personally I'd not do the double returns.

        btfsc STATUS,C ; can compensate for code over 1 ms cycle
	clrf PIDcycle; reset counter if count is met.
	return ;

 

[Mosaic]

I agree about the double return, thx.

Otherwise it's the complete call and return code. Nothing missing.

When I get a chance, I'll code a specific test of that zero flag condition based on this situation, and run it on the PIC.

If u want to post a bit of test code that would verify both conditions, I'd be happy to try it.

 

[Pommie]

Without the read from PIDcycle the zero flag is set on the result of PIDcycle-PIDcycleRef (not the other way around as you might expect). Without seeing a working example it's hard to see what's happening.

Mike.

 

[Mosaic]

Well here's the intention of the code flow, perhaps I'm missing something obvious, hard to edit your own stuff sometimes.


This is the original code that works in ISIS.

call Gainctrl;  check if sample due, PIDcycleRef period, Tmp1 is unaffected.
	btfss STATUS,Z ; test results of Gainctrl, skip if zero,else
	return ; if non zero.(sample period timer not done)

movf PIDcycleRef,w ; set by PID process control
	subwf PIDcycle,w; this count is updated by ISR.
	btfss STATUS,C ; can compensate for code over 1 ms cycle
	return
	clrf PIDcycle; reset counter if count is met.
	return ;

The Gainctrl subroutine is called, then PIDcycle subtracts PIDcycleRef, if carry set then the PIDcycle >= PIDcycleRef, Then 'clrf PIDcycle' happens and a return, else just a return.

'clrf PIDcycle' ought to set the Z flag, upon return 'btfss STATUS,Z' tests this flag.

The problem is without the additional 'movf PIDcycle,f' inserted before the Z flag test the actual 16f886 chip doesn't detect the Z flag as set, based on the clrf PIDcycle.

 

[Pommie]

I'll test this on the actual hardware tomorrow. Today is "Australia Day", a national holiday so I have to go enjoy myself for the rest of the day.

Mike.