Use RAM to modify a field

I need to use Copy and 8K block of data (from a parameter block address in
flash) to RAM, modify data at a particular offset and copy the contents
back to flash. The size of the RAM is 256K.  I believe dynamic memory
allocation with heap (using a pointer)should work for this? Would like to
know if this would be the right way togo?
Note: Please notify if any detail seems missing. 
---------------------------------------
Posted through http://www.EmbeddedRelated.com

On Fri, 01 Apr 2016 19:37:22 -0500, srao wrote:

> I need to use Copy and 8K block of data (from a parameter block address
> in flash) to RAM, modify data at a particular offset and copy the
> contents back to flash. The size of the RAM is 256K.  I believe dynamic
> memory allocation with heap (using a pointer)should work for this? Would
> like to know if this would be the right way togo?
> Note: Please notify if any detail seems missing.

A general description of what you're doing would be useful.

If it's an embedded system and it has to run forever, using the heap is 
probably a bad idea (Google "heap fragmentation").  Truly paranoid* 
embedded engineers would allocate the block statically unless that makes 
the system run out of RAM.  If they did NOT allocate it statically, then 
they would ask themselves if they have enough memory in the first place.

* In embedded, "paranoid" often means "successful"

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

On 03/04/16 02:35, Tim Wescott wrote:
> On Fri, 01 Apr 2016 19:37:22 -0500, srao wrote:
> 
>> I need to use Copy and 8K block of data (from a parameter block address
>> in flash) to RAM, modify data at a particular offset and copy the
>> contents back to flash. The size of the RAM is 256K.  I believe dynamic
>> memory allocation with heap (using a pointer)should work for this? Would
>> like to know if this would be the right way togo?
>> Note: Please notify if any detail seems missing.
> 
> A general description of what you're doing would be useful.
> 
> If it's an embedded system and it has to run forever, using the heap is 
> probably a bad idea (Google "heap fragmentation").  Truly paranoid* 
> embedded engineers would allocate the block statically unless that makes 
> the system run out of RAM.  If they did NOT allocate it statically, then 
> they would ask themselves if they have enough memory in the first place.
> 
> * In embedded, "paranoid" often means "successful"
> 

When you have 256K of ram on the chip, and only need 8K for this block
or buffer, then it's not just the paranoid developers that would use
static allocation - it's the lazy* ones too.

* In embedded, "lazy" also often means "successful".  Good enough is
good enough - a program that does it's job in a simple way is at least
as good as one that does the job in a more advanced way, while the
simpler way has lower development costs and therefore a happier customer.

On 03/04/16 02:35, Tim Wescott wrote:
> On Fri, 01 Apr 2016 19:37:22 -0500, srao wrote:
> 
>> I need to use Copy and 8K block of data (from a parameter block address
>> in flash) to RAM, modify data at a particular offset and copy the
>> contents back to flash. The size of the RAM is 256K.  I believe dynamic
>> memory allocation with heap (using a pointer)should work for this? Would
>> like to know if this would be the right way togo?
>> Note: Please notify if any detail seems missing.
> 
> A general description of what you're doing would be useful.
> 
> If it's an embedded system and it has to run forever, using the heap is 
> probably a bad idea (Google "heap fragmentation").  Truly paranoid* 
> embedded engineers would allocate the block statically unless that makes 
> the system run out of RAM.  If they did NOT allocate it statically, then 
> they would ask themselves if they have enough memory in the first place.
> 
> * In embedded, "paranoid" often means "successful"
> 

When you have 256K of ram on the chip, and only need 8K for this block
or buffer, then it's not just the paranoid developers that would use
static allocation - it's the lazy* ones too.

* In embedded, "lazy" also often means "successful".  Good enough is
good enough - a program that does it's job in a simple way is at least
as good as one that does the job in a more advanced way, while the
simpler way has lower development costs and therefore a happier customer.

Il giorno luned� 4 aprile 2016 08:55:18 UTC+2, David Brown ha scritto:
> On 03/04/16 02:35, Tim Wescott wrote:
> > On Fri, 01 Apr 2016 19:37:22 -0500, srao wrote:
> > 
> >> I need to use Copy and 8K block of data (from a parameter block address
> >> in flash) to RAM, modify data at a particular offset and copy the
> >> contents back to flash. The size of the RAM is 256K.  I believe dynamic
> >> memory allocation with heap (using a pointer)should work for this? Would
> >> like to know if this would be the right way togo?
> >> Note: Please notify if any detail seems missing.
> > 
> > A general description of what you're doing would be useful.
> > 
> > If it's an embedded system and it has to run forever, using the heap is 
> > probably a bad idea (Google "heap fragmentation").  Truly paranoid* 
> > embedded engineers would allocate the block statically unless that makes 
> > the system run out of RAM.  If they did NOT allocate it statically, then 
> > they would ask themselves if they have enough memory in the first place.
> > 
> > * In embedded, "paranoid" often means "successful"
> > 
> 
> When you have 256K of ram on the chip, and only need 8K for this block
> or buffer, then it's not just the paranoid developers that would use
> static allocation - it's the lazy* ones too.
> 
> * In embedded, "lazy" also often means "successful".  Good enough is
> good enough - a program that does it's job in a simple way is at least
> as good as one that does the job in a more advanced way, while the
> simpler way has lower development costs and therefore a happier customer.

also simpler usually means less bugs...

Bye Jack

On 2016-04-04, David Brown <david.brown@hesbynett.no> wrote:

> * In embedded, "lazy" also often means "successful".  Good enough is
>   good enough - a program that does it's job in a simple way is at least
>   as good as one that does the job in a more advanced way, while the
>   simpler way has lower development costs and therefore a happier customer.

And the simpler way is more likely to be right (both now and
especially in the future when somebody else has to make changes to
it).

Good enough is often better.

-- 
Grant Edwards               grant.b.edwards        Yow! MMM-MM!!  So THIS is
                                  at               BIO-NEBULATION!
                              gmail.com            

>On Fri, 01 Apr 2016 19:37:22 -0500, srao wrote:
>
>> I need to use Copy and 8K block of data (from a parameter block
address
>> in flash) to RAM, modify data at a particular offset and copy the
>> contents back to flash. The size of the RAM is 256K.  I believe
dynamic
>> memory allocation with heap (using a pointer)should work for this?
Would
>> like to know if this would be the right way togo?
>> Note: Please notify if any detail seems missing.
>
>A general description of what you're doing would be useful.
>
>If it's an embedded system and it has to run forever, using the heap is 
>probably a bad idea (Google "heap fragmentation").  Truly paranoid* 
>embedded engineers would allocate the block statically unless that makes

>the system run out of RAM.  If they did NOT allocate it statically, then

>they would ask themselves if they have enough memory in the first place.
>
>* In embedded, "paranoid" often means "successful"
>
>-- 
>
>Tim Wescott
>Wescott Design Services
>http://www.wescottdesign.com

Hi Tim, 

Thank you for your response. To describe the goal briefly, I want to
update a particular field in this block. I use a given address offset to
update this 32 byte field. Please let me know if you need more info.
---------------------------------------
Posted through http://www.EmbeddedRelated.com

>On Fri, 01 Apr 2016 19:37:22 -0500, srao wrote:
>
>> I need to use Copy and 8K block of data (from a parameter block
address
>> in flash) to RAM, modify data at a particular offset and copy the
>> contents back to flash. The size of the RAM is 256K.  I believe
dynamic
>> memory allocation with heap (using a pointer)should work for this?
Would
>> like to know if this would be the right way togo?
>> Note: Please notify if any detail seems missing.
>
>A general description of what you're doing would be useful.
>
>If it's an embedded system and it has to run forever, using the heap is 
>probably a bad idea (Google "heap fragmentation").  Truly paranoid* 
>embedded engineers would allocate the block statically unless that makes

>the system run out of RAM.  If they did NOT allocate it statically, then

>they would ask themselves if they have enough memory in the first place.
>
>* In embedded, "paranoid" often means "successful"
>
>-- 
>
>Tim Wescott
>Wescott Design Services
>http://www.wescottdesign.com

Also,

Would static allocation utilize RAM space? I am using this for an embedded
application which has to read data out from hardware, store it in RAM and
modify the field. 

The RAM here is not part of processor.A separate flashchip  has
boot+flash+ RAM region  which the application uses. C++ borland compiler
in use.  Does static memory allocation use space out of RAM? Or does it
depend on the compiler? 
---------------------------------------
Posted through http://www.EmbeddedRelated.com

On Mon, 04 Apr 2016 08:55:15 +0200, David Brown wrote:

> On 03/04/16 02:35, Tim Wescott wrote:
>> On Fri, 01 Apr 2016 19:37:22 -0500, srao wrote:
>> 
>>> I need to use Copy and 8K block of data (from a parameter block
>>> address in flash) to RAM, modify data at a particular offset and copy
>>> the contents back to flash. The size of the RAM is 256K.  I believe
>>> dynamic memory allocation with heap (using a pointer)should work for
>>> this? Would like to know if this would be the right way togo?
>>> Note: Please notify if any detail seems missing.
>> 
>> A general description of what you're doing would be useful.
>> 
>> If it's an embedded system and it has to run forever, using the heap is
>> probably a bad idea (Google "heap fragmentation").  Truly paranoid*
>> embedded engineers would allocate the block statically unless that
>> makes the system run out of RAM.  If they did NOT allocate it
>> statically, then they would ask themselves if they have enough memory
>> in the first place.
>> 
>> * In embedded, "paranoid" often means "successful"
>> 
>> 
> When you have 256K of ram on the chip, and only need 8K for this block
> or buffer, then it's not just the paranoid developers that would use
> static allocation - it's the lazy* ones too.
> 
> * In embedded, "lazy" also often means "successful".  Good enough is
> good enough - a program that does it's job in a simple way is at least
> as good as one that does the job in a more advanced way, while the
> simpler way has lower development costs and therefore a happier
> customer.

True, in my experience -- each line of code is an opportunity for a bug, 
so fewer lines of code often means fewer bugs.

(Unless the pointy-haired boss starts handing out awards for fewest lines 
of code to get the job done -- then your job becomes an obfuscated code 
contest, and bug counts go up.)

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

On Mon, 04 Apr 2016 12:09:53 -0500, srao wrote:

>>On Fri, 01 Apr 2016 19:37:22 -0500, srao wrote:
>>
>>> I need to use Copy and 8K block of data (from a parameter block
> address
>>> in flash) to RAM, modify data at a particular offset and copy the
>>> contents back to flash. The size of the RAM is 256K.  I believe
> dynamic
>>> memory allocation with heap (using a pointer)should work for this?
> Would
>>> like to know if this would be the right way togo?
>>> Note: Please notify if any detail seems missing.
>>
>>A general description of what you're doing would be useful.
>>
>>If it's an embedded system and it has to run forever, using the heap is
>>probably a bad idea (Google "heap fragmentation").  Truly paranoid*
>>embedded engineers would allocate the block statically unless that makes
> 
>>the system run out of RAM.  If they did NOT allocate it statically, then
> 
>>they would ask themselves if they have enough memory in the first place.
>>
>>* In embedded, "paranoid" often means "successful"
>>
>>--
>>
>>Tim Wescott Wescott Design Services http://www.wescottdesign.com
> 
> Also,
> 
> Would static allocation utilize RAM space? I am using this for an
> embedded application which has to read data out from hardware, store it
> in RAM and modify the field.
> 
> The RAM here is not part of processor.A separate flashchip  has
> boot+flash+ RAM region  which the application uses. C++ borland compiler
> in use.  Does static memory allocation use space out of RAM? Or does it
> depend on the compiler?

I believe that you are asking if using the "static" keyword in some C or C
++ code would cause the tools to put the space in RAM.

The answer is that if the tools are working correctly, and if the space 
is not declared as "const", then yes.  The tools working correctly 
depends on both the tools (Borland was still good the last time I used 
it) and how they're set up, though, so I can't just say that it WILL work 
for you based on the fact that it's Borland.

HOWEVER -- if you're declaring a variable outside of any struct, 
function, or whatever, then "static" is telling the compiler about who 
can see the variable, not whether the variable is writable (and thus in 
RAM) or not.

Here's what SHOULD happen in most embedded systems, in C or C++, if you 
declare a variable outside of any struct, function, or whatever:

// "whatever" gets put in read-only memory, and is visible outside of
// the resulting object file
const sometype whatever = <inital value>;

// "whatever" gets put in read-only memory, and is only visible to
// things within the C file:
const static sometype whatever = <initial value>;

// "whatever" gets put in RAM, is visible outside of
// the resulting object file, and (if the tools are set
// up correctly) filled with 0 bytes:
sometype whatever;

// "whatever" gets put in RAM, is only visible to
// things within the C file, and (if the tools are set
// up correctly) filled with 0 bytes:
static sometype whatever;

HTH

If David Brown says that I'm wrong, just fill in a resigned sigh from me 
and believe what he says.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com