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…
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…
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…
Some wistful thinking, as a break from blogging about SKC++.
I spent the last two days at the ESC in Farnborough, UK. Would that be:
Or all three? 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…