thanks for that henrik I never thought to look at how dt ints works . dt's code leaves nothing to chance ,I'm left humbled again
thanks for that henrik I never thought to look at how dt ints works . dt's code leaves nothing to chance ,I'm left humbled again
Guys,
about Darrel code I could put my hand on fire.
about my code I can bet there are bugs ...
but with your help now I have everything clear and know where problems can be or not. I have DTint and other ISR where I'll take care about FSR and TBLPTR.
so, many thanks again for your support !
bye
Marco
Hi Richard,
maybe I'm doing some confusion and about to say something of funny, but I have a doubt:
How do you ensure in this code that you are in the correct bank reading the address of "buffer" ?
Code:ASM Flash2Ram macro buffer, msg ; Fills the buffer from flash msg movlw UPPER msg movwf TBLPTRU movlw HIGH msg movwf TBLPTRH movlw LOW msg movwf TBLPTRL movlw low buffer movwf FSR2L movlw High buffer movwf FSR2H L?CALL _bfill endm ENDASM
buffer does not actually exist its just a label in the macro , when assembled
@ Flash2Ram _buff , _String1 , produces
the label "buffer" is replaced with the symbol of the intended targetCode:000168 0E00 M movlw UPPER _String1 0016A 6EF8 M movwf TBLPTRU 00016C 0E01 M movlw HIGH _String1 00016A 6EF8 M movwf TBLPTRU 00016C 0E01 M movlw HIGH _String1 00016E 6EF7 M movwf TBLPTRH 000170 0E3E M movlw LOW _String1 000172 6EF6 M movwf TBLPTRL 000174 0E1A M movlw low _buff 000176 6ED9 M movwf FSR2L 000178 0E00 M movlw High _buff 00017A 6EDA M movwf FSR2H M L?CALL _bfill
at no stage do we actually write directly to the "buffer" we simply load its address (from the symbol table) into the fsr regs
the bfill subroutine then fills the "buffer" indirectly via the fsr regs
macro's are not subroutines they are just another shortcut way to save typing, every time the macro is encountered the real code as above is inserted into your program
Last edited by richard; - 20th April 2015 at 15:31.
Yes, but while _String1 is a fixed address that point to a univoque ROM location, isn't _buff a RAM location that points to different register according to the current bank ?
Marco
evidently I'm not explaining it well
we never write directly to _buff we do it 'indirectly' via the 16 bit full address in fsr2 its called INDIRECT ADDRESSING read the chapter in the data sheet ,(this is how pic18's have arrays that can be bigger than a ram bank)
bank select is not applicable to indirect addressing
observe symbol table
Code:inbuff var byte[30] buff var byte[30] $500SYMBOL TABLE
LABEL VALUE
_STVREN_OFF_4L 000000FE
_STVREN_ON_4L 000000FF
_StartLoop 00000168
_String1 0000013E
_String2 00000150
_TRISH 00000F94
_TRISL 00000F93
_WDTEN_OFF_2H 000000FE
_WDTEN_ON_2H 000000FF
_WDTPS_1024_2H 000000F5
_WDTPS_128_2H 000000EF
_WDTPS_16384_2H 000000FD
_WDTPS_16_2H 000000E9
_WDTPS_1_2H 000000E1
_WDTPS_2048_2H 000000F7
_WDTPS_256_2H 000000F1
_WDTPS_2_2H 000000E3
_WDTPS_32768_2H 000000FF
_WDTPS_32_2H 000000EB
_WDTPS_4096_2H 000000F9
_WDTPS_4_2H 000000E5
_WDTPS_512_2H 000000F3
_WDTPS_64_2H 000000ED
_WDTPS_8192_2H 000000FB
_WDTPS_8_2H 000000E7
_WRT0_OFF_6L 000000FF
_WRT0_ON_6L 000000FE
_WRT1_OFF_6L 000000FF
_WRT1_ON_6L 000000FD
_WRT2_OFF_6L 000000FF
_WRT2_ON_6L 000000FB
_WRT3_OFF_6L 000000FF
_WRT3_ON_6L 000000F7
_WRTB_OFF_6H 000000FF
_WRTB_ON_6H 000000BF
_WRTC_OFF_6H 000000FF
_WRTC_ON_6H 000000DF
_WRTD_OFF_6H 000000FF
_WRTD_ON_6H 0000007F
_XINST_OFF_4L 000000BF
_XINST_ON_4L 000000FF
__18F45K20 00000001
_bfill 0000022C
_buff 00000500
_inbuff 0000001A
main 000000EA
pauseloop 000000A6
pauseusloop 000000C2
ser2delay 0000007C
serout2bit 0000004E
serout2done 0000004A
serout2loop 00000022
serout2norm 00000068
Bookmarks