Tables data - size limit

[kenmac]

Hi,
Re the RETLW table function on a 16F628A.
What is the limit for the size of a table and where is the data stored?
Does it just reside in the program memory space?

kenmac

 

[Papabravo]

Table Limits

Yes the table values are encoded in the RETLW instruction. You can fill up the entire code space with them. So every instruction will be a return instruction with an indeterminate stack. Pretty random execution I guess.

 

[Nigel Goodwin]

Hi,
Re the RETLW table function on a 16F628A.
What is the limit for the size of a table and where is the data stored?
Does it just reside in the program memory space?

It's stored in program memory, as it's simply a block of program instructions.

However!, it MUST NOT cross a 256 byte boundary, as it only does an 8 bit calculation - there are methods to over come this though.

 

[Pommie]

You can also do a 16 bit calculation and have a table of any size using retlw. Or, use a flash writable part such as 16F88 and use the read flash ability to read tables of any size and with each location able to hold 14 bits.

Mike.

 

[Mike - K8LH]

However!, it MUST NOT cross a 256 byte boundary, as it only does an 8 bit calculation - there are methods to over come this though.

That statement may be a bit confusing... Tables can be placed almost anywhere in code memory and can straddle a 256 byte boundary (though special precautions are necessary when crossing 'pages')... Here's example table code that takes into account a table which may or may not straddle a 256 byte boundary;

;
GetData movwf   INDEX           ; save index value [000..255]      |B0 
        movlw   high Table      ; get table high address           |B0
        movwf   PCLATH          ; preset PCLATH                    |B0
        movlw   low Table       ; get table low address            |B0
        addwf   INDEX,W         ; add index [000..255]             |B0
        skpnc                   ; skip if C=0                      |B0
        incf    PCLATH,f        ; else, increment PCLATH           |B0
        movwf   PCL             ; perform the branch               |B0

As Mike (Pommie) mentioned, using 16-bit values (for PCLATH and PCL) allows access to tables of almost any size located almost anywhere in memory... I use this method for printing in-line code strings to an RS232 port;

;******************************************************************
;
;  here's how I print in-line code strings in my programs
;
;
        _Print  "Bill's Particle Accelerator Demo\r\n\n"
        _Print  "Main Menu\r\n"
;
;******************************************************************

;******************************************************************
;
;  _Print macro - print a string to the RS-232 port
;
_Print  macro   str             ;
        local   String, Print
        movlw   low String      ;
        movwf   PTRL            ;
        movlw   high String     ;
        movwf   PTRH            ;
        goto    Print           ;

String  dt      str,0
Print   call    PutString       ; print string
        endm

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

;******************************************************************
;
;  PutString Subroutine
;
;         - setup PTRL and PTRH to string address before entry
;         - string must be terminated with a 00 byte
;
PutString
        call    GetTable        ; get a table character            |B0
        andlw   b'11111111'     ;                                  |B0
        btfsc   STATUS,Z        ; a 00 byte, last character?       |B0
        return                  ; yes, return, else                |B0
        call    Put232          ; output character                 |B0
        incfsz  PTRL,F          ; increment pointer                |B0
        goto    PutString       ;                                  |B0
        incf    PTRH,F          ;                                  |B0
        goto    PutString       ;                                  |B0
;
GetTable
        movf    PTRH,W          ;                                  |B0
        movwf   PCLATH          ;                                  |B0
        movf    PTRL,W          ;                                  |B0
        movwf   PCL             ;                                  |B0

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

 

[Nigel Goodwin]

However!, it MUST NOT cross a 256 byte boundary, as it only does an 8 bit calculation - there are methods to over come this though.

That statement may be a bit confusing... Tables can be placed almost anywhere in code memory and can straddle a 256 byte boundary (though special precautions are necessary when crossing 'pages')...

Which was why I said "there are methods to over come this though!.

 

[Mike - K8LH]

However!, it MUST NOT cross a 256 byte boundary, as it only does an 8 bit calculation - there are methods to over come this though.

That statement may be a bit confusing... Tables can be placed almost anywhere in code memory and can straddle a 256 byte boundary (though special precautions are necessary when crossing 'pages')...

Which was why I said "there are methods to over come this though!.

Sorry Nigel... That's the part that contradicted the first part of your statement and seemed to make the entire statement somewhat confusing...

I also politely disagree with the first part of your statement... "It MUST NOT cross a 256 byte boundary, as it only does an 8 bit calculation"... This implies that you recommend fixed location tables of 256 words or less that don't cross 256 word boundaries and while that certainly is one way to use tables, that isn't necessarily the best way or the most flexable way to use tables... I hope my examples provided a glimpse of some of the capabilities of tables...

I suspect our opinions, styles, and experiences are clashing again and I apologize... I'd be happy and overwhelmed to have but 25% or your knowledge and experience... I'm a 'dummy' compared to you... But every once in awhile you come up with some unqualified statement that is "off-base" and I've always suspected it's because you're just a little too "quick on the trigger" to provide a quick reply and haven't thought about the subject enough, or your experience level on a particular subject isn't quite "up to snuff" or may be a little outdated... Hopefully you don't mind when I jump in with a different opinion, style, or experience... And, I would expect you to do the same when I say something stupid (which happens all the time, grin)...

Kind regards, Mike

 

[Nigel Goodwin]

Sorry Nigel... That's the part that contradicted the first part of your statement and seemed to make the entire statement somewhat confusing...

I also politely disagree with the first part of your statement... "It MUST NOT cross a 256 byte boundary, as it only does an 8 bit calculation"... This implies that you recommend fixed location tables of 256 words or less that don't cross 256 word boundaries and while that certainly is one way to use tables, that isn't necessarily the best way or the most flexable way to use tables... I hope my examples provided a glimpse of some of the capabilities of tables...

Hi Mike,

No problem, and no disgreement either :lol:

Just that the standard method of tables in PIC's is limited to not crossing a 256 byte boundary, although with extra programming (thanks for posting it!) you can over come the limitation.

However, most lookup tables (or jump tables) are fairly small, and easily fit in the 256 byte space - it's common practice to place small tables at the beginning of memory to ensure they don't cross a boundary (obviously with a GOTO jumping over it).

Thanks again for posting the code!.