Embedded Systems

What do you cover under custom BSP, industrial SoC and firmware work?

We cover custom BSP, industrial SoC selection and embedded firmware development for device makers, machine builders and silicon vendors.

We select the part, design and bring up the board, write the board support package for the peripherals the reference design does not cover, and build the firmware above it. Our team has shipped this work on Xilinx Zynq, Altera Cyclone parts, TI Sitara and Renesas RZ/N-class silicon. The engagement is usually one of these shapes:

• A device you have not built yet. Custom device development from silicon selection and industrial PCB design through bring-up to shipping firmware.
• A third-party board, brought to life. Board bring-up and hardware validation on hardware you already have, including the peripherals the reference design does not document.
• A BSP for a new part. Custom BSP industrial SoC work, which is most of what “porting Linux” means in practice.
• Firmware onto new silicon. Firmware porting industrial SoC-side, where the application is proven and the platform underneath it changed.
• A reference design for a vendor. Silicon vendor reference design and BSP work, so a new part arrives with something a customer can build on.
• The radio. Wireless industrial device design across BLE, Zigbee and wireless HART, industrial Wi-Fi, RF front-end design, or UHF RFID reader development.

Most embedded projects run into trouble one layer below the application: a peripheral with no driver, a BSP that boots but drops interrupts, or firmware that behaves on the bench and misses its deadline in a cabinet at temperature. That layer is the work we take on:

• Silicon selection, which constrains every decision made after it.
• Board design and bring-up, to the point where the software team can treat the hardware as known-good.
• The BSP, covering the peripherals a reference design leaves out.
• Firmware, across bare metal, RTOS and embedded Linux.
• Peripheral bus integration across I²C, SPI and UART, along with the memory interfaces, Ethernet PHYs and high-speed signals that account for a large share of the defects and rework found during bring-up.

What we do not do is commission machines or plants. We build the device inside your product and integrate and test it with your engineers.

A reference BSP boots a reference board. Your board may have different memory, different power sequencing, a different boot medium, and peripherals the reference design might not have carried at all. Each of those has to be brought up and validated on your hardware before the software above it can be trusted.

The build environment is handed over with the BSP, since industrial products typically stay under support for longer than the toolchain that built them.

When does a timing guarantee have to move from software to hardware?

A timing guarantee moves into hardware when the deadline is tighter than a software scheduler can honour.

Jitter matters more than throughput here. On tuned real-time Linux with a driver written for determinism, the practical boundary sits in the tens of microseconds of jitter, which is where our delivered NIC driver figure in the FAQ below sits. Below that band the timing moves into hardware, and there is more than one route:

Which route is suitable depends on volumes, protocol and the timing and processing budget. The same reasoning is why some of our work runs on hybrid arrangements such as an x86 host with an FPGA across PCIe, brought up as one platform.

On TI Sitara parts our team integrates TI’s PRU-ICSS protocol firmware with the customer’s application, builds the interface between the Arm and PRU sides, and tests the combination until the defects that only appear under real traffic are isolated and closed.

What does low-power design constrain?

Low-power design changes the architecture decision and part selection as well as the optimisation level.

A low-power embedded design changes which silicon is eligible, how the radio duty-cycles, whether a peripheral can stay enumerated between samples, and what the firmware is allowed to do while nothing is happening. Three things have to be designed into the hardware rather than added later:

• Power domains that can be switched, so peripherals and whole sections can be turned off and brought back predictably, with the sequencing, inrush and oscillator start-up that implies.
• A way to keep time while it sleeps, usually a low-power real-time clock or a separate always-on timer domain, because the main oscillator is usually disabled in deep sleep modes.
• Headroom for peak current, because a weakening battery can still run the board at rest and then sag when the radio or an actuator draws its peak. Local storage capacitance, or a staggered power-on sequence, holds that peak so a critical function does not fail first.

Small form-factor board design tightens the same loop again, because thermal headroom is low at that size. Both constraints set the silicon and topology choices.

Which parts of a process transmitter do you build?

We build the device itself: the board, the sensor front end, the firmware, the enclosure and the power budget.

A process transmitter programme splits three ways and most need at least two of them. Its communication stack is fieldbus and device networks, and the control application that consumes the measurement and acts on it is control software.