<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>
<@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