<re_irc>
<@bigfive:matrix.org> Hello everyone, I have been following embedded rust for a few years now. I find many aspects very promising and interesting. Still I never got to really building something with it. Only toyed around with some aspects of the language. As with not too much spare time for this it seems hard for me to find something...
<re_irc>
... to work consistently on and achieve progress. After trying to get "in the game" for a few times over the last year I thought maybe I need to find some project to contribute to that has already something going. In my day job I work a lot with CAN Bus and specially with the CANOpen protocol. As I really like CAN I thought maybe that would...
<re_irc>
... be interesting for me to work on with another set of tools (Rust). As I am a real beginner in actual work in Rust I am not confident to just start something but would rather work in it with other people who are able to give me some guidance. In return I could bring experience from working with CAN / CANopen in practice to the table. I...
<re_irc>
... found https://crates.io/crates/canopen but I could not find a repo of that in it does seem to be not worked on for a long time. I am glad for any input or directions to look for. Thanks
<re_irc>
<@come_744:converser.eu> This crate has no associated repository, no documentation and only one published version, 3 years ago… 🤔
<re_irc>
<@braincode:matrix.org> The implementations of this look the most promising in CAN and Rust space at the moment: https://crates.io/crates/embedded-can
<re_irc>
<@jorgeig:matrix.org> braincode: This is a set of traits (like an interface) for building CAN implementations
<re_irc>
<@jorgeig:matrix.org> so if you decide to roll your own, it'd be great if you follow it
<re_irc>
<@jorgeig:matrix.org> that means that people can switch between implementations without having to rewrite higher level code
<re_irc>
<@jorgeig:matrix.org> roll your own or contribute to another project
<re_irc>
<@braincode:matrix.org> bxcan/slcan mentioned on the README for embedded-can, I meant
<re_irc>
<@jorgeig:matrix.org> I don't know much about CAN or its Rust implementations so can't help much there - I'm trying to find a CAN implementation for embedded on crates.io but searching for `can` returns a lot of stuff 😅
<re_irc>
<@jorgeig:matrix.org> ah yes, bxcan is for STM32 MCUs
<re_irc>
<@come_744:converser.eu> In `crates.io` is there any possible filter for to get only `no_std` crates for instance ?
<re_irc>
<@jorgeig:matrix.org> @braincode if I understand right, CANopen is a protocol on top of the CAN bus?
<re_irc>
<@richarddodd:matrix.org> Côme: This would be nice
<re_irc>
<@jorgeig:matrix.org> if that's the case and you want to get your hands dirty, you could build first a crate that implements the CANopen interface, and then a reference implementation using embedded-hal traits for CAN - if that makes sense?
<re_irc>
<@adamgreig:matrix.org> crates.io can't tell and so many no-std libraries may not set that category, but many do
<re_irc>
<@adamgreig:matrix.org> jorgeig: Would it make more sense to build a canopen implementation on top of embedded-can?
<re_irc>
<@jorgeig:matrix.org> ah, yes
<re_irc>
<@adamgreig:matrix.org> Oh, maybe that's what you meant anyway
<re_irc>
<@jorgeig:matrix.org> as I say I literally have no idea about CAN other than that it exists
<re_irc>
<@jorgeig:matrix.org> haha
<re_irc>
<@adamgreig:matrix.org> But yea, if some canopen crate existed it could support embedded-can as well as the Linux interfaces and so forth, and then users could use it with any embedded driver that implemented embedded-can, such as bxcan for stm32
<re_irc>
<@come_744:converser.eu> adamgreig: Cannot use it as a filter when doing a search 😭
<re_irc>
<@bigfive:matrix.org> Thanks for All the Response I will take a Look at your suggestions if I am at home
<re_irc>
<@firefrommoonlight:matrix.org> Benjamin Schlegel: We could use an STM32 driver for FD CAN. Ie a complement to https://github.com/stm32-rs/bxcan, but for the newer periph
starblue2 has quit [Ping timeout: 250 seconds]
fabic has quit [Remote host closed the connection]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 240 seconds]
Rondom_ has quit [Remote host closed the connection]
Rondom has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> Do y'all have any recommendations for learning DSP? Interested in realtime audio processing. I want to make scifi augmented reality headphones. (Less-charitably marketed as "Hearing aids for young people")
<re_irc>
<@firefrommoonlight:matrix.org> I'm pretty sure STM32H7 is a clean kill for MCU choice
<re_irc>
<@firefrommoonlight:matrix.org> I have a STM32H7 dev board (Thanks for the rec on the nucleo guys!), an I2S mic, and closed-ear studio headphone with a jack that plugs into a breadboard.
<re_irc>
<@firefrommoonlight:matrix.org> Also, it looks like most of the material uses a C lib called CMSIS. Not sure if this means I should code in C, make a Rust wrapper lib, FFI etc
<re_irc>
<@jorgeig:matrix.org> speaking only from experience in DSPs more than 10 years ago, you want to use the "manufacturer" libraries for the DSP stuff
<re_irc>
<@jorgeig:matrix.org> CMSIS is the library built by ARM
<re_irc>
<@jorgeig:matrix.org> and they have a DSP part
<re_irc>
<@jorgeig:matrix.org> so I would try to build a wrapper around it
<re_irc>
<@firefrommoonlight:matrix.org> Awesome. So maybe start with trivial things like getting the hardware working with a unity transform, then try to wrap CMSIS so I can code in Rust?
<re_irc>
<@firefrommoonlight:matrix.org> Awesome! THank you
<re_irc>
<@firefrommoonlight:matrix.org> Don't want to reinvent any wheels
<re_irc>
<@jorgeig:matrix.org> I'm assuming the ARM libraries are the best way to do those ops on ARM cores - it could well be false, but implementing an FFT when you're learning DSP is not fun XD
<re_irc>
<@adamgreig:matrix.org> the cmsis libs are fine but i wouldn't worry that much about using them
<re_irc>
<@adamgreig:matrix.org> they're more or less just some libraries, there are pure rust libraries for doing FFTs if you want, too, though it might be interesting to benchmark them
<re_irc>
<@adamgreig:matrix.org> the stm32h7 is about as powerful as it gets for micocontroller-class dsp devices
<re_irc>
<@adamgreig:matrix.org> there's sort of two hard parts, one is working out what dsp you actually want to perform and how it works and so on, and the other is a different problem of making your device do that as fast as it can, which is where the SIMD instructions might help
<re_irc>
<@adamgreig:matrix.org> you might get started by implementing the signal processing on your desktop where it's much much easier to debug and visualise and chart and so on
<re_irc>
<@adamgreig:matrix.org> even just doing the algorithms in python or something, if you're familiar with numpy and matplotlib
<re_irc>
<@adamgreig:matrix.org> i usually lean too hard into doing everything myself for the learning experience rather than reusing existing libraries, so writing my own fft implementation sounds like great fun and would distract me for a while, heh
<re_irc>
<@adamgreig:matrix.org> but if you want to understand what maths is going on and find clever tricks to make it faster or better in your specific implementation i think it's nice
<re_irc>
<@adamgreig:matrix.org> dsp is just chock full of clever tricks
<re_irc>
<@jorgeig:matrix.org> man I love my studies but I am in no rush to re-implement FFTs and TCP again
<re_irc>
<@adamgreig:matrix.org> oh, yea, I think once is enough for that sort of thing :P
<re_irc>
<@adamgreig:matrix.org> but doing it that first time is pretty instructive!
<re_irc>
<@adamgreig:matrix.org> after that it's more like masochism heh
<re_irc>
<@jorgeig:matrix.org> it definitely was, that's true
<re_irc>
<@newam:matrix.org> That is a good point, rust doesn't have a ton in the way of plotting. matplotlib + python help a ton with visualization.
<re_irc>
<@newam:matrix.org> For a little rust SDR lib I ended up dumping IQ samples as binary then writing a python script to load the data and display it.
<re_irc>
<@newam:matrix.org> visualizations are pretty much a requirement for learning DSP, can't easily visualize a waveform by eyeing an array full of numbers.
<re_irc>
<@adamgreig:matrix.org> I really like "Understanding Digital Signal Processing" by Richard Lyons if you want a book rec
<re_irc>
<@adamgreig:matrix.org> it's got a decent but not too heavy coverage of a lot of DSP topics, and a really great chapter on just lots of good tricks
<re_irc>
<@adamgreig:matrix.org> newam: for this I use inline_python and it's _incredible_
<re_irc>
<@newam:matrix.org> adamgreig: oh, now that's smart.
<re_irc>
<@jorgeig:matrix.org> oh wow I did not know that was a thing
<re_irc>
<@adamgreig:matrix.org> it _just works_
<re_irc>
<@jorgeig:matrix.org> that's amazing
<re_irc>
<@adamgreig:matrix.org> (a Mara special)
<re_irc>
<@dirbaio:matrix.org> WTF, that looks so cursed
<re_irc>
<@newam:matrix.org> That is gorgeous compared to the hacks I had. I was generating massive SVGs so I could zoom in on the data.
<re_irc>
<@newam:matrix.org> Makes me wish that project wasn't finished so I could go back to it.
<re_irc>
<@adamgreig:matrix.org> yep i've been absolutely loving it for dsp
<re_irc>
<@adamgreig:matrix.org> it's a shame there's nothing as slick as matplotlib already in rust
<re_irc>
<@adamgreig:matrix.org> and it still needs nightly atm
<re_irc>
<@adamgreig:matrix.org> so I put it behind a "python" featuregate and then `cargo +nightly run --features python` when I want the charting etc
<re_irc>
<@firefrommoonlight:matrix.org> adamgreig: Thank you for the detailed perspective! I suppose you hit the root of the problem, which I ommitted: What I want to do using the DSP. And this will probably evolve over time
<re_irc>
<@firefrommoonlight:matrix.org> I'll check out some native rust libs first
<re_irc>
<@firefrommoonlight:matrix.org> Maybe try this using Python first as you suggested, and not worry about the realtime aspect yet
<re_irc>
<@firefrommoonlight:matrix.org> (Which I assume Python can't hack, or really, anything running on a GPOS can't hack)
<re_irc>
<@firefrommoonlight:matrix.org> (So ironic - you need a slower device to do things faster!)
<re_irc>
<@firefrommoonlight:matrix.org> I'm proficient with Python/Numpy/Scipy etc, and they have loads of libs
<re_irc>
<@firefrommoonlight:matrix.org> I can break this down into 2 problems for now: #1: Get the DAC+headphones (Plus some sort of headphone amp??) + H7 + Mic working with a passthrough. I should be able to do that with the hardware I have on my desk. #2: Use Python to sort out transforms, probably as a record + process + playback later
<re_irc>
<@firefrommoonlight:matrix.org> Problem #1 can probably be sorted with simple breadboarding, and the DAC and SAI peripherals on the STM32H7. I'm proficient with DAC for simple signals, but not with complex, and have no experience with the SAI periph. The STM32H7xx-HAL lib appears to have some support for it in I2S mode, which is what...
<re_irc>
<@come_744:converser.eu> Just wondering, what could cause this?
<re_irc>
<@newam:matrix.org> Côme: Entering low power modes, turning off clocks for the debug domain.
<re_irc>
<@come_744:converser.eu> Hmmm… So the cause is the last program I flashed?
<re_irc>
<@newam:matrix.org> maybe. There are probably other causes for that, but those two are the ones I encounter the most.
<re_irc>
<@come_744:converser.eu> Okay thanks
<re_irc>
<@come_744:converser.eu> Could `probe-run` suggest the `--connect-under-reset` flag when this error occurs, a bit like `rustc` notes to fix errors in the code? I think it could help a lot of noobs like me (and be a remainder for the others). I can open an issue here if you think it is the appropriate place...
<re_irc>
<@newam:matrix.org> That would be a useful diagnostic, yeah. I'm not sure if that message comes from `probe-run` or `probe-rs`, but wouldn't be a wrong first step to file an issue there.
<re_irc>
<@newam:matrix.org> For `probe-run` it probably makes sense to automatically try `--connect-under-reset` as well? `probe-run` clobbers the state by flashing the target every time, so resetting the target shouldn't be an issue for anyone (famous last words)
<re_irc>
<@come_744:converser.eu> It seems it comes from `probe-rs` (file `probe-rs/src/probe/stlink/constants.rs`)
<re_irc>
<@come_744:converser.eu> +1 for an automatic try
<re_irc>
<@come_744:converser.eu> So I can open an issue for `probe-run` so that it catches the `JtagNoDeviceConnected` error and then test with `--connect-under-reset`?
<re_irc>
<@newam:matrix.org> That sounds reasonable to me.
<re_irc>
<@come_744:converser.eu> Okay thanks, I will do this but I will first try to see if I can do it myself and send a PR
<re_irc>
<@adamgreig:matrix.org> newam: connect-under-reset will stop programming ever working on some devices, like nrf52, tho
<re_irc>
<@adamgreig:matrix.org> tho I guess... if programming didn't work first time...
<re_irc>
<@adamgreig:matrix.org> might as well try with it, lol
<re_irc>
<@newam:matrix.org> Yeah that's what I figured.
<re_irc>
<@adamgreig:matrix.org> might make it sort of mask the problem and cause more confusion later though, dunno
<re_irc>
<@adamgreig:matrix.org> it requires the reset line be connected between probe and target, which is often not done if you're hooking stuff up with jumper cables too
<re_irc>
<@adamgreig:matrix.org> still I guess it can say "didn't work, trying with reset" and give it a go
<re_irc>
<@newam:matrix.org> Yeah, I was thinking a really big warning message would make it clear enough; ideally the user should set the flag correctly in the first place.
starblue2 has joined #rust-embedded
<re_irc>
<@come_744:converser.eu> So just print a note message to the user, no automatic try?
<re_irc>
<@newam:matrix.org> I think automatic try isn't a bad idea; but it is debatable.
<re_irc>
<@come_744:converser.eu> Now I am wondering: if it can be risky to use it automatically, wouldn't it be risky to suggest beginners who do not know about it to use the flag?
<re_irc>
<@newam:matrix.org> it's not risky as in it will break anything; just risky in that it may be incorrect for some targets.
<re_irc>
<@come_744:converser.eu> So the worst case is that it is a no-op ?
<re_irc>
<@adamgreig:matrix.org> and it's kinda annoying to imagine a situation where it's required for some firmware/target but the user keeps running without and it keeps just having to spit out a warning and try again
<re_irc>
<@adamgreig:matrix.org> if flashing doesn't work without it, there's no harm in trying with it
<re_irc>
<@adamgreig:matrix.org> but usually the actual problem is the user should enable debug-while-in-low-power or something in their own firmware
<re_irc>
<@adamgreig:matrix.org> (or avoid entering low power during development etc)
<re_irc>
<@adamgreig:matrix.org> it's _required_ when the firmware must disable debug access for some reason, e.g. reusing the pins for something else, or while developing the low-power support, that sort of thing
<re_irc>
<@adamgreig:matrix.org> for I guess for 90% of people hitting this problem unexpectedly, it's because they're using RTIC and it defaults to running WFI in the idle loop, putting the chip to a sleep, which typically (e.g. on stm32) disables debug access
<re_irc>
<@come_744:converser.eu> Actually in my program I don't know why it happened, I have not used such things explicitly…
<re_irc>
<@adamgreig:matrix.org> so the better solution is probably to not do that (in RTIC's case, specify your own idle loop, or whatever)
<re_irc>
<@adamgreig:matrix.org> the other common error on stm32 is to use gpioa.moder().write()
<re_irc>
<@adamgreig:matrix.org> though I guess in theory that should use the reset value 🤔 anyway it's an easy way to accidentally disable the debug pins
<re_irc>
<@come_744:converser.eu> Would it be possible that I unplugged the board at an inappropriate moment?
<re_irc>
<@adamgreig:matrix.org> sorry, I'm probably being a bit overly cautious here, I think having probe-run suggest "try using --connect-under-reset, and if that does help, here's a link to an article suggesting why you might need this and how you might avoid it" or something
<re_irc>
<@adamgreig:matrix.org> probably not
<re_irc>
<@adamgreig:matrix.org> what is in the firmware you flashed?
<re_irc>
<@come_744:converser.eu> Hmm at this time I was using stm32f4xx_hal, no RTIC or such things
<re_irc>
<@come_744:converser.eu> I do not have the code right now, I shot down the computer
<re_irc>
<@come_744:converser.eu> The link option seems good
<re_irc>
<@come_744:converser.eu> But it would imply that someone writes something eg in the GH wiki of probe-run
<re_irc>
<@come_744:converser.eu> And I do not have the knowledge to do this
<re_irc>
<@adamgreig:matrix.org> even just suggesting to try that option is probably more helpful than nothing
<re_irc>
<@adamgreig:matrix.org> you could see what the probe-run maintainers think about having it retry with it automatically
<re_irc>
<@come_744:converser.eu> First I'll try to print a note, and then in the PR (if I succeed) or issue (if I try and fail) I will mention the different ideas mentionned in this channel.
<re_irc>
<@come_744:converser.eu> Thanks!
<re_irc>
<@come_744:converser.eu> (And maybe the automatic use of the flag does not exclude the possibility to print a warning and a link explaining how to avoid the warning)