ARDEP: an open hardware board with Zephyr and UDS already wired up

A board, a shield, and a Zephyr framework in one repository

ARDEP, which the README expands as the Automotive Rapid Development Platform, is described as an open-source hardware and software platform that simplifies automotive development. It combines a feature-rich development board with a robust Zephyr-based software framework, and the stated purpose is that you can build and deploy automotive applications quickly, whether you are prototyping a new automotive device or experimenting with diagnostics. The scope of the repository is unusually complete for a hardware project. The top-level entries include boards/, hardware/, lib/, samples/, modules/, drivers/, dts/, firmware_loader/, include/, doc/, tests/, scripts/, patches/ and zephyr/, alongside a west.yml, a CMakeLists.txt, a Kconfig, a debug.gdbinit file and a PROVIDER_INFORMATION.md. That is a Zephyr west workspace with a real board port in it, not a schematic dump. The documentation lives at mercedes-benz.github.io/ardep/ with separate pages for the board, the PowerIO shield, the UDS library and the samples.

What is actually on the board

The At a Glance section describes the hardware as a complete solution with CAN, LIN and other common communication interfaces, and the key features list expands that. The board has onboard CAN and LIN transceivers, so no external components are needed to talk to a vehicle network. It has an integrated debugger and programmer with a UART connection, which removes the separate debug probe from the bill of materials. There are Arduino headers for compatibility with a wide range of shields and accessories, and the separate PowerIO Shield extends power capabilities with six high-side switches at up to 48V and 3A per channel, described in one place as six outputs and six inputs up to 48V and 3A per channel. The shield has its own documentation and its own board directory in the repository, and the samples directory includes a power_io_shield example, so the shield is a first-class part of the platform rather than an accessory that happens to fit.

UDS diagnostics and DFU are the parts that save you the work

The software side is where the platform earns its keep, and two features stand out. The first is built-in UDS support, ISO 14229, described as professional diagnostics, and the second is integrated DFU, Device Firmware Update, over UDS, so a firmware update path is already there. These are the parts of an automotive project that are tedious to get right and are the same on every ECU, which is exactly why the samples directory has uds/, uds_bus_sample/ and uds_legacy/ entries alongside iso14229/. The connectivity story is broad, with CAN, LIN, SPI, I2C and UART exposed through unified APIs, and the architecture is described as a modular design with a clean separation of concerns, intended for long-term maintainability. The framework is built on Zephyr RTOS, and the README names that as a proven foundation with a large ecosystem, which is a deliberate choice over a vendor SDK and also a decision about which tools you will use for debugging and flashing.

The samples are the learning path

The repository ships a set of sample applications that map directly onto the board's capabilities, and reading them is the fastest way to understand the framework's conventions. The list includes adc/, can/, can_usb_bridge/, dac/, digital_input_interrupt/, gearshift/, gpio_expander/, hardware_test/, hardware_tester/, hv_shield/, led/, lin/, lin2can/, power_io_shield/, uart/, uds/, uds_bus_sample/ and uds_legacy/, with an index.rst tying them together. A few of these names carry more information than the others. can_usb_bridge/ is the case where a PC with a USB CAN adapter talks to the board, lin2can/ does the same for a LIN network, hardware_tester/ and hardware_test/ look like the bring-up applications you would run first on new hardware, and the gearshift/ and gpio_expander/ samples show how the digital and interrupt features are used in something shaped like a real automotive load. There is also a samples/uds_legacy/ directory, which suggests the framework is expected to interoperate with diagnostic tooling that predates the current UDS implementation.

Getting the board, and where the hardware files live

The hardware is not sold off a shelf yet. Frickly Systems has started a Crowd Supply campaign to make the hardware available for purchase, and the README explains that the campaign exists so that people can subscribe to be notified when it launches, with the campaign linked from the getting the hardware entry in the waypoints list. The repository carries the production data in the hardware/ directory, and the waypoints section links the board documentation and the PowerIO Shield documentation separately. So the two halves of the project are in different places in time: the software, the board support, the samples and the documentation are all public and readable now, while the physical board is a campaign that has not yet launched. For a hardware project that is normal, and for an evaluator it means you can read the design and the firmware before committing to anything, but it also means you cannot buy the board today from this README.

Where the platform is the wrong tool

Three limits are worth naming. The first is the availability question above, and it is not a small one: without a board, the samples cannot be run on real hardware, and the repository does not describe an emulator path for them. The second is the specificity of the platform. The samples and the drivers are written for this board's peripherals, and the Zephyr base means you get the ecosystem but also Zephyr's model, its configuration system through Kconfig and the fact that the board is a fixed target rather than a portable abstraction. If your eventual product runs on a different automotive MCU, the reusable part is the driver and UDS work, not the board support package. The third is the vendor relationship. The project is published by Mercedes-Benz, the licence is Apache 2.0, and the hardware is manufactured by Frickly Systems through a crowdfunding campaign, so the long-term availability of the board and the pace of the software both depend on a commercial arrangement outside the code. For learning, evaluation and prototyping, that is a fair trade. For a product line, the risk sits in the hardware rather than in the repository.

Licence, governance and the state of the tree

The licensing is straightforward. The project is licensed under the Apache 2.0 License, with the copyright held by Mercedes-Benz AG, and a LICENSE file at the repository root. The repository also carries CONTRIBUTING.md, a CODE_OF_CONDUCT.md and a SECURITY.md, and the contributing section invites contributions with a pointer to the guidelines file, which is a sign the project wants outside code rather than only publishing its own. There are no GitHub releases, and the last push to the repository was on 2026-09-18, so the tree is being worked on without a published version sequence. The internal structure tells you what the platform is made of, and it is worth reading as a map of the effort: the boards/ directory holds the board support including the mercedes ardep board, hardware/ holds the production files, lib/ holds the software libraries such as the UDS library referenced from the documentation, firmware_loader/ holds the update mechanism, dts/ holds device tree sources, and zephyr/ and modules/ hold the framework integration and the out-of-tree Zephyr modules.

Editorial conclusion

ARDEP suits an engineer or student who wants to prototype an automotive ECU without a lab full of specialist hardware, because the diagnostics, the bootloader and the bus transceivers are already on the board and the software sits on Zephyr rather than a vendor SDK. It is the wrong tool if you need production-grade hardware now, since the board is still being put through a Crowd Supply campaign and the README does not state a shipping date or a unit price, and it is the wrong tool if your work has to run on a specific MCU family that the platform does not carry. Verify first which sample corresponds to your task, since the samples directory spans CAN, LIN, UDS, power IO and hardware test applications, and note that the repository publishes no GitHub releases while the last push was on 2026-09-18.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. mercedes-benz/ardep on GitHub
4. Project website
5. README