<firefrommoonligh>
When I tried the ESP stuff ~2 months ago, the dependency combinations were broken, but could work if you patched together the right combination, including some Git branches. So... not the polish you are expecting from a vendor
<firefrommoonligh>
That said... The STM32 stuff is quite usable for most variants and peripherals
<firefrommoonligh>
Same with nRf5x
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<LudovicVanasse[m>
<firefrommoonligh> "That said... The STM32 stuff..." <- Yeah I hope so, I'd like to use it in one of my company project soon
<LudovicVanasse[m>
Also I wonder, when it says field documented on https://stm32-rs.github.io/stm32-rs/ , does it means that it is usable in the stm32-rs PAC or that the doc is not there? Like what does the bar represent
<trinhtuan[m]>
<firefrommoonligh> "When I tried the ESP stuff ~2..." <- Yes, I have the same experience, although `esp-rs` is very active development but it is not consistent (i.e. a lot of breaks between versions). It seems the governance and/or strategic road-map issue. I have not yet tried with others like STM32, NFR.
<trinhtuan[m]>
Any other thoughts?
<trinhtuan[m]>
PS: I just want to see Rust will be more serious in vendors' eyes, no other intentions. I hope you are all the same.
<trinhtuan[m]>
* between versions, lack of documents). It
<adamgreig[m]>
<LudovicVanasse[m> "Also I wonder, when it says..." <- The bar means that a field that can take multiple values has all those values spelled out, so you can use a named method like "output()" instead of writing raw bits like 0b01 to the gpio mode reg
<adamgreig[m]>
The registers are all there (barring gross errors in the underlying data, which do happen) so can always be used directly
<LudovicVanasse[m>
Ah humm, I'm not sure I understand. Is it like the mapping of the memory addresses on the register are laid out in functions?
<LudovicVanasse[m>
adamgreig[m]: Ah humm, I'm not sure I understand. Is it like the mapping of the memory addresses on the register are laid out in functions?
<adamgreig[m]>
Yep. ST provide an "svd" file which says what registers are at what memory addresses and also what fields are in those registers, like a header file, and svd2rust (or other similar software) uses that to generate rust code that contains functions to read and write those registers and fields
<adamgreig[m]>
But they typically don't contain the possible values they can be written into those fields or what they mean, so those are generally added manually, and that's what those progress bars track
<adamgreig[m]>
Without it you have to consult the reference manual to know what value to write to the field, while with it you can use a convenient function instead. Most users use a HAL instead of the PAC and then it also doesn't matter
<LudovicVanasse[m>
adamgreig[m]: Ahh I see! Thank you I didn't know that there was that limitation with the svd and etc. I knew about the whole svd2rust but didn't understand that part. Thank you
<LudovicVanasse[m>
adamgreig[m]: And I'm surprise you're saying that, why wouldn't that matter when using an HAL?
<adamgreig[m]>
Svd itself can describe those values, just vendors rarely put them in
<adamgreig[m]>
Well if you're using a hal instead of the pac it doesn't matter to you whether the PAC had a convenient function
<adamgreig[m]>
The hal author sorts it out for you and provides a higher level interface
<LudovicVanasse[m>
adamgreig[m]: Right but you could still write some incorrect value using the HAL? You'd have to refer to the datasheet of the board with the right register, wouldn't you?
<LudovicVanasse[m>
Maybe another way to see it is, what is the value in having those fields documented?
<LudovicVanasse[m>
* fields documented? When you say that the HAL would be enough to interact with the peripheral
<adamgreig[m]>
If you're using the hal you're generally not writing values to registers at all
<adamgreig[m]>
Having the field documented is nice for users who are using the PAC, either because they're writing a hal or because they're not using a hal
<LudovicVanasse[m>
Ah I see! So it's really when you are doing the implementation part of an HAL that this is valuable.
<LudovicVanasse[m>
Fair enough thank you for taking the time to explain that
<LudovicVanasse[m>
Sorry if I was exhaustive, it's just that those are questions I might have to answer to my team if I want to continue using Rust at work ^^'
<adamgreig[m]>
any time!
<adamgreig[m]>
If you're just wanting to get firmware going in rust and you'd usually be using a vendor or rtos provided hal, check out either the stm32-rs hals (one per family) or embassy-stm32 (covers all families and also has async support) which can be pretty quick to get going with
<LudovicVanasse[m>
adamgreig[m]: Yes! I would love to use embassy for my first embedded Rust (we are using gstream and another tool in Rust at the moment, but nothing embedded). I'm trying to piece together all the blocks that I need to make it work well. And you might know actually, I'd like to use a DDS inside and if possible outside of the MCU, something like PX4 does with uORB (https://docs.px4.io/main/en/middleware/uorb.html)
<LudovicVanasse[m>
I know that in Rust you could use Channel and such to help communicate between thread (I would assume something similar for async tasks), but I'd like something with that same pattern. I know there's Zenoh that's pretty good, but they don't really seems to have support for bare-metal in the pico version (https://github.com/eclipse-zenoh/zenoh-pico)
<LudovicVanasse[m>
James Munns postcard-rpc is pretty close, but it doesn't do yet machine to machine from what I remember talking to him about a while back
<LudovicVanasse[m>
What I like about Zenoh is that it allow for multi transport layer, so it can be serial, ethernet and etc (although the etc you need to write yourselves, but it would be super cool to do all that with the same DDS pattern and lib)
<adamgreig[m]>
Yea, uORB looks nice and I'm not aware of anything quite like that for embedded rust atm. There's a variety of things in embassy-sync but they're not quite so much a mpmc pub-sub message broker, and indeed postcard-rpc is really more focused on one client talking to one server sort of thing
<adamgreig[m]>
Could be a neat thing to make!
<LudovicVanasse[m>
adamgreig[m]: Maybe I'll have to work on that then :). Today I watched James Munns opening keynote for Oxidize Conf, and that was his advice: if you see something that's missing, build it! https://youtu.be/6CNyuk4JwwA?t=464&si=SvAfNMpGiswyTLI5
<LudovicVanasse[m>
adamgreig[m]: Yes! and a last question, would be if you know about a alternative to nsh in embedded rust? (Sorry those question have been haunting me for a while) I really like the interaction of Nsh in Nuttx (PX4) when dealing with hardware, I'm wondering if you've seen something similar to this? It would probably be something easier to start with (in my opinion) for embedded rust
<LudovicVanasse[m>
* embedded rust than a full embedded DDS ^^'
<ericseppanen[m]>
I'm not sure what you mean -- using StaticCell::init_with still requires the closure to return T by value. Wouldn't that imply that it's on the stack while the closure is running? Also init_with isn't const so it would still require runtime init.
<ericseppanen[m]>
I guess they're just implying that this construction allows the compiler to elide the copy?
<GrantM11235[m]>
Yeah, init_with makes it pretty easy for the compiler to elide the copy and construct the value in place because the value is written to the static immediately after the closure is called
<ericseppanen[m]>
I wonder if the debug build would blow up the stack.
<GrantM11235[m]>
opt=0 almost always causes problems in embedded rust, you should at least use opt=1 even in debug builds
<GrantM11235[m]>
Even if you don't blow up the stack, opt=0 is just too slow. For example, if you are using USB you will time out
<GrantM11235[m]>
All our "zero cost" abstractions are actually very costly if you don't have any inlining
<ericseppanen[m]>
I'm 80% sure James Munns recommended ConstStaticCell to me at RustNL but I couldn't remember the name. 😀
<Henk[m]>
tangentially related: is there a reason to prefer GDB over LLDB, for instance in the Discovery book?
<ryan-summers[m]>
To be honest, I' not certain that GDB/debuggers in general are a significant part of an embedded Rust workflow. This is something that has seriously surprised me coming from a C background, but I find myself rarely jumping in to a debugger, which is often why it can feel a ittle clunky when you need to (since it doesn't get much attention)
<ryan-summers[m]>
* honest, I'm not
<ryan-summers[m]>
So that's a long winded way of saying I'm not certain that GDB vs LLDB matters
<ryan-summers[m]>
The only time I really end up jumping into a debugger is when I want to view the internal control registers if I suspect there's something funky going on
<Henk[m]>
That would be the reason I have to figure it all out ;)
<ryan-summers[m]>
Is that warning causing the debugger to completely break? I've never seen something like that. How are you starting up GDB?
<ryan-summers[m]>
probe-rs's GDB implement with cargo-embed has worked well for me in the past
<Henk[m]>
Well, it all still works fine
<diondokter[m]>
(But it's pretty bad at decoding C)
<diondokter[m]>
ryan-summers[m]: It's starting to be quite nice!
<diondokter[m]>
I've had most luck with the cortex-debug plugin for vscode
<Henk[m]>
For context, I'm porting some chapters from the old discovery book (for stm32f3) to the new one (microbit), and the content on registers is pretty GDB-heavy. For good reason, as it shows readers what is going on under the hood nicely
<ryan-summers[m]>
Yeah is this a rust-native app or a C-app that you're debugging with cargo-embed?
<Henk[m]>
So at this point I'm pretty much tied to GDB
<Henk[m]>
But anyway, the warnings are quite off-putting to new users
<ryan-summers[m]>
Ah gotcha, so this is probably all pure rust on a microbit then
<Henk[m]>
Exactly
<Henk[m]>
Specifically, the V2
<ryan-summers[m]>
I wonder if that error is being generated by GDB or probe-rs's stub. It's not particularly helpful in its verbiage though
<ryan-summers[m]>
If it's coming from probe-rs it might be a lot easier to fix/understand
<Henk[m]>
The few Google hits tell me that it's not specific to my setup
<ryan-summers[m]>
It looks like their conclusion is that this is a gdb bug. Is your version of gdb latest/greatest?
<diondokter[m]>
Ah, bug when a section starts at zero. The vector table is at address 0 on nRF chips
<ryan-summers[m]>
Is microbit an nrf?
<Henk[m]>
I'm running 14.2, which seems to be the latest version
<diondokter[m]>
ryan-summers[m]: 52840 I think
<Henk[m]>
diondokter[m]: 52833
<diondokter[m]>
Off-by-7 error 💀
<Henk[m]>
Not that it matters probably
<ryan-summers[m]>
Yeah it looks like the posts' conclusion was to modify and recompile gdb, which sucks
<Henk[m]>
fml
<ryan-summers[m]>
Obviously can't have beginners doing that one
<Henk[m]>
Note
<Henk[m]>
* Nope
<ryan-summers[m]>
Maybe try lldb or similar other debuggers and see how they work?
<Henk[m]>
I guess we'd need to look into alternatives maybe, possibly the probe-rs vscode extension, if it's any good
<ryan-summers[m]>
You could also use raw memory dumps using probe-rs CLI
<Henk[m]>
ryan-summers[m]: Yeah I'll give lldb a go
<ryan-summers[m]>
You can use the probe-rs CLI to do i.e. probe-rs target read 0x40000_000 or something similar. Although I suspect you may want to stop at breakpoint, observe regs, move to next BP, repeat, which wouldn't work with the CLI
<Henk[m]>
Yeah I'd like the reader to step through buggy code and encounter a hard fault
<Henk[m]>
But then there's many other uses too
<ryan-summers[m]>
I wonder if there's a way you could instrument it remotely. Perhaps you could write a custom probe-rs rust bin that does this
<ryan-summers[m]>
And then software BPs until the user presses enter
<Henk[m]>
Does seem like way more work than I signed up for though
<ryan-summers[m]>
Yeah fair
m5zs7k has quit [Ping timeout: 252 seconds]
m5zs7k has joined #rust-embedded
<JamesMunns[m]1>
Henk one major limitation of LLDB is that it doesn't implement the gdb `load` command, which should actually flash the ELF to the target MCU. I think this is less important if you are using `probe-rs` as your GDB server, as it will do this automatically on launch, but this isn't true if you're using something like `openocd` as your gdb server instead.
<Henk[m]>
And that may be the cause of the previous warning too
<JamesMunns[m]1>
yeah, tbh I'm not sure if probe-rs even supports it. AFAIK cargo-embed assumes it just flashes automatically if you ask it, you don't have the change to re-load the image
<JamesMunns[m]1>
(I very rarely use gdb, to be honest)
<Henk[m]>
JamesMunns[m]1: Yeah, it's not strictly necessary, but the load command not running means I can't use gdb as a cargo runner
<Henk[m]>
And that's just slightly annoying
<Henk[m]>
Means I have to restart my gdb server every time
<JamesMunns[m]1>
fwiw: I have heard very positive things about the probe-rs vscode plugin
<JamesMunns[m]1>
that's likely a much nicer experience for beginners
<Henk[m]>
I guess I'll leave this issue as WONTFIX then, to be ported to the vscode plugin later on
<JamesMunns[m]1>
btw, if anyone is interested in some very silly unsafe code, I wrote up a blog post about some hacking I did over the weekend: https://onevariable.com/blog/pods-from-scratch/
<ryan-summers[m]>
Why do you need the load command exactly? Maybe the file command will do what you need, if you're just looking to load symbols etc
<JamesMunns[m]1>
ryan-summers[m]: the usual reason is keeping a persistent gdb session, and reloading without restarting gdb and connecting to the target remote server
<ryan-summers[m]>
Ah so you can recompile externally and then reload the new elf
<Henk[m]>
JamesMunns[m]1: Yup. It's not mandatory or anything, just way more ergonomic
<ryan-summers[m]>
I looked at load a few years ago in probe rs and from what I can tell it's intentionally omitted because no one has needed it y t
<frere_jacques[m]>
<ryan-summers[m]> "To be honest, I' not certain..." <- Can you give a noob a hint what the better tooling is instead? The embedded rust book and the discovery book really focus on that. But tbh trying to debug with it was confusing, like I reached a panic and I had no clue how to sort out the origin.
<ryan-summers[m]>
frere_jacques[m]: Honestly I use rtt and det etc to get the full panic traceback. It works great and I rarely have stuff that requires intrusive debugging to figure out. Once. I have a stack trace that's often enough
<thejpster[m]>
I had some related feedback from the Embedded Rust course at University Polytehnica Bucharest.
<ryan-summers[m]>
Usually I've needed a debugger in c because of memory race conditions, which generally don't happen in rust programs
<JamesMunns[m]1>
IMO the discovery book would be much better off focusing on defmt-rtt + probe-rs, and leaving gdb as an advanced section/appendix
<ryan-summers[m]>
So the class of bugs tend to be purely logical and functional as opposed to insidious tricky ones
<frere_jacques[m]>
Henk[m]: Hmm, I don't use vscode.
<JamesMunns[m]1>
when the discovery book was first written, gdb was the only option.
<Henk[m]>
I mean, in real world projects, rtt et al work perfectly, but to inspect the state of the MCU for educational purposes, a debugger is really nice
<ryan-summers[m]>
Yeah it explains a lot about the fact that things happen internally to the CPU state that aren't necessarily your code doing things
<thejpster[m]>
one of the notes was "I don't understand why there are two books". Maybe the embedded Rust book should be called "Embedded Rust for Embedded C Programmers" or something.
<ryan-summers[m]>
But also, I wonder if not needing a debugger is correlated to more programming experience as well? I'm not sure
<Henk[m]>
thejpster[m]: Probably
<thejpster[m]>
The second was, the books like to explain things from first principles. This makes sense for educational purposes. but people copy-paste these educational examples, which makes for bad production code.
<thejpster[m]>
Perhaps they can do more to say "Here's how you do it from first principles" and then "now you know that, never do it again but do it this way instead"
<thejpster[m]>
Splitting up theory and practice.
<ryan-summers[m]>
I thought the "base principles" book was the embedonomicon?
<thejpster[m]>
because most people don't care about the theory, they just want to make the thing work RIGHT NOW
<Henk[m]>
JamesMunns[m]1: I woudn't say that. I very much liked the 'Registers` chapter of the f3 book way back when
<Henk[m]>
Henk[m]: I started out with embedded myself using that book
<M9names[m]>
"Here's how to do it, and here's how to do it right" doesn't work because they're already overloaded with info and won't do the second part.
<thejpster[m]>
Also, people need better signage that async rust and blocking rust and non-blocking rust are basically three different pathways and not something you want to really mix up.
<Henk[m]>
M9names[m]: Yeah, I guess referring to the embedded book might solve the issue here though
<thejpster[m]>
Seeing a bunch of students try and cram my blocking SD card driver into their async (embassy on rp2040) applications brought this home to me.
<thejpster[m]>
It's not obvious why that's a bad idea. But it is a bad idea.
<Henk[m]>
thejpster[m]: Still a great learning experience
<frere_jacques[m]>
thejpster[m]: I actually liked that and it's similar to the rust book. It starts of with the straight forward simple idea and explains the draw backs and shows more elegant ways. But hints like don't adapt this, or this is the way, would be helpfull.
<Henk[m]>
Henk[m]: But only in a controlled environment
<thejpster[m]>
a fairly brutal learning experience. Because no other tasks run why the SPI is spinning waiting for the block to write.
<thejpster[m]>
s/why/while/
<thejpster[m]>
They just wanted to play a wav file as part of their burglar alarm, or laser piano, or whatever
<thejpster[m]>
(they made a bunch of really cool stuff. I was quite impressed given they'd all done basically no embedded before - in any language)
<frere_jacques[m]>
<frere_jacques[m]> "Hmm, I don't use vscode." <- Does anybody know whether one can use that with nvim-dap? General rust debugging works with that.
<Henk[m]>
I'm not sure, but you could maybe ask in the [probe-rs channel](https://matrix.to/#/#probe-rs:matrix.org)
<frere_jacques[m]>
Thanks for the hint
<JamesMunns[m]1>
At least my $0.02, and from feedback from Tanks at Ferrous who was head of training (and a background in teaching) for a while - it's usually more effective to start from a working system and work DOWN to first principles, than to start from first principles and work UP.
<JamesMunns[m]1>
I'm certain it's not necessarily universal, and many folks (esp embedded I've found) like to start the other way, but it ends up being less effective for most people, often because they struggle to hold all the "leaf concepts" together to make the next step up.
<JamesMunns[m]1>
Often - you want to start from a working system, something where they can see results, and uncover it bit by bit, so they always have a "solid" ground to step back to when necessary, or step forward when they are ready.
<frere_jacques[m]>
<JamesMunns[m]1> "At least my $0.02, and from..." <- > <@jamesmunns:beeper.com> At least my $0.02, and from feedback from Tanks at Ferrous who was head of training (and a background in teaching) for a while - it's usually more effective to start from a working system and work DOWN to first principles, than... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/hkTRDEdryhbctnRfyUGOIoiv>)
pronvis has joined #rust-embedded
<JamesMunns[m]1>
Yep, I think most people learn better when they have incremental successes - if the only hurdle to say "I've run embedded rust code" is getting the tools installed, `cargo run`, and they can turn a dial or see a light blink, and then "play" from there, adding logs, changing working behavior, they are less likely to get stuck on a concept they don't understand, or at least be more motivated to stick with it if they do stumble
<JamesMunns[m]1>
when they "zoom in".
<JamesMunns[m]1>
IMO we want to support learners that only have an hour to get set up and dip their toes in, as much as we do people ready to approach learning embedded Rust as if it was a semester long undergrad course, learning all the theory and doing labs along the way.
<JamesMunns[m]1>
"time to success" is a pretty big deal, IMO.
<Henk[m]>
I agree
<Henk[m]>
Though it would take some effort to nicely abstract from the internal machinery, which is something Rust is designed not to do
<JamesMunns[m]1>
How so?
<JamesMunns[m]1>
(I think we can encapsulate complexity, even if it's just a couple of handy functions. We don't have to hide it, if they want to look, they can, but the idea is to design it in a way that they don't have to go look, in order to succeed)
purepani[m] has joined #rust-embedded
<purepani[m]>
One of the things that someone had told me was that sometimes the hardest thing is getting a hello world running for something new, not because it's actually the hardest, but because it's the part where you know the least, so it's super easy to get confused, and that's where it's the easiest place to just give up.
<frere_jacques[m]>
Haha, some weeks ago I had the idea to finally grab a bluepill lying in the drawer and just try out embedded rust and write a blinky programme.
<frere_jacques[m]>
In the end it took weeks till I finally wrote some own code, which is merely an adaption and portation due to incompatibility.
<frere_jacques[m]>
On the first day I naively asked if somebody had a good ressource and thought I will have my first hello world in an hour.
<purepani[m]>
In particular, when you're learning embedded as a completely new thing, it's not just about the code; it's also about the pipeline to get the code onto the microcontroller, and having to compile to a particular target, etc. There's stuff aside from the code itself that you have to pick up that can be hard
<Henk[m]>
I think probe-rs does really well in that department though
<Henk[m]>
But I might be biased, coming from openocd
<Henk[m]>
<JamesMunns[m]1> "(I think we can encapsulate..." <- I don't think we actually disagree on this ;)
<purepani[m]>
Yeah I mostly agree: I was just saying that as a general statement and to give examples.
<purepani[m]>
I think there was one permissions thing that tripped me up when I was first using probe-rs, and took me a bit to actually solve, but aside from that it was a relatively smooth experience.
<purepani[m]>
It was just more to make the point of time to a hello world run from nothing is probably a good metric to evaluate against.
<JamesMunns[m]1>
Re streams: I haven't considered it, but mostly because I've never used streams. It's been an "under construction" part of async for so long, I've just never sat down to learn how to implement it as part of a public interface.
<JamesMunns[m]1>
Open to an issue to discuss what the API could look like. You're welcome to PR, but I'm not certain I'd accept it until I understand what the API would look like
<JamesMunns[m]1>
Re: cdc-acm, I can't think of a way it would ever be better? Maybe easier for permissions or something? Or built in flow control signaling of RTS/CTS/dtr whatever that the OS might be able to signal better? But it'd be pretty niche, for how postcard-rpc works, imo. You also then have to pay extra encoding costs.
<JamesMunns[m]1>
Also, nusb is just so damn pleasant to work with over OS serial port APIs.
<JamesMunns[m]1>
I do plan to add back support for cdc-acm/serial ports tho, I've already had a bunch of people use it with usb-uart adapters for MCUs without native USB support. This would even include the esp32-Cx series
<JamesMunns[m]1>
But if you CAN use bulk descriptors, I think I'd recommend using that 10/10 times.
<JamesMunns[m]1>
* CAN use raw USB/bulk descriptors,
<JamesMunns[m]1>
* of people want to use it
<dangroshev[m]>
<JamesMunns[m]1> "Re streams: I haven't considered..." <- > <@jamesmunns:beeper.com> Re streams: I haven't considered it, but mostly because I've never used streams. It's been an "under construction" part of async for so long, I've just never sat down to learn how to implement it as part of a public interface.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/yoodgHVKhQYNiuoagJnrFvNn>)
<JamesMunns[m]1>
dangroshev[m]: Gotcha! Not morally opposed, I've just never made it part of my workflow.
<dangroshev[m]>
<JamesMunns[m]1> "Re: cdc-acm, I can't think of..." <- > <@jamesmunns:beeper.com> Re: cdc-acm, I can't think of a way it would ever be better? Maybe easier for permissions or something? Or built in flow control signaling of RTS/CTS/dtr whatever that the OS might be able to signal better? But it'd be pretty... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/oermdTxqrTyQktsEyntgHLhm>)
<dangroshev[m]>
<JamesMunns[m]1> "I do plan to add back support..." <- oh well, should've read the next message 😆
<JamesMunns[m]1>
dangroshev[m]: I definitely want to make the wire impl generic. I expect to support USB serial like I said, but also want to allow for transports like UDP, for example
<JamesMunns[m]1>
JamesMunns[m]1: dngrs has a PR that starts introducing that, now that async traits are stable. I just haven't worked on it much since RustNL
<JamesMunns[m]1>
JamesMunns[m]1: I'm a big fan of being able to say "you figure out how to get frames from here to there and back, and postcard-rpc should Just Work, regardless of any impl details
<JamesMunns[m]1>
* Just Work", regardless
embedded-enthusi has joined #rust-embedded
embedded-enthusi has quit [Remote host closed the connection]
embedded-enthusi has joined #rust-embedded
DominicFischer[m has joined #rust-embedded
<DominicFischer[m>
<JamesMunns[m]1> "But if you CAN use bulk descript..." <- Doesn't this mean you need a host driver?
<JamesMunns[m]1>
<DominicFischer[m> "Doesn't this mean you need a..." <- Yes, you can use `nusb`, which allows you to do this directly in userspace on win/mac/linux
avery71[m] has quit [Quit: Idle timeout reached: 172800s]
IlPalazzo-ojiisa has quit [Quit: Leaving.]
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
<MurrayToddWillia>
If I am doing an rp2040 (pico-rp BSP) project and need to share the i2c bus across two different sensors, my understanding is that I need to include `embedded-hal-bus` v0.2.0 in my project. (I read that in one of the driver's documentation.) When I do that, I get an error "no method named `compare_exchange` found for struct `portable_atomic::AtomicBool` in the current scope method not found in `AtomicBool` in
<MurrayToddWillia>
embedded-hal-bus's, i2c/atomic.rs and spi/atomic.rs files.
<MurrayToddWillia>
Is there something obvious that I'm missing? I'd seen a comment from a couple months ago suggesting I add some features "inline-asm" and "critical-section-single-core" to my cortex-m crate. I tried that and just got a host of new error messages. Any advice?
<M9names[m]>
Murray Todd Williams: does your project have a dependency on portable-atomic with the critical-section feature enabled?
<M9names[m]>
That being missing would be my guess
therealprof[m] has joined #rust-embedded
<therealprof[m]>
@thejpster:matrix.org Nice touch, I've never spoken at a conference where they did such a thing.