Use RAM to modify a field

On Mon, 04 Apr 2016 12:34:28 -0500, Tim Wescott wrote:

> 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.

I failed to mention:

If you want to permanently allocate some space at compile time, from 
within a function, then you need to use "static" -- otherwise the 
compiler will try to create it on the heap or on the stack.  For an 8kB 
hunk of memory, this would probably cause Bad Things to happen.

void my_function(void)
{
  char bob[8192];  // Allocates on stack or heap -- ick
  static char sue [8192];  // allocates in RAM, only visible
                           // within this function
}

Note that doing this, with this large a chunk of memory, is probably an 
indication that you're doing something wrong.  I could easily see your 
buffer as being static within a C file (or a C++ structure) that's 
dedicated to talking to flash -- but I can't easily see it within a 
function.

-- 

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

On Mon, 04 Apr 2016 12:25:03 -0500, Tim Wescott
<seemywebsite@myfooter.really> wrote:

>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.)

It depends very much about the expected number of units produced every
year. If the expected volume is 100 units or less, it makes sense of
less optimized, preferably COTS devices.

However, if the expected volume is millions of units each year, t
makes sense to do a lot of optimization.

An anecdote from the TV industry when discrete components were used:
Quite a lot of engineering effort could be used to optimize some
circuit so that cheaper resistors with 20 % tolerance could be used,
instead of the 5 % resistors originally designed.

Tim Wescott wrote:

> On Mon, 04 Apr 2016 12:34:28 -0500, Tim Wescott wrote:
>
>> 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.
>
> I failed to mention:
>
> If you want to permanently allocate some space at compile time, from 
> within a function, then you need to use "static" -- otherwise the 
> compiler will try to create it on the heap or on the stack.  For an 8kB 
> hunk of memory, this would probably cause Bad Things to happen.
>
> void my_function(void)
> {
>   char bob[8192];  // Allocates on stack or heap -- ick
>   static char sue [8192];  // allocates in RAM, only visible
>                            // within this function
> }
>
> Note that doing this, with this large a chunk of memory, is probably an 
> indication that you're doing something wrong.  I could easily see your 
> buffer as being static within a C file (or a C++ structure) that's 
> dedicated to talking to flash -- but I can't easily see it within a 
> function.
>

Eh, I've definitely decided I'm just going to drop a megablock like that
on the stack.  Especially if:
  A) You're trying to be MISRA or MISRish, and have nixed malloc from
your vocabulary; and
  B) You've got a single uniform memory, i.e. on-die RAM is enough.

Once you don't have a heap the only things left are static allocations
and the stack, so you might as well have a giant stack.

The nice thing about putting it on the stack is that it's self-cleaning.
 Unlike with heap allocation there's no concerns about fragmentation
or running out of memory; you hit that closing brace and the allocation
neatly and perfectly unwinds itself.  Especially since, for something
like a flash update, it's not like you're going to be doing any kinds
of deeply nested calls underneath it; you're basically at the bottom of
where you're going to take the stack at that point.

It "feels wrong", definitely, because you know that that's not how it's
done.  But it works beautifully and gives you fully deterministic
multipurposing of memory.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com

Email address domain is currently out of order.  See above to fix.

On Mon, 04 Apr 2016 21:42:42 +0300, upsidedown wrote:

> On Mon, 04 Apr 2016 12:25:03 -0500, Tim Wescott
> <seemywebsite@myfooter.really> wrote:
> 
>>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.)
> 
> It depends very much about the expected number of units produced every
> year. If the expected volume is 100 units or less, it makes sense of
> less optimized, preferably COTS devices.
> 
> However, if the expected volume is millions of units each year, t makes
> sense to do a lot of optimization.
> 
> An anecdote from the TV industry when discrete components were used:
> Quite a lot of engineering effort could be used to optimize some circuit
> so that cheaper resistors with 20 % tolerance could be used, instead of
> the 5 % resistors originally designed.

I think we're speaking at cross purposes.  There are those out there who 
write lots of lines of code just because they like writing lots of lines 
of code.  My comments were meant to discourage them.

Personally, my customers get code that's (a) 100% written for their 
specific needs, (b) reused from other, older projects, (c) written for 
them but intended for reuse (i.e., a comms interface for something I 
haven't used before), or (d) obtained from a 3rd party (open-source or 
bought).

(b) and (c) are not written for minimal lines of code for any one 
project, but rather for robustness over a lot of projects.

-- 

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

On Mon, 04 Apr 2016 18:49:30 +0000, Rob Gaddi wrote:

> Tim Wescott wrote:
> 
>> On Mon, 04 Apr 2016 12:34:28 -0500, Tim Wescott wrote:
>>
>>> 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.
>>
>> I failed to mention:
>>
>> If you want to permanently allocate some space at compile time, from
>> within a function, then you need to use "static" -- otherwise the
>> compiler will try to create it on the heap or on the stack.  For an 8kB
>> hunk of memory, this would probably cause Bad Things to happen.
>>
>> void my_function(void)
>> {
>>   char bob[8192];  // Allocates on stack or heap -- ick static char sue
>>   [8192];  // allocates in RAM, only visible
>>                            // within this function
>> }
>>
>> Note that doing this, with this large a chunk of memory, is probably an
>> indication that you're doing something wrong.  I could easily see your
>> buffer as being static within a C file (or a C++ structure) that's
>> dedicated to talking to flash -- but I can't easily see it within a
>> function.
>>
>>
> Eh, I've definitely decided I'm just going to drop a megablock like that
> on the stack.  Especially if:
>   A) You're trying to be MISRA or MISRish, and have nixed malloc from
> your vocabulary; and
>   B) You've got a single uniform memory, i.e. on-die RAM is enough.
> 
> Once you don't have a heap the only things left are static allocations
> and the stack, so you might as well have a giant stack.
> 
> The nice thing about putting it on the stack is that it's self-cleaning.
>  Unlike with heap allocation there's no concerns about fragmentation
> or running out of memory; you hit that closing brace and the allocation
> neatly and perfectly unwinds itself.  Especially since, for something
> like a flash update, it's not like you're going to be doing any kinds of
> deeply nested calls underneath it; you're basically at the bottom of
> where you're going to take the stack at that point.
> 
> It "feels wrong", definitely, because you know that that's not how it's
> done.  But it works beautifully and gives you fully deterministic
> multipurposing of memory.

That would work if you're running a single thread of execution.  But if 
you're running multiple threads of execution (as in an RTOS) then you'd 
need to provide a humongous block of RAM for each task's thread, or you'd 
have to police which threads use which functions.

-- 

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

>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


:) oh please don't. Been a great help
Thanks Tim, for all that information. 
---------------------------------------
Posted through http://www.EmbeddedRelated.com

>On Mon, 04 Apr 2016 12:34:28 -0500, Tim Wescott wrote:
>
>> 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.
>
>I failed to mention:
>
>If you want to permanently allocate some space at compile time, from 
>within a function, then you need to use "static" -- otherwise the 
>compiler will try to create it on the heap or on the stack.  For an 8kB 
>hunk of memory, this would probably cause Bad Things to happen.
>
>void my_function(void)
>{
>  char bob[8192];  // Allocates on stack or heap -- ick
>  static char sue [8192];  // allocates in RAM, only visible
>                           // within this function
>}
>
>Note that doing this, with this large a chunk of memory, is probably an 
>indication that you're doing something wrong.  I could easily see your 
>buffer as being static within a C file (or a C++ structure) that's 
>dedicated to talking to flash -- but I can't easily see it within a 
>function.
>
>-- 
>
>Tim Wescott
>Wescott Design Services
>http://www.wescottdesign.com

Thanks! Completely understand. So do you feel there is a better way to
handle this?
---------------------------------------
Posted through http://www.EmbeddedRelated.com

>On Mon, 04 Apr 2016 18:49:30 +0000, Rob Gaddi wrote:
>
>> Tim Wescott wrote:
>> 
>>> On Mon, 04 Apr 2016 12:34:28 -0500, Tim Wescott wrote:
>>>
>>>> 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.
>>>
>>> I failed to mention:
>>>
>>> If you want to permanently allocate some space at compile time, from
>>> within a function, then you need to use "static" -- otherwise the
>>> compiler will try to create it on the heap or on the stack.  For an
8kB
>>> hunk of memory, this would probably cause Bad Things to happen.
>>>
>>> void my_function(void)
>>> {
>>>   char bob[8192];  // Allocates on stack or heap -- ick static char
sue
>>>   [8192];  // allocates in RAM, only visible
>>>                            // within this function
>>> }
>>>
>>> Note that doing this, with this large a chunk of memory, is probably
an
>>> indication that you're doing something wrong.  I could easily see
your
>>> buffer as being static within a C file (or a C++ structure) that's
>>> dedicated to talking to flash -- but I can't easily see it within a
>>> function.
>>>
>>>
>> Eh, I've definitely decided I'm just going to drop a megablock like
that
>> on the stack.  Especially if:
>>   A) You're trying to be MISRA or MISRish, and have nixed malloc from
>> your vocabulary; and
>>   B) You've got a single uniform memory, i.e. on-die RAM is enough.
>> 
>> Once you don't have a heap the only things left are static allocations
>> and the stack, so you might as well have a giant stack.
>> 
>> The nice thing about putting it on the stack is that it's
self-cleaning.
>>  Unlike with heap allocation there's no concerns about fragmentation
>> or running out of memory; you hit that closing brace and the
allocation
>> neatly and perfectly unwinds itself.  Especially since, for something
>> like a flash update, it's not like you're going to be doing any kinds
of
>> deeply nested calls underneath it; you're basically at the bottom of
>> where you're going to take the stack at that point.
>> 
>> It "feels wrong", definitely, because you know that that's not how
it's
>> done.  But it works beautifully and gives you fully deterministic
>> multipurposing of memory.
>
>That would work if you're running a single thread of execution.  But if 
>you're running multiple threads of execution (as in an RTOS) then you'd 
>need to provide a humongous block of RAM for each task's thread, or you'd

>have to police which threads use which functions.
>
>-- 
>
>Tim Wescott
>Wescott Design Services
>http://www.wescottdesign.com

the 80C186 does have 64K bytes of STACK space. Though it actually is more
like a single threaded execution, and is also a part of a flash update. If
stack is indeed a best way to go, do you mean we would use a local
variable to store the whole 8K buffer array? 
---------------------------------------
Posted through http://www.EmbeddedRelated.com

srao wrote:

>>On Mon, 04 Apr 2016 18:49:30 +0000, Rob Gaddi wrote:
>>
>>> Tim Wescott wrote:
>>> 
>>>> If you want to permanently allocate some space at compile time, from
>>>> within a function, then you need to use "static" -- otherwise the
>>>> compiler will try to create it on the heap or on the stack.  For an
> 8kB
>>>> hunk of memory, this would probably cause Bad Things to happen.
>>>>
>>>> void my_function(void)
>>>> {
>>>>   char bob[8192];  // Allocates on stack or heap -- ick static char
> sue
>>>>   [8192];  // allocates in RAM, only visible
>>>>                            // within this function
>>>> }
>>>>
>>>> Note that doing this, with this large a chunk of memory, is probably
> an
>>>> indication that you're doing something wrong.  I could easily see
> your
>>>> buffer as being static within a C file (or a C++ structure) that's
>>>> dedicated to talking to flash -- but I can't easily see it within a
>>>> function.
>>>>
>>>>
>>> Eh, I've definitely decided I'm just going to drop a megablock like
> that
>>> on the stack.  Especially if:
>>>   A) You're trying to be MISRA or MISRish, and have nixed malloc from
>>> your vocabulary; and
>>>   B) You've got a single uniform memory, i.e. on-die RAM is enough.
>>> 
>>> Once you don't have a heap the only things left are static allocations
>>> and the stack, so you might as well have a giant stack.
>>> 
>>> The nice thing about putting it on the stack is that it's
> self-cleaning.
>>>  Unlike with heap allocation there's no concerns about fragmentation
>>> or running out of memory; you hit that closing brace and the
> allocation
>>> neatly and perfectly unwinds itself.  Especially since, for something
>>> like a flash update, it's not like you're going to be doing any kinds
> of
>>> deeply nested calls underneath it; you're basically at the bottom of
>>> where you're going to take the stack at that point.
>>> 
>>> It "feels wrong", definitely, because you know that that's not how
> it's
>>> done.  But it works beautifully and gives you fully deterministic
>>> multipurposing of memory.
>>
>>That would work if you're running a single thread of execution.  But if 
>>you're running multiple threads of execution (as in an RTOS) then you'd 
>>need to provide a humongous block of RAM for each task's thread, or you'd
>
>>have to police which threads use which functions.
>>
>>-- 
>>
>>Tim Wescott
>>Wescott Design Services
>>http://www.wescottdesign.com
>
> the 80C186 does have 64K bytes of STACK space. Though it actually is more
> like a single threaded execution, and is also a part of a flash update. If
> stack is indeed a best way to go, do you mean we would use a local
> variable to store the whole 8K buffer array? 
> ---------------------------------------
> Posted through http://www.EmbeddedRelated.com

"Best" is relative.  Using the stack for this is, IMO, "not clearly
stupid".

There are problems.  You need to be dead sure that you're not going to
overflow the stack; and that includes if you get an interrupt while
you're in the flash update routine, which is going to push your stack up
as well.

If you've got no interrupts and are completely deterministic
in your execution then it gets pretty easy to determine whether you've
got a risk: just check your stack pointer when you hit that routine as
is, and make sure there's 8K left.  Or, better, that there's well more
than 8K left because you don't want to run into a problem later.

If you're not deterministic than you need to make sure that even under
the worst case execution you're not going to overrun it.  I tend to
have my initialization code fill the entire stack with 0xDEADBEEF.
That way, at any time, I can run a stack check that will give me the
high water mark on stack usage, so I can run around stress testing my
application to make sure I've got plenty of margin.

Another approach is basically a "monoheap".  You block off a static
region of memory, similar to what Tim and others have suggested, and you
make sure that it only has one use at a time; if your flash update code
is using it than no one else is.  Then you don't have to worry about
malloc/free and fragmentation because there's only one big chunk; you've
got dibs on all of it or none.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com

Email address domain is currently out of order.  See above to fix.

On Mon, 04 Apr 2016 15:55:00 -0500, srao wrote:

>>On Mon, 04 Apr 2016 12:34:28 -0500, Tim Wescott wrote:
>>
>>> 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.
>>
>>I failed to mention:
>>
>>If you want to permanently allocate some space at compile time, from
>>within a function, then you need to use "static" -- otherwise the
>>compiler will try to create it on the heap or on the stack.  For an 8kB
>>hunk of memory, this would probably cause Bad Things to happen.
>>
>>void my_function(void)
>>{
>>  char bob[8192];  // Allocates on stack or heap -- ick static char sue
>>  [8192];  // allocates in RAM, only visible
>>                           // within this function
>>}
>>
>>Note that doing this, with this large a chunk of memory, is probably an
>>indication that you're doing something wrong.  I could easily see your
>>buffer as being static within a C file (or a C++ structure) that's
>>dedicated to talking to flash -- but I can't easily see it within a
>>function.
>>
>>--
>>
>>Tim Wescott Wescott Design Services http://www.wescottdesign.com
> 
> Thanks! Completely understand. So do you feel there is a better way to
> handle this?

Better than what?

Keep in mind that with Embedded system programming there is no "best".  
Using the heap is almost always not at all a good idea, but there are a 
very few applications where it'll work OK.  Ditto for just about any 
other idea that works.  Driving factors are how long the thing has to 
work between reboots, how bad it is if the processor cocks up its toes 
unexpectedly, how much RAM you're actually using, how much time you have 
to spend on coding, and, to some extent, how much time you need to 
complete the operation.

If, for instance, you told us that the product has to run for years and 
years between reboots that would point away from using the heap, ever.  
But if you then said that the _only_ time that this code is ever used is 
in the factory or by service personnel who then immediately cycle power, 
then I'd say "sure, go ahead" (in fact, this is one of the two places 
where I'll routinely use the heap).

In nearly all cases that I can think of, statically allocating a chunk 
that's dedicated to this is best, because it's safe (unless you're 
running out of RAM) and easy (so, fewer lines of code and hence fewer 
opportunities for bugs).  But it's not best if you're almost out of 
memory.

Rob's idea of allocating on the stack would work well in a lot of cases, 
but you're using an old 16-bit x86 processor with segments, and that 
makes it a not-quite-so-good idea because you're not talking about up to 
1/32 of the available RAM, you're talking about up to 1/8 of the 
available stack space -- that seems a lot more cramped to me.

Rob's idea of a "monoheap" could also be best, if you're really having to 
shake the box to try to make room for a bit more cereal.

-- 

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