Use RAM to modify a field

On 04/04/16 20:42, upsidedown@downunder.com 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.

You are mixing up the size of the source code (lines of code) and the
size of the object code.  For high volume products, smaller object code
can mean using a part with less flash, leading to real cost savings.
For low volume products, you usually should not worry about the code
size (until you risk exceeding the available flash for that type of device).

But Tim is talking about source code lines.  While there is clearly a
correlation between source code size and object code size, there is a
wide range of possible scaling factors.  Tim recommends avoiding making
the source code unnecessarily large or complicated - but also avoiding
making it unnecessarily compact.  That is, of course, good advice.
Unfortunately there are some PHB's that reward very tight code (usually
in the mistaken belief that this means smaller object code) - and there
are perhaps even more that reward loose and wordy code (in the mistaken
belief that lines of code written is a measure of productivity).



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

On 04/04/16 19:34, 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.
> 

That's my cue for the nit-pick!  Your explanation is a good start, but
there are a couple of other points that I think are worth mentioning.

It is not clear if the OP is actually using C or C++ (his compiler
supports both).  But in the case of

	const sometype whatever = <initial value>;

there is a difference.  In C, the "whatever" has external linkage by
default - it is visible outside of the current object file, assuming
there is a matching "extern" declaration.  In C++, "whatever" has
internal linkage by default - it acts like "static const", unless there
is a matching "extern" declaration visible in the defining translation unit.

(The external visibility does not affect whether the object is put in
read-only or writeable memory, of course.)

Personally, I always make my file-level functions and data either
explicitly "static" (even in C++, in order to be consistent with my C
code), unless it has to be externally visible - in which case there is
always an "extern" declaration in the module's header file which is
#include'd by both the defining module and other modules that use it.
That keeps everything clear and consistent.

And I prefer to write "static const" rather than "const static" - the
compiler accepts both, of course, but I am more fussy!


Also note that when you make something "const", the compiler/linker does
not have to put it into read-only memory.  It /may/ put it in read-only
memory, and any attempt to change it in the program is undefined
behaviour, but it could equally well use ram.  On a PC, for example, it
will go in ram - but it will be put in a different segment from
read-write memory, and the segment will be marked read only.  On an AVR
(which has different cpu instructions for accessing flash and ram),
const data is usually put in RAM so that it can be accessed using the
same instructions as non-const data.  We don't know enough about the
OP's system to know where static const data would end up.

And of course if the compiler feels it doesn't actually /need/ to put
static const data in memory, due to the way it is used (or not used), it
will not put it in any memory.

On 04/04/16 20:41, 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
> }

I know of no compiler that would put "bob" on the heap in the function
above - indeed, I am not convinced that the compiler could do so in
general.  It /could/ have a separate memory area, and it could allocate
the space statically, perhaps shared with other such data if the
functions do not overlap (compilers for cpu's like the 8051 will do
that).  But assuming a half-decent processor and a normal compiler
setup, "bob" will always go on the stack.  Whether that is "ick" or not
depends on how much stack space you have, and how you use it.

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

If you are only ever using it within the one function, there is no
difference between declaring a static block within a function or outside
it.  (It may be more convenient for debugging, or for checking the map
file, if it is file-level rather than inside the function.  But the
memory usage and the generated code will be the same.)

And if you have a "bare metal" system, rather than separate tasks with
separate stacks, then your ram layout very often has the stack at the
top of the ram, growing downwards, and statically allocated data built
up from the bottom (followed by the heap if you use one).  It matters
little whether the buffer lives at a fixed address near the bottom of
the ram, or if it gets allocated on the stack near the top of the ram.

If you have multiple independent functions with local data like this,
putting the data on the stack makes it easy to re-use the space.  It can
also be convenient to use a VLA if the size of the space needed is not
known until run-time (but be sure to check the maximum size!).

But if you have a processor with poor address registers (such as an
AVR), using the stack will give less efficient code.  Putting the data
on the stack also makes it less "visible" (such as in the map file, or
with size-checking utilities.  Both methods are valid.

On 04/04/16 22:50, srao wrote:
Tim Wescott wrote:
>>
>> 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. 

I think Tim meant that I know more of the "ugly details" of C and C++
than he does, which I believe is true.  On the other hand, Tim is
fantastic and explaining the important issues in embedded development.
So pay attention to anything he says, and read my parts if you need the
fine print (but don't feel bad if you don't understand it in one
reading).  My posts are complementary to Tim's, not a replacement.

On 5.4.16 09:17, David Brown wrote:
> On 04/04/16 19:34, 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.
>>
>
> That's my cue for the nit-pick!  Your explanation is a good start, but
> there are a couple of other points that I think are worth mentioning.
>
> It is not clear if the OP is actually using C or C++ (his compiler
> supports both).  But in the case of
>
> 	const sometype whatever = <initial value>;
>
> there is a difference.  In C, the "whatever" has external linkage by
> default - it is visible outside of the current object file, assuming
> there is a matching "extern" declaration.  In C++, "whatever" has
> internal linkage by default - it acts like "static const", unless there
> is a matching "extern" declaration visible in the defining translation unit.
>
> (The external visibility does not affect whether the object is put in
> read-only or writeable memory, of course.)
>
> Personally, I always make my file-level functions and data either
> explicitly "static" (even in C++, in order to be consistent with my C
> code), unless it has to be externally visible - in which case there is
> always an "extern" declaration in the module's header file which is
> #include'd by both the defining module and other modules that use it.
> That keeps everything clear and consistent.
>
> And I prefer to write "static const" rather than "const static" - the
> compiler accepts both, of course, but I am more fussy!
>
>
> Also note that when you make something "const", the compiler/linker does
> not have to put it into read-only memory.  It /may/ put it in read-only
> memory, and any attempt to change it in the program is undefined
> behaviour, but it could equally well use ram.  On a PC, for example, it
> will go in ram - but it will be put in a different segment from
> read-write memory, and the segment will be marked read only.  On an AVR
> (which has different cpu instructions for accessing flash and ram),
> const data is usually put in RAM so that it can be accessed using the
> same instructions as non-const data.  We don't know enough about the
> OP's system to know where static const data would end up.
>
> And of course if the compiler feels it doesn't actually /need/ to put
> static const data in memory, due to the way it is used (or not used), it
> will not put it in any memory.


The OP mentioned Borland C and Intel 80C186 - something I used much
about a quarter century ago.

The Borland toolset produces 16 bit DOS .exe files, which are segment-
relocatable. There is a need for a tool that makes absolute binary
images from the .exe files. I used Paradigm Locate for the conversion.

The Locate determines where a segment group goes, and its configuration
has the final say for the fate of a block of the memory image.

----

For memory allocation, my vote goes for the static block. In all
dynamic schemes, there is a difficult situation if the allocation
goes awry, and many embedded systems have no way to tell what
happened.

I guess that the erase block size of the flash is 8 kB, as the
OP was talking about changing a few bytes in it. I'd be careful
and first copy the contents of the block to a spare block in the
flash, and only after that erase the target for re-write.

-- 

-TV

On 5.4.16 09:17, David Brown wrote:
> On 04/04/16 19:34, 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.
>>
>
> That's my cue for the nit-pick!  Your explanation is a good start, but
> there are a couple of other points that I think are worth mentioning.
>
> It is not clear if the OP is actually using C or C++ (his compiler
> supports both).  But in the case of
>
> 	const sometype whatever = <initial value>;
>
> there is a difference.  In C, the "whatever" has external linkage by
> default - it is visible outside of the current object file, assuming
> there is a matching "extern" declaration.  In C++, "whatever" has
> internal linkage by default - it acts like "static const", unless there
> is a matching "extern" declaration visible in the defining translation unit.
>
> (The external visibility does not affect whether the object is put in
> read-only or writeable memory, of course.)
>
> Personally, I always make my file-level functions and data either
> explicitly "static" (even in C++, in order to be consistent with my C
> code), unless it has to be externally visible - in which case there is
> always an "extern" declaration in the module's header file which is
> #include'd by both the defining module and other modules that use it.
> That keeps everything clear and consistent.
>
> And I prefer to write "static const" rather than "const static" - the
> compiler accepts both, of course, but I am more fussy!
>
>
> Also note that when you make something "const", the compiler/linker does
> not have to put it into read-only memory.  It /may/ put it in read-only
> memory, and any attempt to change it in the program is undefined
> behaviour, but it could equally well use ram.  On a PC, for example, it
> will go in ram - but it will be put in a different segment from
> read-write memory, and the segment will be marked read only.  On an AVR
> (which has different cpu instructions for accessing flash and ram),
> const data is usually put in RAM so that it can be accessed using the
> same instructions as non-const data.  We don't know enough about the
> OP's system to know where static const data would end up.
>
> And of course if the compiler feels it doesn't actually /need/ to put
> static const data in memory, due to the way it is used (or not used), it
> will not put it in any memory.


The OP mentioned Borland C and Intel 80C186 - something I used much
about a quarter century ago.

The Borland toolset produces 16 bit DOS .exe files, which are segment-
relocatable. There is a need for a tool that makes absolute binary
images from the .exe files. I used Paradigm Locate for the conversion.

The Locate determines where a segment group goes, and its configuration
has the final say for the fate of a block of the memory image.

----

For memory allocation, my vote goes for the static block. In all
dynamic schemes, there is a difficult situation if the allocation
goes awry, and many embedded systems have no way to tell what
happened.

I guess that the erase block size of the flash is 8 kB, as the
OP was talking about changing a few bytes in it. I'd be careful
and first copy the contents of the block to a spare block in the
flash, and only after that erase the target for re-write.

-- 

-TV

On Tue, 05 Apr 2016 08:17:06 +0200, David Brown wrote:

> On 04/04/16 19:34, Tim Wescott wrote:

>> 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:
>> 
<< snip >>
 
> Also note that when you make something "const", the compiler/linker does
> not have to put it into read-only memory.  It /may/ put it in read-only
> memory, and any attempt to change it in the program is undefined
> behaviour, but it could equally well use ram.  On a PC, for example, it
> will go in ram - but it will be put in a different segment from
> read-write memory, and the segment will be marked read only.  On an AVR
> (which has different cpu instructions for accessing flash and ram),
> const data is usually put in RAM so that it can be accessed using the
> same instructions as non-const data.  We don't know enough about the
> OP's system to know where static const data would end up.
> 
> And of course if the compiler feels it doesn't actually /need/ to put
> static const data in memory, due to the way it is used (or not used), it
> will not put it in any memory.

Good point, but note the weasel-wording in my post: "should", meaning, in 
this case, "is morally obliged", not "can be expected".

One of the reasons I Really Like using the el-cheapo Cortex parts that 
are out now is that it's very easy to set up the tool chain to do what I 
think it should do (like putting const in some sort of ROM).

I really hate working with processors that need a different flavor of 
fetch to read from program or data memory.  I'll put up with it in a DSP, 
because you're trading speed for awkwardness, but in a general 8-bitter 
-- well, the Cortex M0 core is mighty nice.

-- 
www.wescottdesign.com

On Tue, 05 Apr 2016 08:38:41 +0200, David Brown wrote:

> On 04/04/16 22:50, srao wrote:
> Tim Wescott wrote:
>>>
>>> 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.
> 
> I think Tim meant that I know more of the "ugly details" of C and C++
> than he does, which I believe is true.  On the other hand, Tim is
> fantastic and explaining the important issues in embedded development.
> So pay attention to anything he says, and read my parts if you need the
> fine print (but don't feel bad if you don't understand it in one
> reading).  My posts are complementary to Tim's, not a replacement.

Fine details.  They're only ugly details when you trip over them at some 
inconvenient time.  

I always like having folks like you on a project with me, and they 
usually seem to like having me (or the ones I've worked with have been 
incredibly polite).  It's nice to run my stuff through a sieve of brains 
made like yours.  

I hope I don't sound too much like Donald Trump when I say this, but I'm 
really good at turning an abstract description of some big electro-
mechanical wonder into reality.  My downside is that while I'm quite 
_competent_ at software and analog circuit design*, I'm not absolutely 
brilliant at either.

* Yes.  Those two.  No, I don't understand it either.

-- 
www.wescottdesign.com

>On 04/04/16 22:50, srao wrote:
>Tim Wescott wrote:
>>>
>>> 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. 
>
>I think Tim meant that I know more of the "ugly details" of C and C++
>than he does, which I believe is true.  On the other hand, Tim is
>fantastic and explaining the important issues in embedded development.
>So pay attention to anything he says, and read my parts if you need the
>fine print (but don't feel bad if you don't understand it in one
>reading).  My posts are complementary to Tim's, not a replacement.

Sure. Got it :)
---------------------------------------
Posted through http://www.EmbeddedRelated.com

>On 5.4.16 09:17, David Brown wrote:
>> On 04/04/16 19:34, 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.
>>>
>>
>> That's my cue for the nit-pick!  Your explanation is a good start, but
>> there are a couple of other points that I think are worth mentioning.
>>
>> It is not clear if the OP is actually using C or C++ (his compiler
>> supports both).  But in the case of
>>
>> 	const sometype whatever = <initial value>;
>>
>> there is a difference.  In C, the "whatever" has external linkage by
>> default - it is visible outside of the current object file, assuming
>> there is a matching "extern" declaration.  In C++, "whatever" has
>> internal linkage by default - it acts like "static const", unless
there
>> is a matching "extern" declaration visible in the defining translation
>unit.
>>
>> (The external visibility does not affect whether the object is put in
>> read-only or writeable memory, of course.)
>>
>> Personally, I always make my file-level functions and data either
>> explicitly "static" (even in C++, in order to be consistent with my C
>> code), unless it has to be externally visible - in which case there is
>> always an "extern" declaration in the module's header file which is
>> #include'd by both the defining module and other modules that use it.
>> That keeps everything clear and consistent.
>>
>> And I prefer to write "static const" rather than "const static" - the
>> compiler accepts both, of course, but I am more fussy!
>>
>>
>> Also note that when you make something "const", the compiler/linker
does
>> not have to put it into read-only memory.  It /may/ put it in
read-only
>> memory, and any attempt to change it in the program is undefined
>> behaviour, but it could equally well use ram.  On a PC, for example,
it
>> will go in ram - but it will be put in a different segment from
>> read-write memory, and the segment will be marked read only.  On an
AVR
>> (which has different cpu instructions for accessing flash and ram),
>> const data is usually put in RAM so that it can be accessed using the
>> same instructions as non-const data.  We don't know enough about the
>> OP's system to know where static const data would end up.
>>
>> And of course if the compiler feels it doesn't actually /need/ to put
>> static const data in memory, due to the way it is used (or not used),
it
>> will not put it in any memory.
>
>
>The OP mentioned Borland C and Intel 80C186 - something I used much
>about a quarter century ago.
>
>The Borland toolset produces 16 bit DOS .exe files, which are segment-
>relocatable. There is a need for a tool that makes absolute binary
>images from the .exe files. I used Paradigm Locate for the conversion.
>
>The Locate determines where a segment group goes, and its configuration
>has the final say for the fate of a block of the memory image.
>
>----
>
>For memory allocation, my vote goes for the static block. In all
>dynamic schemes, there is a difficult situation if the allocation
>goes awry, and many embedded systems have no way to tell what
>happened.
>
>I guess that the erase block size of the flash is 8 kB, as the
>OP was talking about changing a few bytes in it. I'd be careful
>and first copy the contents of the block to a spare block in the
>flash, and only after that erase the target for re-write.
>
>-- 
>
>-TV


Thanks TV for your input. 
So, changing the adj files would define how the RAM is being used up? "And
thus determine where the block goes" you mean into RAM/stack/ ROM?

Also a question, why do you think this needs to be copied to flash? to
save the data in case of a failure/ sudden power loss I believe?  
---------------------------------------
Posted through http://www.EmbeddedRelated.com