You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
feat(transport): SPI transport for Zephyr's new SMP-over-SPI server transport #139
This issue was authored by claude-opus-5-5[1m] on behalf of @JPHutchins. While surveying Zephyr main's SMP server transports for the #58 design, we found a new SPI transport, and @JPHutchins asked for a tracking issue.
Zephyr added an SMP server transport over SPI in zephyrproject-rtos/zephyr#106947 (merged 2026-08-11), resolving the feature request zephyrproject-rtos/zephyr#106233. smpclient has no SPI transport. The natural client is an SPI controller, e.g. Linux spidev plus a GPIO line for data-ready.
Not part of #58, but it should be written against #58's shape: the transport wraps an already-open resource (here the spidev handle and the data-ready GPIO), and the Transport.connected(...) bracket opens and closes both.
The server's protocol (Zephyr main @ 70be2ff0)
Roles. The device is the SPI peripheral and drives a data-ready GPIO while a response is queued. DT compat zephyr,smp-spi with a required data-ready-gpios (binding).
Transfers. Full-duplex transfers of up to CONFIG_MCUMGR_TRANSPORT_SPI_MTU bytes (default 256, range 8 MCUMGR_TRANSPORT_NETBUF_SIZE; Kconfig.spi). The peripheral's TX buffer is zeroed before each transfer, so a transfer with nothing queued clocks out zeros.
Receive. Raw SMP, no encoding. A transfer whose first 8 bytes are all zero is treated as idle. Otherwise the SMP header's nh_len drives reassembly across transfers, and a message larger than NETBUF_SIZE is rejected with -EMSGSIZE (smp_spi_reassembly_collect).
Transmit. A response is copied into a TX packet and sent in SPI_MTU-sized chunks on subsequent transfers. Data-ready stays asserted until the response is drained (smp_spi_finish_tx).
Sizing for the client. The largest message the client may send is the MCUmgr params buf_size itself (no framing overhead). SPI_MTU (the per-transfer chunk size) is not reported by any command, so the client must be told it or choose a transfer size itself. The server's get_mtu callback exists but nothing calls it.
Warning
LLM Disclosure
This issue was authored by
claude-opus-5-5[1m]on behalf of @JPHutchins. While surveying Zephyrmain's SMP server transports for the #58 design, we found a new SPI transport, and @JPHutchins asked for a tracking issue.Zephyr added an SMP server transport over SPI in zephyrproject-rtos/zephyr#106947 (merged 2026-08-11), resolving the feature request zephyrproject-rtos/zephyr#106233. smpclient has no SPI transport. The natural client is an SPI controller, e.g. Linux
spidevplus a GPIO line for data-ready.Not part of #58, but it should be written against #58's shape: the transport wraps an already-open resource (here the spidev handle and the data-ready GPIO), and the
Transport.connected(...)bracket opens and closes both.The server's protocol (Zephyr
main@70be2ff0)zephyr,smp-spiwith a requireddata-ready-gpios(binding).CONFIG_MCUMGR_TRANSPORT_SPI_MTUbytes (default 256,range 8 MCUMGR_TRANSPORT_NETBUF_SIZE; Kconfig.spi). The peripheral's TX buffer is zeroed before each transfer, so a transfer with nothing queued clocks out zeros.nh_lendrives reassembly across transfers, and a message larger thanNETBUF_SIZEis rejected with-EMSGSIZE(smp_spi_reassembly_collect).SPI_MTU-sized chunks on subsequent transfers. Data-ready stays asserted until the response is drained (smp_spi_finish_tx).buf_sizeitself (no framing overhead).SPI_MTU(the per-transfer chunk size) is not reported by any command, so the client must be told it or choose a transfer size itself. The server'sget_mtucallback exists but nothing calls it.🤖 Generated with Claude Code