Re: [avr-chat] Array of sctructs in flash - getting the address of an element

[Erik Christiansen]

On 10.09.12 15:16, Bob von Knobloch wrote:

> The zero'th element works OK (it is the name of the array), but
> subsequent array indexes are incorrect (a number of bytes wrong).

Hi Bob,

It's dangerous to ask for thoughts. It encourages rambling replies.

Suggestions for the actual problem comes later, but the first questions I
usually ask myself when the only problem is that subsequent elements are
off by only a few bytes, are:
What is the alignment of the .text section in the linker script?
Will an odd number of bytes of cmdhelp[] result in one or more bytes of
fill, to satisfy that alignment?

Admittedly, in the AVR linker scripts, there is a tendency to just do a
". = ALIGN(2);" in .text, to set up the alignment required for
instructions, then leave it at that for a while. (So multibyte alignment
should not be an assue.)

Still, if there is padding to be seen in the map file, or your testing,
then you could try giving the struct this attribute, in addition to
PROGMEM:

__attribute__ ((packed))

That should squeeze out any alignment padding.

Disclaimer: I haven't tried it with avr-gcc, only on other targets.

And I don't think that is the problem in this case.
Having returned a few hours ago from ten days on the farm, my mind is more
attuned to chainsaws and postholes than toolchains, so I may be slow in
syncing, but here are two thoughts on what seems to be the nub of the
problem:

> The third element of the struct is not dimensioned and is set by the
> length of the strings, is this preventing the compiler from calculating
> the correct address?

1) Is there any reason not to place the strings elsewhere, and include
   only a pointer to them in the struct?
   That removes the SIZEOF variability, leaving no problem to solve?

2) How the compiler would know the length of the last struct element is
   a puzzle. There's nothing you can SIZEOF, AIUI. To make the addresses
   computable at runtime, the length of each (compile time) variable
   length string would need to be stored in flash, and a very fancy
   offsetof() would be needed to try to automate it. You could manually
   add a "length" element to the struct, but 1) is simpler, because
   there's no length variability to complicate addressing.

> Normally the access systems to such elements are over arrow or dot
> methods, but Harvard architecture prevents this.
> 
> Would appreciate any thoughts.

Not sure how useful thoughts generated after midnight are, but there
seems to be enough there to make the problem go away, if the right sized
hammer is used.

Erik

-- 
Less is more or less more
        - Y_Plentyn on #LinuxGER