Re: [avr-gcc-list] Re: Larger than 64K memory sections
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. 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. Nayani ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] Re: Larger than 64K memory sections
David Kelly wrote:
On Wed, Aug 26, 2009 at 03:10:05PM +0200, David Brown wrote:
All in all, I can't see any advantage to the OP in using memory
sections here, and I can see a great many complications if it can be
made to work at all.
I agree that with the avr-gcc toolset that a great many complications
will occur if one tries to map 4MB into the existing 4MB memory space
used by the linker. For lack of multiple address spaces the AVR tools
magically assume an address space way out in never-never land is EEPROM.
Perhaps the linker can be made 64-bit with minimal effort?
A 32-bit address space has 4 GB, so there is no need to go to 64-bit.
But the avr-gcc tools already have some "magic" to fit a 16-bit data
space, 16-bit eeprom space, and >16-bit flash space at different
addresses within a virtual 32-bit address space that does not really
exist on the avr. Adding new large address spaces may be easy, or it
may be complicated - I have not tried this myself, but I it would at
least require some effort to understand the existing system and see what
is involved.
I disagree with the claim that mapping external regions like this in to
linker address space is a bad idea. We know nothing of the user's
application or design for utilizing this space. Is very useful to create
named globals and let the linker assign the address whether or not this
global is in FLASH, RAM, EEPROM, or an external device. Otherwise one
must manually manage allocation.
You are right that we know nothing about the application in question -
details here would make it much easier to give recommendations. But for
most purposes, standard allocation of global data in memory spaces is
only suitable for code flash and ram data - not eeprom, external flash,
or external devices. The problem is that the compiler and/or linker are
free to re-order and re-arrange any objects they allocate.
Suppose you've made a payment card application. In one place, you've
got an eeprom-allocated variable "moneyLeft", and in another place
you've got "runTimeSeconds". When re-compiling after a change, the
compiler/linker could easily swap these two - updating software from
version 1.00.01 to 1.00.02 would then trash your eeprom data.
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?
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.
The same sort of system will work for external data, although I would
guess that the 4 MB flash will be filled with an array or other such
structure - it would be easier to fit the details within getter and
setter access functions. Typedef'ed structs, offsetof and sizeof will
probably still feature in the code - precisely to avoid manual allocation.
___
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, 8/26/09, David Brown wrote: From: David Brown Subject: [avr-gcc-list] Re: Larger than 64K memory sections To: avr-gcc-list@nongnu.org Date: Wednesday, August 26, 2009, 6:40 PM > sections for EEPROM and FLASH - and the latter can be >64kB large. Yes, that's true. I hadn't thought about the EEPROM sections, Hello, Perhaps as David Brown mentioned it may be better to manually handle larger memories, but I would like to know how larger sections are defined in the makefile? Any pointers will be appreciated. Thank you. 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
On Wed, Aug 26, 2009 at 03:10:05PM +0200, David Brown wrote: > > All in all, I can't see any advantage to the OP in using memory > sections here, and I can see a great many complications if it can be > made to work at all. I agree that with the avr-gcc toolset that a great many complications will occur if one tries to map 4MB into the existing 4MB memory space used by the linker. For lack of multiple address spaces the AVR tools magically assume an address space way out in never-never land is EEPROM. Perhaps the linker can be made 64-bit with minimal effort? I disagree with the claim that mapping external regions like this in to linker address space is a bad idea. We know nothing of the user's application or design for utilizing this space. Is very useful to create named globals and let the linker assign the address whether or not this global is in FLASH, RAM, EEPROM, or an external device. Otherwise one must manually manage allocation. -- 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
[avr-gcc-list] Re: Larger than 64K memory sections
Jan Waclawek wrote: I am using a 4MB flash memory with my Mega64. I would like to create a memory section for the entire 4MB. Is it possible? If yes, how can this be done in the makefile? Thank you very much for your time. You can't directly access such large memory areas from an AVR, therefore it makes no sense to talk about a memory section for it. IMHO your implication is incorrect. Even if there's no builtin support for non-RAM variables in avr-gcc (yet), we already have sections for EEPROM and FLASH - and the latter can be >64kB large. Yes, that's true. I hadn't thought about the EEPROM sections, mainly because I think they are often a bad idea in practice and thus don't use them (it's far too easy for the final addresses to change between builds, making a mess of stored data after changing the software. I much prefer to use a struct at a fixed manually-specified address to order my eeprom data). Still, without direct access the OP will need manual paging at least (and possibly more manual work - for all we know, this could be a serial flash, or 16-bit flash connected via GPIOs, or whatever). Memory sections and pointer arithmetic get messy or impossible after 32K or 64K limits. A 4MB section may also crash with other sections in the linker file unless you are very careful. All in all, I can't see any advantage to the OP in using memory sections here, and I can see a great many complications if it can be made to work at all. ___ 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
>> I am using a 4MB flash memory with my Mega64. I would like to create a >> memory section for the entire 4MB. Is it possible? If yes, how can this >> be done in the makefile? Thank you very much for your time. >> > >You can't directly access such large memory areas from an AVR, therefore >it makes no sense to talk about a memory section for it. IMHO your implication is incorrect. Even if there's no builtin support for non-RAM variables in avr-gcc (yet), we already have sections for EEPROM and FLASH - and the latter can be >64kB large. JW ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] Re: Larger than 64K memory sections
Parthasaradhi Nayani wrote: Hello all, I am using a 4MB flash memory with my Mega64. I would like to create a memory section for the entire 4MB. Is it possible? If yes, how can this be done in the makefile? Thank you very much for your time. Regards, Nayani You can't directly access such large memory areas from an AVR, therefore it makes no sense to talk about a memory section for it. You have to manually implement some sort of access to the memory (for example, you might have the device connected to the standard external memory bus, which provides the low address bits, then use paging for the higher bits). ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] Problem allocating memory in xflash
Hello all, I have created an external flash memory section in the makefile thus LDFLAGS += -Wl,--section-start,.exflash=0x85 and named (defined) this section as XFLASH. 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" If the size of the section is 64K, then the above i well within the limit but still the error is popping up. Has this anything to do with sign? Please advice. Thank you. Regards, Nayani ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] Larger than 64K memory sections
Hello all, I am using a 4MB flash memory with my Mega64. I would like to create a memory section for the entire 4MB. Is it possible? If yes, how can this be done in the makefile? Thank you very much for your time. Regards, Nayani ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
