As we are finalizing the initial release of REXIS, we would like to provide some quantitative data on some of its features so that users and potential users can make intelligent decisions regarding this product.
There are a variety of methods for measuring timing on MCU firmware. Two popular methods are 1) using an internal MCU timer, and 2) toggling a GPIO pin so that you can observe the output waveform with an external device.
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.)
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 not support printing of floating point values (to reduce the size of the function) and…, and…, … These are not hard to figure out, just tedious to remember the exact options to use for each one.
So of course we are adding new options to the Project Build options in the next release of the JumpStart C++ for Cortex IDE:
Simple, easy to use. That’s our motto.
Oh, one more thing. What’s that QFPlib option? Stay tuned and find out…
As more and more “Internet of Things” devices come onto the market, the existence of exploitable flaws will become unavoidable. As the provider of a (forthcoming) TCP/IP+RTOS stack in ImageCraft’s JumpStart IOT Suite, it behooves us to come up with a plan for if and when this happens. Clearly, we need to:
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:
REXIS is both ImageCraft’s RTOS and a component of the JumpStart IoT Connectivity Suite. It’s easy to use and also supports multiple APIs for IPC (Inter-Process Communication). In this post, we aim to show how easy it is to write an interrupt handler to interact with a normal REXIS task.
Problem Description: in an embedded system, the most efficient method of detecting sensor and other data input is through peripheral interrupts. An interrupt handler, or Interrupt Service Routine (ISR), is called when the hardware device receives data (e.g.: a character arrives at a UART receive register). The ISR reads the data from the hardware device, and the data can then be processed by the firmware. Because interrupts preempt other code from running, to minimize performance impact on the rest of the system the ISR should do its job as quickly as possible and leave the more complex data processing to code that is not running in an interrupt context.
Why is this important? While the example in this post is trivial in nature (basically, it’s a terminal I/O echo program), it demonstrates one of the most important aspects of using an RTOS: use an ISR to handle a hardware event, and then pass the data to a normal task for data processing.
Most modern MCU have some kind of readout protection of the flash. Unfortunately, there’s only the minimal level of protection of your firmware IP. The TL;DR version is that serious crackers can etch the physical shielding off, and then read the flash content via microscope.
http://imagecraft.com/download/demo-software direct download link: https://imagecraft.com/pub/iccv9cortex_demo.exe
9.05.00 2018/10/04 – IDE and JDB Debugger Added Semihosting support. This redirects printf calls when the program is under debugger control to the ADT’s semihosting output window. See help file for detail. – IDE Enabled support for USB licensing dongle. Once the driver is installed, the IDE will recognize the dongle license automatically whenever it is plugged in.
NOTE: Win8/Win10 users may need to install the driver using the “unsigned driver install hack” (do a web search).