ProtoZOA Latest - #11
Open
AmeNote-Michael wants to merge 7 commits into
Open
Conversation
lib/CMSIS_5 was checked in directly (9,816 files, 414 MB), matching none of the project's other four dependencies, which are submodules. Only the CMSIS-DAP firmware sources (DAP.c, JTAG_DP.c, DAP_vendor.c, SWO.c) and CMSIS/Core/Include headers are actually consumed, by ProtoZOA_Main and ProtoZOA_PicoProbe. Switch to a submodule pointing at ARM-software/CMSIS_5, pinned to the latest stable tag (5.9.0, up from the in-tree 5.7.0).
- sdkVersion/toolchainVersion/picotoolVersion bumped to the versions the Raspberry Pi Pico VS Code extension pairs with SDK 2.3.0 (toolchain 15_2_Rel1, picotool 2.3.0). - cmake_minimum_required bumped 3.12 -> 3.13 across the project's own CMakeLists.txt files, matching the SDK's own floor. - Replaced the stale PICO_SDK_VERSION_STRING VERSION_LESS "1.3.1" guard (inconsistent with the 2.x pin) with a 2.0.0 floor. - Replaced ProtoZOA_PicoProbe's out-of-sync pico_sdk_import.cmake (hardcoded GIT_TAG master, missing PICO_SDK_FETCH_FROM_GIT_TAG support) with the current upstream template, matching the top-level copy. Verified with a from-scratch build against SDK 2.3.0 + toolchain 15_2_Rel1: all 8 targets (ProtoZOA_Main, ProtoZOA_PicoProbe, 4x UUT, 2x UUT_FreeRTOS) build and link cleanly, producing .uf2 outputs. Note: SDK 2.3.0's new linker-script include system (raspberrypi/pico-sdk#2841) requires CMake >= 4.x to correctly translate the LINKER:-L generator expressions it relies on -- CMake 3.31 (Homebrew's current release) fails to link copy_to_ram-type binaries (ProtoZOA_Main, picoprobe) with "cannot open linker script file section_platform_end.incl". This will be called out in the developer docs.
Gives CLI users, CI, and non-VS-Code IDEs (CLion, etc.) a single known-good configure/build command that doesn't depend on the VS Code extension's injected pico-vscode.cmake block -- that block is untouched and still applies when present, so both paths coexist. release/debug presets using Ninja; PICO_SDK_PATH (and PICO_TOOLCHAIN_PATH, unless on PATH) must still be set in the environment, matching how pico_sdk_import.cmake already resolves the SDK. Verified end-to-end: `cmake --preset release && cmake --build --preset release` produces all 8 .uf2 outputs from a clean build dir. Also gitignore CMakeUserPresets.json, the conventional location for personal local overrides (e.g. a machine-specific PICO_SDK_PATH) that shouldn't be committed.
Previously the only setup guidance was dated (2022-era) links to generic third-party tutorials -- nothing repo-specific about the Pico VS Code extension, PICO_SDK_PATH, required SDK/toolchain versions, CMSIS_5, or a CLI build path. - README: add a Building section covering both the VS Code extension and CLI/CMakePresets paths; fix the stale "ProtoZOA_UUT" directory table entry (actual dirs are UUT/ and UUT_FreeRTOS/) and add rows for lib/ and CMakePresets.json. - DeveloperGuide: replace the external tutorial links with concrete steps for both setup paths, call out the CMake 4.x requirement (SDK 2.3.0's new linker-script system doesn't link correctly under CMake 3.x -- confirmed while validating the SDK bump), note that submodules are SSH-only and require a configured GitHub SSH key, and explain what lib/CMSIS_5 is for and why it's pinned to 5.9.0.
The tusb_ump submodule's upstream main renamed MIDI_CS_INTERFACE_GR_TRM_BLOCK to MIDI_1_CS_INTERFACE_GR_TRM_BLOCK. Update the 4 app-level USB descriptor files that referenced the old name so the firmware builds against current tusb_ump main.
Bump lib/tusb_ump to pick up the endian fix, and switch all UUT projects from tud_ump_read/tud_ump_write to the new tud_ump_read_ntoh/tud_ump_write_hton variants for portable byte order. Also trim DIN_Bridge's USB descriptor down to a single UMP interface: it previously declared two Audio-Control+MIDIStreaming interface pairs while CFG_TUD_UMP is 1 and the firmware only ever reads/writes UMP interface 0, so the second interface's open() call was failing its slot-allocation assert and breaking USB MIDI enumeration for the whole device. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Bump lib/tusb_ump to pick up the wire-byte-order fix for native UMP (alt-setting 1) passthrough: the driver was serializing UMP words MT-byte-first, backwards from USB MIDI 2.0 spec section 3.2.2 (least-significant-byte-first), confirmed against real USB captures of both a spec-compliant host and this device's own output. Add a minimal UMP Endpoint/Function Block Discovery responder to DIN_Bridge (main.cpp), instantiating a umpProcessor and replying to the host's Discovery request with Endpoint Info, Device Identity, Endpoint Name, and a single Function Block declaration covering the one UMP group actually bridged to/from the DIN port. Without this, a UMP-native host may never finalize the endpoint as a live MIDI source even when raw UMP data is otherwise flowing correctly, which matched observed behavior (host traffic visible in USB captures but never surfaced by MIDI Monitor/Pocket MIDI as incoming data). Also adds timestamped diagnostic logging (ALT_SET changes, and both OUT/IN UMP words) to correlate firmware-side state against USB captures during this investigation. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This brings ProtoZOA code to latest SDK and VS Code plugin. All code tested, compiled. Main properly functions with LCD, buttons, knobs. The picodebugger also works as expected.
All UUT code runs. UUT_DIN_BRIDGE however currently seems to provide corrupted DIN MIDI stream. Needs to be investigated.
Note that this also makes the CMSIS library a submodule instead of part of code, significantly reducing size of repository.