rrf INDF - doesn't seem to work properly

[geko]

Google "rrf indf,f"

Which means that I *personally* have not seen it work, but it seems that others have. (Conspiracy theorists may argue differently )

Rotates through indirection work, even on a 16F688, I've used it.

I tried a quick run through of the code you posted on the MPLAB simulator and it behaves as you would expect it too.

Can you post the section of your code where you declare the variables so we can see where things like Fr0End and Fr0Row0 actually reside.

 

[Nigel Goodwin]

Of course I have. I thought that was obvious.

Saying "yes I have" would have been obvious, instead of completely ignoring the question - and taking more words to do it.

 

[Nigel Goodwin]

Rotates through indirection work, even on a 16F688, I've used it.

Thanks for a sensible response Geko

 

[Nigel Goodwin]

#13 ?? (Dealing with an LED matrix, but I don't see any shifting)

13.2, 13.3, and 13.4 all shift, here's the code section for all four directions.

ScrollR8	call	ScrollR
		call	Delay50	
		call	ScrollR
		call	Delay50	
		call	ScrollR
		call	Delay50	
		call	ScrollR
		call	Delay50	
		call	ScrollR
		call	Delay50	
		call	ScrollR
		call	Delay50	
		call	ScrollR
		call	Delay50	
		call	ScrollR
		call	Delay50
		return

ScrollL8	call	ScrollL
		call	Delay50	
		call	ScrollL
		call	Delay50	
		call	ScrollL
		call	Delay50	
		call	ScrollL
		call	Delay50	
		call	ScrollL
		call	Delay50	
		call	ScrollL
		call	Delay50	
		call	ScrollL
		call	Delay50	
		call	ScrollL
		call	Delay50
		return

ScrollU8	call	ScrollUp
		call	Delay50	
		call	ScrollUp
		call	Delay50	
		call	ScrollUp
		call	Delay50	
		call	ScrollUp
		call	Delay50	
		call	ScrollUp
		call	Delay50	
		call	ScrollUp
		call	Delay50	
		call	ScrollUp
		call	Delay50	
		call	ScrollUp
		call	Delay50
		return

ScrollD8	call	ScrollDn
		call	Delay50	
		call	ScrollDn
		call	Delay50	
		call	ScrollDn
		call	Delay50	
		call	ScrollDn
		call	Delay50	
		call	ScrollDn
		call	Delay50	
		call	ScrollDn
		call	Delay50	
		call	ScrollDn
		call	Delay50	
		call	ScrollDn
		call	Delay50
		return

ScrollUp	movf	six, w
		movwf	seven
		movf	five, w
		movwf	six
		movf	four, w
		movwf	five
		movf	three, w
		movwf	four
		movf	two, w
		movwf	three
		movf	one, w
		movwf	two
		movf	zero, w
		movwf	one
		movf	seven1, w
		movwf	zero
		movf	six1, w
		movwf	seven1
		movf	five1, w
		movwf	six1
		movf	four1, w
		movwf	five1
		movf	three1, w
		movwf	four1
		movf	two1, w
		movwf	three1
		movf	one1, w
		movwf	two1
		movf	zero1, w
		movwf	one1
		movlw	0x00
		movwf	zero1
		return

ScrollDn	movf	one, w
		movwf	zero
		movf	two, w
		movwf	one
		movf	three, w
		movwf	two
		movf	four, w
		movwf	three
		movf	five, w
		movwf	four
		movf	six, w
		movwf	five
		movf	seven, w
		movwf	six
		movf	zero1, w
		movwf	seven
		movf	one1, w
		movwf	zero1
		movf	two1, w
		movwf	one1
		movf	three1, w
		movwf	two1
		movf	four1, w
		movwf	three1
		movf	five1, w
		movwf	four1
		movf	six1, w
		movwf	five1
		movf	seven1, w
		movwf	six1
		movlw	0x00
		movwf	seven1
		return

ScrollL		bcf	STATUS, C
		rlf	zero1, f
		rlf	zero, f
		bcf	STATUS, C
		rlf	one1, f
		rlf	one, f
		bcf	STATUS, C
		rlf	two1, f
		rlf	two, f
		bcf	STATUS, C
		rlf	three1, f
		rlf	three, f
		bcf	STATUS, C
		rlf	four1, f
		rlf	four, f
		bcf	STATUS, C
		rlf	five1, f
		rlf	five, f
		bcf	STATUS, C
		rlf	six1, f
		rlf	six, f
		bcf	STATUS, C
		rlf	seven1, f
		rlf	seven, f
		return

ScrollR		bcf	STATUS, C
		rrf	zero1, f
		rrf	zero, f
		bcf	STATUS, C
		rrf	one1, f
		rrf	one, f
		bcf	STATUS, C
		rrf	two1, f
		rrf	two, f
		bcf	STATUS, C
		rrf	three1, f
		rrf	three, f
		bcf	STATUS, C
		rrf	four1, f
		rrf	four, f
		bcf	STATUS, C
		rrf	five1, f
		rrf	five, f
		bcf	STATUS, C
		rrf	six1, f
		rrf	six, f
		bcf	STATUS, C
		rrf	seven1, f
		rrf	seven, f
		return

 

[LabRat]

Rotates through indirection work, even on a 16F688, I've used it.

I tried a quick run through of the code you posted on the MPLAB simulator and it behaves as you would expect it too.

Can you post the section of your code where you declare the variables so we can see where things like Fr0End and Fr0Row0 actually reside.

Should be at the top of the file ...


(did you remove the call to call BlinkStatus just after the cmdLeft label? With this call present (causing delays), the code works. Without it.. it fails. I say delay as I had also tried replacing this with 4 calls to wait1ms, and the code would then work)

A.

 

[Pommie]

Sorry Nigel, You are out of order. I did not ignore the question.

You asked, Does it work?

And I replied "of course it works"

Nothing ambiguous there.

Mike.

 

[LabRat]

13.2, 13.3, and 13.4 all shift, here's the code section for all four directions.

Ahh... didn't realize there was additional content in the zip archive(s).
So you are rotating via direct addressing of each cell. I considered this, but it would mean 96 addresses. I'm not going to rule it out however, if I can't track down the how/why my other rrf isn't working properly.

 

[LabRat]

Rotates through indirection work, even on a 16F688, I've used it.

I tried a quick run through of the code you posted on the MPLAB simulator and it behaves as you would expect it too.

Can you post the section of your code where you declare the variables so we can see where things like Fr0End and Fr0Row0 actually reside.

Realized you may not have pickedup the ASM file.. here's the variable declarations:

	; -------------------
	; BANK0 Memory Block
	; -------------------        
	CBLOCK 0x20
		smSTATE		; ADDR of State Machine handler
		cmdPENDING	; Pending commands require a PAYLOAD to exist before
					; we do anything, this variable records what command
					; is "pending" when the payload is completly loaded.
					; Value of the PENDING command
					; Note PENDING_0 = PikC CONFIG
					;      PENDING_5 = Frame BANK0
					;      PENDING_6 = Frame BANK1
		payloadCount; # of bytes remaining to received in the payload.
		rxBYTE		; Command Byte received (not sure this is needed)
		pikcADDR		; For matching address from the TRIX-C commands
		gSTATUS		; 8 Bits of globals
		
		; Top of "Image Frame"
		Fr0Row0:6		; Point to start of the buffer
		Fr0Row1:6
		Fr0Row2:6
		Fr0Row3:6
		Fr0Row4:6
		Fr0Row5:6
		Fr0Row6:6
		Fr0Row7:6
		Fr0End:0		; Point to the end of the buffer, for reverse access

; Debug	
		dumpChar

; Wait/Loop timer/counters
		COUNT
 		timer

        end_bank_0_vars:0	
	ENDC
    if end_bank_0_vars > 0x70
              error "Bank0 variable space overrun"
    endif

	; -------------------
	; BANK 1 Memory Block
	; -------------------
	CBLOCK 0xA0
		Fr1Row0:6		; Point to start of the buffer
		Fr1Row1:6
		Fr1Row2:6
		Fr1Row3:6
		Fr1Row4:6
		Fr1Row5:6
		Fr1Row6:6
		Fr1Row7:6
		Fr1End:0		; Point to the end of the buffer, for reverse access
        
        end_bank_1_vars:0	
	ENDC
    if end_bank_1_vars > 0xF0
              error "Bank1 variable space overrun"
    endif

	; -------------------
	; Global Memory Block
	; -------------------
	CBLOCK 0x70
        wsave   ; Save W, STATUS, and PCLATH on entry to interrupt
        ssave   
        psave
		fsrsave
		temp
		; --- The rxBuffer --- 
		; Multi-Purpose RAM space
		; For Roll Left/Right
		;   rxBuffer:0 = Row Counter
		;   rxBuffer:1 = Column Counter
		;   rxBuffer=4 = Frame1 Input Data
		;   rxBuffer=6 = Frame0 Input Data
		; For Roll Up/Down 
		;   rxBuffer[0..5] = Incoming Data
		rxBuffer:0
			row_count:1
			column_count:1
			bitShifter:1
			voldemort:1		; The BYTE that shall not be named
			input1:1
			input2:0		; Maps onto rxBufferEnd
		rxBufferEnd:1 		; Point to last BYTE of rxBuffer
; MemCopy
		memcpy_i
		memcpy_a
		memcpy_b
        end_global_vars:0	
	ENDC
    if end_global_vars > 0x80
              error "Global Variable Space overrun"
    endif

 

[geko]

Well I've ultra-cut your code down to the that in the attached file and it shifts as you'd expect it to in the MPLAB simulator.

I'm not going to get home tonight so I can't try it on the real thing which I guess is the next step.

Realized you may not have pickedup the ASM file.. here's the variable declarations:

I spotted your code attachment after the last post. Just out of interest, why have you commented the FSR save and restore lines out of the ISR?

 

[Nigel Goodwin]

Sorry Nigel, You are out of order. I did not ignore the question.

You asked, Does it work?

And I replied "of course it works"

Nothing ambiguous there.

Perhaps Australians have a different definition of 'ambiguous'? - certainly from an English point of view your answer is very ambiguous, giving the impression that you think it should but have never actually tried it. 'Yes it works' is one word less, and not ambiguous at all, as is 'of course it works, I've done it loads of times'.

 

[LabRat]

I spotted your code attachment after the last post. Just out of interest, why have you commented the FSR save and restore lines out of the ISR?

Paranoia - I was wondering if the ISR was causing corruption of the FSR. So I commented those lines out... and then went further to comment out the start of the timer (and thus the ISR altogether is now redundant code).

Well I've ultra-cut your code down to the that in the attached file and it shifts as you'd expect it to in the MPLAB simulator.

I'm not going to get home tonight so I can't try it on the real thing which I guess is the next step.

Ok.. I'm curious how your "real thing test" would work (unless you mean testing the full code). Unless you have the 16F688 ICD dongle thingy. What method would you use to validate that the shift was working? (My method was copy the results to eeprom, and then read those back). Which means the fault *could* have been with the copy to eeprom, but I think I've persuaded myself that this isn't the case. If I stored a known constant in the array, and then did the copy, I saw the expected results. If I read the value, write it back to the array, then did the copy, I saw the expected results. It's just that fardling shift right...

It's odd that doing two shift-rights, resulted in the same 0x10 data.. I haven't tried two shifts *with* the delay.. there may be something else in there as well. (more as I investigate tonight).

 

[Nigel Goodwin]

Ahh... didn't realize there was additional content in the zip archive(s).
So you are rotating via direct addressing of each cell. I considered this, but it would mean 96 addresses. I'm not going to rule it out however, if I can't track down the how/why my other rrf isn't working properly.

I stopped listing full assembler on the pages as the code got longer, and just listed particularly relevent bits, with the full code in a ZIP download.

Direct addressing might be 'nasty' but the RISC architecture of the PIC very often is, and direct addressing is faster.

 

[LabRat]

I stopped listing full assembler on the pages as the code got longer, and just listed particularly relevent bits, with the full code in a ZIP download.

Direct addressing might be 'nasty' but the RISC architecture of the PIC very often is, and direct addressing is faster.

Hard coded the address of the last byte in the array (0x55), and had the loop exit after a single iteration. 0x10 (not the desired value (0x40)).

It's a weird one for sure...

 

[Mr RB]

Check for bank switching issues when you read or write (or indirectly rotate ) any variables.

 

[LabRat]

Ok.. I can demonstrate that the shifting is working, so the corruption MUST be happening at some point after that. Use of carefully placed "infinite loops" allows me to see that after the shift, but before processing another serial packet, the data was correct.

(very slow progress)

 

[LabRat]

AAAAAGHHHHH..... (translated - I figured it out)

"It was almost like it was shifting things 3 times instead of 1"

Answer - because it was.

The program on the PC (BASIC file) does not align with the functionality of the corresponding executable. So my request to Tx a single command, resulted in (you guessed it) three copies of the command being sent to the PIC.

(sound of my head pounding on the table) So this has been working properly for days... (ugh)

Thanks everyone who layed eyes on, and provided some suggestions. I was going around the bend on this one.

Thx again.