Repository navigation
Pin directions on by default: dut_dirs in the wiring profile, sent on connect (SDK + MCP 2.13.14) - #77
Merged
Conversation
…beddedci 2.13.14) On firmware 3.10.4+ the SDK sends the wiring profile's DUT directions with la_dir on connect and whenever bp.wiring changes, and marks unwired pins unknown; older firmware is skipped quietly. bp.pin_directions_status says how it went; the connection never fails over it. Every wired role and signal has a direction (SWD now too: SWCLK dut_input, SWDIO bidir); the new top-level dut_dirs key overrides any of them. Old profiles stay valid, and releases before this one keep a server profile with dut_dirs in Wiring.extra. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…_dir (embeddedci-mcp 2.13.14) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Nov 13, 2026
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
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.
The pod's pin-direction safety (
la_dir, firmware 3.10.4) only protected pins someone marked by hand. Now the wiring profile gives every wired role and signal a DUT direction, and the SDK and MCP send them on their own.SDK (embeddedci 2.13.14)
Capabilities.la_dir),BenchPod()sends the profile's directions withla_dirwhen it connects and wheneverbp.wiringchanges (alsosave_wiringwith a new profile). Pins the profile doesn't name are markedunknown. Older firmware and the USB console are skipped quietly.bp.pin_directions_statusis"sent"or"not sent: <why>"(older firmware, or a pin the profile calls a DUT output that is driven right now).apply_pin_directions()still raises.uart_rx,spi_miso=dut_output;uart_tx,spi_sclk/mosi/cs,swd_swclk=dut_input; I2C andswd_swdio=bidir(SWD is new); signals from their pod-sidedirection(input->dut_output,output->dut_input, elsebidir).dut_dirs: role key or signal name ->dut_input/dut_output/bidir, validated. Top-level on purpose: released SDKs keep an unknown top-level key inWiring.extra(a new signal field would make them drop the whole server profile). Old profiles stay valid.Wiring.dut_dir(name),Wiring.pin_dut_dirs();describe()shows the direction column.apply_pin_directions()sendsunknownfirst anddut_outputlast.MCP (embeddedci-mcp 2.13.14)
connectandset_wiringsend them (via the SDK);wiringrows havedut_dir,wiring/set_wiringreportdirections;statuswarns when a driven pin kept them from going out (not for old firmware).Order: the server must be deployed before an SDK sends
dut_dirsto it (the current production server rejects unknown keys). The server side (schema, validation, server-side push on connect and save) is pushed to embeddedci-server main.Tests: fake-transport host tests for defaults, overrides, validation, round trip, push on connect, skip on 3.10.3/unknown firmware, re-mark on a new profile, driven-pin conflict; MCP tests for
set_wiring/wiring/old firmware. Not run on hardware.🤖 Generated with Claude Code