Pointers to const array

Oznog · Joined: 16 Oct 2004 Posts: 6

I have a constant struct which uses a pointer to a constant array of data. The data length varies depending on which instance of struct it is. It's for graphical LCD fonts of differing sizes, and some cover only the numbers.

I'm seeing that CCS does not allow pointers to const arrays, and I see no way to implement this.

These arrays must all be accessed in the same way by the LCD driver tasks, it is not practical to make a function access the array directly, it must be a pointer.

The small arrays would use far too much memory if they were all the same size.

The arrays will consume more RAM than in existance if they are not constants.

Is this true that there is no way to access constant arrays via pointers? How on earth would this be worked around?

Mark · Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA

Well the driver could access the elements of the array instead of using a pointer. Just pretend its BASIC Laughing

You can copy the const array to a RAM array and use a pointer to the RAM instead.

asmallri · Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia

Oznog · Joined: 16 Oct 2004 Posts: 6

Haplo · Joined: 06 Sep 2003 Posts: 659 Location: Sydney, Australia

I'm afraid that's the way it is...CCS implements RETLW-based look-up tables for constant arrays, and you can't have a pointer to such a lookup table.
This is probably CCS's biggest shortcoming.

Mark · Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA

Ttelmah · Guest

Oznog · Joined: 16 Oct 2004 Posts: 6

dyeatman · Joined: 06 Sep 2003 Posts: 1934 Location: Norman, OK

I just completed a large project using a multiline LCD display. I allocated all my strings (more than 60 strings in all) to ROM like the following:

// *************************
// Message Constant Strings
char const WD_MSG[]= {"<W93>"};
char const CLR_ERROR_MSG[]= {"<q000D>"};
char const ACK_MSG[]= {"@"};
char const VERSION_MSG[]= {"<L88>"};
char const GAP_MSG[]= {"<G16EA>"};
char const MODE_MSG[]= {"<M4BD>"};
char const LOOPBACK_TEST_MSG[]= {"<SLOOPBACKDA>"};
....etc...
// *************************

I then used the standard Printf to send a desired string.
printf(ACK_MSG);

I also defined LCD control sequences as constant strings then combined them with other strings for transmission using multiple variables in Printf.

Using this method I implemented a very large number of strings while using only 21% of RAM It worked great for me, put all my strings in ROM and I didnt use a single "pointer".

FWIW...

Mark · Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

What he wants to do is to put variable length blocks of bytes (or words)
into program memory, and have the compiler automatically construct
a table of addresses of these blocks. He would prefer that this all be
done at compile time.
Then at runtime, he can use C code to index into the table of block
addresses, and get the address, and then use read_program_eeprom()
to read the data into a ram array. Then he can send the data to his
display device.

The question is, does CCS have the capability to do this ?
I mean, with respect to automatically generating the table of addresses,
with a minimal amount of effort by the programmer when typing in
the data.

I don't know. I played around and came up with the following approach.
This method has the disadvantage that you have to visually check the
size of each block of bytes, and then enter that number into a #define
statement right above the block. Also, there may be some limitation
on the number of #define'd constants in CCS. For 128 characters,
you would need ADDR0 through ADDR127, with the method below.

Oznog · Joined: 16 Oct 2004 Posts: 6

Mark · Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA

Trampas · Joined: 04 Sep 2004 Posts: 89 Location: NC

I think what Oznog is saying is that he has code he is porting to the CCS compiler and finding it will not port easily due to the pointers to const data issue. Therefore it appears that he feels redesigning the code to use alternative methods is not reasonable at this point.

I know that personally in my designs I usually place external flash chips to store data. Usually these flash chips and the compiler do not allow me to have pointers to the data so I just create read/write functions. I try to leave my on chip flash available for code, but then again I am more concerned with development time than manufacturing costs in most of my products.

Trampas