Jump to content
hollie

Speed Up Read Of Arrays Of Data In Rom

Recommended Posts

Hello,

 

in a time-critical application, I need to look up a calibration value from a table of 128 values that is placed in ROM.

 

The table is defined as

rom char* calibration_table = {0x10, 0x20, 0x30 , <and so on...>};

 

When I try to read a value from the table, it takes quite some cycles before the value is returned.

 

This is due to the assembly code that is generated to read rom tables:

 

__rom_get_00000
; { __rom_get; function begin
   MOVF __rom_get_00000_arg_objNumb, W
   MOVWF __rom_get_00000_1_gotoTblOffs
   CLRF __rom_get_00000_1_gotoTblOffs+D'1'
   MOVF __rom_get_00000_arg_idx, W
   MOVWF __rom_get_00000_1_gotoTblOffs+D'2'
   BCF STATUS,C
   RLF __rom_get_00000_1_gotoTblOffs, F
   RLF __rom_get_00000_1_gotoTblOffs+D'1', F
   MOVF __rom_get_00000_arg_objNumb, W
   ADDWF __rom_get_00000_1_gotoTblOffs, F
   BTFSC STATUS,C
   INCF __rom_get_00000_1_gotoTblOffs+D'1', F
   MOVLW    LOW( label4026531870 )
   ADDWF __rom_get_00000_1_gotoTblOffs, F
   MOVLW    HIGH( label4026531870 )
   BTFSC STATUS,C
   INCF __rom_get_00000_1_gotoTblOffs+D'1', F
   ADDWF __rom_get_00000_1_gotoTblOffs+D'1', F
   MOVF __rom_get_00000_1_gotoTblOffs+D'1', W
   MOVWF PCLATH
   MOVF __rom_get_00000_1_gotoTblOffs, W
   MOVWF PCL
label4026531870
   MOVLW    HIGH( label4026531871 )
   MOVWF PCLATH
   GOTO    label4026531871
   MOVLW    HIGH( label4026531872 )
   MOVWF PCLATH
   GOTO    label4026531872
label4026531871
   MOVLW    LOW( label4026531873 )
   ADDWF __rom_get_00000_1_gotoTblOffs+D'2', W
   MOVLW    HIGH( label4026531873 )
   BTFSC STATUS,C
   ADDLW 0x01
   MOVWF PCLATH
   MOVF __rom_get_00000_1_gotoTblOffs+D'2', W
   ADDWF PCL, F
label4026531873
   RETLW 0x10
   RETLW 0x20
       ... table goes on here

 

I assume the code just below the rom_get label is a way to support multiple rom tables in memory by using just one function entry. This code then selects the correct table to jump to.

 

The question is: is it possible to get around this? What I'd like to have in the end is some assembly code that look like:

 

 ; get the value at position 5
  movlw 5
  call lookup_table
; w register will contain the value now

lookup_table
  addwf PCL, F
  nop
  retlw 0x10
  retlw 0x20
  ... and so on

 

I tried to put this in an 'asm' block inside a function like this:

void lookup_table(char index){
   
   char retval;
   
   asm {
       goto    getval
       
      lookuptable:
       addwf    _pcl, F
       nop
       retlw    0x10
       retlw   0x20
       retlw   0x30
           
      getval:
       movf    _index, W
       call     lookuptable
       movwf    _retval
       
       }
       
   return retval;
           
}

 

But the compiler errors out with:

 

failure

xxx: error: unknown function 'lookuptable'

 

The target device is a PIC16F84, there is no option to select another device that can do FLASH reads.

 

Any ideas how to get around this one?

 

Thanks,

Lieven.

 

P.S. I know I need to be careful not to cross page boundaries with this type of code.

Edited by hollie

Share this post


Link to post
Share on other sites

hollie,

 

I assume the code just below the rom_get label is a way to support multiple rom tables in memory by using just one function entry. This code then selects the correct table to jump to.
Yes you have go it.

The code caters for multiple ROM tables that also can cross page boundaries. This does make the code longer.

 

To guarantee that the table doesn't cross a boundary needs some special command to the compiler/linker, and that not availble (yet).

 

As a work around I would suggest using #pragram DATA and creating a ret table like that.

I suggested a similar thing for use in BoostBasic here.

 

Regards

Dave

Share this post


Link to post
Share on other sites

Dave,

 

thanks for your swift reply.

 

Inserting the lookup table with the #pragma DATA solves my problem.

 

However, I notice that the compiler v6.40 does not take into account the program memory area that I assign using the #pagma DATA. It happily maps the other application code on the same memory location. This problem is correctly flagged during assembly.

 

I have to manually map the table 'high enough' in memory to make sure that there is no other code overlapping with the defined table.

 

Is this intended behaviour, or should I file a bugfix/enhancement request on this? It would be nice to be able to put the table in front of my other code so I don't have to worry about setting the PCLATH register before adding the offset to the PCL register.

 

Kind regards,

Lieven.

Share this post


Link to post
Share on other sites

Hollie,

 

However, I notice that the compiler v6.40 does not take into account the program memory area that I assign using the #pagma DATA. It happily maps the other application code on the same memory location. This problem is correctly flagged during assembly.

I have to manually map the table 'high enough' in memory to make sure that there is no other code overlapping with the defined table.

 

Is this intended behaviour, or should I file a bugfix/enhancement request on this?

Yes this what should happen. The compiler knows nothing much about the intended target, it is down to linker to sort out the memory usage and check for overlaps.

 

It would be nice to be able to put the table in front of my other code so I don't have to worry about setting the PCLATH register before adding the offset to the PCL register.
Best bet here would be to use linker -rb option to start code later in memory. You will need to patch up reset and interrupt vectors to the new location by using some more #pragram DATA with the oppropriate opcodes.

 

Regards

Dave

Share this post


Link to post
Share on other sites

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...