IAR C-compiler for AVR: Array of pointers to strings in flash

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi group!

Looking for help from someone with experience with IARīs C-compiler
for AVR (ATmega16/32)

I want to declare an array with pointers to constant text. And both of
the should be in flash-memory, like this.

__flash char * __flash textTab[] =
{
"Text1",
"Text2",
"Text3",
"Text4",
"Text5",
"Text6",
"Text7",
"Text8",
"Text9",
};

The array is easy to make in flash but the strings i cant manage.
I managed to accomplish it by doing like this:

__flash char textText1[] = "Text1";
__flash char textText2[] = "Text2";
__flash char textText3[] = "Text3";
__flash char textText4[] = "Text4";
__flash char textText5[] = "Text5";
__flash char textText6[] = "Text6";
__flash char textText7[] = "Text7";
__flash char textText8[] = "Text8";
__flash char textText9[] = "Text9";

__flash unsigned char __flash *textTable[] =
{
textText1,
textText2,
textText3,
textText4,
textText5,
textText6,
textText7,
textText8,
textText9,
};

But this is not sufficient bacause we need a LOT more texts.

Anyone got any idea?

//Erik

Re: IAR C-compiler for AVR: Array of pointers to strings in flash
Quoted text here. Click to load it

AFAIK this is the only way. IAR does it this way, ICCAVR too.

Meindert



Re: IAR C-compiler for AVR: Array of pointers to strings in flash
Quoted text here. Click to load it

Thanks for the answer although it was incorrect!

I lookad at some tech. notes at iar.com and found out that you can this
with the command line option --string_literals_in_flash

//Erik

Re: IAR C-compiler for AVR: Array of pointers to strings in flash
snipped-for-privacy@japro.se (Erik Cato) wrote in

Quoted text here. Click to load it

Doesn't const help here? I may have the second const in the wrong
position.

const char * const textTab[] =
{
    "foo",
    "bar",
    "baz"
};

--
- Mark ->
--

Re: IAR C-compiler for AVR: Array of pointers to strings in flash
Quoted text here. Click to load it



You forgot to say how this approach failed.  

This may just be a bug in that compiler's C extension keyword __flash,
particularly in how it's parsed, or you may be missing something on
how it's supposed to be used.  

If you've seen the trouble people have in getting the usage of
standard keyword "const" right in such multi-level pointer situations,
you'll realize that getting this __flash thingy to parse exactly right
may be tricky.  You may have to expend a couple of parens, or a
typedef, like this:

typedef __flash const char flashstring[];

__flash *flashstring = {
 /* ... */
};


--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: IAR C-compiler for AVR: Array of pointers to strings in flash
Quoted text here. Click to load it

If you only define the array itself as const, and not the strings, only the
array with pointers will be in rom or flash. The pointers are pointers to
ram locations, where the strings are copied to from rom by the startup code.

Meindert



Re: IAR C-compiler for AVR: Array of pointers to strings in flash

Quoted text here. Click to load it

There's a bug in the declaration, it should write:

   char __flash * __flash textTab[] = ....

or
   __flash char __flash * textTab[] = ...

(I know, this is really confusing.)

The reason is that writing a memory attribute first on the line
associates this memory attribute to every variable being declared (for
pre-ANSI backward compatability reasons).
 
The warning message emitted is something about "char const *" not
being convertible to "char __flash *" (not very surprising, they are
in completely different address spaces).

The problem is a result of the fact that, according to the ANSI
standard, generic pointers have to be able to point to string literals
and generic pointers cannot point to flash memory.

Best wishes,
Mats Kindahl
--
IAR Systems in Uppsala, Sweden.

Any opinions expressed are my own and not those of my company.

We've slightly trimmed the long signature. Click to see the full one.
Re: IAR C-compiler for AVR: Array of pointers to strings in flash

Quoted text here. Click to load it

Let's first note that ANSI/ISO C specs obviously say nothing about
flash memory.

Now, if the compiler does implement an extension like this __flash,
but does not also implement generic pointers in a way that they *can*
point at it, that's IMHO at least a serious misfeature of the
compiler.  It's not strictly a bug for the only reason that this whole
issue is outside the domain of the standard, i.e. the implementor can
technically do whatever they please about it.

Such a situation effectively means that "pointers to flash" are not
actually "pointers" (as defined by the language) at all.  Just about
every usage of such pointers could go fatally wrong, then, for lots of
crazy, hard-to-find reasons.

The language specs go to quite some length to make sure that generic
pointers can be implemented including a "memory class specifier", if
the target platform needs that.  Not making use of that flexibility is
somewhat wasteful.

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: IAR C-compiler for AVR: Array of pointers to strings in flash



Quoted text here. Click to load it

Let me guess, you have never written a compiler for the embedded market for
use by embedded engineers? :-)

With all due respect, having the flexibility by the standard is nice.
However, implementing a generic pointer requires the pointer to be larger
than 16 bits, and runtime check to see what type of a pointer it is, thus
blowing up resulting code's FLASH and RAM requirements and make things run
slower.

--
// richard
http://www.imagecraft.com



Re: IAR C-compiler for AVR: Array of pointers to strings in flash

Quoted text here. Click to load it



Written one: no.  Used one, though, and I actually do think I
understand enough of the underlying issues to be allowed to speak up
here.

Quoted text here. Click to load it

It only makes slower if and where it gets used, of course.  The issue
I'm debating here is not whether pointers specialized to a single
memory should exist --- on these architectures, they rather obviously
have to.

I'm debating whether a "generic" pointer type deserves being called
that if there are some addressable objects out there it can't point
to.  And whether the default pointer type, i.e. the one whose
behaviour _is_ covered by the C standard, should be such a truly
generic one, or one that is tied to one of the memory classes.  My
view is that the answers to these are "no" and "yes", in that order.

And BTW, I have indeed seen at least one compiler that did a better
job, IMHO, in this area than the ones being discussed here: Keil C51,
where a pointer without a memory class specifier is a generic pointer,
and it truly is generic.  The code size increase can be kept quite
reasonable at the expense of some helper functions in the runtime lib,
and the speed loss is for the programmer to decide about --- he has to
decide whether he needs the gain in flexibility badly enough to
justify it or not.

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: IAR C-compiler for AVR: Array of pointers to strings in flash
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

Ignoring specific hardware, the general approach of segmentation
can pay off here.  Consider a machine with 16 bit entities.  For
pointers, we could designate 3 of those bits to specify one of
eight segment registers, each of which in turn specifies a storage
area and base location therein.  The remaining 13 bits in the
pointer can specify an offset of up to 8191.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline