OT: More MPLAB program problems

A reasonable guess for these symptoms would be that swcount is not actually pointing to ram and it is rather hard to alter rom.

TI9900 series could get into that sort of bind if it ever ended up with all of its registers in ROM (including the program counter).

BTW If you described what the intention of the code was instead of adding cryptic crossword clues here and there and missing out crucial details like the symbol definitions then it would be easier to help.

TBH I think you would be better off with a more suitable chip that had enough hardware capacity to do the job properly. Maybe even copying the data to RAM so that you can do lookups much faster with FSR.

--
Regards, 
Martin Brown
Reply to
Martin Brown
Loading thread data ...

Problems.

Code snippet #1: CLRW ADDWF swcount,W ; count to W BTFSC STATUS,Z ; zero count = divide by zero ==> value as zero GOTO BY1 DECF swcount,W ; count = 1 ** Neither W nor swcount change; WTF? ; assembles to 0x032A which decodes to DECF direction "W", swcount. BTFSC STATUS,Z GOTO BY1 DECF swcount,W ; count = 2 ** ditto BTFSC STATUS,Z GOTO BY2 DECF swcount,W ; count = 3 ** ditto BTFSC STATUS,Z GOTO BY35 DECF swcount,W ; count = 4 ** ditto BTFSC STATUS,Z GOTO BY4 BY35: CLRW MOVWF ampres ; dividend MOVF swcount,W ; count = 5 or 3 to W BCF STATUS,C ; clear carry bit for rotate

RLF amplo RLF amphi ; MPLAB error message "Argument out of range. Least significant bits used" ; assembled to 0x0280 or SUBWF with destination "F", BUT zero for F (amphi at 0x27) WTF? SUBWF W,amphi ; want results in amphi (d=1) BTFSS STATUS,C ; if carry, result is negative so no count INCF ampres RLF ampres ; bit 7 done,ready for next

END snippet #1

Code snippet #2: ;;;** tab4, tab5 locations considered as invalid... T4L: BTFSC K1.4,0 ; Wave enable input, 1 => enabled GOTO T5L ; skip lookup code when disabled MOVLW High(tab4) MOVWF PCLATH CALL tab4 ; far call ADDWF amplo ; add lookup value to amplitude BTFSC STATUS,C INCF amphi INCF swcount

T5L: BTFSC K1.5,0 ; Wave enable input, 1 => enabled GOTO DIV ; skip lookup code when disabled MOVLW High(tab5) MOVWF PCLATH CALL tab5 ; far call ... ; ---------------------------------------------- tab1: ; TABLE SUBROUTINE MOVLW High(tab1_data) ADDWF timhi,W MOVWF PCLATH MOVLW Low(tab1_data) ADDWF timlo,W BTFSC STATUS,C INCF PCLATH,F MOVWF PCL ; computed GOTO into data ; ------------------ tab1_data: ; ---------------------------------------------- tab1 RETLW 0x01 ; [1] ... RETLW 0x01 ; [768] ; ---------------------------------------------- tab2: ; TABLE SUBROUTINE MOVLW High(tab2_data) ADDWF timhi,W MOVWF PCLATH MOVLW Low(tab2_data) ADDWF timlo,W BTFSC STATUS,C INCF PCLATH,F MOVWF PCL ; computed GOTO into data ; ------------------ tab2_data: ; ---------------------------------------------- arbitrary RETLW 0x01 ; [1] ... etc for tab3, tab4, and tab5 Program easily fits in 0xFD3 space (under 0xFFF limit).

Help?

Reply to
Robert Baer

That works but you can test swcount for zero in just one instruction like this: movf swcount,f ; move to itself just updates Z flag

Since swcount is not the dest then of course it will not change. You said swcount was 1 going in. Since W is the dest it will be zero after decrementing one.

You could try it the other (correct) way around, as in: subwf amphi,f ; dest is file (d=1)

piglet

Reply to
piglet

Piglet has already pointed out the correct answer to this.

swcount is unchanged because that is what you have asked for. W is loaded with swcount-1

Enter the routine with swcount=5 and you will see more clearly.

I suspect it is baulking at syntax here. Try

SUBWF amphi

which has assmebled OK further down.

My hunch is that the code map has gone beyond the ROM size or there is something mangled in the declaration of the higher labels. Try halving the length of all lookup tables to be sure it will fit in ROM. The map file might show where things have gone awry.

I'd be more inclined to do all the tricky arithmetic in one code page taking time, and active table and longjump to the tables rather than doing a far call to duplicate code in every table. The you need routines to lookup next and previous samples once they are initialised.

BTW you might find it helpful to have your lookup tables in reverse temporal order and count time from t=Tmax down to zero.

Saves a comparison if you do it right.

--
Regards, 
Martin Brown
Reply to
Martin Brown

  • 0x032A decodes to DECF loc(swcount) .. see below: LIST p=P16F648A ;; * header stuff removed.. ; VARIABLES timhi EQU 0x20 ; time pointer (0-1023) timlo EQU 0x21 COUNT1 EQU 0x22 ; delay counter COUNT2 EQU 0x23 COUNT3 EQU 0x24 sSTATUS EQU 0x25 sW EQU 0x26 amphi EQU 0x27 amplo EQU 0x28 ampres EQU 0x29 swcount EQU 0x2A ;
  • 1) The PIC16F648A cannot work with the FSR, 2) my data for access is in the form of RETLW and 3) my data tables are rather large (~1K).

Would you be so kind as to also address the other problems?

Reply to
Robert Baer

My guess is the period "." has a reserved meaning and that is what throws the assembler. Try "K1pt4 EQU RB7" instead?

piglet

Reply to
piglet

  • nice trick! Thanks.
  • I said that W did not change (either), and that is the why of my WTF.
  • Thanks; will try. That worked. Thanks again.
  • Found out after some more research, that the complaint was about K1.4 only. Early statement in code is "K1.4 EQU RB7" so that really is referring to RB7. So.. WTH is bad about RB7 when the others (RB3, RB2, RB0, and RB6) are OK?
Reply to
Robert Baer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.