Software Integrity Ltd

I’ve been looking over my SKC++ postings so far and have come to the conclusion that it’s time for a review. Also, before launching into the details of the kernel’s message-passing techniques, I need to show why message-passing is needed in the first place. I’ll start by presenting some thoughts on the tasking model. Read more…

Just possibly, you may have been wondering why Task::wait does not include a timeout parameter. The answer is that it does not need to because a timeout is itself an event, so this can be waited for along with whatever event might be timed out. SKC++ has general-purpose timers which can be used not only for timing out other events but in their own right for other purposes. Here is a picture:- Read more…

Systems running a pre-emptive kernel are essentially event-driven.

Primary events are things which happen outside the software system, in the real world. These are usually communicated to the software via Interrupt Service Routines (ISRs) which are pre-emptively “called” by the hardware interrupt mechanism of the processor. Our kernel becomes aware of the event if and only if the ISR signals its occurrence, in some way, to a task. Read more…

Today’s post discusses the basic structure and characteristics of an SKC++ task. Here is a picture of the class, together with a skeletal but updated version of the Pooled class, from which Task inherits: Read more…

Following on from previous postings, here is a UML diagram showing two classes concerned with dynamic memory handling: Read more…

Today’s post is about the strategy of dynamic memory handling in SKC++.

Last time, I recommended a short slide presentation for perusal. I will not repeat here what that says, except to quote the last slide:

Preventing fragmentation
• Always use pools, never heaps
– Exception: memory which is never intended to be freed can be taken from a heap
• Override the global new() and delete() operators
• Consider per-class new() and delete() operators
– Quicker, as well as safer

In a nutshell, that is the strategy for SKC++. Read more…

I have been thinking about SKC++ for longer than I have been blogging about it and dynamic memory allocation should not have been my first topic. Before all else, I should have taken the trouble to explain SKC++ in more general terms. I’ll do it now… Read more…

Today, I am working on the dynamic allocation scheme for SKC++. It’s very simple (as everything is supposed to be in SKC++), so it won’t be long before I post again, reporting on progress.

In the meantime, if you’re wondering what’s wrong with using the standard new and delete mechanisms that come with C++ I urge you to have a look at my short slide presentation on the subject. The last two slides are particularly important.

Till soon…

Most of today’s RTOS offerings are too complicated. Here are some reasons why this is so:

• Insufficient thought , before designing, as to what is really essential and what is not, leading to redundancy and confusion.
• The perceived need to offer everything already offered by competitors, then to add more features in an attempt to steal a march on them.
• The fact that some products, as in all walks of life, are just badly designed. Unfortunately, the power of heavy marketing to foist mediocre products onto customers has been proven over and over again.
• The fact that some people, including software designers, have a natural tendency to complicate rather than simplify. This, I’ve noticed, happens particularly with younger engineers who are anxious to shoehorn everything they know into a project rather just what’s needed. I probably did some of that, too, but it’s so long ago that I can’t remember!

Well, I’m bucking the trend by writing what I believe will be a simpler and better pre-emptive kernel Read more…