In the previous part of the series we explored the embedded-hal traits and how they can be used to create platform agnostic drivers in Rust. In this part, we will focus on how we can use the FT232H breakout board to interact with our I2C device from a desktop environment.

In this first part of the series, we’ll focus on the Embedded HAL (Hardware Abstraction Layer) and Embedded HAL Async—the foundation for writing portable Rust drivers.

What is it?

• embedded-hal-bus - provides traits for shared bus access, allowing multiple devices to share the same bus without conflicts.
• embedded-can - provides traits for Controller Area Network (CAN) communication, commonly used in automotive and industrial applications.
• And many more systems…

It’s a set of official traits maintained by the Rust Embedded Working Group that provide standardised interfaces for embedded protocols. Instead of everyone reimplementing read/write functions for I²C, SPI, or GPIO, there’s one common interface. There are two flavours: embedded-hal for blocking/synchronous operations, and embedded-hal-async for non-blocking/asynchronous ones.

Writing drivers that work consistently across microcontrollers, embedded Linux boards, and desktop operating systems is deceptively hard. Different HALs, conflicting abstractions, and platform-specific quirks often lead to duplicated code or forests of #ifdef blocks.

In the previous part of the series, we discussed the FT232H breakout board and how we can use it with Rust to interact with our I2C devices from a desktop environment. In this part, we will explore how we we can use our I2C driver on multiple platforms without changing any of the driver code, thanks to the embedded-hal and embedded-hal-async traits.

The Platforms

The beauty of using the embedded-hal traits is that we can write our driver code once and then use it on multiple platforms without any modifications. This is because the embedded-hal traits provide a common interface for interacting with hardware peripherals, regardless of the underlying platform. This means our vendors are responsible for implementing these traits in their HALs.

After leaving Babcock, I joined Dyson as part of the New Product Innovation Software Team (NST), a multidisciplinary group working across the entire technology stack—from embedded systems and application development through to cloud services and data science. During my time in the team, I developed numerous prototypes and explored a wide range of technologies, from bare-metal microcontrollers to embedded Linux platforms.

My Open Source Contributions

I’m a big fan of open source—where code is shared, bugs are squashed, and collaboration is the name of the game. Over the years, I’ve dabbled in all sorts of open source projects, sometimes as a developer, sometimes as a user. I especially like to get involved in Rust projects, and I hope to keep adding more to the ecosystem. You’ll find some of my favourite projects below, and even more on my GitHub profile.