Jump to content
Sign in to follow this  
DTPIC

Fun With Rom Arrays...

Recommended Posts

Hi,

just thought I'd let you know about this 'feature'...

 

If I write:

 

rom char* myarray1[256] = { 0,1,2,3,4,5,6,7 };

 

and then

 

for (i=0;i<4;i++)

{lprintf("%d ", myarray);}

 

 

I get

 

1 3 5 7

 

However, if I use

 

rom char myarray1 = { 0,1,2,3,4,5,6,7 };

 

I get

 

0 1 2 3

 

Apparently the compiler treats the array differently if I try to bound it with .

 

I know that 'according to the manual', a rom char* array strictly shouldn't have a size in its definition, but the compiler accepts it, and produces an unusual result - if the compiler were to throw out a rom char* array definition with a size, it might save a few cross words...!

 

It would also be useful if there was a way to produce a rom char array larger than 256 bytes without having to define an access function to select between several 256 byte sub-arrays...

Share this post


Link to post
Share on other sites
rom char* myarray1[256] = { 0,1,2,3,4,5,6,7 };

 

Apparently the compiler treats the array differently if I try to bound it with .

 

It would also be useful if there was a way to produce a rom char array larger than 256 bytes without having to define an access function to select between several 256 byte sub-arrays...

 

 

Some compilers have an issue with assigning 256 to a char , i do not know if BoostC does,

as computers count from 0->255 weird things sometimes happen when you assign

the 256th value.

 

If you need a larger than 256 you maynot be able to use a char array, you would have to use an int.

 

Out of curiosity, what are you doing that you need more than a 256 indicies array? i'd be looking

at using my eeprom at even a 1/4 of that size instead of trying to shoehorn that into the PIC's

data area.

Edited by emte

Share this post


Link to post
Share on other sites

Emte,

thanks for the response. The code is now working - I just put this up because I thought it might help others with the same problem, and to inform the developers.

 

According to the documentation, BoostC allows rom char * arrays of a maximum of 256 bytes - I would hope that any compiler that allows an array of that size would allow me to access the last byte of the array! (this seems to be true, as borne out by more recent code...).

 

I am constructing a piece of test equipment, where each test takes 8 parameters, and there may be up to 40-50 tests - this could require arrays greater than 256 bytes.

 

The array \ table goes into program memory space because of the "rom" keyword, and is packed 2 bytes to each program word - the compiler accesses the arrays using the TABLAT, etc assembly instructions (its an 18F target...) - it is a very efficient way of storing this amount of non-varying data.

 

Besides, the user EEPROM space is in use for 'other things'...!

Share this post


Link to post
Share on other sites
According to the documentation, BoostC allows rom char * arrays of a maximum of 256 bytes - I would hope that any compiler that allows an array of that size would allow me to access the last byte of the array! (this seems to be true, as borne out by more recent code...).

 

The last element of a 256 wide array is element number 255 since the array is zero based :P

 

Regards,

 

Wally

Share this post


Link to post
Share on other sites

Hi Wally,

thanks for the reminder about arrays being zero-based - we've all forgotten it sometime! But no confusion there - I said that the <size> of the array was 256 bytes, and I expected to be able to access the last byte (ie, array[255]).

 

Anyway, all this doesn't change the fact that you get 2 different behaviours from the BoostC compiler depending on whether you try to specify a at declaration... :P It seems that you need to declare a rom char* array without to get the 'correct' (expected?) behaviour from the array afterwards...... I just wanted to point it out for anyone making the same mistake, and for the developers to perhaps get a future release of the compiler to throw out such a rom char* .... declaration...

Share this post


Link to post
Share on other sites

Dave,

 

Why does this code compile without errors?

// PIC16F876A
// Test constants allocation in ROM

#include <system.h>
#pragma CLOCK_FREQ 20000000

// why doesn't this statement cause a compile error?
rom char* myarray1[] = { 8,9,10,11,12,13,14,15 };

volatile char a;
volatile char b;

void main()
{
 unsigned char j;
 
 while (1)
 for (j=0;j<4;j++)
 {
   // why does this work?
   a = myarray1[j][0]; // get even element
   b = myarray1[j][1]; // get odd element
 }
}

Edited by cac001

Share this post


Link to post
Share on other sites
Why does this code compile without errors?

 

Maybe boostC knows enough about dynamic compile-time allocation?

Would be a pretty neat feature if it does.

Share this post


Link to post
Share on other sites
Why does this code compile without errors?

 

Because char* myarray1[] is array of pointers but BoostC supports only rom char arrays.

 

Regards,

Pavel

Share this post


Link to post
Share on other sites
Why does this code compile without errors?
Because char* myarray1[] is array of pointers but BoostC supports only rom char arrays.

If your statement is correct then this code should cause a compile time error:

// why doesn't this statement cause a compile error?
rom char* myarray1[] = { 8,9,10,11,12,13,14,15 };

Edited by cac001

Share this post


Link to post
Share on other sites
Why does this code compile without errors?
Because char* myarray1[] is array of pointers but BoostC supports only rom char arrays.

If your statement is correct then this code should cause a compile time error:

// why doesn't this statement cause a compile error?
rom char* myarray1[] = { 8,9,10,11,12,13,14,15 };

 

Yes it should.

 

Regards,

Pavel

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...
Sign in to follow this  

×
×
  • Create New...