DaisyExamples: the hardware-sorted sample code behind the Daisy audio platform

An example corpus organised by hardware board

DaisyExamples is the sample code repository for the Daisy platform, and its organising principle is hardware, not feature. The top level directories are named after board families, including seed, pod, petal, field, legio and versio, and each holds example projects for that specific board. That is a deliberate choice: a Daisy example is only meaningful against the pins, DAC channels and peripherals of one piece of hardware, so the repository refuses to pretend there is one universal demo. The code is C++ and builds on the libDaisy and DaisySP libraries, which are included as git submodules rather than vendored as plain directories, so the library versions you compile against are exactly the ones the repository pins. For a newcomer the project points to a separate Getting Started page, which suggests the examples assume you already have a development environment configured.

Two clone routes, both of which need the submodules

Getting the source right is the first practical hurdle, and the repository documents two equivalent ways to do it. The recursive clone pulls submodules in one step. The alternative clones plainly and then initialises the submodules separately. The reason both are documented is that the build will not work without libDaisy and DaisySP in place, and a plain clone leaves those directories empty, which produces a failure deep in the makefiles rather than an obvious message.

git clone --recursive https://github.com/daisyaudio/DaisyExamples

The two-step form reaches the same state:

git clone https://github.com/daisyaudio/DaisyExamples
git submodule update --init

Later, when you want to refresh your copy, the same logic applies to updates: a pull with the recurse-submodules flag brings both the examples and the libraries forward, while a submodule update with the remote flag advances only the libraries. Running ordinary git commands from inside a submodule directory also works, since git treats that directory as its own repository.

The build scripts cover the whole tree or just the libraries

There are two levels of build automation and they answer different needs. The top level script rebuilds everything, the libraries and all the examples, and the documentation is candid that this is time consuming. More often you only need one library rebuilt or one example compiled, so the ci directory holds a script that builds both libraries, which the documentation equates to entering each library directory and running make. The separate examples script compiles every example. The library build prints a short progress trace, and the toolchain used is the ARM bare metal GCC distribution, with the archive step named in the output. Toolchain installation itself is not covered here; the project defers to the Daisy support site for platform specific instructions, which is the point where most Windows and Linux newcomers will need that external page.

A single example builds with plain make in its own directory

When you are iterating on one program, the fast path is to change into that example's directory and run make. The documented Blink example sits under the seed board folder. The compiler invocation is worth reading once, because it explains what the platform is: an ARM Cortex-M7 target compiled with hard float and the fpv5-d16 FPU, the STM32H750 part selected by a define, HAL driver defines, and include paths into libDaisy and DaisySP. The build ends by reporting the size of the linked ELF image, then converting it to an ihex file and a raw binary, which are the artifacts you actually flash. That size report is the number to watch if you are adding code to a board with limited memory, and the presence of nano and nosys specs tells you the runtime is the minimal newlib configuration for bare metal.

Flashing takes either DFU over USB or a debug probe

Programming the board has two paths and the choice is about what hardware you have on the desk. Over USB, the board must be put into bootloader mode first and the make program-dfu target is used. With a JTAG or SWD adaptor such as an STLink, the make program target does the job. There is also a web flasher hosted on the Daisy domain that the project links to, which avoids the command line entirely. The make targets are per example directory, which is the same pattern as the build itself, so the workflow is consistent: change into the project directory, build it, flash it. Note that the DFU route needs the bootloader state, which is a physical step on the device and the most common place for a new user to get stuck.

VS Code tasks hide the terminal, including the clean rebuild

The repository ships a .vscode directory with tasks, and the workflow it enables is genuinely useful. Open the DaisyExamples directory as the workspace, open a .cpp file or Makefile for an example, and use Terminal then Run Build Task, bound to CMD/CTRL plus SHIFT plus B, to compile only the selected example. Pressing F5 starts a debug session with an ST-Link probe, and a second debug configuration exists for Segger J-Link probes, selectable from the Run and Debug panel. The task list adds four more entries that map onto make targets: a clean that removes the build folder, a DFU program, a program over a debug probe, and a re-build that cleans and recompiles. The re-build entry exists for a specific reason, stated in the documentation: editing a header file does not always trigger a recompile, so a forced clean is sometimes the only way to see a change.

Where the examples repository stops being useful

There are clear boundaries. First, it is not a library: pulling it into your own project means copying code, and the submodule setup exists to build the examples, not to serve as a dependency manager for downstream work. Second, the whole approach assumes the ARM bare metal toolchain and the Daisy board in hand, so there is no way to evaluate these examples on a desktop machine. Third, the repository carries patch and patch_sm directories alongside a stmlib directory and a cube folder with .ioc files and example projects that use STM32CubeMX generated code through the STM32 HAL, which is a second, parallel way of targeting the hardware. A newcomer who follows the CubeMX path ends up in different territory from the libDaisy path, and the repository does not explain in detail how the two relate. Finally, the helper.py utility script at the root is described as having several helpful uses, but the visible documentation stops before describing them.

Maintenance state and what a fork actually costs

The repository is not archived, and the last push was on 2026-10-20, so the examples are being kept in step with the library submodules they point at. There are no GitHub releases for this project, which is normal for an examples corpus: you take the tip of the default branch, master, and the versioning of the libraries comes from the submodules rather than from tags here. The licence is MIT, which means the example code can be reused in your own hardware project without a licensing obstacle, though a reader who copies patterns into a commercial product should still read the LICENSE file. A useful reference point for the surrounding ecosystem is the project homepage, which points to the DaisyWiki wiki rather than to a standalone site, and the community is organised around a Discord invite and a forum at community.daisy.audio.

Editorial conclusion

Adopt DaisyExamples if you are writing code for Daisy hardware and want working starting points per board rather than a single generic demo. Do not adopt it as a library dependency, since it is an examples repository that pulls in two submodules and expects a full embedded toolchain on your machine. Before starting, confirm that the arm-none-eabi toolchain is installed and that the board folder matching your hardware exists in the repository, then check the submodule pointers because the examples build against whatever libDaisy and DaisySP revisions are pinned there.

Frequently asked questions

Official sources

1. daisyaudio/DaisyExamples on GitHub
2. Issues
3. License: MIT
4. Project website
5. README