feat: add cu-linux-resources and igrates Linux/std components to consume centralized serial/I2C/GPIO resources#790
Conversation
433e5e6 to
fac6ac2
Compare
gbin
left a comment
There was a problem hiding this comment.
It is going in the right direction but it looks half done. The users of the serial ports should just get a serial port, no adapter needed from both std and nostd implementations. (but if I missed some hard requirement please comment)
| Ok(FromStd::new(port)) | ||
| pub struct LockedSerial<T>(pub T); | ||
|
|
||
| impl<T> LockedSerial<T> { |
There was a problem hiding this comment.
Applied same change for MSP: removed bridge-local serial wrapper and kept resource acquisition as Owned<S> from bundle mapping
| @@ -403,53 +413,23 @@ impl ResourceBundle for StdSerialBundle { | |||
| )) | |||
| })?; | |||
| let device = cfg | |||
There was a problem hiding this comment.
serial setup remains in bundle config/provider, and bridge user path is now uniform without extra adapter code
|
|
||
| /// Wrapper for resources that are logically exclusive/owned by a single | ||
| /// component but still need to satisfy `Sync` bounds at registration time. | ||
| pub struct Exclusive<T>(T); |
There was a problem hiding this comment.
this is basically what the users of the bundle should be using? Why do we need to wrap it?
There was a problem hiding this comment.
Yes, this is the bundle-level wrapper users should use when needed. We still need Exclusive<T> at registration because ResourceManager::add_owned requires T: Send + Sync. I kept that adaptation centralized in cu_linux_resources, added embedded-io 0.7 forwarding, added a test
Serial consumer-side adapters were removed; serial adaptation now lives in bundle/resource layer only, with |
gbin
left a comment
There was a problem hiding this comment.
ok I think the LLM doesn't understand at all what we are trying to do here.
# Conflicts: # components/sinks/cu_lewansoul/src/lib.rs # components/sources/cu_rp_encoder/src/lib.rs # components/sources/cu_wt901/src/lib.rs
|
I would just expose a set of hardcoded peripherals in the bundle for now: like /dev/ttyACM0 /dev/ttyACM1 /dev/ttyACM2 then /dev/ttyUSB0 /dev/ttyUSB1 /dev/ttyUSB2 then /dev/i2c-0 /dev/i2c-1 /dev/i2c-2 ... you can imagine those as "slots" the tasks can take in just dag it should exactly look like this but with a bunch of unused resources |
2e3f782 to
6ef7695
Compare
|
@codex review |
|
Codex Review: Didn't find any major issues. Swish! ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
Summary
This PR introduces a new shared resource crate,
cu-linux-resources, and migrates several Linux/std components to consume centralized serial/I2C/GPIO resources instead of opening devices ad hoc.Changes
components/res/cu_linux_resources(cu-linux-resourcespackage,cu_linux_resourcesmodule path).LinuxResourcesbundle can register:LinuxSerialPorti2cviaLinuxI2cgpio_outviaLinuxOutputPingpio_inviaLinuxInputPincu_crsf,cu_msp_bridgecu_lewansoul,cu_rp_gpiocu_rp_encoder,cu_wt901docs/examplesto show provider:cu_linux_resources::LinuxResourcesand resource wiring (e.g.<bundle>.serial,<bundle>.gpio_in).StdSerialBundlecompatibility remains in CRSF/MSP bridges, now backed by LinuxSerialPort.Testing
just std-cijust lintcargo +stable nextest run --workspace --all-targetsjust nostd-ciChecklist
Breaking changes (if any)
Additional context
N/A