initialization at run time?

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

I am using the AVR AT90CAN128 and AVR Studio. Now I’d like to do following thing.
Some default parameters are initialized with

#define ROMCONST const
para ROMCONST user_para[user_para_size] =
{
	0x1000, 0x2000, 0x3000;
}

in flash memory.
I want to change these default values in flash at run time, say, with RS232 port. Is it possible to use the const declaration twice like

para ROMCONST user_para[user_para_size] =
{
	0x4000, 0x5000, 0x6000;
}

?

Or do you have any suggestions?

Thanks.

[/code:1]
</pre></blockquote>
</div>
<p>[code:1]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What do you think of having a fall-back copy of the parameter in the flash and a modifiable version in the EEPROM? So if EEPROM is empty or invalid use the Flash, otherwise use EEPROM.

Knut

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think you want to have a read about PROGMEM (perhaps the excellent tutorial in the Tutorial Forum here?) as ROMCONST or just 'const' is not sufficient to co-erce const data to be in ROM in GCC. As written your values will still be copied out to the .data segement in RAM

However as you want to modify the value at runtime maybe this is such a bad thing. (you can't modify the copy in code flash!). So just drop the const modifier all together and treat them as normal RAM based globals.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you.
What do you mean by saying 'not sufficient to coerce const data to be in ROM in GCC'? What should I do to assure that the data is stored into the flash? This program is written by another but I am sure these default values are stored in the flash because the EEPROM is empty.

As far as I understand, man can put data either in flash or in EEPROM and the data cannot be changed if they are in flash. Is it right?

Thanks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm guessing this program wasn't written for GCC initially then? The fact is that in some of the AVR compilers the very act of using 'const' is enouhg to say "this data to be held in AVR code flash space only". In other compilers there's a 'flash' keyword that has the same effect. But in GCC because it's a generic compiler designed for Von Neumann architecture processors and not Harvard architecture like the AVRs it's not quite as simple. There needs to be special "helper" directives to say that specifically for the AVR version of the GCC compiler that data is only to be located in code flash space and not copied out to .data in SRAM at boot time.

That directive is neatly packaged up in a macro called PROGMEM and, like I say, there's a great tutorial about its use in the Tutorial Forum here which I HIGHLY encourage you to go and read right now.

As you'll read, having co-erced data to be located in flash space alone you then need to use helper functions (pgm_...()) to gain access to the data.

But in your original post you said you wanted to be able to modify this data at run time as a result of data received over the UART so you DO want the array to be held out in RAM as that's the only place it's possible to modify it.

'course you may then want to commit the new values back to non-volatile storage. If that is a requirement then you are right to be thinking of using EEPROM as that's exactly what it's therefore (holding persistent, but modifiable configuration values). While it IS technically possible to modify constant data held in the code space it is extraordinarily convulted to do this (you need to position code into the bootloader segment and mange the positioning of the data) and code flash has a 10,000 cycle write life while EEPROM has a 100,000 cycle write life.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
The fact is that in some of the AVR compilers the very act of using 'const' is enouhg to say "this data to be held in AVR code flash space only".

And to be pedantic, for other readers, these other compilers that use 'const' in this manner are doing so in a non-standard way. The semantics of 'const' were not intended for this type of usage.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Cliff.

I think you mean this tutorial under https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=38003, which I have read.
In the same file there is another similar constant array:

para __attribute__((progmem)) const user_para_new[]= {0x1500, 0x2500, 0x3500};

The only difference is __attribute__((progmem)).
I have searched the document of the AVR library but havn't found the definition of __attribute__((progmem)).
Does this one equal to PROGMEM? Why does this file have two types of constant arrays?

Thanks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did you take a look at pgmspace.h? If you did you'll have found:

#define PROGMEM __ATTR_PROGMEM__

and

#define __ATTR_PROGMEM__ __attribute__((__progmem__))

Therefore the code:

para __attribute__((progmem)) const user_para_new[]= {0x1500, 0x2500, 0x3500};

could be written more readably as:

para PROGMEM const user_para_new[]= {0x1500, 0x2500, 0x3500};