We just submitted a new ad to Circuit Cellar Inc. It should appear in their Nov issue. (Note: the young woman demonstrating her eBox kit IS a student, not a professional model. 🙂 )
Meanwhile, we have a few new major and minor product releases in flight, so many that it is almost tough to keep track of them. Some highlights:
- As blogged in a previous entry, the Parallax Propeller is an exciting new microcontroller that brings the power of multiprocessing to embedded market. We are now prototyping a XMM (external memory model) scheme where programs can be stored in external memory, in as much as multi-megabytes of storage. With the 8 32-bit cores in the Propeller and combined them with huge amount of program memory, this could be a potent combination for experimenters.
- Atmel is aggressively pushing out their new XMega versions of the AVR devices. Our AVR compiler already provide the basic support and we will be releasing a beta version of the Application Builder that works with the XMega soon.
- Also in development is a CAN library for the AVR. We will be releasing the base version soon which will support the CAN128 and will be included as a part of the compiler package. Forthcoming are higher level APIs and faster performance and integration with a RTOS.
I should expand on the last entry a little bit more. We will be releasing an embedded message passing OS, hence named eMOS, tentatively in Nov 2008. It has a preemptive scheduler with task priorities and round robin scheduling. Comparing to a cooperative kernel, it has higher overhead on RAM usage but it allows very natural use of “functions as tasks” model. The philosophy is that as much as possible, the RTOS should not impose restrictions on the user programs.
So what is message passing? After deciding on a scheduling mechanism, the next major decision in a RTOS design is that synchronization and interprocess communication mechanism. QNX has the right answer since the 80s: message passing is the right mechanism for performance, robustness, and simplicity reasons. That sounds like a good choice to me. As an example, in the simplest case, with a message passing OS, you can divide the tasks into server tasks and client tasks. A server task listens for requests:
    pid = eMOS_Receive(&request, sizeof (request));     ...     eMOS_Reply(pid, &reply, sizeof (reply));
if there is no outstanding request, the receive call waits until one arrives. The message being passed is not interpreted by the OS in any way. After processing the request, the server calls the reply function to tell the client that it is done. A typical client then looks like this:
   eMOS_Send(pid, &request, sizeof (request), &reply, sizeof (reply));    ...
If the server is listening, then the send message gets copied into the server’s buffer almost immediately. Otherwise, the sender will just waits until the server listens. The send call returns once the server replies to the message via the reply call shown above.
Simple and elegant. It addresses both synchronization and interprocess communication issues. No additional intermediate abstractions such as mailboxes is needed. Our initial release includes the basic kernel with the message passing APIs and semaphores etc. Later releases will have add-ons such as UART and USB stacks, and of course the CAN stacks as above, and eventually a TCP/IP stack.
To address RAM usage consideration, priorities can be changed dynamically and scheduling can be temporarily turend on and off, allowing great control for embedded systems. The basic scheduling mechanism is based off a timer interrupt and a simple mechanism allows you to hook into the timer interrupt for quick processing.
Oh one more thing, to support the subsumption architecture (see earlier blog on REXIS), messages can be suppressed and inhibited – if you choose the features. Otherwise, eMOS is high performance message passing OS, suitable for most embedded needs.