46c26796cc
BAUD_RATE was declared separately in firmware/src/board.rs and bridge/src/main.rs with a comment asking that they be kept in agreement by hand. A baud mismatch between two ends of an RS485 segment is silent and presents as random CRC failures, which is a poor thing to debug and a poor thing to leave to a comment. It now lives in wiredsensor_core::timing alongside the arithmetic that derives from it, because the line rate is a property of the segment rather than of any one board. board.rs re-exports it, and the bridge takes a dependency on core purely to read it — it still knows nothing about the protocol itself. INTER_FRAME_GAP_US and CHAR_TIME_US move with it and are now derived at the definition site, with a test asserting they cannot go stale if the rate changes. Also fills two documentation gaps: the bridge and PC test suite were committed without any README coverage, and the account of the RTIM pitfall still described the incomplete understanding held before the hardware test found the real mechanism. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
31 lines
671 B
TOML
31 lines
671 B
TOML
[package]
|
|
name = "wiredsensor-bridge"
|
|
description = "Turns a spare RP2040 into a USB-to-RS485 bridge for testing the bus"
|
|
version.workspace = true
|
|
edition.workspace = true
|
|
license.workspace = true
|
|
|
|
[[bin]]
|
|
name = "wiredsensor-bridge"
|
|
path = "src/main.rs"
|
|
test = false
|
|
bench = false
|
|
|
|
[dependencies]
|
|
# Only for the shared line rate; the bridge deliberately knows nothing about
|
|
# the protocol itself.
|
|
wiredsensor-core = { workspace = true }
|
|
|
|
rp2040-hal = { version = "0.12", features = ["rt", "critical-section-impl"] }
|
|
rp2040-boot2 = "0.3"
|
|
|
|
cortex-m = "0.7"
|
|
cortex-m-rt = "0.7"
|
|
embedded-hal = "1.0"
|
|
fugit = "0.3"
|
|
|
|
usb-device = "0.3"
|
|
usbd-serial = "0.2"
|
|
|
|
panic-halt = "1.0"
|