Use RAM to modify a field

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.

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.

Reply to
David Brown
Loading thread data ...

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.

Reply to
David Brown

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
Reply to
Tauno Voipio

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
Reply to
Tim Wescott

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
Reply to
Tim Wescott

me

Sure. Got it :)

--------------------------------------- Posted through

formatting link

Reply to
srao

heap

it

it

or

space

used

who

in

you

me

there

does

read-only

it

AVR

it

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

formatting link

Reply to
srao

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 to
Tauno Voipio

segment-

conversion.

configuration

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

formatting link

Reply to
srao

need

Yes, its only used every time the image needs to be updated.

--------------------------------------- Posted through

formatting link

Reply to
srao

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
Reply to
Reinhardt Behm

to

TV , Would you know where/how to figure out how Paragdigm locate works with the LOC file and adj, cfg files to create the image. Any particular information source on this tool ?

--------------------------------------- Posted through

formatting link

Reply to
srao

See the excellent, detailed Locate reference manual that was provided to any legitimate purchaser of the tool.....

Reply to
Dave Nadler

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.