explore has quit [Quit: Connection closed for inactivity]
emerent has quit [Ping timeout: 250 seconds]
emerent has joined #rust-embedded
conplan1 has joined #rust-embedded
conplan1 has left #rust-embedded [#rust-embedded]
conplan has joined #rust-embedded
<conplan>
hello
ska has quit [Remote host closed the connection]
conplan has quit [Quit: Leaving.]
conplan has joined #rust-embedded
<conplan>
hello
<conplan>
I am working with the MSP432p401r-hal
conplan has quit [Quit: Leaving.]
conplan has joined #rust-embedded
<conplan>
jpg: sorry didn't get that
conplan has left #rust-embedded [Leaving.]
conplan has joined #rust-embedded
conplan has quit [Remote host closed the connection]
conplan has joined #rust-embedded
conplan has quit [Remote host closed the connection]
conplan has joined #rust-embedded
conplan has quit [Client Quit]
Socke has quit [Quit: WeeChat 3.6]
conplan has joined #rust-embedded
Socke has joined #rust-embedded
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 268 seconds]
starblue has quit [Ping timeout: 265 seconds]
starblue has joined #rust-embedded
conplan has quit [Remote host closed the connection]
cr1901_ is now known as cr1901
<re_irc>
<dkhayes117> I'm using a"heapless::Vec()" for a data buffer, and I'm thinking of adding timestamps to each data point. Would you use a separate "vec" for the timestamps, or is there are better way of handling that?
<re_irc>
<mattjperez> So each element would be a struct with a data point and timestamp?
causal has joined #rust-embedded
<re_irc>
<dkhayes117> Right now, it's just a single struct with a single member which is the Vec. I thought of maybe adding another member "timestamps" which would be another Vec
<re_irc>
<mattjperez> If the datapoints are tightly related to the individual data point i would just put them in a single DataWithTime struct and then store that in the Vec.
<re_irc>
<mattjperez> * timestamps
<re_irc>
<dkhayes117> Yeah they are tightly coupled, so double the Vec size where I would push a timestamp, the data point, then repeat
<re_irc>
<marmrt> +<marmrt> struct val {
<re_irc>
<marmrt> struct Element {
<re_irc>
time: u32,
<re_irc>
data: u32,
<re_irc>
}
<re_irc>
vec: Vec<Element,64> = Vec::new();
<re_irc>
<dkhayes117> Cool, I'll give that a try
<re_irc>
<diondokter> Does anybody know of a library that does kind of this?
<re_irc>
<dirbaio> derive(TryInto) from derive_more maybe?
<re_irc>
<dirbaio> it won't generate the enum, but it'll generate TryInto/TryFrom impls that do what your "get" method does
<re_irc>
<dirbaio> but honestly i'd just hand-write the enum and use match / if-let / let-else to get the variants out
<re_irc>
<diondokter> dirbaio: Hmmm, that may be good enough
<re_irc>
<dirbaio> because this'll lead to very unwrappy code
<re_irc>
<diondokter> Well, we may have a lot of combos
<re_irc>
<dirbaio> for example if the "get_foo" above can only work with a "Message::Foo" then it should take a "&Foo", not a "&Message"
<re_irc>
<dirbaio> but I guess the real problem is more complex than that, so idk :D
<re_irc>
<diondokter> Yeah, everything is gonna be super generic
<re_irc>
<diondokter> Basically, we have a bunch of libraries that need to communicate with each other about their status. So the application needs to create a Message or Signal type (however you want to call it) that the libraries can use to communicate. One library might care about the connection status of the device. So it will only care about Signals that contain network information.
<re_irc>
Each application has a different set of libraries, so it'd not be very nice if we had to create an enum that contains all different possibilities across all projects.
<re_irc>
<diondokter> So instead every library takes a channel, something like
<re_irc>
}
<re_irc>
let latest_signal = bus.wait_on_signal().await;
<re_irc>
<mattjperez> Sounds like how tracing subscribers work
<re_irc>
<diondokter> Never really looked at it, but it may be a good inspiration
<re_irc>
<dirbaio> why not avoid mixing unrelated events into a giant bus in the first place?
<re_irc>
<dirbaio> like, if a lib needs network status info, it takes a "Receiver<NetworkStatus>" and that's it
<re_irc>
<dirbaio> it has other advantages too: for example this way it'll check at compile time that you have something actually sending network status updates
<re_irc>
<diondokter> True, but it's mostly practiacality
<re_irc>
<diondokter> Passing 5 busses by parameter is not really nice...
<re_irc>
<diondokter> And we don't need the performace
<re_irc>
<diondokter> * performance
<re_irc>
<dirbaio> sure it'll have some more boilerplate in "main" wiring everything up
<re_irc>
<dirbaio> but it's straightforward boilerplate :D
<re_irc>
<diondokter> Haha
<re_irc>
<dirbaio> vs crazy generic/macro magic
<re_irc>
<diondokter> Well, maybe I am overthinking it
<re_irc>
<dirbaio> +needed for the mega-bus
<re_irc>
<dirbaio> i'd rather have straighforward boilerplate any day ;D
<re_irc>
<diondokter> Not sure :P
<re_irc>
This is more opinion than anything else, so maybe I just have to speak with my colleagues and see what they think about it haha
<re_irc>
<omar_u8> Quick question, exclude field in cargo.toml "[package]" section seems to throw an error if only one path is provided. Is this a known thing?
<re_irc>
<omar_u8> * "exclude"
<re_irc>
<dkhayes117> chaosprint: You'll need nightly for that
<re_irc>
<jessebraham> omar_u8: That shouldn't be the case, I have a project with a single path in the "exclude" and it's never been an issue for me.
<re_irc>
<therealprof> "cargo update" might help
GenTooMan has joined #rust-embedded
<re_irc>
<omar_u8> therealprof: That did the trick, thanks!
<re_irc>
<therealprof> omar_u8: Uhm, that was meant for chaosprint, but maybe it's a twofer. 😉
<re_irc>
<chaosprint> therealprof: mine is pretty new. but I don't why for some other crates, current version works fine but nightly one gives numerous errors.
<re_irc>
<therealprof> I had a similar error recently and it turned out to be a slightly stale Cargo.lock.
<re_irc>
<omar_u8> therealprof: Two birds one stone 😂
<re_irc>
<adamgreig> room meeting time again! agenda is https://hackmd.io/U-W393pxTM64F530_am4gQ, please add anything you want to talk about or discuss, and we'll start in a few minutes :)
<re_irc>
<adamgreig> OK, let's go! Couple announcements, svd2rust 0.26 is out which uses "critical-section" instead of the previous per-architecture "interrupt::free" methods, along with some bug fixes
<re_irc>
<adamgreig> it might be worth waiting a little longer since setting the global allocator may actually become stable soon, and then we could tidy this up at the same time
<re_irc>
<adamgreig> or possibly the crate just doesn't need to exist and the udnerlying allocators could add an impl for GlobalAlloc using critical_section
<re_irc>
<adamgreig> the only thing alloc-cortex-m does is use cortex_m::interrupt::free to wrap access to an allocator, so
<re_irc>
<therealprof> "good memory allocator" is a rather strong name... 😄
<re_irc>
<almindor> adamgreig: That's my bad. I merged a 0.8.1 release request (due to another change) but missed that we removed some macro APIs so we had to bump to 0.9 and yank 0.8.1
<re_irc>
<therealprof> Hard to top, can now only go for "better memory allocator", "best memory allocator" and "godlike memory allocator".
<re_irc>
<adamgreig> lots of room left at the top!
<re_irc>
<adamgreig> almindor: ah no worries, if the pr is otherwise ok maybe it makes sense to yank 0.9.0 and do 0.9.1? or just skip right to 0.10.0? dunno
<re_irc>
<therealprof> Good to know we're not running out of superlatives any time soon. 🤣
<re_irc>
<adamgreig> i didn't notice until literally just now when i mentioned svd2rust's c-s and remembered riscv had a pr for it, heh
<re_irc>
<almindor> I think we'll go 0.10 with the critical section changes, the PR just needs changelog conflict resolution as far as I can say? disasm was there anything else left to address with Riscv PR 110 (https://github.com/rust-embedded/riscv/pull/110)?
<re_irc>
<almindor> I wonder if we should call things single-core or single-hart in RISCV setups...
<re_irc>
<therealprof> single-❤️, the all new RISC-V dating show
<re_irc>
<almindor> my hart melts for you...
<re_irc>
<fawaz> almindor: I'm in favor of single-hart, as I'm pretty sure a single core supporting SMT has multiple harts
<re_irc>
<fawaz> Not 100% sure of that though
<cr1901>
hart == Hardware Thread
<cr1901>
HARdware*
<re_irc>
<adamgreig> that's all I had for this week, anyone else have anything to discuss?
<cr1901>
I may have a hack around the CS bloat
<cr1901>
I don't like it, but I'll accept it for my own applications
<cr1901>
Use a cargo patch to change the upstream critical-section crate to a git-provided one with the cs impl in-line within the crate
<re_irc>
<adamgreig> the new pr #666 is for when the register has _no_ fields but is specified that you can write any value to it
<re_irc>
<adamgreig> eldruin: that's a pain but I guess not totally surprising, I feel like anything depending on a .alpha release should be ready for breaking changes in the new alpha release
<re_irc>
<adamgreig> so probably shared-bus should just bump it and any downstream users enabling the eh-alpha feature will get a break and fix it
<re_irc>
<eldruin> it might be just a side-effect of the allowance to upgrade to -beta if you only specified -alpha
<re_irc>
<newam> I figured this one out the hard way, I just use "=x.x.x-alpha.x" now.
<cr1901>
^Indeed
<cr1901>
(Also found out the hard way)
<re_irc>
<eldruin> I think strictly seen it is a bug
<cr1901>
There's a years-old open cargo issue about it, I don't think it's getting fixed.
<re_irc>
<rahix> eldruin: yeah, didn't get around to raising that here in more detail... this was surprising to me as well but cargo says this "works as intended"
<re_irc>
<eldruin> newam: yeah the problem is that you cannot have two pinned versions of the crate with "=" because cargo thinks they conflict with each other because it takes them as semver-compatible
<re_irc>
<rahix> the rule is apparently that there must not be two semver-compatible versions of a crate in the dependency tree _ever_. I wasn't aware up to now
<re_irc>
<rahix> multiple versions of the same crate are only allowed when they are incompatible
<re_irc>
<rahix> eldruin: this was my first thought as well.
<re_irc>
<eldruin> yeah I was not aware of that either, but either way, if pre-releases are allowed to bring semver-incompatible changes as the cargo resolver docs state, you cannot treat them as semver-compatible
<cr1901>
But then you have mutually-exclusive features, which are _also_ discouraged
<cr1901>
(This is not a reflection of your workaround, eldruin. But a reflection of how cargo is a bit too strict sometimes...)
<re_irc>
<adamgreig> huh yea, I see what you mean, that does seem like a cargo resolver bug
<re_irc>
<adamgreig> is the compatibility because it wants to be able to ugprade you to later alphas etc?
<re_irc>
<eldruin> might be, that is the only reason I can see but I have no insight there
<re_irc>
<eldruin> it makes sense if you specify something like "e-h = "1.0.0-alpha""
<re_irc>
<eldruin> for crates that only need one alpha 🤣
<re_irc>
<eldruin> that can upgrade you to -beta even
cr1901 is now known as cr1901_
<re_irc>
<eldruin> but it does not make sense to me to do that if the versions can be semver-incompatible
<cr1901_>
Siiiigh I forgot to change my nick lmao
<re_irc>
<eldruin> it is a convenience thing
<re_irc>
<adamgreig> yea, you probably want to always have a specific alpha dependency otherwise it can just break underneath you huh
<re_irc>
<eldruin> but I think it was not completely thought through
<re_irc>
<adamgreig> edge-case-tastic
<re_irc>
<eldruin> yeah totally
<re_irc>
<eldruin> e-h-compat would also have the problem but there only the last version is tracked
<re_irc>
<eldruin> but especially there is where it would be nice if this was supported
<re_irc>
<adamgreig> I guess for the time being it'l just have to be an annoying break but maybe worth opening an issue on the cargo tracker if there isn't one already?
<re_irc>
<eldruin> I would think so
<re_irc>
<eldruin> alright, I need to go now, thanks everybody! 👋
<re_irc>
<adamgreig> yep, thanks all! 👋
<re_irc>
<orclev> anyone have any experience with flashing a nice!nano and/or using the adafruit bootloader and uf2 to flash a nrf52840? I've been poking at this thing for a few days now and nothing seems to work, but eyeballing everything seems to match every example or piece of documentation I've found. I'm suspecting the problem is in generating the uf2 file, but no idea what.
<re_irc>
<9names (@9names:matrix.org)> chaosprint: If you run commands with sudo, any output files will be owned by root. So any later attempt to not run as root will fail (because you don't have permission to delete or replace them).
<re_irc>
Can fix by identifying the root-owned paths using ls -la and taking ownership of them with the chown command or deleting them.
<re_irc>
This should be enough info to google your way to a fix.
<re_irc>
<chaosprint> Any suggestion for what to look for this error?
<re_irc>
<therealprof> Also make sure to adjust memory.x to the actual RAM size in the chip. The -hal supplied one uses the smalled RAM size per default.
<re_irc>
<therealprof> * smallest
<re_irc>
<therealprof> ... and flash size.
<re_irc>
<plouklapenguin> Anyone know how to fix this: `
<re_irc>
<plouklapenguin> Anyone know how to fix this: `Error Probe could not be created
<re_irc>
Caused by:
<re_irc>
0: hidapi error: Permission denied
<re_irc>
1: hidapi error: Permission denied`
<re_irc>
<plouklapenguin> * `
<re_irc>
<plouklapenguin> Anyone know how to fix this: `
<re_irc>
Error Probe could not be created
<re_irc>
Caused by:
<re_irc>
0: hidapi error: Permission denied
<re_irc>
1: hidapi error: Permission denied`
<re_irc>
<plouklapenguin> -`
<re_irc>
<plouklapenguin> nevermind, I had the wrong versions of cargo-embed and cargo-binutils
<re_irc>
<orclev> anyone see anything wrong with building a UF2 file using these commands?