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
<cgc17[m]> Hi all, i recently came across Embassy when looking for how to get started with Bluetooth with the nrf52. Is that currently the best supported way to do that? I’ve never worked with Bluetooth before if that makes a difference. I saw other crates but they seemed or even stated they were now unmaintained.
<dirbaio[m]> yes
<cgc17[m]> Thanks!
Averyshethey[m] has quit [Quit: Idle timeout reached: 172800s]
<cgc17[m]> I’m sure I’ll be back with questions but just wanted to be sure I start down the right path.
IlPalazzo-ojiisa has quit [Quit: Leaving.]
M9names[m] has joined #rust-embedded
<M9names[m]> <ragarnoy[m]> "i mean i did ask around before..." <- > i mean i did ask around before asking you and no one knew
<M9names[m]> people ask again later all the time and usually get a reply. please try this strategy next time.
<M9names[m]> no response does not mean nobody knew. there are a lot of people in this room, but at any given moment only a few may have time for the back-and-forth required to help someone debug an issue where the cause is not immediately obvious.
<M9names[m]> M9names[m]: ragarnoy ^
yourarj[m] has quit [Quit: Idle timeout reached: 172800s]
notgull has quit [Ping timeout: 256 seconds]
notgull has joined #rust-embedded
juliand[m] has quit [Quit: Idle timeout reached: 172800s]
Foxyloxy_ has joined #rust-embedded
Foxyloxy has quit [Ping timeout: 252 seconds]
<JamesMunns[m]> btw, if you are a `postcard` user, I have an open Request For Comments about doing a 2.0 version in the next month or two, to decouple postcard from public deps like `heapless` and `embedded-io`, so that we can easily add support for new versions of those (and other) crates in the future:
<JamesMunns[m]> If you are a user, or you work at a company that uses postcard, I'm definitely interested in comments, thoughts, or sponsorship for this work. Feel free to shoot me a DM or comment on that issue.
<JamesMunns[m]> I say this in the issue, but just for clarity:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/WXrSYsqKVPKXiQZeKqcVGyXS>)
<JamesMunns[m]> Basically: I'd like to know if the thought of this makes anyone annoyed or angry. If yes: lemme know and we can talk about it. Otherwise, this is me signaling intent that I'm gunna do it unless someone convinces me otherwise.
holo[m] has joined #rust-embedded
<holo[m]> Hey, do you recommend some MQTT no_std library?
crabbedhaloablut has quit []
MathiasKoch[m] has quit [Quit: Idle timeout reached: 172800s]
lulf[m] has joined #rust-embedded
<lulf[m]> There's rust-mqtt and minimq
IlPalazzo-ojiisa has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
<holo[m]> <lulf[m]> "There's rust-mqtt and minimq" <- Will that rust-mqtt work with embassy executor?
<lulf[m]> Yes
<holo[m]> Thanks
_whitelogger has joined #rust-embedded
<Ecco> I'm using panic_probe with defmt. When my code panics, I don't get a backtrace. All I get is defmt's location (so I know what file/line the panic happened). But I don't get the full trace.
<Ecco> Any idea why?
<JamesMunns[m]> <Ecco> "I'm using panic_probe with defmt..." <- Do you have debug info turned on in your profile? And are you using probe-rs or probe-run?
<Ecco> I'm using probe-rs
<Ecco> Checking the debug info thing :)
<Ecco> Also, defmt seems to be "missing" some messages
<Ecco> If I log a bunch of stuff on startup, then at some point the first N messages are just dropped
<Ecco> they come back if I add DEFMT_RTT_BUFFER_SIZE=8192
<Ecco> But that's weird tho, I'm not even logging that much
<Ecco> (I'm running in debug mode, so I guess the debug info is there?)
<JamesMunns[m]> Might be worth dropping by #probe-rs:matrix.org and asking. It's possible that you are filling up the buffer, or it just takes some time to start draining? idk
<Ecco> ok :)
<khionu[m]> No progress on my FIELD_CHANGE issue. I've kept searching for code examples, but I think everyone doing this has kept their source closed :/ Might see if I can get a hold of someone in STM...
<AdamHott[m]> Hi all, I've soldered a board with some components, some of the components weren't the best solder job. I'm questioning whether this board will be a risk if I plug it into my computer. Wondering if anyone would care to take a look at these 5 photos to give me feedback? https://github.com/CodingInGreen/project_green_storm_zoom
<JamesMunns[m]> Do you have a multimeter?
<JamesMunns[m]> If you do, I would probably check that there isn't a short between the 5v rail and ground, or the 3v3 rail and ground. If there isn't, I'd probably wouldn't consider it a risk.
<AdamHott[m]> yep
<AdamHott[m]> ok let me check my diagram to see where those rails are
<JamesMunns[m]> you don't have a benchtop power supply, do you?
<AdamHott[m]> I don't have a benchtop, but my Analog Discovery 3 is capable of supplying up to 5v
<AdamHott[m]> I don't know how I'd wire it up to a micro USB cable though
<JamesMunns[m]> A benchtop supply lets you limit the max current to like 10/50/100mA, which means if there is a short, you can stop chips from frying themselves
<JamesMunns[m]> but, if there isn't a short, I'd say your PC is likely safe.
<AdamHott[m]> If I bought a benchtop supply would it give me connectors like the micro-usb cable so that I could plug it into the board to power it?
<AdamHott[m]> or maybe I could by that connector separately?
jessebraham[m] has joined #rust-embedded
<jessebraham[m]> Many supplies have USB now, but if not you can just snip the end off a cable and attack +/- to Red/Black at 5V
<jessebraham[m]> s/attack/attach/
<AdamHott[m]> this one has USB, but it looks like its just for charging a cell phone. Is that adequate to test with? https://mauser.pt/catalog/product_info.php?products_id=076-0613
<AdamHott[m]> Doesn't look like you can control the amps
<AdamHott[m]> It does have a separate display for the USB, and it's got volts and amps on it, maybe it does allow to control the amps
<AdamHott[m]> I'll check out the manual, thanks!
kevlan[m] has joined #rust-embedded
<kevlan[m]> Any computer should have current limits on the USB ports. Some are better than others though with respect to how they get reset. I believe on my laptop I have to completely reboot it to get a port to come back after I trip the current limiter. These are usually in the range of 1-3A depending on how the port is setup. To be spec compliant all USB hardware is also "supposed" to handle shorting the D+/- lines to 5V without damage which
<kevlan[m]> is in-case cables are damaged.
<AdamHott[m]> what if I plugged it into a micro-usb charger connected directly to the wall then test with a multimeter, would that be risky?
<AdamHott[m]> as you can tell, I know enough to get myself in trouble
<JamesMunns[m]> :D
<JamesMunns[m]> I mean, I'd probably plug it into the wall charger, see if anything gets hot or starts smoking immediately, then check the 5v rail is 5v +/- 0.25v
<JamesMunns[m]> if it's way lower, unplug it immediately (it's probably shorting)
<JamesMunns[m]> but you're probably fine
<AdamHott[m]> ok cool, this is my schematic, what do I poke at with the multimeter to test the 5v rail? https://github.com/CodingInGreen/project_green_storm_zoom/blob/master/green_storm_schematic.pdf
<AdamHott[m]> Got it! 5v - USB connector - 3v - voltage regulator
<JamesMunns[m]> Anywhere it says VBUS, yeah
<JamesMunns[m]> "5v rail" means "anywhere the voltage is 5v", could be on your capacitors, the MCU, the connector, or at the LDO.
<AdamHott[m]> thanks James Munns , kevlan , and jessebraham! I plugged the micro USB cable into the board and the USB component on the board popped off! haha, I forgot to solder two of the four points on the USB component! no shocks, smoke, or overheating though! Unplugged and will solder those later, thanks!
mameluc[m] has quit [Quit: Idle timeout reached: 172800s]
<Ecco> Oh, I have an Embassy question
<Ecco> I'm trying to use it with a C library, that is synchronous
<Ecco> e.g. the C library exposes some blocking functions, and those functions expect some other task to run in the background
<Ecco> This just cannot work with embassy, right?
dngrs[m] has quit [Quit: Idle timeout reached: 172800s]
explodingwaffle1 has quit [Quit: Idle timeout reached: 172800s]
spinfast[m] has joined #rust-embedded
<spinfast[m]> Without scheduling points the only thing that works for long running blocking functions is time slicing which requires stacks and threads
<spinfast[m]> Assuming tasks of the same priority from the “idle” thread here not interrupts
djdisodo[m] has joined #rust-embedded
<djdisodo[m]> is there virtual filesystem abstraction for embedded rust?
<djdisodo[m]> s/virtual//
<dirbaio[m]> <Ecco> "This just cannot work with..." <- kiiiiinda. if you can write the "background task" to be async (or blocking for short periods of time) you can spawn it in a higher-priority executor. So when the lower-priority code is blocking, the higher-priority background task can still preempt it and run. see the [multiprio example](https://github.com/embassy-rs/embassy/blob/main/examples/stm32f4/src/bin/multiprio.rs).
<dirbaio[m]> if the background task also needs to block for long periods of time then it's not easy, no
<dirbaio[m]> like, if task A blocks waiting for task B, and task B blocks waiting for task A, then you will run into deadlocks even with multiprio
<dirbaio[m]> but if only one is blocking and the other is async, then you can
<dirbaio[m]> s/you/multiprio/, s/can/will work/
<ragarnoy[m]> I'm back with this... complicated signature `&'static mut (dyn SpiBus<u16, Error = Infallible>`
<ragarnoy[m]> It turns out Infallible was a bad idea, I'd like to use the same Error type as the library user, I tried `dyn SpiBus<u16, Error = dyn embedded_hal::spi::Error` but -> the size for values of type `(dyn embedded_hal::spi::Error + 'static)` cannot be known at compilation time
<dirbaio[m]> yeah you can't do that
<dirbaio[m]> dyn Trait is an "unsized type", the size of it is only known at runtime.
<dirbaio[m]> you can't make the error type unsized
<ragarnoy[m]> Apparently I cannot add Sized, or if I do I have to have a new trait, but if i create a new trait the user will have to implement it too, i'd just like to use the same errors as the hal's Spi
<dirbaio[m]> what you can do is put it behind a pointer
<dirbaio[m]> to make it sized
<dirbaio[m]> `dyn Trait` is unsized, while `&mut dyn Trait`, `Box<dyn Trait>` are sized (because the pointer itself is fixed size, even if the pointed-to data isn't)
<dirbaio[m]> in this case the only one you can use is `Box<dyn Trait>`
<ragarnoy[m]> so dyn &'static Error ?
<ragarnoy[m]> oh
<dirbaio[m]> `&` won't work because the error is returned from the spi functions, so it must be owned, not borrowed
<dirbaio[m]> '&'static mut (dyn SpiBus<u16, Error = Box<dyn embedded_hal::spi::Error>>`
<dirbaio[m]> * `&'static mut (dyn SpiBus<u16, Error = Box<dyn embedded\_hal::spi::Error>>`
<ragarnoy[m]> but Box means alloc
<dirbaio[m]> yeah
<dirbaio[m]> you can't do it without alloc
<ragarnoy[m]> noooooo
<dirbaio[m]> dyn is quite limited in no-alloc Rust, you can't own a dyn Trait because you need Box for that
<dirbaio[m]> you can only ever use behind `&`/`&mut`
<ragarnoy[m]> seems odd for something that only needs to implment kind(), but that's just me ranting
<dirbaio[m]> well
<dirbaio[m]> the embedded-hal errors are set up that way so that each HAL can use a different error type
<dirbaio[m]> the hardware might provide more info than just the "kind" of the error
<dirbaio[m]> so the HAL-specific error type can carry that information
<dirbaio[m]> so code using HAL-specific types can access all the information, while generic code can only access the kind
<dirbaio[m]> so if you really want to keep all the information, you must use dyn, but in this case that needs alloc
<dirbaio[m]> if you don't want alloc
<dirbaio[m]> you can either use generics (but in this case you can't because you want to put this thing in a static iirc?)
<dirbaio[m]> or use dyn, but then you have to throw away some information about the error
<dirbaio[m]> you can do `dyn SpiBus<u16, Error = Infallible>` and convert errors to panics
<dirbaio[m]> or you can do `dyn SpiBus<u16, Error = embedded_hal::spi::ErrorKind>`, but then you're throwing away all information about the error except the kind
<dirbaio[m]> and in both cases you will need an "adapter" for SpiBus
<ragarnoy[m]> and I have to make a wrapper over Spi that reimplements SpiBus with an Infallible Error ?
<dirbaio[m]> yeah, an adapter that converts from `SpiBus<u16, Error = E>` to `SpiBus<u16, Error = Infallible>`
<dirbaio[m]> * = E>` (for any error type `E`) to `SpiBus<u16,
<dirbaio[m]> (or to `SpiBus<u16, Error = embedded_hal::spi::ErrorKind>`)
<dirbaio[m]> it's a bit unfortunate, the root cause of this issue is you hvae to put the SPI in a static
<dirbaio[m]> if you could avoid that, you'd have an easier time
<dirbaio[m]> if you could pass a "context pointer" through to the callback for example.. but the C lib cna't
<dirbaio[m]> s/cna/can/
<dirbaio[m]> C being C ... 🫠
<ragarnoy[m]> yeah, in a way you could say it's C's fault, it sucks that there is not way to like... downcast the errors to their kind
<ragarnoy[m]> without making an adapter i mean
<dirbaio[m]> well
<dirbaio[m]> Rust won't do it for you since it's more like "throw information away" rather than "downcast"
<ragarnoy[m]> yeah i'm being a bit unreasonable
<ragarnoy[m]> But!.. In those kinds of environment sometimes you have to make do with the small amount of ressources you have
<dirbaio[m]> in a "traditional inheritance" language like Jave you'd expect the HAL-specific error type would inherit from ErrorKind so you can always use one in place of a kind, without generics. but no such thing in Rust
<ragarnoy[m]> the adapter kind of seems like a dirty fix
barafael[m] has quit [Quit: Idle timeout reached: 172800s]
chaeyounglee[m] has joined #rust-embedded
<chaeyounglee[m]> has anyone worked with cameras in embassy-rust?
aziz6004[m] has joined #rust-embedded
aziz6004[m] has left #rust-embedded [#rust-embedded]
tiwalun[m] has quit [Quit: Idle timeout reached: 172800s]
<Ecco> dirbaio[m]: Thanks for the comprehensive answer :)
jmgr[m] has joined #rust-embedded
<jmgr[m]> Now I'm using `ExclusiveDevice` to convert the SpiBus into a SpiDevice, but that doesn't offer any option to "release" the device, as far as I can see.
<jmgr[m]> Hi there, I'm trying to migrate my small project to embedded-hal 1.0 and it's mostly okay, but I'm having an issue with `ExclusiveDevice`. I'm using a SSD1351 managed display and using the crate of the same name to configure the display and then switching to a double buffered DMA transfer for updates. I was previously using the free() function from the rp2040-hal implementation to release the Spi bus and use it as a target for DMA
<jmgr[m]> transfers.
<jmgr[m]> Is there another way of doing this? How do you switch from configuring a device to raw DMA transfers?
<dirbaio[m]> ah yes, we should add something like .into_inner() to ExclusiveDevice
<dirbaio[m]> PRs welcome
<dirbaio[m]> if you want a quick fix you can copypaste ExclusiveDevice into your project, it's not that much code
<jmgr[m]> Right, good to know that I'm not doing something silly.
<jmgr[m]> Thanks, I'll try that locally. Happy to have a got at a PR afterwards though.
<dirbaio[m]> actually
<dirbaio[m]> you can create the ExclusiveDevice with `&mut Bus` instead of `Bus`
<dirbaio[m]> and `&mut OutputPin`
<jmgr[m]> s/got/go/
<dirbaio[m]> (there's blanket impls for `&mut` for all e-h traits)
<dirbaio[m]> so if you drop the ExclusiveDevice, the borrows on the bus and the CS pin are released and you can use them again with something else
<dirbaio[m]> (we should still add .into_inner() though, the borrow thing doesn't always work, sometimes you want owned everything)
emerent is now known as Guest6392
emerent has joined #rust-embedded
Guest6392 has quit [Killed (zirconium.libera.chat (Nickname regained by services))]
firefrommoonligh has quit [Quit: Idle timeout reached: 172800s]