>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 forthis?>>>>> 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 theheap>> 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 ofRAM?>>>>> Or does it depend on the compiler? >>>> >>>> I believe that you are asking if using the "static" keyword in someC>> 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 Iused>>>> 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 aboutwho>>>> 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 outsideof>> // >>>> 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 // theresulting>>>> object file, and (if the tools are set // up correctly) filled with0>>>> bytes: >>>> sometype whatever; >>>> >>>> // "whatever" gets put in RAM, is only visible to // things withinthe>> C >>>> file, and (if the tools are set // up correctly) filled with 0bytes:>>>> static sometype whatever; >>>> >>>> HTH >>>> >>>> If David Brown says that I'm wrong, just fill in a resigned sighfrom>> 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 an8kB>>>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 charsue>>> [8192]; // allocates in RAM, only visible >>> // within this function >>>} >>> >>>Note that doing this, with this large a chunk of memory, is probablyan>>>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.comWell, this is used by service personnel once in a while during a image update only. Once the image is in, the application running does not need to use this functionality, is a part of boot only. --------------------------------------- Posted through http://www.EmbeddedRelated.com
Use RAM to modify a field
Started by ●April 1, 2016
Reply by ●April 5, 20162016-04-05
Reply by ●April 5, 20162016-04-05
On 5.4.16 19:54, srao wrote:>> 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?You did not respond to the questions: - is the processor an Intel 80C186/80C188? - is the compiler Borland C (version?) ? - which is the locating tool you use for refining the .exe? I do not recall any adj files in the toolset I used years ago, but my memory may leak in a quarter century. My recommedation to copy the image to a back corner of flash is just for the situation when something goes awry (and sure it will!). First do the code to do it and verify that you can reliably make the copy and only after that start on the code for erasing, modifying and rewriting the original loaction. It is much easier to recover if you have a backup. -- -TV (Tauno Voipio, older MSEE)
Reply by ●April 5, 20162016-04-05
On Tue, 05 Apr 2016 12:39:48 -0500, srao wrote:>>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 > > Well, this is used by service personnel once in a while during a image > update only. Once the image is in, the application running does not need > to use this functionality, is a part of boot only.In that case then I'd say go ahead and use the heap. Most of the "OMG" connected with heap usage in an embedded system is that heaps don't usually stand up well to having everything in the world using one heap for a very long time. You are proposing a very limited use of the heap -- it certainly works for me. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●April 5, 20162016-04-05
Den tirsdag den 5. april 2016 kl. 22.55.12 UTC+2 skrev Tim Wescott:> On Tue, 05 Apr 2016 12:39:48 -0500, srao wrote: > > >>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 > > > > Well, this is used by service personnel once in a while during a image > > update only. Once the image is in, the application running does not need > > to use this functionality, is a part of boot only. > > In that case then I'd say go ahead and use the heap. Most of the "OMG" > connected with heap usage in an embedded system is that heaps don't > usually stand up well to having everything in the world using one heap > for a very long time. > > You are proposing a very limited use of the heap -- it certainly works > for me. >and the heap and stack will usually be competing for the same memory -Lasse
Reply by ●April 5, 20162016-04-05
>>> 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 aresegment->>> relocatable. There is a need for a tool that makes absolute binary >>> images from the .exe files. I used Paradigm Locate for theconversion.>>> >>> The Locate determines where a segment group goes, and itsconfiguration>>> 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? > > >You did not respond to the questions: > - is the processor an Intel 80C186/80C188? > - is the compiler Borland C (version?) ? > - which is the locating tool you use for refining the .exe? > >I do not recall any adj files in the toolset I used years ago, >but my memory may leak in a quarter century. > >My recommedation to copy the image to a back corner of flash >is just for the situation when something goes awry (and sure >it will!). First do the code to do it and verify that you can >reliably make the copy and only after that start on the code >for erasing, modifying and rewriting the original loaction. >It is much easier to recover if you have a backup. > >-- > >-TV (Tauno Voipio, older MSEE)yes its an Intel 80c188 Boarland C++ 4.5 Paradigm LOCATE is the tool used. Yeah, even i agree a backup is essential and good way to do it. --------------------------------------- Posted through http://www.EmbeddedRelated.com
Reply by ●April 5, 20162016-04-05
>>>Tim Wescott Wescott Design Services http://www.wescottdesign.com >> >>On Tue, 05 Apr 2016 12:39:48 -0500, srao wrote: >> Well, this is used by service personnel once in a while during a image >> update only. Once the image is in, the application running does notneed>> to use this functionality, is a part of boot only. > >In that case then I'd say go ahead and use the heap. Most of the "OMG" >connected with heap usage in an embedded system is that heaps don't >usually stand up well to having everything in the world using one heap >for a very long time. > >You are proposing a very limited use of the heap -- it certainly works >for me. > >-- > >Tim Wescott >Wescott Design Services >http://www.wescottdesign.comYes, its only used every time the image needs to be updated. --------------------------------------- Posted through http://www.EmbeddedRelated.com
Reply by ●April 6, 20162016-04-06
srao wrote:> yes its an Intel 80c188 > Boarland C++ 4.5 > Paradigm LOCATE is the tool used. > > Yeah, even i agree a backup is essential and good way to do it.But that is only one half of the solution. You also need some means to detect if you should copy back from the backup. If or example during erase/modify/write of the flash segment you have a power loss, does your system start safely with the flash segment corrupted? Can you detect this corruption? -- Reinhardt
