From: David Kelly
>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_
From: Jan Waclawek >
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
__
From: Joerg Wunsch >
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-li
> 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 = 6
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!
Jan Waclawek wrote:
>>Sure, it depends from sizeof(int).
> Hummm, for me, the relationship is not quite "sure". Can you explain
> that in more detail, please?
An array is implicitly (without the option to change it) indexed by
type `int'. Not `unsigned int', it's `int' -- because negative
indi
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.
>> 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 Wacla
Jan Waclawek wrote:
> So, it appears to be limit of avr-gcc specifically.
Sure, it depends from sizeof(int).
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have source
Tero Sinervo wrote:
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 i
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
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
>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-i
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
14 matches
Mail list logo