<re_irc>
<@dirbaio:matrix.org> in the end,I think i2c bus/device didn't make much sense...
<re_irc>
<@dirbaio:matrix.org> * end, I
dc740 has quit [Remote host closed the connection]
<re_irc>
<@tmgross:matrix.org> : Whoops I disappeared for half a day. But you're right about this one, MII/RMII/XFI/etc probably make less sense than MDIO
<re_irc>
<@tmgross:matrix.org> I do think MDIO is reasonable to have, since almost any phy driver would be generic over a MDIO interface
<re_irc>
<@tmgross:matrix.org> And I don't mind being the one to head that up if there's nothing against the proposal, just curious where it would best belong
<re_irc>
<@sourcebox:matrix.org> : If you decide to support ADC oversampling, here's my code for the L4. G4 should also work, as well as G0. But the field names are not consistent across the different series.
<re_irc>
/// Ratio options for oversampling.
<re_irc>
#[allow(dead_code)]
<re_irc>
Times2 = 0b000,
<re_irc>
pub enum OversamplingRatio {
<re_irc>
Times4 = 0b001,
<re_irc>
Times8 = 0b010,
<re_irc>
Times16 = 0b011,
<re_irc>
Times32 = 0b100,
<re_irc>
Times64 = 0b101,
<re_irc>
Times128 = 0b110,
<re_irc>
Times256 = 0b111,
<re_irc>
}
<re_irc>
/// Shift options for oversampling.
<re_irc>
#[allow(dead_code)]
<re_irc>
pub enum OversamplingShift {
<re_irc>
None = 0b0000,
<re_irc>
Bits1 = 0b0001,
<re_irc>
Bits2 = 0b0010,
<re_irc>
Bits3 = 0b0011,
<re_irc>
Bits4 = 0b0100,
<re_irc>
Bits5 = 0b0101,
<re_irc>
Bits6 = 0b0110,
<re_irc>
Bits7 = 0b0111,
<re_irc>
Bits8 = 0b1000,
<re_irc>
}
<re_irc>
trait Oversampling {
<re_irc>
/// Enable or disable the oversampling mode.
<re_irc>
.modify(|_, w| unsafe { w.ovss().bits(shift as u8) });
<re_irc>
}
<re_irc>
}
<re_irc>
<@sourcebox:matrix.org> I run this on my board with 16x ratio, 4 bits shift and the readings have improved a lot in terms of noise.
fooker has quit [Ping timeout: 264 seconds]
lehmrob has joined #rust-embedded
fooker has joined #rust-embedded
lehmrob has quit [Ping timeout: 246 seconds]
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> I wonder if that could help on a sensor project I have. I switched to external ADCs because the internal ones gave very noisy output
<re_irc>
<@firefrommoonlight:matrix.org> (The internal ones have been fine for other uses, but seem to struggle on sensitive or high-impedance signals, from my testing)
<re_irc>
<@sourcebox:matrix.org> Internal ADC noise is also dependent on what's going on inside the chip, there has been some application note from ST about that a while ago.
<re_irc>
<@sourcebox:matrix.org> In my testing, oversampling has improved the situation by a good amount. If you can use it depends on the required sampling rate, but since the internal ADCs are quite fast, it's often possible.
<re_irc>
<@sourcebox:matrix.org> If you can use adaptive filtering, then you could also try my dyn-smooth crate: https://crates.io/crates/dyn-smooth
emerent has quit [Ping timeout: 248 seconds]
emerent has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> That is interesting
<re_irc>
<@firefrommoonlight:matrix.org> I've been using fixed-cutoff FIR and IIR
<re_irc>
<@firefrommoonlight:matrix.org> I bet you could use that for a dynamic notch filter, which I have a specific use for
<re_irc>
<@sourcebox:matrix.org> My crate is a dynamic lowpass, that's what you typically use for noise-filtering.
dc740 has joined #rust-embedded
<re_irc>
<@sourcebox:matrix.org> I think for a notch fiter, you have to determine the center frequency in some way.
<re_irc>
<@firefrommoonlight:matrix.org> Yes I know in this case
<re_irc>
<@firefrommoonlight:matrix.org> Filtering out rotor RPM noise
<re_irc>
<@firefrommoonlight:matrix.org> That changes each update
<re_irc>
<@sourcebox:matrix.org> And since a notch filter is quite steep, center frequency has to be exact.
<re_irc>
<@firefrommoonlight:matrix.org> Yep - I have that from measuring RPM
<re_irc>
<@sourcebox:matrix.org> Could be also possible to have more than one filter applied because of harmonics.
<re_irc>
<@firefrommoonlight:matrix.org> Yep. And due to multiple rotors
<re_irc>
<@sourcebox:matrix.org> If you have a quadcopter, then probably 😃
<re_irc>
<@firefrommoonlight:matrix.org> Yea - for quads and fixes-wings
<re_irc>
<@sourcebox:matrix.org> How many menasurements are you taking per seconds? You talked about external ADCs, are they fast enough?
<re_irc>
<@sourcebox:matrix.org> * second?
<re_irc>
<@firefrommoonlight:matrix.org> Not sure what will settle on, but probably 1-4k for quads, and 500ish for fixed
<re_irc>
<@firefrommoonlight:matrix.org> No ADCs here
<re_irc>
<@firefrommoonlight:matrix.org> Sorry I missed projects
<re_irc>
<@firefrommoonlight:matrix.org> I'm using external ADCs for water sensors . Will probably keeping using the ext since they're fine
<re_irc>
<@firefrommoonlight:matrix.org> The aircraft would be filtering IMU data
<re_irc>
<@firefrommoonlight:matrix.org> The aircraft is using onboard ADCs for some low priority things like batt voltage measurement. Those don't need filtering
<re_irc>
<@sourcebox:matrix.org> I see. The IMU stuff is a different beast.
<re_irc>
<@sourcebox:matrix.org> I'm always fascinated how precise they can be with image stabilisation in cameras.
<re_irc>
<@therealprof:matrix.org> : Hm, when I checked it looked all fine to me?
<re_irc>
<@therealprof:matrix.org> I wonder why I haven't noticed #41 as open.
mightypork has quit [Ping timeout: 264 seconds]
mightypork has joined #rust-embedded
cr1901_ is now known as cr1901
<re_irc>
<@mehmet:grusbv.com> Since there were 👀 reactions to this post, I update. I talked at the Asahi channel about this, and they recommended me to setup a QEMU emulator for aarch64.
<re_irc>
With some help, I was able to boot an image. It seems that all my current use cases are covered. Can install, compile, link my current embedded rust projects. It will probably work on an ARM mac too.
<re_irc>
<@thejpster:matrix.org> I do Embedded Rust on an M1 Pro running macOS and it’s great.
<re_irc>
<@thejpster:matrix.org> An M1 Mac Running Linux will be close to a Pi 4 in terms of user space binaries (both aarch64 Linux glibc) and they work great too.
<re_irc>
<@mehmet:grusbv.com> : That is great to hear.
<re_irc>
<@therealprof:matrix.org> I don't do much embedded development these days... but I'm also on the M1 Pro. 😉
<re_irc>
<@thejpster:matrix.org> I had to watch Jorge compile a project the other day. It was painful. I’m like, how can you live like this?! Took minutes to do what mine did in 20 seconds.
<re_irc>
<@richarddodd:matrix.org> Is the M2 a big step up from the M1 or is it basically the same?
<re_irc>
<@thejpster:matrix.org> I might not be able to upgrade my RAM or SSD but hooo boy is having Flash running at near DRAM speeds impressive.
<re_irc>
<@thejpster:matrix.org> Never tried one.
<re_irc>
<@therealprof:matrix.org> : It's a bit more power efficient but not a lot difference in performance. The M1 Pro is a bit beefer than a M1 though and should also beat the M2 (non-pro).
<re_irc>
<@therealprof:matrix.org> My other significant has a M2 MacBook Air. Very fascinating the power which Apple can get out of chips. The Air doesn't even any moving parts... The new Intel and AMD chips are also quite swift but the cooling systems to get to the same performance level are super annoying.
<re_irc>
<@dngrs:matrix.org> yeah, I specifically bought an M2 for that reason
<re_irc>
<@dngrs:matrix.org> previously had an intel mbp and it's just ... loud
<re_irc>
<@dngrs:matrix.org> bad for making music
<re_irc>
<@therealprof:matrix.org> My MBP has a fan and I've never seen it spin up so far.
<re_irc>
<@dngrs:matrix.org> yeah, I specifically bought an M2 Air for that reason
<re_irc>
<@dngrs:matrix.org> I think it's mostly when you connect an external monitor. That seems to auto-activate the power hungry gpu
<re_irc>
<@dngrs:matrix.org> oh also, to be clear, I was comparing intel mbp to M2, not M1 to M2
<re_irc>
<@therealprof:matrix.org> The Intel MBPs were always spinning the fans at low RPM, though. But you're right the dGPU was the main culprit of excessive power consumption and noise.
<re_irc>
<@dngrs:matrix.org> bad for me, since I exclusively work with external monitor, mouse and keyboard :D ("why get a laptop then in the first place?" - well because pre-pandemic I was doing a lot of freelance work at clients' offices)
<re_irc>
<@therealprof:matrix.org> I feel you, we're exactly the same. 😉
<re_irc>
<@therealprof:matrix.org> I was rather positively surprised about the lack of annoyances in macOS 13.2. Previously I tried to stay on the oldest version supported by homebrew etc. due to breakages all over the map with every upgrade.
<re_irc>
<@therealprof:matrix.org> The dropped support for 32bit Intel binaries was super annoying.
<re_irc>
<@dngrs:matrix.org> yeah… I get it - but, mnwahrgh
<re_irc>
<@rjknet:matrix.org> Hi everybody. I am new at Rust Embedded. I was following the tutorial of the Rust Embedded Documentation using a Micro:bit v2 and (after having installed everything shown in the documentation) I was trying to run the command "cargo embed --target thumbv7em-none-eabihf". However, it says the following:
<re_irc>
failed to select a version for "rtt-target".
<re_irc>
versions that meet the requirements "^0.4.0" are: 0.4.0
<re_irc>
the package "rtt-check" depends on "rtt-target", with features: "cortex-m" but "rtt-target" does not have these features.
<re_irc>
... required by package "rtt-check v0.1.0 (/microbit/src/03-setup)"
<re_irc>
failed to select a version for "rtt-target" which could resolve this conflict
<re_irc>
Error Failed to run cargo build: exit code = Some(101).
<re_irc>
Can anybody help me? Thank you in advance for the reply.
<re_irc>
<@dirbaio:matrix.org> that feature was removed in rtt-target 0.4. did you edit the Cargo.toml to use 0.4 instead of 0.3?
<re_irc>
<@rjknet:matrix.org> Yes, now my Cargo.toml is this one
<re_irc>
<@dirbaio:matrix.org> if you edit it to upgrade dependencies, you might have to update other code to deal with breaking changes
<re_irc>
<@dirbaio:matrix.org> in this case, rtt-target 0.4 was updated to use "critical-section". there's no "cortex-m" feature anymore, instead you have to enable "critical-section" support in the "cortex-m" crate. This might work:
<re_irc>
cortex-m = { version = "0.7.6", features = ["critical-section-single-core"]}
<re_irc>
rtt-target = { version = "0.4.0" }
<re_irc>
[dependencies]
<re_irc>
<@dirbaio:matrix.org> though if you don't want to deal with the hassle of upgrading, I'd suggest leaving the versions in the repo as-is.
<re_irc>
<@rjknet:matrix.org> Thank you, but i changed the Cargo.toml file adding your snippet and it still gives me the same problem...
<re_irc>
<@dirbaio:matrix.org> replace the cortex-m and rtt-target lines, not add them
<re_irc>
<@rjknet:matrix.org> Yes that's what I ment
<re_irc>
<@dirbaio:matrix.org> can you post the full edited Cargo.toml?
<re_irc>
<@dirbaio:matrix.org> workspaces "merge" features across all "Cargo.toml"s, make sure you don't have that feature any of them, not just the one you're trying to compile
<re_irc>
<@dirbaio:matrix.org> (perhaps a workspace is not the most beginner-friendly repo layout?)
<re_irc>
<@dirbaio:matrix.org> * layout? should we remove it?)
<re_irc>
<@rjknet:matrix.org> Thank you very much!! It worked
<re_irc>
<@rjknet:matrix.org> I wasn't aware of the Cargo workspace...
<re_irc>
<@rjknet:matrix.org> I just substituted every occurrence of cortex-m in Cargo.toml with the one you suggested me and now it works!
dc740 has quit [Remote host closed the connection]
IlPalazzo-ojiisa has quit [Remote host closed the connection]