Tag Archives: embedded

Enhancing Real-Time Capabilities with the PRU – Ron Birkett, Texas Instruments

The PRU is a real-time microcontroller co-processor that is present on some OMAP/Sitara-series processors.

The meaning of real-time is different depending on your application. How much time you have, how much there is to do in that time, … It’s not necessarily about high performance, though increasing performance may be a way to get your real-time behaviour. What is always there is that it needs to be (to some extent) deterministic and that it has to be low-latency.

In e.g. a Cortex-A based system, there are a lot of components that are bad for real-time; caches, interconnect, GPIOs that are beyond the interconnect, …. It’s really designed for throughput, not for (deterministic) latency. So TI added a Programmable Real-Time Unit (PRU). It has fast deterministic access to on-chip RAM and to GPIOs. It’s a simple 32-bit RISC instruction set, it doesn’t have a pipeline, it runs at 200MHz. It’s connected to the Cortex-A over the non-deterministic interconnect, but that doesn’t matter because at that point it’s not RT anymore. It has direct access to the GPIOs, so the pins can toggle at 100MHz. It also has some dedicated peripherals, e.g. UART, eCAP/PWM, MDIO for ethernet, and timers.

Every Cortex-A SoC from TI in the future is going to have at least one PRU.

The PRU doesn’t have real interrupts, instead it uses polling. Not good for power consumption (it’ll take about 500mW all the time), but great for determinism.

The PRU recently got a compiler, which is based on TI’s earlier DSP compilers, there are some register header files. Compiler runs in Linux/x86, they’re thinking about porting it to ARM.

How to interface between the PRU and the Linux on the Cortex-A? Linux needs to load the firmware to the PRU, it needs to manage the shared resources (memory, which CPUs are used, who uses which peripheral), it needs to start and stop the PRUs, it needs to share data and synchronize (events, interrupts). This is done through the remoteproc/rpmsg and virtio transport frameworks.

Remoteproc is a framework meant to deal with other processors in the system. It’s configured through the DTB, which specifies each PRU in the subsystem, how much memory it has, …. remoteproc has an interface for powering up the remote device and controlling it. It’s completely upstream. The probe function looks for firmware to load in /lib/firmware. A resource table is used to pass information to the remote firmware about how Linux is using it.

remoteproc has a communications framework called rpmsg. Note that sometimes you don’t need to communicate anything, because you just need to get events from the PRU and no data (e.g. temperature monitor sends an event when temperature is too high) – in that case, you can just use the interrupt provided by remoteproc. The PRU has an rpmsg library to handle the communication. rpmsg is built on top of virtio (which is meant for VMs, but this is actually similar). rpmsg has a userspace component (/dev/rpmsg-pruN) on Linux so you can use it from your application. TODO: implement a demuxing part in the kernel so that e.g. you can send debug messages from the PRU directly to the console.

There are still some core architecture changes needed in rpmsg to improve performance (e.g. avoid the 40-cycle hardware mailboxes).

Testing of Open Source Embedded Systems

While developing software for an embedded system, you want to be sure that you’re going in the right direction and that you don’t break things. Testing the software is the easiest way to get feedback about the code you’ve written. However, the developer has to find a good balance between time spent on testing and time spent on development. As consultants for embedded open source technologies, we at Mind encounter many different approaches to testing with our customers. This article structures these varied experiences and combines best practices, techniques and tools, with a focus on embedded open source software.

I presented this content at the Embedded Linux Conference – Europe, 2010 in Cambridge. Slides are available in PDF and in ODP format.  They are CC-BY, so you can reuse them if you like.

Continue reading

Embedded software quality: testing, debugging and optimization

Writing the code is only half the story. To make something that actually works for the user, it will have to be tested, debugged and probably optimized. That is the focus of this part of our series of articles about embedded software development using FOSS. Continue reading

The embedded FOSS software development process toolbox

Like any software, the embedded software development process needs to be supported by development and maintenance practices. In the first part we saw why in modern embedded systems the use of Free and Open Source Software can no longer be ignored, and the difficulties this introduces in the software development process. In the next part, we’ll look at testing, debugging and optimization. In this part, we look at the software development process support tools that are suitable for embedded system development with FOSS. These include version control systems, issue tracking systems, documentation systems, managing the build process, and managing releases. Bringing these practices together allows you to deal efficiently with FOSS in your embedded software development.
Continue reading

The case for embedded FOSS and the consequences

Basing an embedded device on Free and Open-Source Software (FOSS) brings many advantages, not the least of which is complete control over the software stack and free reuse of existing high quality solutions. However, it also means having to deal with large amounts of code, mainly coming from external parties. Coping with this can be a challenge for small embedded teams, used to smaller stacks developed in-house.In this series of articles, we take a step by step tour of good software development processes and how to use them to improve your organisation. We emphasise embedded development and point out particular pitfalls to avoid.
Continue reading