Jump to content
Sign in to follow this  
DTPIC

Fun Initialising Rom Arrays

Recommended Posts

I am using BoostC 6.60....

 

There seems to be a limit on the number of parameters I can OR together in one entry of a rom table initialisation, which is also possibly dependent on the paramter names and values...

 

Let's define some constant parameters:

 

#define PARAM_1 1

#define PARAM_2 2

......

#define PARAM_7 7

 

The compiler seems ok with

 

#define RESULT PARAM_1 | PARAM_2 | PARAM_3 | ....PARAM_7

 

or even

 

char result:

 

result = PARAM_1 | PARAM_2 | PARAM_3 | ....PARAM_7;

 

I can initialise some rom char* array elements with

 

rom char* test_array =

 

{

PARAM_1,

PARAM_2,

1,

2,

3

etc

 

But I cant init a single element with

 

rom char* test_array =

 

{

PARAM_1 PARAM_2 | PARAM_3 | PARAM_4 ,

1,

2,

3,

 

etc

 

Worse still, it seems to be dependent on the name or value of the parameters used:

 

#define TONE_CHECK_IDLE 0x00

#define RX_IDD_MEAS_OFF 0x00

#define RX_IDLE_SEL 0x00

#define XXX1_2_LOAD_OFF 0x00

#define XXX3_4_LOAD_OFF 0x00

 

rom char* test_array =

 

{

TONE_CHECK_IDLE | RX_IDD_MEAS_OFF | RX_IDLE_SEL | XXX_4_LOAD_OFF,

1,

2,

 

works, while

 

rom char* test_array =

 

{

TONE_CHECK_IDLE | RX_IDD_MEAS_OFF | RX_IDLE_SEL | XXX3_4_LOAD_OFF | XX1_2_LOAD_OFF,

1,

2,

 

doesnt work!

 

 

There seems to be a limit on the number of parameters I can OR together in one entry of a rom table initialisation, which is dependent on the paramter names and values...

 

I really wanted to adopt the PARAM1 | PARAM2| PARAM3 style of notation as it is self-documenting....

 

Any ideas or workarounds?

Share this post


Link to post
Share on other sites

Hi,

no response to this one after 2 weeks....!

 

Can anybody

 

a) verify this problem

:ph34r: tell me if there are any workarounds

c) tell me if it's likely to be fixed?

 

I have previously been using the MPLAB assembler,and it has allowed me to initialise items with many ORed terms in this fashion, so I dont think its completely unreasonable to attempt the same in BoostC?

 

It looks like the part of the preprocessor which deals with defined constants is not being applied to array initialisation... I am guessing that the fix is not so much a "big block of new compiler code", but a re-direction of an existing part of the preprocessor...

Share this post


Link to post
Share on other sites

DTPIC,

 

Hi,

    no response to this one after 2 weeks....!

....

Can anybody

 

a) verify this problem

B) tell me if there are any workarounds

c) tell me if it's likely to be fixed?

Appologies, I verified the problem as added it to our bugs/jobs list but forget to post a response :ph34r:

 

I couldn't find any work around other than put the actual numerical constant in the array initialisation.

It is likely to be fixed, but not sure when.

 

Regards

Dave

Share this post


Link to post
Share on other sites

OK,

thanks for that - agree that the only reliable workaround I could find was to use a numeric constant - puzzling thing was that the use of certain #defines seemed to work, while others didn't(!) - I'll wait for the fix!

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...