After a bit of a lull, I have resumed work in earnest on what will become, I hope, a useful and fairly comprehensive C++ software library for embedded and real-time developers. To begin with, I am updating the Dynamic Memory Classes which I first published on this blog about two years ago. The first instalment – the “Pooled” class and its ancillaries – is now available for subscribers to download. Just go to the Subscribers page and follow the guidance there in order to get hold of the software.
I publicised the software yesterday on LinkedIn and it is apparent that some of you have downloaded it already. Please check that you really do have the latest version (28 February 2012). Having successfully downloaded it myself yesterday evening, I was dismayed to find that I got an older version when I tried again this morning! I don’t what caused that, but I’ve fixed it now and the old versions have been completely removed from this site.
Some time ago, I blogged about a problem I had with these classes in statically allocating the pools. I temporarily fixed this with a one-off dynamic allocation for each pool when it was first used. I was never happy with that and I’m pleased to say that I have solved the problem properly now. Consequently, the pools are now statically allocated, as was always the intention, and the “Pooled” facility (one pool per class) operates completely independently of “MemSpace”, which is another part of the class library to be incorporated in the next update, quite soon.
Those of you who are mystified by all of this, please browse the “Dynamic Memory” section of this blog. Better still, subscribe to the blog and download the software. This version is comprehensively documented and it comes with its own Demo program, which you can run natively on the desktop or cross-compile and run on an embedded target using a suitable IDE, such as IAR’s.
Enjoy!
When we link our programs together, the success of the operation reassures us that all our code and our static and global(?!) variables fit into the available memory. But what about the function parameters, the local variables and various other unknowns which go on the stack?
When someone mentions dynamic memory allocation, the worst-casers amongst us – which should be all of us – immediately start ranting against heap allocation and advocating either the somewhat safer use of fixed-size-block pools, or the ostensibly even safer but often design-compromising measure of banning of dynamic allocation altogether. But heaps and pools I’ve covered before on this blog. What we all tend to brush under the carpet is the admission that the implicit use of the stack in all our programming (in C and C++ at least) is also dynamic allocation and deserves much more careful consideration than we tend to give it. Read more…
Anyone using PendSV on Cortex (e.g. to implement an RTOS scheduler) should read this!
[Edited 29/09/11] It appears that there may or may not be a problem; the argument continues on the Embedded Gurus blog. If you’re tinkering with PendSV, it would be good to read the article (and the comments to it) anyway.
Timing issues are often important in systems containing software but, ultimately, all timing is determined by hardware. Let’s pursue this by splitting a hypothetical system into (1) the software we’re designing and (2) the platform it’s intended to run on. We also need to consider (3) the toolchain. To be a little more precise: Read more…
My last article, Whatever Happened to the Worst Case?, was a bit of a rant but it promised further articles on the subject. This is the first of these, which does no more than describe what I mean by the “Worst Case Principle”, or WCP. I am using WCP as both a label in the title and as a tag to identify each of the articles. The series is intended to provoke thought, not to be a complete treatise on designing robust software. That would fill a whole book – at least! Read more…
I’m dismayed about sloppy attitudes to design. I suspect they’re creeping across from consumer-focused software, where raw average speed is everything and an occasional glitch doesn’t matter. Well, I’m sorry, but as that kind of thinking creeps towards the vehicles I may travel in, or possibly the new nuclear power plant to be commissioned up the road from here, I feel the need to voice my concerns. Read more…
My last post, quite a while ago, expressed my preference for putting usage comments (as opposed to implementation comments), as far as possible, in header files on the grounds that the header file is the primary interface which the user has with the code. The code file (.c or .cpp), from a user’s perspective, contains a lot of irrelevant text and may not even be available for inspection in any case.
I did, however, write:
I’ve used several approaches but I’ve yet to settle on a “best” one. Indeed, the concept of “best” hinges to some extent on the approach, if any, taken with regard to external code documentation
Doxygen is perhaps the most popular open source tool for producing extensive, structured, external documentation by extracting comments (which have some special formatting) from the source files. As it can extract from both header and code files, the question is re-opened as to where it is best to put the usage comments. Read more…
An excellent and succinct article by Michael Barr entitled “What Belongs in a C .h Header File?” triggered the thoughts I am about to write down, for he forgot to mention comments as worthy items to be included. When conducting Advanced C courses, as I sometimes do, I have always emphasised the need for usage comments in header files. Header files provide the user’s interface to the implementation in the corresponding .c files, but the latter are often uninteresting to the user and may not even be available. Proprietary libraries, for example, are typically shipped in object form with their header files. It follows, therefore, that any comments which might be valuable to the user should be in the header file. Read more…
Most embedded software practitioners – sadly, not all – know that some form of what is normally called “Mutual Exclusion” is necessary when a read-write resource is shared among two or more concurrent activities, particularly (but not necessarily only) when test-and-set operations are involved. The expression “Mutual Exclusion” is so entrenched as a generic concept that I feel obliged to use it as such, but sometimes it is anything but mutual. Read more…
Since Easter, when I promised a new release of this software, I’ve been exceptionally busy in a money-earning sort of way. I’ve noticed that others are blogging less now that their business has (presumably) picked up, so I’m not alone in disappointing my readers, but that is no excuse and so I have just uploaded the software I promised. Read more…