• AVR Freaks

Helpful ReplyHot!Table Read PIC18Fxxx TBLPTR

Author
nur53
Super Member
  • Total Posts : 1102
  • Reward points : 0
  • Joined: 2008/06/07 08:16:33
  • Location: 0
  • Status: offline
2008/11/05 10:08:37 (permalink)
0

Table Read PIC18Fxxx TBLPTR

I have already studied the related datasheet and MPASM User's Guide .
I want to read the 16 bits wide Flash Memory and put them into the 8 bits wide RAM in 2 steps as stated in datasheet but I have not understood the logic .
The address of a 16 bits wide value in Flash should be loaded into TBLPTR  which consists of 3 registers (U,H,L).
 
For example :
 
org 0x1000
 
tb1_data  data  0x7ABC,0x3DEF ; 0x7ABC is at address 0x1000  and 0x3DEF is at address 0x1001
                                                                                              (each of them 16 bits wide)
First address 0x1000  is loaded into TBLPTR
 
    movlw  0x00
    movwf  TBLPTRU
    movlw  0x10
    movwf  TBLPTRH
    movlw  0x00
    movwf  TBLPTRL 
READ_WORD
    TBLRD*+
    movf  TABLAT,w      ; Takes 0xBC into TABLAT (Odd Byte) ?
    movwf WORD_EVEN
    TBLRD*+                ; Why increase address as the whole 0x7ABC is in 0x1000 ? In 0x1001 there is 0x3DEF ?
    movf  TABLAT,w      ; Takes 0x7A into TABLAT (Even Byte) ?
    movwf WORD_ODD
    TBLRD*+
    movf   TABLAT,w     ; Takes 0xEF into TABLAT (The next Odd Byte) ?
    movwf WORD_EVEN
    .
    .
    .
 
Can you help me understanding the logic ?
 
Thanks and Best Regards
 
 
 
#1
nur53
Super Member
  • Total Posts : 1102
  • Reward points : 0
  • Joined: 2008/06/07 08:16:33
  • Location: 0
  • Status: offline
RE: Table Read PIC18Fxxx TBLPTR 2008/11/05 10:22:33 (permalink)
0
Sorry ,
 
READ_WORD
   TBLRD*+
   movf  TABLAT,w      ; Takes 0xBC into TABLAT (Even Byte) ?
   movwf WORD_EVEN
   TBLRD*+                ; Why increase address as the whole 0x7ABC is in 0x1000 ? In 0x1001 there is 0x3DEF ?
   movf  TABLAT,w      ; Takes 0x7A into TABLAT (Odd Byte) ?
   movwf WORD_ODD
   TBLRD*+
   movf   TABLAT,w     ; Takes 0xEF into TABLAT (The next Even Byte) ?
   movwf WORD_EVEN

#2
BitWise
Super Member
  • Total Posts : 1238
  • Reward points : 0
  • Joined: 2004/11/09 13:24:20
  • Location: UK
  • Status: offline
RE: Table Read PIC18Fxxx TBLPTR 2008/11/05 11:00:56 (permalink)
0
ORIGINAL: nur53
  TBLRD*+                ; Why increase address as the whole 0x7ABC is in 0x1000 ? In 0x1001 there is 0x3DEF ?

On 18F devices the memory addresses are byte based not word based (like the 12F,16F series). If you look at the address column in your code listings or a disassembly you will see that all the instructions fall on even addresses (0, 2, 4, 6, ...). All 18F instructions are 2 or 4 bytes long.

So when you do the first tblrd *. it reads the low byte of the 16-bit constant and the second tblrd *+ gets the high byte.


tb1_data data 0x7ABC,0x3DEF ; 0x7ABC is at address 0x1000 and 0x3DEF is at address 0x1001
(each of them 16 bits wide)

The address of the second constant is 0x1002 not 0x1001

post edited by BitWise - 2008/11/05 11:10:39

Throughout your life advance daily, becoming more skillful than yesterday, more skillful than today. This is never-ending.

Yamamoto Tsunetomo (1659-1719)
#3
nur53
Super Member
  • Total Posts : 1102
  • Reward points : 0
  • Joined: 2008/06/07 08:16:33
  • Location: 0
  • Status: offline
RE: Table Read PIC18Fxxx TBLPTR 2008/11/05 11:14:15 (permalink)
0
Thank you BitWise ,
 
I will make a simple program and see this difference in the disassembly .
 
Regards
 
#4
nur53
Super Member
  • Total Posts : 1102
  • Reward points : 0
  • Joined: 2008/06/07 08:16:33
  • Location: 0
  • Status: offline
RE: Table Read PIC18Fxxx TBLPTR 2008/11/06 06:01:45 (permalink)
0
I have made a simple test program in order to understand the logic .
 
org 0x1000

tb1_data  data  0x7ABC,0x3DEF 
 
In disassembly listing I see :
 
1000   7ABC
1002   3DEF
 
Repeating TBLRD*+ instruction I read :
 
1) 0xBC  -> Even address 0x1000  Low Byte
2) 0x7A  -> Odd  address 0x1001  High Byte
3) 0xEF  -> Even address 0x1002  Low Byte
4) 0x3D  -> Odd address  0x1003  High Byte
 
Is this correct ?
 
Regards
 
 
 
#5
BitWise
Super Member
  • Total Posts : 1238
  • Reward points : 0
  • Joined: 2004/11/09 13:24:20
  • Location: UK
  • Status: offline
RE: Table Read PIC18Fxxx TBLPTR 2008/11/06 06:06:09 (permalink)
0

ORIGINAL: nur53
Is this correct ?

Looks right to me.

Throughout your life advance daily, becoming more skillful than yesterday, more skillful than today. This is never-ending.

Yamamoto Tsunetomo (1659-1719)
#6
1and0
Access is Denied
  • Total Posts : 9607
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
RE: Table Read PIC18Fxxx TBLPTR 2008/11/06 07:32:46 (permalink)
0
ORIGINAL: nur53

In disassembly listing I see :

1000   7ABC
1002   3DEF

If you take a look to the .hex file, you will notice the lower byte of each 16-bit instruction word is located before the upper byte.  This is how each instructon word allocated into the 18F's program memory--lower byte first, then upper byte.  Take your case as an example, your .hex file should have this at address 0x1000:
 
:......BC7AEF3D...
#7
nur53
Super Member
  • Total Posts : 1102
  • Reward points : 0
  • Joined: 2008/06/07 08:16:33
  • Location: 0
  • Status: offline
RE: Table Read PIC18Fxxx TBLPTR 2008/11/06 08:18:23 (permalink)
0
Thanks ,
 
After all can we come to the following conclusion ?
 
If you store in PIC18Fxxx values with even numbers of bytes (2,4,...) in form of Table , you use the Flash Memory area with 100% efficiency .
I think this is very important to transfer this data into RAM easily , where you save place in RAM too .
No unnecessary 0x00 datas in RAM .
 
But if you want to store values with odd numbers of bytes (1,3,...) :
 
For example : 0x12 and 0x34 (each one byte)  it is better to combine two one byte values into one with two bytes in order to use ROM and RAM with 100% efficiency .
Otherwise you use ROM with 50% efficiency .
 
Just the same for  3 bytes each  0x123456 and 0x789ABC  (75% eff.) but
when stored as 0x1234 and 0x5678  and  0x9ABC (3 values each two bytes with 100% eff.)
 
So you save space in ROM and RAM , it is easier to transfer the data into RAM but it is a tricky way if you have many values to prepare the table .
 
Regards
 
 
 
#8
1and0
Access is Denied
  • Total Posts : 9607
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
RE: Table Read PIC18Fxxx TBLPTR 2008/11/06 09:32:48 (permalink)
0
You can store constants into 18F's program memory by words

         dw      0x7ABC
         dw      0x3DEF
         ...

or by bytes

         db      0xBC, 0x7A
         db      0xEF, 0x3D
         ...
#9
Steven37
Super Member
  • Total Posts : 347
  • Reward points : 0
  • Joined: 2008/08/29 05:20:14
  • Location: South Australia
  • Status: offline
RE: Table Read PIC18Fxxx TBLPTR 2008/11/06 16:26:38 (permalink)
+2 (1)
I have found using assembler, that the simplest way to store constants into code space is to define a "packed" section. You can then store any size constants without bothering about trying to pack two bytes into word addresses. This automatically packs 2 bytes into each word address, so if you have 2 constants that are 1 byte long they get stored into 1 word. 100% efficiency.

Regards Steve Jones.

;*****************************************************************************************
;               LCD text strings                START = 7900 to 7DBF hex.
;*****************************************************************************************

TXT_STRINGS   CODE_PACK       H'7A00'                 ; Packed data. Not word aligned.

LSB_TXT    DB      "LSB"
USB_TXT    DB      "USB"
CW_TXT     DB      "CW"
CWR_TXT    DB      "CWR"
AM_TXT     DB      "AM"
FM_TXT     DB      "FM"
DIG_TXT    DB      "DIGITAL"

;*****************************************************************************************


#10
nur53
Super Member
  • Total Posts : 1102
  • Reward points : 0
  • Joined: 2008/06/07 08:16:33
  • Location: 0
  • Status: offline
RE: Table Read PIC18Fxxx TBLPTR 2008/11/07 04:56:25 (permalink)
0
Simple Test Program like the one on page 59 of the PIC18FXX2 datasheet  :
 
org 0x1000
db 0x12, 0x34, 0x56, 0x78, 0x9A, 0xBC
 
Disassembly Listing :
 
1000   3412
1002   7856
1004   BC9A
 
.hex File :
 
......123456789ABC.....
 
Using repeated TABLAT's I take the table values which I intend to transfer into RAM in series :
 
0x12
0x34
0x56
0x78
0x9A
0xBC
 
I think I have understood the logic .
 
Thank you for your help .
 
Regards
 
 
 
#11
_pike
Senior Member
  • Total Posts : 131
  • Reward points : 0
  • Joined: 2012/12/02 11:34:43
  • Location: 0
  • Status: offline
Re: Table Read PIC18Fxxx TBLPTR 2019/08/20 07:27:13 (permalink)
0
Hello very nice explanations from all of you!!!
But i want to ask also something.... lets say that we have a table and we havent declared it to ram for example
using org 0x1000 and we leave it to the assembler to place it somewhere in program memory.....
Why when i try this is not working?
 

 
   BCF       NVMCON1, REG0           ; point to Program Flash Memory
   BSF       NVMCON1, REG1           ; access Program Flash Memory
   MOVLW     STRING_OF_DATA  ;<- Shouldn't the assembler somehow take care of that?
   MOVWF     TBLPTRU                
   MOVLW     STRING_OF_DATA  ;<-Shouldn't the assembler somehow take care of that?
   MOVWF     TBLPTRH
   MOVLW     STRING_OF_DATA  ;<- Shouldn't the assembler somehow take care of that?
   MOVWF     TBLPTRL
READ_WORD
  TBLRD*+               
  MOVF      TABLAT, W   
 
 
 

 
Using the method by pointing where to look (meaning using org ......) everything works fine...
 
 Thank you !!!
 
 
post edited by _pike - 2019/08/20 07:29:11
#12
1and0
Access is Denied
  • Total Posts : 9607
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: Table Read PIC18Fxxx TBLPTR 2019/08/20 07:37:33 (permalink) ☄ Helpfulby _pike 2019/08/20 09:36:00
+1 (1)
Add the UPPER, HIGH, and LOW operators to select the appropriate bytes of the address label:

   MOVLW     upper STRING_OF_DATA
   MOVWF     TBLPTRU                
   MOVLW     high STRING_OF_DATA
   MOVWF     TBLPTRH
   MOVLW     low STRING_OF_DATA
   MOVWF     TBLPTRL

 
post edited by 1and0 - 2019/08/20 07:55:04
#13
_pike
Senior Member
  • Total Posts : 131
  • Reward points : 0
  • Joined: 2012/12/02 11:34:43
  • Location: 0
  • Status: offline
Re: Table Read PIC18Fxxx TBLPTR 2019/08/20 09:38:10 (permalink)
0
When i was experimenting i used it at the end of the label with an underscore....Thats why it took it as a label and never worked!!
 
  THANK YOU...!!!!!
 
<edit> Perhaps you edited your post..... but i firstly saw your answer through my e-mail..... if i dont use these bits the program is not working <edit>
post edited by _pike - 2019/08/20 09:45:37
#14
1and0
Access is Denied
  • Total Posts : 9607
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: Table Read PIC18Fxxx TBLPTR 2019/08/20 10:00:58 (permalink)
0
_pike
Perhaps you edited your post..... but i firstly saw your answer through my e-mail..... if i dont use these bits the program is not working

Yes, you need those bits. I was thinking of another PIC18 that does not have NVMREG.
#15
_pike
Senior Member
  • Total Posts : 131
  • Reward points : 0
  • Joined: 2012/12/02 11:34:43
  • Location: 0
  • Status: offline
Re: Table Read PIC18Fxxx TBLPTR 2019/08/20 10:11:34 (permalink)
0
This works like a charm !!!! But i noticed to the mplabx terminal output that if my text is...
 
hello db "Hello"
 
it outputs HHello  
 
It re-print the first letter...does this has to do with the way that it stores the bytes?
(i mean because its making words)
 
Thank you!!!
#16
1and0
Access is Denied
  • Total Posts : 9607
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: Table Read PIC18Fxxx TBLPTR 2019/08/20 12:32:54 (permalink)
0
_pike
This works like a charm !!!! But i noticed to the mplabx terminal output that if my text is...
 
hello db "Hello"
 
it outputs HHello  
 
It re-print the first letter...does this has to do with the way that it stores the bytes?

No, that line of code is same as
hello   db  'H', 'e', 'l', 'l', 'o'

so the issue is somewhere else.
 
#17
_pike
Senior Member
  • Total Posts : 131
  • Reward points : 0
  • Joined: 2012/12/02 11:34:43
  • Location: 0
  • Status: offline
Re: Table Read PIC18Fxxx TBLPTR 2019/08/20 12:46:02 (permalink)
0
Here is the code.....  Smile: Smile
 

 
 
  BANKSEL NVMCON1

  BCF       NVMCON1, REG0           ; point to Program Flash Memory
  BSF       NVMCON1, REG1           ; access Program Flash Memory
  MOVLW     upper HELLO            
  MOVWF     TBLPTRU               
  MOVLW     high HELLO
  MOVWF     TBLPTRH
  MOVLW     low HELLO
  MOVWF     TBLPTRL
 
READ_WORD
  TBLRD*+                   ; read into TABLAT and increment
  MOVF      TABLAT, W       ; get data
 
    
   banksel U1ERRIR
    MOVWF U1TXB
   
    btfss U1ERRIR,TXMTIF
    bra $-2
    
    call wait250msec
    call wait250msec
    call wait250msec
    call wait250msec
    call wait250msec
    call wait250msec
    
     bra read_word
   
 HELLO DB "HELLO"
 
 
 
 
 

post edited by _pike - 2019/08/20 12:49:50

Attached Image(s)

#18
_pike
Senior Member
  • Total Posts : 131
  • Reward points : 0
  • Joined: 2012/12/02 11:34:43
  • Location: 0
  • Status: offline
Re: Table Read PIC18Fxxx TBLPTR 2019/08/21 11:02:55 (permalink)
0
Found the problem of re-printing the first character...!!!! Hope to help someone else... (if has same issue.)
These days i am experimenting with a new microcontroller i bought. So after the SFR's initialization, i have the above code running as a main ... Adding a small delay fixed the problem. I am not completely sure why is this happening but i guess that has to do with the ftdi board... Because although i havent any source connected to my breadboard the microcontroller takes the required voltage from the ftdi board through the usb and works .So all this somewhere interferes and adding a small delay lets the things settle down before starting transmittion...  ( Hope to write someone who can understand exactly why is this happening. )
 
Regards Panagiotis
#19
1and0
Access is Denied
  • Total Posts : 9607
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: Table Read PIC18Fxxx TBLPTR 2019/08/21 15:01:26 (permalink)
+1 (1)
_pike

   banksel U1ERRIR
    MOVWF U1TXB
   
    btfss U1ERRIR,TXMTIF
    bra $-2


Replace that with this
    banksel PIR3
    btfss   PIR3,U1TXIF
    bra     $-2
 
    banksel U1TXB
    movwf   U1TXB

so it does not wait for transmission to finish.
#20
Jump to:
© 2019 APG vNext Commercial Version 4.5