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!
Hypothesis: SKC++ doesn’t need semaphores. If you disagree with this, please comment, with supporting arguments. In the meantime, I’ll present a few arguments of my own, Read more…
When it comes to interrupts, SKC++’s guiding principle is “minimum interference”.
Some kernels require that interrupts be processed internally, the internal Interrupt Service Routine (ISR) calling out to an ordinary user function, sometimes also called an ISR, confusingly. Some others let you code the ISR yourself but impose restrictions on how you do it.
SKC++ does not require you to alter the way you program ISRs; Read more…
Just a short article today as SKC++’s mutual exclusion facilities follow a familiar pattern Read more…
Although I separated the ideas of posting an untrammelled event, using post, and sending a message (which also posts an event), using send, this is not such a good idea for receiving messages. One of the key things about an SKC++ task is that it should be able to wait at a single point in its processing in order to get something to process and that it should deal with only one event or message at a time. Accordingly, the wait function has been enhanced to deal with message reception, as well as with raw events. Read more…
I have simplified the prototype for send in order to make its use a little easier and also to improve the efficiency of the implementation. Here is the new prototype: Read more…
This is a relatively short article, as the sending of messages from one task to another is straightforward. I decided to defer its counterpart, “Receiving Messages”, until next time because there are several things to consider there, making the subject worthy of an article of its own. Read more…
To avoid clutter, I haven’t shown the class methods. On this occasion, I’ll just describe the classes and their characteristics in the text. Read more…
Before jumping into the design of the message-passing classes, it is as well to consider how the facility might be used in applications.
I start with a common, nicely encapsulated but rather restricted kind of use…
Local Message-Passing
In this slightly abused UML activity diagram we see Read more…
Message-passing is used, in an RTOS-based system, to provide a safe way of transferring data from one context to another or, in other words, from task to task. What is safe, though, is not always efficient and vice versa. Read more…