Skip to content

feat(052): runtime-neutral KNX connector - #252

Open
lxsaah wants to merge 5 commits into
mainfrom
feat/platform-agnostic-knx-connector
Open

feat(052): runtime-neutral KNX connector#252
lxsaah wants to merge 5 commits into
mainfrom
feat/platform-agnostic-knx-connector

Conversation

@lxsaah

@lxsaah lxsaah commented Sep 6, 2026

Copy link
Copy Markdown
Contributor

Wave B of design 052, third and last connector. The adapter owns the UDP socket and the clock; this crate owns the tunnelling protocol.

tokio_client.rs (632) and embassy_client.rs (473) are gone, along with the whole Tokio*/Embassy* alias set. One KnxConnector<B, D, N> wires both runtimes onto the client::connection_task that landed in wave A.

With this, all three connectors carry zero runtime modules and zero unsafe impls.

Breaking

  • KnxConnector::new(binder, delay, gateway_url, &CHANNELS) — generic over core's DatagramBinder and Delay.
  • KnxConnector::tokio(gateway_url) on a host: supplies the Tokio transports and its channels, so a caller needs only the URL.
  • with_command_queue_size becomes the const generic N. An embassy_sync::Channel is sized at compile time — an MCU allocates it in a static, where the size must be a constant.
  • KnxConnectorBuilder, KnxConnectorImpl and the Tokio*/Embassy* aliases are gone.

Updated in-tree: aimdb-codegen, both KNX demos, and topic_provider_tests.

Worth a look in review

The channels are a caller-supplied &'static Channels<N>. Both the connection task and the pumps are spawned as 'static futures, so the channels must outlive the connector. An MCU supplies them from a StaticCell; KnxConnector::tokio leaks one pair at build — bounded, once per process, matching design 037's allocate-at-build model, but a deliberate leak worth seeing.

D1 moved into this PR. codegen-drift runs in make check, and aimdb-codegen emitted KnxConnector::new(&knx_gateway) — a signature that no longer exists. KnxConnector::tokio exists so the generated line stays one call rather than adapter types plus a static; codegen changed by one word and no re-baseline was needed (✓ Codegen output compiles against the workspace).

aimdb-tokio-adapter becomes a tokio-runtime dependency, the same relaxation taken for the serial connector — the adapter owns the datagram socket on both runtimes rather than the connector duplicating it.

Two adapter binders gained Clone. TokioUdpBinder and EmbassyUdpBinder could not be held by a ConnectorBuilder, which clones its transport per build. That is the third wave-A type to need this after the TCP dialers — the traits were right, but their composition into a builder was untested. Worth a compile-time assertion in core.

Verification

make check clean: 2 017 tests, 0 failures, all stages including codegen-drift.

Note

Touches examples/embassy-knx-connector-demo/src/main.rs, which #251 also edits (its SerialServer line). Whichever merges second needs a rebase there.

lxsaah and others added 5 commits September 6, 2026 10:23
- Updated the KNX connector usage in examples and tests to utilize the new `KnxConnector::tokio` method instead of the deprecated `KnxConnector::new`.
- Removed the `tokio_client.rs` file as it is no longer needed with the new connector structure.
- Adjusted the `lib.rs` file to reflect the new connector organization and removed platform-specific implementations.
- Updated tests to ensure compatibility with the new connector API.
- Added static buffers and channels for the Embassy adapter in the embassy example.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Brings in the runtime-neutral TCP (#250) and serial (#251) connectors.

Conflict was in the Embassy KNX demo's imports, where both sides moved:
main rehomed `SerialServer` out of `embassy_transport` and wrapped its
halves in the new `EmbassyUart`, while this branch replaced
`KnxConnectorBuilder` with the sans-io `KnxConnector::new`. Kept both.

Also adds the embassy adapter's `net` feature to the demo. It used to
arrive transitively through the serial connector's `embassy-runtime`
feature; #251 made that crate runtime-neutral, so nothing pulls the
adapter in on its behalf any more and `EmbassyNet::udp`/`EmbassyDelay`
have to be requested where they are used.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant