Re: [avr-gcc-list] Problem allocating memory in xflash
Parthasaradhi Nayani wrote: I have a structure prclkp of size 32 bytes. When I define struct prclkp XFLASH PLULOC1[1023]; No error is reported, whereas struct prclkp XFLASH PLULOC1[1024]; generates an error - size of array too large You've probably reached a built-in limit in gcc. It has nothing to do with the size of your memory section. -- Tero Sinervo ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Problem allocating memory in xflash
Parthasaradhi Nayani wrote: I have a structure prclkp of size 32 bytes. When I define struct prclkp XFLASH PLULOC1[1023]; No error is reported, whereas struct prclkp XFLASH PLULOC1[1024]; generates an error - size of array too large You've probably reached a built-in limit in gcc. It has nothing to do with the size of your memory section. I've just tried to compile a 64kB initialised variable with gcc (GCC) 3.4.4 (cygming special) to confirm this is NOT limit of gcc. So, it appears to be limit of avr-gcc specifically. JW ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Re: Larger than 64K memory sections
Parthasaradhi Nayani wrote: Details of application - I have data packets each 32 bytes in size and we have accommodate 2000 of these (predefined). This I plan to put in a part of the 4MB Flash. Rest of the memory will be used for storing records comprising of these data packets with data and time etc. The records will be deleted from time to time but the data packets will remain. It is possible to use a long int as an address pointer from the start of the available memory (after the data packets) and store records. I still curious to know how one can create a section larger than 64K. You'll have to customise your linker script and add your section there. I fiddled with this a while ago but sadly have lost the results both in computer and brain memory. After the linker knows what you want to do you'll be a bit farther down the road. Then you'll have to deal with pointers being reduced to 16 bits. You should see Carlos Lamas's morepgmspace.h. It might give you some help with that. -- Tero Sinervo ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Re: Larger than 64K memory sections
David Brown wrote:
It does not matter what addresses are used for ram variables, nor for
the flash code that is updated. But very often it /does/ matter for
persistent data, and it is certainly important for pre-defined memory
maps such as for external peripherals (there is a good reason why
internal peripherals are not defined in a file with lines like volatile
uint8_t PORTD !). The only way to be entirely sure that an object is
allocated to the same address each time is for it to be the only thing
in a section, and the section is given an explicit address at link time.
When you are talking about data that can't be addressed directly in C
on the AVR anyway, why bother with that?
Yes, very often but not always. Consider having text strings in pgmspace
but running out of space. Good thing you have a mass storage and file
system - you can move the text strings to an external section and load
the section to a file. Only thing you need to do is write a driver that
replaces pgmspace string stuff with file access. It doesn't matter in
which order the strings are in the file.
Note that you /can/ (and should) get the compiler to do most of the
effort in the allocation. The easiest way is to make a struct type for
all your eeprom data:
typedef struct { uint16_t moneyLeft; uint16_t runTimeSeconds; }
eepromData;
Then you can access this data with something like:
eeprom_read_word((uint16_t*) (baseAddress +
offsetof(eepromData, runTimeSeconds)));
You manually specify a base address, and let the compiler handle the rest.
This is all all right although perhaps offsetof is redundant:
eepromData* eeprom = BASEADDRESS;
eeprom_read_word(eeprom-runTimeSeconds);
--
Tero Sinervo
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Problem allocating memory in xflash
Jan Waclawek konf...@efton.sk wrote: So, it appears to be limit of avr-gcc specifically. Sure, it depends from sizeof(int). -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Problem allocating memory in xflash
So, it appears to be limit of avr-gcc specifically. Sure, it depends from sizeof(int). Hummm, for me, the relationship is not quite sure. Can you explain that in more detail, please? Also, how does it imply the 32k limit on the initialiser and the lack of warning when crossed? Jan Waclawek ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Re: Larger than 64K memory sections
On Wed, Aug 26, 2009 at 08:21:00PM -0700, Parthasaradhi Nayani wrote: David Kelly wrote: You are right that we know nothing about the application in question - details here would make it much easier to give recommendations. Hello all, I mentioned 4MB flash as it is the HW spec. This 4MB gets filled over a period of time. 4 million bytes or bits? Most FLASH devices are sized by the bit. Details of application - I have data packets each 32 bytes in size and we have accommodate 2000 of these (predefined). 32 * 2000 = 6400 bytes. This I plan to put in a part of the 4MB Flash. Rest of the memory will be used for storing records comprising of these data packets with data and time etc. The records will be deleted from time to time but the data packets will remain. It is possible to use a long int as an address pointer from the start of the available memory (after the data packets) and store records. I still curious to know how one can create a section larger than 64K. What you describe is probably best *not* mapped into avr-gcc name space or AVR address space. Is probably best to #define the starting offsets of each of your blocks of data. No matter what you do you won't be able to say *MyUInt16Ptr = 0x1234; you will have to write a routine and use it something like this: u16_value = 0x1234; result = Write4MBFlash( (uint32_t)MyUint16Ptr, sizeof(uint16_t), u16_value ); All the external SPI FLASH devices I have used are paged. One read/writes to a RAM buffer in the device then flush that buffer to a page in FLASH. IIRC the Atmel device I last used had 264 byte pages which served to complicate addressing if one insisted on using all 264 bytes. Believe the designer's intent was that one use 256 bytes as a sector and the other 8 bytes for tracking usage, even linking to previous sector and next sector for a form of filesystem. Atmel had a very useful appnote containing C routines for access to their DataFlash parts which helped a lot. I felt the need to heavily edit it for style and naming convention. Rearranged a bit, and deleted a lot that I didn't use. But it was a very good start. -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Re: Larger than 64K memory sections
On Thu, Aug 27, 2009 at 09:55:05AM -0500, David Kelly wrote: On Wed, Aug 26, 2009 at 08:21:00PM -0700, Parthasaradhi Nayani wrote: Details of application - I have data packets each 32 bytes in size and we have accommodate 2000 of these (predefined). 32 * 2000 = 6400 bytes. Arrgh! Decaf! 64,000 bytes. Half of a megabit. -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] Re: Larger than 64K memory sections
On Thu, Aug 27, 2009 at 09:55:05AM -0500, David Kelly wrote: On Wed, Aug 26, 2009 at 08:21:00PM -0700, Parthasaradhi Nayani wrote: Details of application - I have data packets each 32 bytes in size and we have accommodate 2000 of these (predefined). 32 * 2000 = 6400 bytes. Arrgh! Decaf! 64,000 bytes. Half of a megabit. :D must... find antidote Stu ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Problem allocating memory in xflash
From: Joerg Wunsch j...@uriah.heep.sax.de Sure, it depends from sizeof(int). My array size is 32K bytes and the section is supposed to be 64K right? and is not the built-in limit of a section 64K? Thanks. Regards Nayani ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Problem allocating memory in xflash
From: Jan Waclawek konf...@efton.sk Sure, it depends from sizeof(int). Hummm, for me, the relationship is not quite sure. Can you explain that in more detail, please? I tried to allocate 32K bytes of memory. I am not sure if this is a problem of user defined sections. Nayani ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Re: Larger than 64K memory sections
From: David Kelly dke...@hiwaay.net 4 million bytes or bits? Most FLASH devices are sized by the bit. It is 4M Bytes. No matter what you do you won't be able to say *MyUInt16Ptr = 0x1234; you will have to write a routine and use it something like this: u16_value = 0x1234; result = Write4MBFlash( (uint32_t)MyUint16Ptr, sizeof(uint16_t), u16_value ); One advantage I found, using name spaces (sections) is, generating a hex file for initialised data, which can be downloaded through serial port. All the external SPI FLASH devices I have used are paged. One read/writes to a RAM buffer in the device then flush that buffer to a page in FLASH. IIRC the Atmel device I last used had 264 byte pages which served to complicate addressing if one insisted on using all 264 bytes. Believe the designer's intent was that one use 256 bytes as a sector and the other 8 bytes for tracking usage, even linking to previous sector and next sector for a form of filesystem. Never thought of this (using the extra 8 bytes for tracking/linking to other sectors) Atmel had a very useful appnote containing C routines for access to their DataFlash parts which helped a lot. I felt the need to heavily edit it for style and naming convention. Rearranged a bit, and deleted a lot that I didn't use. But it was a very good start. Will check Atmel's site . Thank you. Nayani ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
