Re: [Fwd: RE: [Fwd: RE: [avr-chat] BOOTLOADER on ATMega644]]

[Preston Wilson]

"Weddington, Eric" wrote:

>> -----Original Message-----
>> From: address@hidden
>> [mailto:address@hidden
>>  On Behalf Of Bob Paddock
>> Sent: Monday, December 22, 2008 9:18 AM
>> To: address@hidden
>> Subject: Re: [Fwd: RE: [Fwd: RE: [avr-chat] BOOTLOADER on ATMega644]]
>> 
>>> Dimensioned variables are not accepted by the compiler e.g.:
>>> 
>>> const prog_uint8_t eeprom[64];
>> 
>> Do Zero Length Arrays work in AVR GCC?
>> I have never seen them used nor documented as such,
>> but have never tried to use them.
>> 
>> http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
>> 
>> Try:
>> const prog_uint8_t eeprom[0];
>> 
>> Why not initialize your array to the blank flash state?
> 
> Even if they did work, what would be the point? The compiler is not aware of a
> variable named 'eeprom' that resides in program memory. The user does not
> access the data via a symbol named 'eeprom' except, perhaps, by taking the
> address of the symbol. One can just #define a macro equivalent to the program
> memory address where the data resides. The compiler just views this as a block
> of memory, because the only way to access this is through memcpy_P().

I too do not understand how you would use uninitialized variables that only
live in flash.  You can only write to them when programming the part.  You
cannot update them from within a running program, so why have it
uninitialized?

It sounds like you are trying to make space for the code that will be
downloaded to one part (ATtiny13) within the program flash of the
programming part (ATmega644).  It also sounds like you want to be able to
occasionally update the code that is downloaded to the ATtiny13 without
reprogramming the ATmega644.

If that is the case, I would recommend looking at using Atmel's DataFlash
parts in combination with the ATmega644/324/164.  The DataFlash parts that I
am thinking about are the AT25xxxx and AT45xxxx parts.

-Preston