Hardening of firmware

The reason I did pick that example was because Jack has a pre-chewed policy document for how to develop software (where to store source, how to indent, ...) on his page. One of the things it mentions is to be careful about malloc() defragmentation and to check if malloc() has support for garbage-collect of free space.

It can be done using dual indirection (segmented MMU like in 286 or explicit handles like used in several OS from before MMU) or by instrumenting the source code to allow the stack and data structures to be walked - 16-bit Windows for example has special progolgue/epilogue for all functions, so that Windows can patch the return addresses on the stack when a memory block has been moved.

But I haven't seen anyone trying to take this to the embedded world because of the big problems with deterministic response times. So I wonder if Jack did add that part by accident, or if he really had specific usage cases with such memory managers in the embedded world.

In the end, it is normally way easier to write the application to use fixed-size memory blocks that can be allocated/released without any fragmentation. Most RTOS has thread-safe allocation functions that can work with arrays of such memory blocks. And when the requirements gets higher, or the work with specifically rewriting the code is decided to increase the complexity too much, then a processor with MMU and paged memory will work well, as long as all dynamic allocations are made for a number of pages instead of using a variable-size scheme like malloc() normally uses.

The reason I did pick that example was because Jack has a pre-chewed policy document for how to develop software (where to store source, how to indent, ...) on his page. One of the things it mentions is to be careful about malloc() defragmentation and to check if malloc() has support for garbage-collect of free space.

It can be done using dual indirection (segmented MMU like in 286 or explicit handles like used in several OS from before MMU) or by instrumenting the source code to allow the stack and data structures to be walked - 16-bit Windows for example has special progolgue/epilogue for all functions, so that Windows can patch the return addresses on the stack when a memory block has been moved.

But I haven't seen anyone trying to take this to the embedded world because of the big problems with deterministic response times. So I wonder if Jack did add that part by accident, or if he really had specific usage cases with such memory managers in the embedded world.

In the end, it is normally way easier to write the application to use fixed-size memory blocks that can be allocated/released without any fragmentation. Most RTOS has thread-safe allocation functions that can work with arrays of such memory blocks. And when the requirements gets higher, or the work with specifically rewriting the code is decided to increase the complexity too much, then a processor with MMU and paged memory will work well, as long as all dynamic allocations are made for a number of pages instead of using a variable-size scheme like malloc() normally uses.

Even worse.

I have been seeing a lot of people (not really a lot, but enough), who even don't know what an interrupt service routine or a Linux kernel module is, are "MODIFY"ing an interrupt service routine or a Linux kernel module.

And those people think that I (John Linq) is an idiot. (At least, they make me feel I am an idiot.)

Why so serious? It is the human society geting weaker and weaker.

(I have never worked on an area, where Human Safty is an issue that has to be concerned.)

Per,
You posted:
The reason I did pick that example was because Jack has a pre-chewed policy document for how to develop software (where to store source, how to indent, ...) on his page

What "page"? Do you mean this forum or can you post a link...?

It was this link:
http://www.ganssle.com/fsm.pdf

You can find it from Special Reports/A Firmware Standard.

What made me interested was page 6, "Stack and Heap Issues", third section. I was thinking that there might be an interesting story hidden there somewhere - the concept of garbage-collecting fragmented blocks is not something I would expect in any embedded world because of all the problems. And in a non-embedded world it would most probably not be needed.

Holy cow, I thought you meant "Jack Sprat" :-)
That Jack I do know...

LOL :)

No, I was just "donating" a question for Silly Sausage to ask, and then let us see if he would become a breakfast sausage or if there would come something interesting out of it :)

I just have to ask: How could you even think about Jack Sprat, given how silent he is between the times when he decides to pick a fight?

Cpt. Vince said it just a few days ago:

"And of course I think of you: I'm sure we all do."

"...I was just "donating" a question for Silly Sausage to ask..."

Wot???

A trap just for li'le ol' me, Per? How thoughtful :)

Actually, I'm still reading through some of the information on that page (when my day job allows).

I stumbled across a very interesting data sheet that I first saw printed in (I think) ETI about 25 years ago. It's for a brilliantly advanced memory device:

www.ganssle.com/.../wom2.pdf

Don't forget page one too. Yes, it would probably have quite good figures for bit errors when used in rough environments. But you may not make use of all bits, to have some margin depending on temperature. Just a tip: Solder the chip instead of using a socket :)

"about 25 years ago" - I wonder what the average age is for the regulars on this forum.

Per;
I have no idea about average ages but I'll bet that Erik and myself severely skew the curve age wise.
Still I enjoy the info on this forum.
Al Bradford

"Don't forget page one too."

Silly me!

Can be found at:

www.ganssle.com/.../wom1.pdf