Too hard for the today’s engineers. The push for a lot of cheap labor has paid off.
To get less capable people graduated (and better results in the P.O.V of university administrations) the level must have been dropped.

“There are no crimes if even murder is legal”.

However, I did write a couple of functions to set and clear bits in a word whose address was given as an argument. I’m not putting those on the blog (unless the demand is overwhelming!) but I’ll send you the code by email.

I hadn’t really thought about it, but I don’t see why things couldn’t be configured that way, though the class would then need to be a template to set the array size for the unsigned ints. The other point I would make is that it would be m_value[x][32], the way I have things configured (for unsigned int rather than unsigned char, which would also be possible).

What I’d prefer to see, as a tidier alternative, is an array of actual BitWord variables, where such a thing might be required – something like this:

BitWord b[12];
b[2][1] = 1U;

If you want to use the class, the constants need to be defined in a better place.

The workshop attracted a “full house” of 14 people and I was pleased that my talk was well attended, too – especially as it took place at the very end of the day.

Interest seems to be picking up again in C++ for embedded work, and not before time!

Looking forward to hearing more about SKP as things develop!

I was pleasantly surprised by the interest in C++ in general, at the event. Perhaps its time has finally come, to steal at least some of C’s thunder, for smaller embedded and real-time systems.

Thanks.

My thoughts about doing some of the spadework at unit testing time are relevant here. If per-function figures can be obtained through an enhanced, automated test harness, then normal regression testing will produce fresh numbers each time. There remains the call-tree analysis, but that could be automated too (with some initial manual input for function pointers, which shouldn’t need to be modified too often). These are my current thoughts and, like you, I welcome other people’s.

One thing many engineers overlook – the problem that as software is refactored, debugged/fixed, enhanced, etc. its RAM usage (stack in particular) changes. Maybe now we’re using more stack in certain places, maybe now we’re using less. **But no one ever goes back & re-evaluates the stack usage.**

I’ve worked in (with) a lot of different organizations, and I can say confidently that very few of them do very detailed stack usage analysis in the first place… and even those who do tend to do it one time, during the initial development, and then the subject is never re-visited. Typically task stacks (in the case of an RTOS) are sized conservatively, and then some kind of margin is added on top (either a fixed amount or a percentage).

My point is that the holy grail would be some way to analyze the worst case at build time, and then have some type of stack size configuration file generated which would be guaranteed to be sufficient / correct. This file would be used at initialization (when tasks are created) to ensure stack sizes are adequate.

This is unattainable, however, because the dynamic nature of most programs makes this difficult or impossible. For example, with function pointers, the call flow isn’t known at compile time. And with C++ and dynamic types (not to mention 3rd party libraries, etc.) the problem expands even further. Now adjust your compiler options, inline (or un-inline) some routines, get rid of some globals & pass more parameters, and bang! everything has changed again. Change an iterative algorithm to a recursive one, yep that’s gonna screw things up too…

I guess my point is that this is indeed a complex problem and I haven’t found the proverbial silver bullet. I just now went over to Nigel’s post & read it – he identified many of the same issues, especially the points about function pointers & also not measuring once & then forgetting about it.

I’ll be interested to see what others have to say. Although I’m a big believer in doing the required rigorous work each time, what I’d really like to see is some sort of automated process that (mostly) removes the human from the equation (in other words, a system that always ensures by the time the code is loaded on the target, we’re “guaranteed” to not have stack overflow problems). Not saying it’s attainable, but it’s an interesting thought. Until then, I think we’ll have to continue to use things like stack checking hooks, MPUs, etc. to detect the problem post-facto & recover.

Dave (and others), you might find this post interesting, though my comment underneath it is more relevant to your point about timescales:

http://embeddedgurus.com/stack-overflow/2011/08/rabbit-patches-and-embedded-systems/

In my experience, the one thing more than any other that contributes to poor quality is when management insist on development time scales that are too short and thereby result in the job being rushed and botched through. The very fact that we are using software in an embedded system means that the problem is more complex than can easily or cost effectively be solved by hardware alone. Therefore this complexity needs a commensurate amount of engineering time! The only way that I can see to deal with this problem is the practise of software estimation, even though this is just as difficult as Peter’s experience with high reliability hardware design and often just as tedious. However, without it the software engineering team has no stick with which to bat back the big stick of management!

Hear, hear! I wish more of our peers would take software quality seriously. Over the years, I’ve learned a lot by working with people who design firmwarethat is life-critical – peoples’ lives are saved when it works, and people die when it malfunctions. I try to apply the same principles of every system I work on, even if lives aren’t at stake.

I’ve found that shops that “test bugs out of the system” tend to have low quality. By “test bugs out of the system”, I mean using the test phase to find bugs that they pretty much “know” are in there, because of deficiencies in specification / design / implementation phases. In other words, they enter the test phase *expecting* to find bugs. If the test phase was treated more like a verification phase, the expected outcome would be different.

In probably 3 or 4 opportunities in my career, I’ve encountered someone who acknowledged a design deficiency, but basically said “unlikely to happen, and too painful to design in prevention.” 2 of the cases I can recall were race conditions. In one case, the window was approximately 20 nsec, and the engineer said something to the effect “It’s so unlikely to happen, I’m not going to go to the trouble to prevent it.” I said to him, “If this firmware was in a product that your mother was using, and her life depended on it, would you have that same attitude?” Naturally, he decided it actually *was* worthwhile…

One other thing – you mentioned your early career as an electronics engineer & the worst case. About 3 years ago I was brought in to find & fix a very strange problem… customer thought it was firmware, in fact the hardware manager said (literally) “There is absolutely no possibility that this is a hardware problem.” Turns out it was hardware. Complicated circuit with many resistors, 10% tolerance parts used on the board, and guess what? The tolerances lined up in the circuit (almost +10% here, almost -10% there) such that readings & behavior were intermittently erratic. Original designer assumed a 470K resistor meant a 470K resistor, not possibly a 430K resistor.

Last thing – and I don’t mean to steal your thunder, since you’re going to be writing a series, but in addition to good design & implementation, I think process can have a huge beneficial impact on quality. I’m not a process fanboy, I’m in the “just enough to make sense” camp, but coding standards, code reviews, static analysis, version control, regression testing, etc. can all have huge impacts on the product’s shipping quality. Seems silly to even have to mention these activities, they should almost be a foregone conclusion, but sadly I can say that is *definitely* not the case.

I have certainly been neglecting my blog but have resolved to get back to it – though I don’t have so much time for it as I had a year or so ago.

I’ve been reviewing SKC++ and will revive it, with some changes, probably under a different name. I made the prototype; now I’m going for the product!

Will you be continuing with the SKC++ series? I enjoyed that & hope that you have time to resurrect it!

I got around the problem by allocating the initial pool space dynamically instead of declaring an array. (Static allocation, as originally attempted, would have been better, but I couldn’t figure out a reliable way to automate it.) The pool memory can be taken from the standard heap (if you must); the actual pool is never given back, so there is no fragmentation issue. The preferred method, though, is to use my super-simple allocate-only code for obtaining pools. This is a configuration option and it works completely transparently – the user doesn’t have to manage the initial allocation of pool space, except to ensure that sufficient total space is made available.

If you haven’t already downloaded the code, I suggest that you do so and have a look through it. I expect to be updating it again soon, and will post another message when I have done so.