This week, our team began shifting more substantially from the design and component-selection phase of the project toward implementation. Over the past several weeks, much of our work has focused on determining the overall system architecture, selecting the processor and audio components, understanding the requirements of the ANC algorithm, and determining how the electronics can be integrated into the wearable form factor. With most of these larger architectural decisions now established, we have started ordering development hardware, completing breakout boards, and preparing the firmware that will allow us to begin testing individual subsystems as soon as the hardware arrives.
A major milestone this week was ordering the development boards for the processor that we plan to use in the final system. Having the development boards on the way allows us to begin moving from theoretical estimates of processing capability and latency toward measurements on the actual hardware. In preparation for their arrival, we have started drafting several of the low-level drivers that will eventually be needed for the system. This includes planning the interfaces for peripherals such as I2C, I2S/SAI, DMA, timers, and other hardware needed to communicate with the audio codec and supporting components. Although these drivers cannot yet be completely validated without the target hardware, beginning them now should allow us to bring up the development boards more quickly once they arrive rather than starting the firmware from scratch at that point.
We also made progress on the custom hardware required to interface with several of our selected components. The breakout boards that we had been designing are now largely complete, allowing us to move closer to fabrication and physical testing. In particular, these boards will make it easier to prototype with components that would otherwise be difficult to connect directly to development hardware. Completing these designs represents another transition from system-level planning toward building and validating the actual electrical interfaces. Once the boards are fabricated and assembled, our immediate goal will be to verify power delivery and communication with each device independently before beginning full-system integration.
Another area we investigated this week was how firmware will eventually be programmed onto the processor once we transition away from the development board and onto our own PCB. To better understand how this is handled in an existing compact wearable product, we disassembled a commercially available headphone and examined how its internal electronics were laid out and accessed during manufacturing. This gave us useful inspiration for how programming and debugging interfaces can be incorporated into a small device without requiring a large permanent connector. It also helped us think more concretely about how our own PCB will transition from a development platform into hardware that can actually fit inside the final wearable.
Based on this investigation, we currently plan to use ST-Link and the STM32 SWD programming/debug interface for flashing the processor on our custom board. Rather than including a large header that would remain permanently attached to the final device, we plan to expose only the small number of connections required for programming and debugging. Our current concept uses approximately five wires for the ST-Link connection, providing the necessary programming, debugging, power-reference, ground, and reset connections. These wires can be attached during development and initial programming and then cut or removed once the board has been flashed and no longer requires a permanent programming connector. This approach should reduce the PCB area and physical volume required by the programming interface while still preserving convenient access during development.
The firmware architecture is also beginning to move from a high-level block diagram toward an actual implementation plan. Our previous work established that the ANC pipeline will rely heavily on DMA so that audio samples can continuously move between the codec and processor without requiring the CPU to manually handle every sample transfer. The processor can then operate on blocks of incoming samples while DMA simultaneously receives and transmits other blocks. With the development hardware now ordered, we can begin implementing the software infrastructure required for this architecture and eventually benchmark the actual interrupt frequency, DMA transfer timing, CPU utilization, and end-to-end latency. These measurements will be important because our previous research showed that latency is one of the most important constraints for achieving effective feedforward ANC.
We are also beginning to think more carefully about the progression of our hardware bring-up. Rather than immediately attempting to run the full adaptive ANC algorithm, we plan to validate the system incrementally. The first step will be confirming that the STM32 can communicate correctly with the audio codec and reliably receive and transmit audio using DMA. We can then test simple passthrough and fixed-filter processing before moving to the adaptive FxLMS implementation. This should make debugging significantly easier because problems involving the codec configuration, DMA transfers, timing, or signal processing can be isolated before they become part of a much larger system.
The physical teardown of an existing headphone also helped connect our electrical and mechanical design work. Previously, we had considered the size of the processor, codec, battery, microphones, and speakers primarily from datasheets and rough physical layouts. Seeing how a commercial headphone routes wires, distributes electronics, provides manufacturing access, and packages its PCB inside a limited enclosure gave us a more realistic reference for our own design. While our sleep-mask form factor is different from a conventional headphone, many of the same constraints apply, particularly minimizing rigid PCB area, avoiding large connectors, and ensuring that development interfaces do not unnecessarily increase the size of the final product.
Overall, the project is now moving from determining what we intend to build toward actually building and testing the subsystems required for the final device. Component selection and architectural decisions will still continue as necessary, but the development boards being ordered, breakout-board designs being completed, driver development beginning, and programming strategy becoming more concrete represent a significant transition into implementation. Our next major objective is hardware bring-up once the development boards and breakout boards are available. We plan to verify the basic STM32 peripherals, establish communication with the audio codec, test DMA-based audio transfers, and begin measuring the timing and computational performance of the audio-processing pipeline. These results will provide the first direct indication of how closely our earlier design assumptions match the behavior of the actual system and will guide the next stage of ANC implementation and hardware integration.