<re_irc> <@f​irefrommoonlight:m​atrix.org> Hah yeah I had a typo!
<re_irc> <@f​irefrommoonlight:m​atrix.org> And.... It's showing working on my end! All issues fixed
<re_irc> <@a​damgreig:m​atrix.org> 🎉
<re_irc> <@a​damgreig:m​atrix.org> the only lesson here is that the YAML patching format I came up with in five minutes in 2017 was bad
<re_irc> <@f​irefrommoonlight:m​atrix.org> Committed / pushed (From the Windows native CLI...)
<re_irc> <@f​irefrommoonlight:m​atrix.org> Thank you so much
<re_irc> <@f​irefrommoonlight:m​atrix.org> No! It just has some subtleties and I'm a noob at it
<re_irc> <@f​irefrommoonlight:m​atrix.org> It's the fix we need to clean up the SVDs
<re_irc> <@f​irefrommoonlight:m​atrix.org> I'm thrilled with the PAC project's results
<re_irc> <@f​irefrommoonlight:m​atrix.org> Do you want me to squash the commits etc?
<re_irc> <@a​damgreig:m​atrix.org> sure, thanks
<re_irc> <@a​damgreig:m​atrix.org> glad it's all fixed, i'll try and get it merged asap
<re_irc> <@f​irefrommoonlight:m​atrix.org> There are 5 commits in this PR. Will this do it? `git rebase --interactive HEAD~5`
<re_irc> <@a​damgreig:m​atrix.org> yep, if in doubt i just go a bit further back and then leave the previous commits alone
<re_irc> <@f​irefrommoonlight:m​atrix.org> It's doing the thing where it opens a text editor then doesn't merge them
<re_irc> <@a​damgreig:m​atrix.org> in the editor you need to change 'keep' to 'squash' on all the commits after your first one, then save the file in the editor and quit
<re_irc> <@f​irefrommoonlight:m​atrix.org> Hah. Now I have 7 commits
<re_irc> <@a​damgreig:m​atrix.org> 🙃
<re_irc> <@f​irefrommoonlight:m​atrix.org> We've already established I don't do good at git
<re_irc> <@d​irbaio:m​atrix.org> question: I want CI to deny warnings
<re_irc> <@d​irbaio:m​atrix.org> but I don't want to use `#[deny(warnings)]` in the source because that also applies when developing locally and is super annoying
<re_irc> <@d​irbaio:m​atrix.org> I've seen you can do `RUSTFLAGS=-Dwarnings cargo build`
<re_irc> <@d​irbaio:m​atrix.org> but RUSTFLAGS envvar overrides rustflags from .cargo/config 🤣
<re_irc> <@d​irbaio:m​atrix.org> overrides, not appends
<re_irc> <@a​damgreig:m​atrix.org> dirbaio: also it makes new rustc warnings a breaking change in your code, which is rubbish
<re_irc> <@d​irbaio:m​atrix.org> so it doesn't pick up linker scripts and I end up with empty binaries 💩
<re_irc> <@d​irbaio:m​atrix.org> and I don't want to put `-Dwarnings` in `.cargo/config` either because it'll apply it during local dev too
<re_irc> <@d​irbaio:m​atrix.org> so I have no idea what to do... any ideas?
<re_irc> <@d​irbaio:m​atrix.org> oh CI is only doing cargo check anyway
<re_irc> <@d​irbaio:m​atrix.org> so the linker scripts shouldn't matter there
<re_irc> <@d​irbaio:m​atrix.org> is it a good practice to only do check in CI?
<cr1901> Add a PR to cargo for CARGO_RUSTFLAGS_APPEND :), which will only append RUSTFLAGS
<re_irc> <@d​irbaio:m​atrix.org> https://github.com/rust-lang/cargo/issues/5376 🤣
<re_irc> <@a​damgreig:m​atrix.org> https://github.com/tock/libtock-rs/pull/271/files
<re_irc> <@a​damgreig:m​atrix.org> and https://github.com/rust-lang/cargo/issues/8424 i guess
<re_irc> <@d​irbaio:m​atrix.org> LOL editing .cargo/config
<re_irc> <@a​damgreig:m​atrix.org> yea lol
<re_irc> <@a​damgreig:m​atrix.org> cargo check is ok but if you have stuff that's gated by arch it won't pick it up afaik
<re_irc> <@d​irbaio:m​atrix.org> but adding a `[target.'cfg(all())']` won't work if I already have a `[target.'cfg(all(target_arch = "arm", target_os = "none"))']` right?
<re_irc> <@d​irbaio:m​atrix.org> or does it merge them in that situation? 🤣
<cr1901> >build.rustflags cannot be used here as the lower section would override its effect.
<cr1901> why would build.rustflags factor into this at all?
<re_irc> <@d​irbaio:m​atrix.org> huh it DOES merge them in that case
<cr1901> I think that's a side effect of how TOML works
<re_irc> <@d​irbaio:m​atrix.org> cr1901: it means rustflags in [target] override rustflags in [build]
<re_irc> <@d​irbaio:m​atrix.org> but if you have multiple [target]s that apply, it does merge them
<re_irc> <@d​irbaio:m​atrix.org> wtf cargo
<re_irc> <@a​damgreig:m​atrix.org> lol what on earth
<re_irc> <@a​damgreig:m​atrix.org> does that work?
<re_irc> <@d​irbaio:m​atrix.org> yeah it does work
<re_irc> <@a​damgreig:m​atrix.org> sweet
<re_irc> <@d​irbaio:m​atrix.org> just tested
<re_irc> <@d​irbaio:m​atrix.org> still it doesn't solve my problem 🤣
<re_irc> <@a​damgreig:m​atrix.org> close your eyes, copy it into your workflow, commit, look away
<re_irc> <@d​irbaio:m​atrix.org> I have 8 `.cargo/config` files in the repo
<re_irc> <@d​irbaio:m​atrix.org> I have to edit them all....
<re_irc> <@f​irefrommoonlight:m​atrix.org> adamgreig: Can you hold off on merging for now?
<re_irc> <@a​damgreig:m​atrix.org> hmmm
<re_irc> <@d​irbaio:m​atrix.org> or does it get merged ACROSS .cargo/config files?
<cr1901> Why would you want that overriding behavior? ._.
<re_irc> <@f​irefrommoonlight:m​atrix.org> I think the BCDR thing was breaking the adding-interrupt to l4x3, that was my concern with it which I now found out
<re_irc> <@a​damgreig:m​atrix.org> firefrommoonlight: sure, under 'reviewers' there's a "Still in progress? Convert to draft" button you can click to mark a PR as not ready
<re_irc> <@f​irefrommoonlight:m​atrix.org> Done
<re_irc> <@a​damgreig:m​atrix.org> cool, there's a bigger 'ready for review' button at the bottom when it's ready
<re_irc> <@a​damgreig:m​atrix.org> what's the bdcr issue?
<re_irc> <@d​irbaio:m​atrix.org> lol yep I can place a `.cargo/config` file at the root that gets merged with all the others
<re_irc> <@a​damgreig:m​atrix.org> 🤯
<re_irc> <@d​irbaio:m​atrix.org> so it merges THAT
<re_irc> <@d​irbaio:m​atrix.org> but not the RUSTFLAGS envvar
<re_irc> <@a​damgreig:m​atrix.org> (btw use config.toml these days)
<re_irc> <@d​irbaio:m​atrix.org> good job cargo
<re_irc> <@f​irefrommoonlight:m​atrix.org> Ok, fixed; was a YAML syntax issue where I had 2 `_add` blocks, but needed only 1
<re_irc> <@f​irefrommoonlight:m​atrix.org> I guess the second one overrides the first
<cr1901> I wonder if I can do merging BS with multiple [dependencies.foo] entries
<re_irc> <@a​damgreig:m​atrix.org> yea, unfortunately identical keys in a map override each other when the yaml is read
<re_irc> <@a​damgreig:m​atrix.org> while identical keys from included files get merged... yaml
<re_irc> <@a​damgreig:m​atrix.org> wonder if i can make the former emit a warning in pyyaml
fabic has joined #rust-embedded
<re_irc> <@f​irefrommoonlight:m​atrix.org> Yea - I think explicit errors would be great
<re_irc> <@a​damgreig:m​atrix.org> yea. it looks like pyyaml can not and will not detect this, even though the yaml spec says it must. of course.
<re_irc> <@f​irefrommoonlight:m​atrix.org> :/
<re_irc> <@a​damgreig:m​atrix.org> opened an issue to try and resolve later, looks like it might be possible to override the relevant bit of pyyaml
<re_irc> <@f​irefrommoonlight:m​atrix.org> Sweet!
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
<re_irc> <@d​irbaio:m​atrix.org> what's the best way for using an `impl DelayUs`?
<re_irc> <@d​irbaio:m​atrix.org> `fn foo(delay: impl DelayUs)` will take ownership and drop it which sucks for the user if they want to use it more
<re_irc> <@d​irbaio:m​atrix.org> return it back? `fn foo<D: DelayUs>(delay: D) -> D`
<re_irc> <@d​irbaio:m​atrix.org> borrow it? `fn foo(delay: &mut impl DelayUs)`
<re_irc> <@d​irbaio:m​atrix.org> maybe EH should get a `impl<T: DelayUs> DelayUs for &mut T`?
<re_irc> <@a​damgreig:m​atrix.org> can it? that seems like a fairly nice addition if it works
<re_irc> <@a​damgreig:m​atrix.org> saves hals having to impl for T and &T themselves
<re_irc> <@a​damgreig:m​atrix.org> and the traits all already take &mut, right
<re_irc> <@d​irbaio:m​atrix.org> AFAICT drivers usually take &mut
<re_irc> <@d​irbaio:m​atrix.org> which sucks because it's not zero cost D:
<re_irc> <@d​irbaio:m​atrix.org> adamgreig: HALs do that?
<re_irc> <@d​irbaio:m​atrix.org> can't find one
<re_irc> <@d​irbaio:m​atrix.org> and lol the systick delay is copypasted everywhere 🤣
<re_irc> <@d​irbaio:m​atrix.org> good thing it's in cortex-m now
starblue1 has joined #rust-embedded
starblue has quit [Ping timeout: 258 seconds]
<re_irc> <@t​halesfragoso:m​atrix.org> dirbaio: You mean if the type is a ZST ?
<re_irc> <@d​irbaio:m​atrix.org> Yeah
<re_irc> <@f​irefrommoonlight:m​atrix.org> `<D: DelayUs>(delay: &mut D) {`
<re_irc> <@f​irefrommoonlight:m​atrix.org> ... Or use the delay directly: `fn slowdown(delay: &mut Delay)`
<re_irc> <@w​illeml:m​atrix.org> Hey, firefrommoonlight I made some progress on my QSPI flash stuff, rfuest fixed reading by correctly setting pin speeds (made them VeryHigh instead of whatever the default is) and I also stopped the crash that occurs when unsetting memory mapped mode, I was simply reading a pin wrong (checking for it to be high...
<re_irc> ... instead of low), unfortunately writing flash still does not work...
<re_irc> <@f​irefrommoonlight:m​atrix.org> Nice!
<re_irc> <@f​irefrommoonlight:m​atrix.org> I've made 0 progress on my end
<re_irc> <@b​urrbull:m​atrix.org> Can someone also spend time to review my changes in `svd-parser`? https://github.com/rust-embedded/svd/pulls
<re_irc> <@b​urrbull:m​atrix.org> Full work https://github.com/rust-embedded/svd/tree/roxmltree
fabic has quit [Ping timeout: 258 seconds]
<re_irc> <@b​urrbull:m​atrix.org> therealprof: I forgot this during rebase https://github.com/stm32-rs/stm32f4xx-hal/pull/336
<re_irc> <@b​urrbull:m​atrix.org> Several periphs in f4xx-hal (Serial, Spi, Crc32) don't use rcc Reset on start, only Enable. Is it normal?
<re_irc> <@t​halesfragoso:m​atrix.org> burrbull: I think a reset would be preferable, probably a oversight
<re_irc> <@w​illeml:m​atrix.org> reg.bitfield().clear_bit() is the same as setting the bit to 0 or false right?
<re_irc> <@b​urrbull:m​atrix.org> `reg.modify(|_,w| w.bitfield().clear_bit())` if you about pacs
<re_irc> <@w​illeml:m​atrix.org> Awesome, thanks
<re_irc> <@b​urrbull:m​atrix.org> thalesfragoso: Same with GPIOs. What about them?
astroanax has quit [*.net *.split]
Rahix has quit [*.net *.split]
<re_irc> <@t​halesfragoso:m​atrix.org> Yeah, probably reset them too
astroanax has joined #rust-embedded
bendemctl has quit [*.net *.split]
x56 has quit [*.net *.split]
Rahix has joined #rust-embedded
x56 has joined #rust-embedded
<re_irc> <@w​alther:k​apsi.fi> hello hi! wondering if anyone has successfully used WSL2 for rust-embedded purposes? it seems possible that WSL doesn't have proper USB support yet, so e.g. flashing things could be a dead-end right now https://github.com/microsoft/WSL/issues/2195
mightypork has quit [Quit: ZNC - https://znc.in]
mightypork has joined #rust-embedded
mightypork has quit [Quit: ZNC - https://znc.in]
mightypork has joined #rust-embedded
neceve has joined #rust-embedded
<re_irc> <@m​athias_koch:m​atrix.org> Hi! I am trying to cross-build a project for Raspberry Pi using `cross`, but i am running into some libUSB issues, and could really use some pointers on where to look?
<re_irc> <@m​athias_koch:m​atrix.org> I am building with `Cross.toml`:
<re_irc> <@m​athias_koch:m​atrix.org> ```toml
<re_irc> <@m​athias_koch:m​atrix.org> [build]
<re_irc> <@t​iwalun:m​atrix.org> There is some documentation for cross-compiling on the probe.rs website: https://probe.rs/docs/library/crosscompiling/
<re_irc> <@t​iwalun:m​atrix.org> Maybe that can help.
<re_irc> <@m​athias_koch:m​atrix.org> Hmm.. Yeah, with just that i am getting `libusb-1.0.so.0: cannot open shared object file: No such file or directory`:/
<re_irc> <@j​amesmunns:m​atrix.org> You may need to modify the image to have libusb installed when cross compiling
<re_irc> <@m​athias_koch:m​atrix.org> I think i do that with the dockerfile above?
<re_irc> <@j​amesmunns:m​atrix.org> Often the compilation needs the library (or more likely headers) installed to figure out how to dynamically link later.
<re_irc> <@j​amesmunns:m​atrix.org> Oh.
<re_irc> <@j​amesmunns:m​atrix.org> yes.
<re_irc> <@j​amesmunns:m​atrix.org> hm. It's been a while since I did cross compiling. Not sure why that doesn't work, apologies.
<re_irc> <@m​athias_koch:m​atrix.org> No worries :)
fabic has joined #rust-embedded
<re_irc> <@h​egza:m​atrix.org> Walther: I run a course on such things. This is the reason I recommend against using WSL :D
<re_irc> <@h​egza:m​atrix.org> If there's a solution let me know :)
<re_irc> <@j​amesmunns:m​atrix.org> Yeah, in Ferrous' embedded trainings, we also advise against it, which is why we test our Windows instructions as well.
<re_irc> <@j​amesmunns:m​atrix.org> (we suggest native windows for building and flashing, at least)
<re_irc> <@a​damgreig:m​atrix.org> kinda a shame, I wonder if libusb on WSL could be made to work
<re_irc> <@j​amesmunns:m​atrix.org> You could *probably* build the elfs in WSL, and use probe-run (or cargo-flash) directly from the windows side.
<re_irc> <@a​damgreig:m​atrix.org> jamesmunns: yea, but I guess why bother when probe-run does the building for you
<re_irc> <@j​amesmunns:m​atrix.org> probe-run doesn't.
<re_irc> <@j​amesmunns:m​atrix.org> (cargo-embed does)
<re_irc> <@a​damgreig:m​atrix.org> it triggers a cargo build, doesn't it?
<re_irc> <@j​amesmunns:m​atrix.org> we usually just make probe-run the runner, so it's post-cargo.
<re_irc> <@a​damgreig:m​atrix.org> sure
<re_irc> <@j​amesmunns:m​atrix.org> it just takes the elf as an arg
<re_irc> <@a​damgreig:m​atrix.org> ah, I see what you mean
<re_irc> <@a​damgreig:m​atrix.org> anyway "cargo run" would do it
<re_irc> <@j​amesmunns:m​atrix.org> yeah
<re_irc> <@j​amesmunns:m​atrix.org> you lose that if you build in WSL and run on Win
<re_irc> <@a​damgreig:m​atrix.org> I wonder if libusb inside WSL could be told to use windows USB APIs instead of linux or something
<re_irc> <@j​amesmunns:m​atrix.org> ¯\_(ツ)_/¯
<re_irc> <@a​damgreig:m​atrix.org> you don't actually need USB passthrough to the linux kernel if your application can somehow access the windows api directly... idk
<re_irc> <@a​damgreig:m​atrix.org> anyway I have never used WSL so I know nothing
emerent has quit [Ping timeout: 256 seconds]
emerent has joined #rust-embedded
starblue1 has quit [Quit: WeeChat 2.3]
fabic has quit [Ping timeout: 246 seconds]
starblue has joined #rust-embedded
<re_irc> <@w​alther:k​apsi.fi> right, if this can be made to run under windows i don't mind that either. (i haven't had a desktop linux for the past ... 3 years now? most of my linux things are on server end these days)
<re_irc> <@w​alther:k​apsi.fi> i'm not sure probe-rs, cargo-embed, etc work for the teensy though
<re_irc> <@f​irefrommoonlight:m​atrix.org> willeml: Regrettably, I'm going to shelve the QSPI stuff for now. I was interested since one of the dev boards I bought (stm32wb55) to test with RF has a QSPI flash wired up, and I wanted to see if I could get it working. A device that's almost ready for prediction (Why I can't dedicate the time to...
<re_irc> ... QSPI) uses a QSPI chip I have wired up in normal SPI mode. Ideally would change that to QSPI mode, but requires a board respin to wire up the other pins.
<re_irc> <@f​irefrommoonlight:m​atrix.org> From what I can tell, the stm32H7xx-hal and F7xx-hal QSPI modules are compliant with the RMs, for indirect mode. The module I wrote essentially does the same writes, but with a different structure and API, and has some broken memory-mapped-read code
<re_irc> <@f​irefrommoonlight:m​atrix.org> In the future, when onboard flash isn't enough, QSPI in memory-mapped mode seems like the way to go, so I hope you (or later, I) figure this out. The trouble I was having might have had to do with the flash chip programming instead of MCU code, but I don't know
<re_irc> <@f​irefrommoonlight:m​atrix.org> For some context, the one on the dev board is a Cypress, and the one on my production board wired in normal SPI mode is a WinbondW25
<re_irc> <@f​irefrommoonlight:m​atrix.org> Of note, it seems like for a lot of MCUs, it's cheaper to expand storage with external modules like this vice more onboard; STM32 price increases significantly with the higher flash and ram variants. But onboard will be faster
mightypork_ has joined #rust-embedded
mightypork has quit [Ping timeout: 246 seconds]
neceve has quit [Ping timeout: 246 seconds]
<re_irc> <@w​illeml:m​atrix.org> Sad to hear, but yeah, I will still keep chipping away at this, I have already gotten quite far (memory mapped mode appears to be fully functional now) the only thing left is writing to the chip and erasing it
<re_irc> <@w​illeml:m​atrix.org> And I am pretty sure that the chip I am using is compatible with the wind bond w25
<re_irc> <@f​irefrommoonlight:m​atrix.org> Awesome!
<re_irc> <@f​irefrommoonlight:m​atrix.org> That chip's working great for me btw in normal mode
<re_irc> <@f​irefrommoonlight:m​atrix.org> Simple API
<re_irc> <@f​irefrommoonlight:m​atrix.org> Clear datasheet
<re_irc> <@f​irefrommoonlight:m​atrix.org> The Cypress one is harder to decypher
<re_irc> <@p​yaillet:m​atrix.org> Hi there !
<re_irc> <@p​yaillet:m​atrix.org> I'm beggining with embedded rust (especially #![no_std]).
<re_irc> <@p​yaillet:m​atrix.org> How do you convert an u8 to an str without std ?
<Shell> core::str::from_utf8?
<re_irc> <@j​amesmunns:m​atrix.org> Walther: You probably need some tooling to convert the elf to the format that the bootloader expects. Have you seen this repo? https://github.com/mciantyre/teensy4-rs ?
<re_irc> <@j​amesmunns:m​atrix.org> (I think all that stuff should work on Windows too, but I haven't tried it personally)
<re_irc> <@w​alther:k​apsi.fi> jamesmunns: that's exactly the repo i'm using, yes - it instructs using `cargo objcopy` and `teensy_loader_cli`, no mention of the `probe-rs` etc ecosystem
<re_irc> <@j​amesmunns:m​atrix.org> Ah, gotcha!
<re_irc> <@j​amesmunns:m​atrix.org> The approach should be the same, you could do all the steps to prepare the hex file in WSL, then use the teensy_loader_cli on windows
<re_irc> <@j​amesmunns:m​atrix.org> AFAIK, no, the tools I mentioned won't work with the teensy4 (at least as-is), because they all expect to talk to a debugger, and the teensy4 doesn't expose debugger pins - it instead uses an external bootloader chip.
<re_irc> <@w​alther:k​apsi.fi> yeah - although i have no idea how i would approach building `teensy_loader_cli` on windows... the releases page on github has a latest build in 2016, no support for the newer boards
<re_irc> <@j​amesmunns:m​atrix.org> https://www.pjrc.com/teensy/loader_cli.html
<re_irc> <@j​amesmunns:m​atrix.org> maybe they linked an old repo?
<re_irc> <@j​amesmunns:m​atrix.org> Seems relatively up to date: https://github.com/PaulStoffregen/teensy_loader_cli
<re_irc> <@w​alther:k​apsi.fi> i specifically said _releases_ though - sure, if you're able to compile from source, the source is up to date
<re_irc> <@j​amesmunns:m​atrix.org> Ah, gotcha :)
<re_irc> <@j​amesmunns:m​atrix.org> https://www.pjrc.com/teensy/loader.html, the gui tool, should also work.
<re_irc> <@j​amesmunns:m​atrix.org> Walther: I missed that! Long day, sorry for not being helpful.
<re_irc> <@w​alther:k​apsi.fi> yeah, it's possible i have to go the gui route, but it'll be annoying to click through that every time after running cargo build
<re_irc> <@w​alther:k​apsi.fi> had no issues building the latest `teensy_loader_cli` under WSL2, but i don't have VisualStudio etc set up in Windows land - and no idea if it would even build, finding the various dependencies like `libusb` etc could end up trickier than under linux
<re_irc> <@w​alther:k​apsi.fi> wonder what it would take to get the teensy4 into supported devices for `cargo-flash` / `cargo-embed` / whichever projects are considered the "de facto" best user experience in rust embedded
<re_irc> <@w​alther:k​apsi.fi> it's a wonderful board, i'd love to see it supported by the great tools
neceve has joined #rust-embedded
<re_irc> <@j​amesmunns:m​atrix.org> You'd need to add support for flashing via bootloader (none of those tools do that yet), and a method for getting defmt logs over the USB serial port (possible but not generally done yet)
<re_irc> <@d​irbaio:m​atrix.org> flashing over a bootloader and flashing over SWD are fundamentally very different
<re_irc> <@d​irbaio:m​atrix.org> i don't think the first is in scope of probe-rs/cargo-flash
<re_irc> <@j​amesmunns:m​atrix.org> It takes more "usage procedure" hints from arduino (bootloader, serial console) than most other dev boards (via SWD debugger)
<re_irc> <@d​irbaio:m​atrix.org> plus via SWD you can read/write ram, debug with breakpoints and stuff
<re_irc> <@j​amesmunns:m​atrix.org> The former and latter are maybe in scope for probe-run, but not planned any time soon afaik
<re_irc> <@d​irbaio:m​atrix.org> if you're doing "real" development you want to use SWD, it's just wayyyyy better
<re_irc> <@j​amesmunns:m​atrix.org> Basically, we haven't decided NOT to support that use case, but also have no plans to do it yet.
<re_irc> <@w​alther:k​apsi.fi> yeah. it's still a bit of a shame, considering how amazing of a board the teensy4 is. Cortex-M7 at 600 MHz, proper FPU math, etc
<re_irc> <@t​iwalun:m​atrix.org> For cargo-flash supporting bootloaders would be in scope I think, for probe-rs it's too different.
<re_irc> <@w​alther:k​apsi.fi> and yeah of course, no judgement intended! people are busy and prioritization needs to happen because time is limited etc
<re_irc> <@j​amesmunns:m​atrix.org> The imxrt are stonking powerful and complicated chips
<re_irc> <@j​amesmunns:m​atrix.org> Just getting them to boot from flash is a complicated process
<re_irc> <@d​irbaio:m​atrix.org> also flashing via SWD is mostly standardized
<re_irc> <@d​irbaio:m​atrix.org> flashing via bootloaders sucks, every manufacturer does its own crazy hacks and shit protocols
<re_irc> <@j​amesmunns:m​atrix.org> Their SVD files generate over 1M lines of PAC code.
<re_irc> <@d​irbaio:m​atrix.org> lol
<re_irc> <@j​amesmunns:m​atrix.org> dirbaio: The challenge is the imxrt usually doesn't have ANY on chip flash
<re_irc> <@d​irbaio:m​atrix.org> nothing that some arrayifying and blockifizing can't fix >_>
<re_irc> <@j​amesmunns:m​atrix.org> It has its own hw bootloader and config you need just to get it to work with different kinds of spi/qspi/hyperflash
<re_irc> <@d​irbaio:m​atrix.org> same with the pico
<re_irc> <@d​irbaio:m​atrix.org> but you can still flash it via swd
<re_irc> <@w​alther:k​apsi.fi> yeah... i know i would probably have an easier time rust tooling wise if i used one of the more-used-in-rust-circles board like blue pill or what have you. but on the other hand, i have a bunch of teensies lying around and i really, really enjoy the idea of having so much raw compute power available
<re_irc> <@j​amesmunns:m​atrix.org> Totally understandable!
<re_irc> <@j​amesmunns:m​atrix.org> Pjrc and rust folks just have diverging goals
<re_irc> <@j​amesmunns:m​atrix.org> Or, diverging strategies, I guess
<re_irc> <@w​alther:k​apsi.fi> i know there's also plenty of joy in making things work within limited constraints too, but especially for these audio-related projects i would love to have those capabilities. i guess i could also look around for other boards
<re_irc> <@j​amesmunns:m​atrix.org> But the teensy4 actually hard-wires the SWD lines to their external bootloader chip. No test points or anything
<re_irc> <@j​amesmunns:m​atrix.org> So you sorta have to use their tooling and ecosystem, to some depth.
<re_irc> <@j​amesmunns:m​atrix.org> Or adapt the existing rust tools to play nice in that ecosystem, as the teensy4-rs folks are.
<re_irc> <@w​alther:k​apsi.fi> yep yep, understandable. things are complex!
<re_irc> <@j​amesmunns:m​atrix.org> I have used the imxrt-evk boards for rust development in the bast, but they are much bigger and more expensive boards
<re_irc> <@w​alther:k​apsi.fi> i guess a question from the other direction would be - what are some known well-supported boards in the rust ecosystem, with the most compute available? (as opposed to optimizing for lowest cost, like blue pills etc)
<re_irc> <@d​irbaio:m​atrix.org> stm32h7 probably
<re_irc> <@j​amesmunns:m​atrix.org> Walther: Probably chips in the stm32h7 family
<re_irc> <@j​amesmunns:m​atrix.org> WeAct makes a nice cheap one, any of the H7 nucleos are also going to be nice AND CHEAP.
<re_irc> <@j​amesmunns:m​atrix.org> Or, honestly the rp2040 will probably nice and powerful as well (not as much as the H7 tho, but cheaper), but it's not really "daily driver ready" yet, but I can see it being that way in a year.
<re_irc> <@w​alther:k​apsi.fi> yeah - that's the thing, i wouldn't necessarily be all that concerned about unit price at all, if i could just get something with a) lots of audio-capable compute, so proper FPU math etc b) excellent rust tooling support
<re_irc> <@j​amesmunns:m​atrix.org> H7.
<re_irc> <@j​amesmunns:m​atrix.org> Hands down best perf+rust support combination
<re_irc> <@d​irbaio:m​atrix.org> don't get a multicore one though ☠️
<re_irc> <@j​amesmunns:m​atrix.org> Yeah, the WeAct 743 board is single core at 480 MHz, with an fpu
<re_irc> <@j​amesmunns:m​atrix.org> Not sure if it has hw f64 support like the imxrt1062 does
<re_irc> <@j​amesmunns:m​atrix.org> But definitely an f32 fpu
<re_irc> <@j​amesmunns:m​atrix.org> 1Meg RAM, 2Meg internal flash, like 16meg external flash
<re_irc> <@d​irbaio:m​atrix.org> if f64 needed for good audio stuff? 🤔
<re_irc> <@j​amesmunns:m​atrix.org> I dunno, my customer was doing motor control stuff
<re_irc> <@j​amesmunns:m​atrix.org> Only reason I know it CAN do that stuff.
<re_irc> <@j​amesmunns:m​atrix.org> That 1062 chip is a beast though.
<re_irc> <@j​amesmunns:m​atrix.org> And I think they make a 1ghz version too, the 1170?
<re_irc> <@j​amesmunns:m​atrix.org> Just nutter butters.
<re_irc> <@j​amesmunns:m​atrix.org> "we want a cortex-a, but we hate the idea of an MMU"
<re_irc> <@j​amesmunns:m​atrix.org> "have we got the chip for you!"
<re_irc> <@j​amesmunns:m​atrix.org> Anyway, good luck!
fabic has joined #rust-embedded
<re_irc> <@w​alther:k​apsi.fi> thanks for all the help! 🧡
<re_irc> <@p​inkhatbeard:m​atrix.org> I have been struggling for most of a week to send anything with the modem on an nrf9160 using Rust. I am clearly not understanding something pretty basic. At this point I'm not even able to successfully send anything with the [42tech/JPster demo](https://github.com/42-technology-ltd/nrf9160-demo/). If anyone...
<re_irc> ... has any advice or wants to give me an ELI5, I would greatly appreciate it. Feel free to redirect me if this should be in the nRF Rust room instead.
<re_irc> <@d​irbaio:m​atrix.org> you'll need to give more info than "it doesn't work please help" :)
<re_irc> <@d​irbaio:m​atrix.org> what code are you trying, how are you flashing it, what error are you getting
<re_irc> <@p​inkhatbeard:m​atrix.org> dirbaio: Ha. Fair enough. Just working with the `nrf9160-demo` code, I get an error when trying to [connect](https://github.com/42-technology-ltd/nrf9160-demo/blob/master/src/main.rs#L505)
<re_irc> <@p​inkhatbeard:m​atrix.org> Making socket..
<re_irc> <@p​inkhatbeard:m​atrix.org> Connecting to jsonplaceholder.typicode.com..
<re_irc> <@p​inkhatbeard:m​atrix.org> Got Err(Nrfxlib(Nordic("tls_dns", 51, 0))) after 0.024142 seconds
<re_irc> <@p​inkhatbeard:m​atrix.org> DEBUG - Connecting via TLS to jsonplaceholder.typicode.com:443
<re_irc> <@f​irefrommoonlight:m​atrix.org> Is bootloader flashing was dfu-util and CubeProgranmer do? Where you run cargo objcopy to make a .bin file, then flash using one of those tools?
<re_irc> <@d​irbaio:m​atrix.org> yep
<re_irc> <@f​irefrommoonlight:m​atrix.org> For stm, you also need to pull boot 0 high at reset or plug-in, and use zadig or something to install drivers
<re_irc> <@f​irefrommoonlight:m​atrix.org> Sweet
<re_irc> <@d​irbaio:m​atrix.org> if you're flashing via uart/usb/i2c/whatever instead of swd, you're using a bootloader
<re_irc> <@f​irefrommoonlight:m​atrix.org> Gotcha. I've only done it with USB
<re_irc> <@f​irefrommoonlight:m​atrix.org> Works well, but there's a process
<re_irc> <@f​irefrommoonlight:m​atrix.org> Ie setting up the tools I posted about
<re_irc> <@f​irefrommoonlight:m​atrix.org> I have a program that automated it for firmware updates, where you download a standalone exe that includes the firmware to flash, dfu-util, and a script to run it
<re_irc> <@f​irefrommoonlight:m​atrix.org> But the user still needs to run Zadig etc first to install drivers for USB, and press a button to get boot 0 high
<re_irc> <@d​irbaio:m​atrix.org> pinkhatbeard: searching nrfxlib for "tls_dns" shows this
<re_irc> <@d​irbaio:m​atrix.org> v
<re_irc> <@d​irbaio:m​atrix.org> means getaddrinfo is failing (ie, dns resolution)
<re_irc> <@d​irbaio:m​atrix.org> return value 51, errno 0
<re_irc> <@d​irbaio:m​atrix.org> (why does it return the error as an int like that? it's not very friendly)
<re_irc> <@p​inkhatbeard:m​atrix.org> dirbaio: That's been a lot of the problem...tying to find what the `errno` means.
<re_irc> <@d​irbaio:m​atrix.org> ENETUNREACH: network unreachable
<re_irc> <@p​inkhatbeard:m​atrix.org> dirbaio: Wow. It's embarrassing how long I tried to search for what the errno meant and you just found it in 60 seconds.
<re_irc> <@d​irbaio:m​atrix.org> maybe no network coverage, maybe a problem with your sim (deactivated, expired, no data)
<re_irc> <@d​irbaio:m​atrix.org> with AT commands you probably can see more info
<re_irc> <@p​inkhatbeard:m​atrix.org> dirbaio: Coverage and sim should be fine. If I load the demo code from Nordic, it works fine. I just can't get anything from Rust work. I stopped trying to troubleshoot my code and have been only trying to get the `nrf9160-demo` project to work since at least I know it should work.
<re_irc> <@d​irbaio:m​atrix.org> could very well be a problem with `nrf9160-demo`
<re_irc> <@d​irbaio:m​atrix.org> seems to have some sort of menu
<re_irc> <@p​inkhatbeard:m​atrix.org> dirbaio: Yeah, the menu allows you to run a few tests or send it AT commands.
<re_irc> <@d​irbaio:m​atrix.org> maybe you're not doing `on`? or maybe you're trying to connect before it has actually connected to the network?
fabic has quit [Ping timeout: 252 seconds]
<re_irc> <@p​inkhatbeard:m​atrix.org> That's what I assumed in my code, which is why I was attempting to only work with the demo code since it should work. However, the demo code is out of sync with the nrfxlib, so maybe something more drastic changed and it's not giving the correct error.
<re_irc> <@d​irbaio:m​atrix.org> maybe wrong lte-m / nb-iot mode? depending on your area only one might work
<re_irc> <@d​irbaio:m​atrix.org> what do you see with "stat"?
<re_irc> <@p​inkhatbeard:m​atrix.org> The mode is correct, it works perfectly with the nordic asset-tracker.
<re_irc> <@p​inkhatbeard:m​atrix.org> stat >
<re_irc> <@p​inkhatbeard:m​atrix.org> > +CFUN: 0
<re_irc> <@p​inkhatbeard:m​atrix.org> > +CEREG: 0,4,"FFFE","FFFFFFFF",7
<re_irc> <@p​inkhatbeard:m​atrix.org> > %XSNRSQ: 127,32767,255
<re_irc> <@d​irbaio:m​atrix.org> CFUN=0 means the modem is off, are you doing `on`?
<re_irc> <@p​inkhatbeard:m​atrix.org> dirbaio: Let me create a minimal example of my own. I think the `nrf9160-demo` code is adding an extra layer of confusion.
<re_irc> <@d​irbaio:m​atrix.org> you just need to do `on`
<re_irc> <@p​inkhatbeard:m​atrix.org> > on >
<re_irc> <@p​inkhatbeard:m​atrix.org> Configure GNSS antenna...
<re_irc> <@p​inkhatbeard:m​atrix.org> GNSS antenna enabled.
<re_irc> <@p​inkhatbeard:m​atrix.org> DEBUG - Configuring XMAGPIO pins for 1574-1577 MHz
<re_irc> <@d​irbaio:m​atrix.org> O_o
<re_irc> <@p​inkhatbeard:m​atrix.org> That error suggests that I need to change the mode, however, when I attempt to use the mode command the way it seems it needs to be used....I get
<re_irc> <@p​inkhatbeard:m​atrix.org> mode ltem >
<re_irc> <@p​inkhatbeard:m​atrix.org> Enabling LTE-M.
<re_irc> <@p​inkhatbeard:m​atrix.org> Err running AT%XSYSTEMMODE=1,0,0,0: AtError(Error)
<re_irc> <@p​inkhatbeard:m​atrix.org> > %XSYSTEMMODE: 1,0,0,0
<re_irc> <@d​irbaio:m​atrix.org> maybe you can only do it with modem off
<re_irc> <@d​irbaio:m​atrix.org> id' rust read through the AT commands docs to understand what they're doing and what are the right ones to make it work...
richbridger has quit [*.net *.split]
dirbaio2 has quit [*.net *.split]
bpye has quit [*.net *.split]
dkm has quit [*.net *.split]
agg has quit [*.net *.split]
jasperw has quit [*.net *.split]
richbridger has joined #rust-embedded
dkm has joined #rust-embedded
bpye has joined #rust-embedded
dirbaio2 has joined #rust-embedded
jasperw has joined #rust-embedded
agg has joined #rust-embedded
<re_irc> <@p​inkhatbeard:m​atrix.org> dirbaio: Okay. I'll give it a shot again. I was having trouble find anything that resembled an order of operations which is how I went back to that demo code. I'll keep stepping through and see where I can get.
<re_irc> <@p​inkhatbeard:m​atrix.org> Unfortunately I've got a deadline on Friday for a working demo...haha. I suppose that's what they get for changing the requirements to cellular last week.
<re_irc> <@p​inkhatbeard:m​atrix.org> Thank you.
richbridger has quit [Max SendQ exceeded]
richbridger has joined #rust-embedded
<re_irc> <@d​irbaio:m​atrix.org> > changing the requirements to cellular last week.
<re_irc> <@d​irbaio:m​atrix.org> lol, RIP
mightypork_ has quit [Quit: ZNC - https://znc.in]
mightypork has joined #rust-embedded
mightypork has quit [Quit: ZNC - https://znc.in]
mightypork has joined #rust-embedded
mightypork has quit [Client Quit]
mightypork has joined #rust-embedded
neceve has quit [Ping timeout: 246 seconds]
<re_irc> <@s​ympatron:m​atrix.org> I'm kind of frustrated with Rust right now :(
<re_irc> <@s​ympatron:m​atrix.org> I'm trying to write device drivers, but this seems almost impossible without alloc. For example if I want to have a method like `pub fn send(&mut self, data: &[u8])` to let users send arbitrary length data to a device (via SPI, I²C, UART, doesn't matter) and the driver needs to send this data + some header or...
<re_irc> ... footer to the device it's simply not easily possible in Rust today with `embedded-hal`. Especially with I²C. I didn't realize how much I used variable sized stack arrays in C until I didn't have them anymore. How can you solve this? I would love to translate my codebase to Rust, but it's an extremely painful experience for me at the...
<re_irc> ... moment
<re_irc> <@s​ympatron:m​atrix.org> </rant>
<re_irc> <@s​ympatron:m​atrix.org> It's even more annoying that you are kind of forced to not use `alloc`, because it's still not available on stable and the stabilization seems to be stuck ☹️
<re_irc> <@s​ympatron:m​atrix.org> Sadly embedded doesn't seem to be a very high priority for the Rust core team, although I think this is by far the most interesting part of Rust
<re_irc> <@t​halesfragoso:m​atrix.org> alloc doesn't seem a good solution for your case anyway
<re_irc> <@t​halesfragoso:m​atrix.org> you probably want e-h to support write_vectored
<re_irc> <@f​irefrommoonlight:m​atrix.org> Almost done with my first embedded project. Firmware, updater, and PC software it can interface with over USB are all in Rust
<re_irc> <@f​irefrommoonlight:m​atrix.org> Need to do some testing, finishing touches on the enclosure, and figure out how to get MCUs
<re_irc> <@f​irefrommoonlight:m​atrix.org> I have 2 left
<re_irc> <@f​irefrommoonlight:m​atrix.org> sympatron: Why not stream word-by-word?
<re_irc> <@s​ympatron:m​atrix.org> thalesfragoso: `write_iter` would help a little bit, but no hal seems to implement it
<re_irc> <@s​ympatron:m​atrix.org> firefrommoonlight: Firstly this doesn't work for I2C (at least with e-h). Secondly it is even more difficult to receive arbitrary length data
<re_irc> <@f​irefrommoonlight:m​atrix.org> What *specific* problem are you trying to solve, eg what data are you sending to what device (or receiving from)
<re_irc> <@t​halesfragoso:m​atrix.org> sympatron: I think there's a default implmentation
<re_irc> <@f​irefrommoonlight:m​atrix.org> What type of data is arbitrary length? You could chunk it
<re_irc> <@s​ympatron:m​atrix.org> thalesfragoso: e-h 0.2 does not. But I just saw that 1.0 has a new `transactional` module. This could probably solve some of my problems
<re_irc> <@f​irefrommoonlight:m​atrix.org> Something to keep in mind: MCUs may have things like FIFO buffers etc for various comm protocols. Ie they will only hold one word in regs at a time. You can keep reading or writing until you or the device is out of data. There's no inerrant limitation to rust that would force you to need an allocator. I...
<re_irc> ... guess I don't understand what you're hitting.
<re_irc> <@t​halesfragoso:m​atrix.org> sympatron: https://docs.rs/embedded-hal/0.2.5/src/embedded_hal/blocking/spi.rs.html#87-105
<re_irc> <@f​irefrommoonlight:m​atrix.org> What are you using EH for, in this specific case?
<re_irc> <@f​irefrommoonlight:m​atrix.org> I don't use it at all, for example, in that device I just posted, yet, it's Rust through and through
<re_irc> <@f​irefrommoonlight:m​atrix.org> And no allocator
<re_irc> <@s​ympatron:m​atrix.org> I use e-h because I want the driver to be hardware independent
<re_irc> <@f​irefrommoonlight:m​atrix.org> and does all sorts of SPI, I2C, and USB comms
<re_irc> <@f​irefrommoonlight:m​atrix.org> What is your *specific* task?
<re_irc> <@f​irefrommoonlight:m​atrix.org> My gut says you're trying to make something with a general API and undertermined used case
<re_irc> <@t​halesfragoso:m​atrix.org> I think they just want to write a driver...
<re_irc> <@s​ympatron:m​atrix.org> One example: I tried to refactor `spi-flash-rs` to not require `alloc` anymore. At the moment it relies heavily on `Vec`s.
<re_irc> <@f​irefrommoonlight:m​atrix.org> Ok. If you're trying to make stuff generic, maybe alloc is the answer
<re_irc> <@s​ympatron:m​atrix.org> This part is especially difficult, because the amount of data that has to be read from flash depends on some other data that was read from the chip
<re_irc> <@f​irefrommoonlight:m​atrix.org> Can you give a concrete use case?
<re_irc> <@f​irefrommoonlight:m​atrix.org> Ie, a general user is using that crate to do *what* task, and doesn't want to use alloc for *x* reason
<re_irc> <@s​ympatron:m​atrix.org> I want to use it, and I don't want to use alloc because it is not stable
<re_irc> <@f​irefrommoonlight:m​atrix.org> We're not on the same wavelength
<re_irc> <@s​ympatron:m​atrix.org> :D
<re_irc> <@f​irefrommoonlight:m​atrix.org> Btw, cool crate agg
<re_irc> <@g​rantm11235:m​atrix.org> Are you just using alloc to add a header and a footer to some data before sending it via spi/uart/whatever?
<re_irc> <@s​ympatron:m​atrix.org> That's one case. Another one would be escaping.
<re_irc> <@a​damgreig:m​atrix.org> sympatron: for something akin to dynamically sized stack allocated arrays, can you just allocate a large array on the stack and only use some of it? or use heapless's vec?
<re_irc> <@s​ympatron:m​atrix.org> Currently I can only send data exactly as I get it from a user if it's not `&mut`. I couldn't even allocate an equally sized array to make changes to the data before sending
<re_irc> <@a​damgreig:m​atrix.org> heapless's vec especially is very convenient
<re_irc> <@s​ympatron:m​atrix.org> I thought about that.
<re_irc> <@s​ympatron:m​atrix.org> But then I would set a hard limit for the maximum size and potentially waste a lot of stack size and maybe even blow the stack up
<re_irc> <@s​ympatron:m​atrix.org> A generic driver cannot know how much stack will be available
<re_irc> <@a​damgreig:m​atrix.org> you can choose how big the vec is at runtime though
<re_irc> <@a​damgreig:m​atrix.org> uh
<re_irc> <@a​damgreig:m​atrix.org> (no)
<re_irc> <@s​ympatron:m​atrix.org> The only viable solution I found was require the user to give some kind of scrap buffer to the driver on construction
<re_irc> <@a​damgreig:m​atrix.org> I guess that's a key difference to c's VLA
<re_irc> <@g​rantm11235:m​atrix.org> GrantM11235: For this case, you can simply send the header, the data, then the footer in 3 separate transactions
<re_irc> <@s​ympatron:m​atrix.org> That way they can decide how much space will be available and were in memory it is. But it's still more complicated than C
<re_irc> <@s​ympatron:m​atrix.org> GrantM11235: This would work for SPI and UART, but not I2C. At least with e-h 0.2. And it does not really work for receiving data
<re_irc> <@b​arafael:m​atrix.org> The MicroRust book seems to have some missing chapters which are actually low hanging fruit. There are some features like i2c which the crate actually supports. Or is there something blocking further work? I think this book is important
<re_irc> <@a​damgreig:m​atrix.org> sympatron: I wonder if you end up just needing a different design from the start for it to really make sense on embedded, I dunno
<re_irc> <@a​damgreig:m​atrix.org> i wrote spi-flash deliberately ignoring embedded use-cases because I had immediately plans to do it from std and wanted to support more in-depth sfdp parsing and the like
<re_irc> <@a​damgreig:m​atrix.org> often on embedded you already know the one or two flashes you're using specifically and just go ahead and use the one or two flash commands you need, I guess
<re_irc> <@a​damgreig:m​atrix.org> still maybe just a user-provided scratch buffer or something would be enough
<re_irc> <@f​irefrommoonlight:m​atrix.org> When building things - software, hardware, physical or digital products of any case, you need to start with the problem. Something a potential user or customer has a hard time with; engineering requirements; something you want to accomplish; a topic you're trying to learn more about. If you start...
<re_irc> ... building without this, you will run into this
<re_irc> <@f​irefrommoonlight:m​atrix.org> Building something with a general idea that it might be useful to someone in the future rarely works
<re_irc> <@j​amesmunns:m​atrix.org> This advice is generally correct, but less applicable to API design I find,. Particularly in widely applicable code like embedded-hal.
<re_irc> <@j​amesmunns:m​atrix.org> It can be easy to over-constrain to single (or a small subset) of applications.
<re_irc> <@j​amesmunns:m​atrix.org> but heck, for end projects, I spend a lot of time giving that same advice to clients :)
<re_irc> <@j​amesmunns:m​atrix.org> sympatron: for these kinds of problems, I tend to find myself using something like bbqueue's framed mode.
<re_irc> <@j​amesmunns:m​atrix.org> It allows you to alloc variable length data from a ring buffer, so very little wasted memory, and you can alloc from a static buffer.
<re_irc> <@j​amesmunns:m​atrix.org> I don't think it's likely for e-h to merge official support for bbqueue, but I do find it works really well with the embedded-dma traits.
<re_irc> <@j​amesmunns:m​atrix.org> (as bbqueue, at least in a branch that I am way overdue to merge, impl's the buffer traits).
<re_irc> <@f​irefrommoonlight:m​atrix.org> Regarding that approach and embedded-hal: I think the Readme could be more clear about what the scope is - it took me a while to GROK what that was, and it's common for new users to conflate it with rust embedded in general, or with MCU-specific HALs
<re_irc> <@j​amesmunns:m​atrix.org> https://docs.rs/bbqueue/0.4.12/bbqueue/framed/index.html
<re_irc> <@f​irefrommoonlight:m​atrix.org> (Ie embedded-hal does have a clear problem to solve, but many people misinterpret what it is)
<re_irc> <@j​amesmunns:m​atrix.org> firefrommoonlight: I bet they would *love* a PR that clarifies this!
<re_irc> <@f​irefrommoonlight:m​atrix.org> Hah fair
<re_irc> <@f​irefrommoonlight:m​atrix.org> I yield
<re_irc> <@j​amesmunns:m​atrix.org> We're just a bunch of volunteers in an official looking trench coat.
<re_irc> <@f​irefrommoonlight:m​atrix.org> The foundation of something great-to-be
<re_irc> <@f​irefrommoonlight:m​atrix.org> https://github.com/rust-embedded/embedded-hal/pull/293
<re_irc> <@d​irbaio:m​atrix.org> what are the requirements for?
<re_irc> <@d​irbaio:m​atrix.org> for EH traits, for HALs..?