BASEplatform in Depth: The Modules

Two weeks ago, we launched our first embedded software product, BASEplatform. This article is the first of a series where we go into more details about the features and advantages of the BASEplatform.

BASEplatform is designed to bring application developers all the necessary low-level components such as startup code, drivers, BSP, RTOS integration as well as toolchain support files and configuration in one, ready to go package that works out of the box.

To fulfill this claim, the BASEplatform, is, at the heart of its architecture extremely modular. Developers are free to choose only the modules that they require, as well as mix and match with third party code from manufacturers, RTOS vendors or their own in-house drivers and stacks.

In this article we explore some of the modules that can be delivered as part of the BASEplatform.

Core modules

The core modules constitute the minimal set of modules required for any non-trivial application. While technically it is possible to reduce the BASEplatform to only the startup code that gets an application to the main function, it wouldn’t be very useful.

Diagram of the BASEplatform core modules centered around CPU architecture support and RTOS integration.
BASEplatform core modules

Arch The arch module, short for architecture, is responsible for abstracting as much of the chosen CPU core and toolchain as possible. This includes the startup code, MMU/MPU configuration, critical sections & spinlock, memory barriers, cache management etc.

Interrupt The interrupt module, as the name implies, centrally manage the platform interrupts, including registering, enabling or disabling interrupts, as well as configuring priorities & type in a platform independent way. The interrupt module can be the primary interface to interrupt management in the case that the chosen RTOS does not manage interrupt directly (or in bare-metal), or subordinate to the RTOS interrupt management.

Timebase Responsible for providing the primary time base, the timebase module manages the main system timer. It offers high resolution, timers and delays while minimizing software generated jitter. When an RTOS is present the kernel time base, also called tick or system tick, is derived from the timebase module.

Clock & Reset More specifically the SoC clocks and resets this module interacts with the MCU’s clock and reset subsystems as required by other BASEplatform components. At a minimum, it will be able to report core and peripherals clock frequencies, enable & disable peripheral clock gates as well as control peripheral reset lines.

Next, the all-important low-speed peripherals.

Low-speed I/Os

Those four hardly need an introduction. While many of those low-speed peripherals have been around since the early days of microcontrollers, they are used in increasing numbers in modern designs. Nearly all of today’s embedded systems must interact with an ever-increasing number of sensors, power controllers, non-volatile storage, off-chip security modules and more. Yet, they are often overlooked, resulting in an incomplete software solution because of lack of features, quality, or integration.

BASEplatform low-speed I/O modules, GPIO, I2C, UART and SPI.
BASEplatform low-speed I/O modules

BASEplatform includes all the necessary software to interact with those peripherals using a powerful and thread safe API.  Moreover, both master and slave modes are provided for SPI and I2C to enable easy chip-to-chip communication. The API supports the traditional blocking call mode as well as non-blocking and asynchronous mode.

High-speed Communication and Storage

The next modules to cover are the high-speed communication and mass storage peripherals.

BASEplatform high-speed communication and storage integration including file system, TCP/IP communication and USB connectivity.
BASEplatform high-speed communication and storage

Contrary to low speed I/Os, interacting with those peripherals requires rather heavy protocol stacks or file systems. In this aspect the BASEplatform attempts to be as flexible as possible. Developers can select their preferred vendor or open source project and it is integrated within the BASEplatform. Depending on availability and the project specific requirements the drivers are either provided by the BASEplatform or the vendor native drivers can be used.

Other Peripherals and External Components

Finally, there is all the other components imaginable.

BASEplatform miscellaneous and external component modules such as SDIO, Wi-Fi, security and sensors and more.
BASEplatform miscellaneous and external components.

Those that do not always fall within the usual set of supported peripherals by RTOS vendors or manufacturer provided libraries. This can include application-specific peripherals such as MIPI and I2S as well as on-chip features such as random number generators and security accelerators. As an important differentiating factor in favour of the BASEplatform we can support off chip components as well. These off-chip components can be as simple as an IO expander and sensors to more complicated image sensors, Wi-Fi modules, etc.

All Together

Overall the BASEplatform bring customers a solid foundation for an embedded design along with long-term support and updates. All of this at a fraction of the cost of developing it in-house or subcontracting the development to a third party.

Read more about the BASEplatform here: jblopen.com/baseplatform


See all articles