ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
GenTooMan has quit [Ping timeout: 246 seconds]
GenTooMan has joined #rust-embedded
duderonomy has quit [Remote host closed the connection]
duderonomy has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
emerent has quit [Ping timeout: 264 seconds]
emerent has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
Shell has quit [Remote host closed the connection]
Shell has joined #rust-embedded
<re_irc> <@firefrommoonlight:matrix.org> : which MCU are you doing CAN on?
<re_irc> <@firefrommoonlight:matrix.org> I've been doing a lot of CAN-FD lately, but that lib hasn't come up
<re_irc> <@firefrommoonlight:matrix.org> I think it's for if you're writing a generic driver?
<re_irc> <@firefrommoonlight:matrix.org> This lib, for STM32, is quite good: https://crates.io/crates/fdcan
<re_irc> <@apache8080:matrix.org> I’m doing CAN from linux using socketcan
<re_irc> <@firefrommoonlight:matrix.org> o
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
<re_irc> <@phaseonx11:matrix.org> Hey guys...I know this might be a really dumb/more Rust related question, but how does one share pins/buses with different functions? Since main owns drivers and drivers (typically) own pins, how does one break up a program into functions for re-usable code?
<re_irc> <@phaseonx11:matrix.org> For example, how would I abstract out the logic to build a string to display on a screen, clear the buffer then draw the screen into its own function? https://pastebin.com/7yuDCjKj
<re_irc> <@k900:conduit.0upti.me> You give it individual drivers
<re_irc> <@phaseonx11:matrix.org> Do you have any examples or code I can look at?
IlPalazzo-ojiisa has quit [Remote host closed the connection]
crabbedhaloablut has quit []
<re_irc> <@mali:grusbv.com> Can I feature gate memory.x or the build script?
dc740 has joined #rust-embedded
<cr1901> https://github.com/cr1901/postcard-infomem/tree/main/examples This isn't feature-gating, but memory.x is chosen based on an env variable. There should be env vars for your features too (and fail the build script if mut exclusive features are set)
<cr1901> Alternatively, if you don't want to fail the build, have one feature "override" another if they are mutually exclusive and both are set
<re_irc> <@mali:grusbv.com> cr1901: In that case, would the feature defined in the manifest be applicable in build.rs which is not in the src/ dir?
<cr1901> I have a weird workspace layout where src/ is also part of the workspace as the "default" package so to speak.
<cr1901> Oh wait. Ignore that. I misunderstood. I _think_ features are available as env vars (CARGO_FEATURE_*) even when the build script is runnin
nex8192 has left #rust-embedded [Error from remote client]
dc740 has quit [Remote host closed the connection]
<re_irc> <@mali:grusbv.com> Oh that is handy.
<re_irc> <@mali:grusbv.com> So like I could feature gate through env vars
<re_irc> <@firefrommoonlight:matrix.org> mali ⚡️: memory.x yes
<re_irc> <@firefrommoonlight:matrix.org> add a "build.rs" that looks like this:
<re_irc> use std::env;
<re_irc> use std::io::Write;
<re_irc> use std::fs::File;
<re_irc> use std::path::PathBuf;
<re_irc> fn main() {
<re_irc> let mut memory_x = None;
<re_irc> if let Some(_feature) = env::var_os("CARGO_FEATURE_H7") {
<re_irc> memory_x = Some(include_bytes!("memory_h7.x").to_vec());
<re_irc> } else if let Some(_feature) = env::var_os("CARGO_FEATURE_G4") {
<re_irc> memory_x = Some(include_bytes!("memory_g4.x").to_vec());
<re_irc> }
<re_irc> // Put `memory.x` in our output directory and ensure it's
<re_irc> // on the linker search path.
<re_irc> let out = &PathBuf::from(env::var_os("OUT_DIR").unwrap());
<re_irc> File::create(out.join("memory.x"))
<re_irc> .unwrap()
<re_irc> .write_all(&memory_x.unwrap())
<re_irc> .unwrap();
<re_irc> println!("cargo:rustc-link-search={}", out.display());
<re_irc> println!("cargo:rerun-if-changed=memory.x");
<re_irc> println!("cargo:rerun-if-changed=build.rs");
<re_irc> }
<re_irc> <@firefrommoonlight:matrix.org> Then you'd have "memory_h7 x" and "memory_g4 x" depending on the "CARGO_FEATURE_" lines
<re_irc> <@firefrommoonlight:matrix.org> Swap out those for what you need
nex8192 has joined #rust-embedded
<re_irc> <@firefrommoonlight:matrix.org> Then you'd have "memory_h7.x" and "memory_g4.x" depending on the "CARGO_FEATURE_" lines. (for features "h7" and "g4" respectively
<re_irc> <@mali:grusbv.com> : I am wondering, where does these println! s print to?
<re_irc> <@mali:grusbv.com> I never see them during compilation, but might be missing them
<re_irc> <@phaseonx11:matrix.org> K900: Maybe I'm not understanding correctly, but how would that be possible? Let's say for example:
<re_irc> let mut i2c = I2C::new(
<re_irc> io.pins.gpio21,
<re_irc> peripherals.I2C0,
<re_irc> io.pins.gpio22,
<re_irc> 400u32.kHz(),
<re_irc> &mut system.peripheral_clock_control,
<re_irc> &clocks,
<re_irc> );
<re_irc> let interface = I2CDisplayInterface::new_alternate_address(i2c);
<re_irc> let mut display = Ssd1306::new(interface, DisplaySize64x48, DisplayRotation::Rotate0)
<re_irc> .into_buffered_graphics_mode();
<re_irc> display.init().unwrap();
<re_irc> I should just pass the interface to a function so it makes its own driver?
<re_irc> <@phaseonx11:matrix.org> Maybe I'm not understanding correctly, but how would that be possible? Let's say for example:
<re_irc> let mut i2c = I2C::new(
<re_irc> peripherals.I2C0,
<re_irc> io.pins.gpio21,
<re_irc> io.pins.gpio22,
<re_irc> 400u32.kHz(),
<re_irc> &mut system.peripheral\_clock\_control,
<re_irc> &clocks,
<re_irc> );
<re_irc> let interface = I2CDisplayInterface::new\_alternate\_address(i2c);
<re_irc> let mut display = Ssd1306::new(interface, DisplaySize64x48, DisplayRotation::Rotate0)
<re_irc> .into\_buffered\_graphics\_mode();
<re_irc> display.init().unwrap();
<re_irc> I should just pass the interface to a function so it makes its own driver?
<re_irc> <@phaseonx11:matrix.org> Maybe I'm not understanding correctly, but how would that be possible? Let's say for example:
<re_irc> let mut i2c = I2C::new(
<re_irc> peripherals.I2C0,
<re_irc> io.pins.gpio21,
<re_irc> io.pins.gpio22,
<re_irc> 400u32.kHz(),
<re_irc> &mut system.peripheral\_clock\_control,
<re_irc> &clocks,
<re_irc> );
<re_irc> let interface = I2CDisplayInterface::new\_alternate\_address(i2c);
<re_irc> let mut display = Ssd1306::new(interface, DisplaySize64x48, DisplayRotation::Rotate0)
<re_irc> .into\_buffered\_graphics\_mode();
<re_irc> display.init().unwrap();
<re_irc> I should just pass the interface to a function so it makes its own driver?
<re_irc> <@firefrommoonlight:matrix.org> No idea
<re_irc> <@firefrommoonlight:matrix.org> I c+ped that from someone else lol
<re_irc> <@firefrommoonlight:matrix.org> I don't really understand it other than it appears to be making a "memory.x" in memory from the one you choose
<re_irc> <@firefrommoonlight:matrix.org> I haven't tried, but I bet you could make that script work with "config.toml" too
<re_irc> <@firefrommoonlight:matrix.org> *Naive attempt with .config/toml isn't working
<re_irc> <@jannic:matrix.org> The "println!"s in "build.rs" are the way it communicates back to "cargo". So they probably print to a pipe that's read by cargo. They are not meant to be shown to the user. (They can be seen in the output of cargo when called with "-vv")
<re_irc> <@onsdag:matrix.org> I think the esp-hals do it nicely
<re_irc> <@onsdag:matrix.org> (feature flagging linker scripts)
<re_irc> <@onsdag:matrix.org> * gating
<re_irc> <@mali:grusbv.com> I think this feels neater, not getting env vars into action