new product

Synchronous Message Passing and REXIS Benchmarking

If you have read the blog on REXIS Examples, or the REXIS documentation, you may have noticed that REXIS supports synchronous message passing API, in addition to the more common asynchronous messaging with mailboxes. Synchronous message passing is not a new idea. Indeed, the inspiration came from QNX Neutrino, the message passing kernel that powered the BlackBerry smartphone devices in the early 2000s. Synchronous message passing is a great idea. For example, it makes writing a “full-blown” OS (e.g. Linux) based on microkernel simpler. In such a system, OS services such as the file system support, networking etc. are written as regular

Synchronous Message Passing and REXIS Benchmarking Read Post »

REXIS Examples

REXIS is both ImageCraft’s RTOS and a component of the JumpStart IoT Connectivity Suite. It’s powerful yet easy to use. This post is from an excerpt of the forthcoming REXIS User Guide, containing examples to demonstrate REXIS features. As some users may not be familiar with using an RTOS, let’s dive in and look at some examples. The examples are located in <install root>\rexis\examples\, and introduce all the major features of REXIS. (This document will not provide the full listing of the programs, as minor details may change.)

REXIS Examples Read Post »

Making Tedious/Complex Things Easy

The development world is full of IDE, and “everyone” uses GCC anyway. So how can ImageCraft be better? One way we can achieve excellency is by making tedious or complex things easy to do. For example, there are different floating point options for the Cortex-M MCUs, depending on what architectural features the CPU core support. For example, Cortex M0 and M3 cores must use software floating point libraries whereas M4 has optional single precision floating point FPU, and the M7 has optional single and double precision FPU. But wait! There’s more: by default, the printf function in the newlib/nano-lib does

Making Tedious/Complex Things Easy Read Post »

Dynamic Memory and REXIS

According to some coding guidelines such as MISRA, it is “common wisdom” that embedded firmware should not use dynamic memory, e.g. malloc/free, as it introduces non-deterministic behaviors. Many firmware engineers have taken this to heart.  So is it surprising that REXIS (our forthcoming RTOS) uses dynamic memory allocation? Have we gone mad? Surely not ;-). REXIS uses dynamic memory for three main reasons:

Dynamic Memory and REXIS Read Post »

Scroll to Top