<re_irc> <@g​rantm11235:m​atrix.org> Would this trait be useful to put in embedded_hal?
<re_irc> <@g​rantm11235:m​atrix.org> ```rust
<re_irc> <@g​rantm11235:m​atrix.org> pub trait Reconfigurable<T> {
<re_irc> <@g​rantm11235:m​atrix.org> fn with_reconfigured<R>(&mut self, f: impl FnOnce(&mut T) -> R) -> R;
<re_irc> <@g​rantm11235:m​atrix.org> fn reconfigure(self) -> T;
<re_irc> <@g​rantm11235:m​atrix.org> }
<re_irc> <@g​rantm11235:m​atrix.org> Here is what you can do with it https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=446832464a182d9756a9c488552f8263
fabic has joined #rust-embedded
emerent has quit [Ping timeout: 246 seconds]
emerent has joined #rust-embedded
starblue2 has joined #rust-embedded
starblue1 has quit [Ping timeout: 246 seconds]
<re_irc> <@f​irefrommoonlight:m​atrix.org> That's all quite abstract. What practical use case would you apply it to?
<re_irc> <@f​irefrommoonlight:m​atrix.org> ```rust
<re_irc> <@f​irefrommoonlight:m​atrix.org> Went with this syntax:
<re_irc> <@f​irefrommoonlight:m​atrix.org> Keeps the docs and imports more consistent; ie you don't have to worry about which ports you're using; less code to change when you reshuffle pins on new hardware spins etc
<re_irc> <@f​irefrommoonlight:m​atrix.org> let _sck = Pin::new(Port::A, 5, PinMode::Alt(5));
<re_irc> <@f​irefrommoonlight:m​atrix.org> Ie docs now for GPIO module are `Pin` struct, with supporting cfg enums, and fields in that struct's page
<re_irc> <@g​rantm11235:m​atrix.org> I was thinking about how to temporarily switch an spi from 8 bit to 16 bit words, but i think it would also be useful for switching a gpio from input to output and vice versa
<re_irc> <@f​irefrommoonlight:m​atrix.org> Also more consistent with other periph init, ie `StructName::new`
<re_irc> <@f​irefrommoonlight:m​atrix.org> It sounds like that could be a very useful backdoor for more flexibility when using EH traits. I'm not skilled enough with some of the trait magic used in your example to comment on the feasibility and limits
<re_irc> <@f​irefrommoonlight:m​atrix.org> But I see the use case now
<re_irc> <@f​irefrommoonlight:m​atrix.org> Although I wonder if this is a smell from how the word size is specified in the `eh` lib, and implementors, ie forcing you to fix words
<re_irc> <@f​irefrommoonlight:m​atrix.org> I believe you proposed addressing at that level earlier - what was the result?
<re_irc> <@f​irefrommoonlight:m​atrix.org> (Actually, my last comment would apply to the Spi thing, but not GPIO)
<re_irc> <@g​rantm11235:m​atrix.org> https://github.com/rust-embedded/embedded-hal/pull/295
<re_irc> <@g​rantm11235:m​atrix.org> That PR does technically limit some flexibility (for good reason imo), I am trying to figure out if I can add some of that flexibility back in a better way
<re_irc> <@f​irefrommoonlight:m​atrix.org> Updated Gpio generated docs module: https://docs.rs/stm32-hal2/0.2.11/stm32_hal2/gpio/index.html
<re_irc> <@f​irefrommoonlight:m​atrix.org> As my project code becomes more complex, little things like API consistency and clarify, breadth of structs, docs etc become more important for keeping things organized
<re_irc> <@f​irefrommoonlight:m​atrix.org> GrantM11235: I really like your reasoning in that PR, especially discussion re 16-bit words over 8-bit interfaces etc. It's nuanced. I don't have a strong opinion on which way you should proceed. Is there a particular driver you're attempting to create or modify that needs this functionality?
bpye has quit [Quit: The Lounge - https://thelounge.chat]
bpye has joined #rust-embedded
<re_irc> <@g​rantm11235:m​atrix.org> firefrommoonlight: I cleaned up my example a bit https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=9cccc892b67c9c28a3fb322eb56f75d7
<re_irc> <@g​rantm11235:m​atrix.org> When using an SPI LCD, you usually need to convert each 16 bit rgb565 pixel into big-endian bytes
<re_irc> <@g​rantm11235:m​atrix.org> With my example, you can get the same result by temporarily changing the spi to 16 bit mode and sending the pixels as-is
dcz has joined #rust-embedded
bpye has quit [Quit: The Lounge - https://thelounge.chat]
bpye has joined #rust-embedded
dcz_ has joined #rust-embedded
dcz has quit [Ping timeout: 255 seconds]
dcz_ has quit [Ping timeout: 255 seconds]
<re_irc> <@w​illeml:m​atrix.org> Does anyone know of a barcode reader library for rust embedded (either supporting an existing barcode scanner module or using a connected camera)
bpye has quit [Quit: The Lounge - https://thelounge.chat]
bpye has joined #rust-embedded
<re_irc> <@n​ihal.pasham:m​atrix.org> Quick question - just wanted to see if there are updates for this thread - https://github.com/rust-embedded/cortex-m-rt/pull/100
<re_irc> <@n​ihal.pasham:m​atrix.org> I'm working on a driver that writes a `blob of data` to internal flash. I was wondering if `ramfunctions` are necessary for my use-case.
<re_irc> <@n​ihal.pasham:m​atrix.org> - The reference manual for nrf52840 (my board) says `The CPU is halted if the CPU executes code from the flash while the NVMC is writing to the flash.` So, I guess this means it is ok to have `code in flash that writes to flash` i.e. copy data from one location in flash to another. Is my understanding...
<re_irc> ... correct here? I plan to use the nrf52840-hal for NVMC register access and configuration.
fabic has quit [Ping timeout: 255 seconds]
<re_irc> <@d​irbaio:m​atrix.org> > this means it is ok to have code in flash that writes to flash i.e. copy data from one location in flash to another.
<re_irc> <@d​irbaio:m​atrix.org> Yup! it just runs slower, but it doesn't break
dcz_ has joined #rust-embedded
creich has joined #rust-embedded
dcz_ has quit [Ping timeout: 258 seconds]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 268 seconds]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 258 seconds]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 265 seconds]
<re_irc> <@h​argonix:m​atrix.org> therealprof: its me again^^ so I've been playing around a bit with the version of microbit that's on git and i notice that when i just compile and flash:
<re_irc> <@h​argonix:m​atrix.org> #![deny(unsafe_code)]
<re_irc> <@h​argonix:m​atrix.org> #![no_std]
<re_irc> <@h​argonix:m​atrix.org> #![no_main]
<re_irc> <@u​bik:m​atrix.org> newam: still stuck with this thing Getting `Ok(Status(168))` when I call `Get_Status()`
<re_irc> <@u​bik:m​atrix.org> I must be doing something very wrong, the radio module doesn't even get started
<re_irc> <@t​herealprof:m​atrix.org> hargonix: Hah, interesting. Haven't tried that but I would consider that a bug.
<re_irc> <@h​argonix:m​atrix.org> I'm guessing it would be related to these pins being set up at these levels? https://github.com/nrf-rs/microbit/blob/main/microbit-common/src/v1/board.rs#L121-L133 but I haven't looked into the micro:bit schematic yet, maybe that's the correct setup to keep stuff turned off
<re_irc> <@t​herealprof:m​atrix.org> hargonix: Yes, very certainly related to the default levels.
<re_irc> <@t​hejpster:m​atrix.org> Is there a document that explains the branch and release model for cortex-m-rt? I'm confused as to where the backports into the 0.6 release series have come from.
<re_irc> <@h​enrik_alser:m​atrix.org> Yeah the schematic confirms this :)
<re_irc> <@h​argonix:m​atrix.org> henrik_alser: that the default elvels are right? Or that they are wrong?
<re_irc> <@h​enrik_alser:m​atrix.org> hargonix: That they should light up
<re_irc> <@h​argonix:m​atrix.org> in that case i'll fork quickly and check if i can fix it and shoot you a PR
<re_irc> <@t​herealprof:m​atrix.org> Should be an easy fix.
<re_irc> <@h​argonix:m​atrix.org> yup works after swapping default levels
<re_irc> <@h​argonix:m​atrix.org> just delete it i guess?
<re_irc> <@t​herealprof:m​atrix.org> Yes. With properly initialised pins there shouldn't be any flickering.
<re_irc> <@h​argonix:m​atrix.org> https://github.com/nrf-rs/microbit/pull/62 here's your PR then
<re_irc> <@a​damgreig:m​atrix.org> thejpster: Master branch contains all merged PRs which currently includes unreleased break-in changes for 0.7, so after the first such breaking change was merged we kept a 0.6.x branch where other changes can be cherrypicked and released as 0.6.12-
<re_irc> <@a​damgreig:m​atrix.org> So the commits in my 0.6 PR are all from master
<re_irc> <@t​hejpster:m​atrix.org> Ok. Shouldn't master have a 0.7 version number then? And can we write this down somewhere so I don't have to ask again in a month when I've forgotten ;)
<re_irc> <@a​damgreig:m​atrix.org> Doesn't get bumped until release, in part to make it easier to use patch in cargo but in part because we just don't bump the version number until the release
<re_irc> <@a​damgreig:m​atrix.org> In this case it's waited an unusually long time to actually get the breaking change released and hence so many backports...
<re_irc> <@a​damgreig:m​atrix.org> therealprof yay, simd32 type aliases merged into stdsimd
<re_irc> <@t​herealprof:m​atrix.org> Sweet. I had a few more chats on Zulip about adding various other stuff... There's quite some resistence to adding new funtionality "just like that" in a lot of different places. Still trying to figure out the way of least resistence and best order.
<re_irc> <@t​hejpster:m​atrix.org> I had the opposite problem - I couldn't patch because master was older than what was on cargo
<re_irc> <@w​illeml:m​atrix.org> Does anyone know of an rp2040 spi example?
<re_irc> <@t​herealprof:m​atrix.org> willeml: I think dirbaio has recently worked on getting a ST7789 SPI display running at warp speed.
<re_irc> <@w​illeml:m​atrix.org> (I know it's still wip, but the PR to add it in the hal mentions that they got an SPI oled display working)
<re_irc> <@w​illeml:m​atrix.org> therealprof: Hmm, do you know if the code is public? Ill just search github
<re_irc> <@t​herealprof:m​atrix.org> No idea, but pretty sure you might get an answer soon. 😉
<re_irc> <@w​illeml:m​atrix.org> Based on looking at github repos on profile, looks like not
<re_irc> <@t​herealprof:m​atrix.org> adamgreig: It's really curious that quite a few ARM instructions are not really used, like `SSAT` and `USAT`. I'm still struggling a bit to generate the correct patterns in LLVM, they're quite complex and the generation of immediate values to go into the instructions is anything but well documented.
<re_irc> <@w​illeml:m​atrix.org> Ooo, thanks
<re_irc> <@w​illeml:m​atrix.org> I guess I have to switch to embassy
<re_irc> <@w​illeml:m​atrix.org> Is there an advantage to embassy over "normal" hal like stm32f7xx-hal?
<re_irc> <@d​irbaio:m​atrix.org> I have the display one around too but it's using a whacky half-upgraded to e-g 0.7 fork of st7789, I should switch it back now that the author beat me to upgrading it haha
<re_irc> <@d​irbaio:m​atrix.org> hm
<re_irc> <@d​irbaio:m​atrix.org> async support (optional though, you can also use blocking i/o with embedded-hal), imo nicer/simpler api (much less generics and typestates), consistent API for all chips
<re_irc> <@d​irbaio:m​atrix.org> much faster builds due to stm32xxx-hals using too many macros
<re_irc> <@d​irbaio:m​atrix.org> stm32 is very work in progress though
<re_irc> <@d​irbaio:m​atrix.org> most of the basics (uart/spi/i2c) are done with blocking e-h apis, lately there's been lots of work on DMA to allow async apis too
<re_irc> <@w​illeml:m​atrix.org> I wonder how hard it would be to port the fmc display over to embassy
<re_irc> <@w​illeml:m​atrix.org> Oh yay, I can use my extra pico as a debugger
<re_irc> <@u​bik:m​atrix.org> newam: I believe this is what success looks like 😀
<re_irc> <@u​bik:m​atrix.org> still not sure why the ISR doesn't fire though 🤔
<re_irc> <@u​bik:m​atrix.org> i've enabled it in the NVIC
<re_irc> <@a​lmindor:m​atrix.org> > I have the display one around too but it's using a whacky half-upgraded to e-g 0.7 fork of st7789, I should switch it back now that the author beat me to upgrading it haha
<re_irc> <@a​lmindor:m​atrix.org> does embassy not "just work" with the default ST7789?
<re_irc> <@d​irbaio:m​atrix.org> Yea it does, I'm referring to the e-g upgrade
<re_irc> <@d​irbaio:m​atrix.org> When I did it, St7789 was still on eg 0.6 and I esnted 0.7
<re_irc> <@a​lmindor:m​atrix.org> ah yeah sorry, I didn't have any hw left to try on, I botched my pinetime and waited for the new red-v for ages
<re_irc> <@d​irbaio:m​atrix.org> But the spi part just worked thanks to the e-h traits yup
synack has left #rust-embedded [#rust-embedded]
<re_irc> <@w​illeml:m​atrix.org> Is it possible to use the rp2040 version of probe-rs and probe-run with picoprobe?
<re_irc> <@a​damgreig:m​atrix.org> i don't believe so, picoprobe uses its own custom USB protocol (instead of say implementing the standard cmsis-dap one), which probe-rs doesn't speak
<re_irc> <@a​damgreig:m​atrix.org> though i recall some people talking about either modifying picoprobe to use cmsis-dap or probe-rs to learn picoprobe, and you can certainly get some firmware for a pico that talks cmsis-dap instead
<re_irc> <@a​damgreig:m​atrix.org> (so you can use a pico as a probe with probe-rs)
<re_irc> <@t​herealprof:m​atrix.org> Yeah, there is a CMSIS-DAP implementation for the Pico though.
<re_irc> <@w​illeml:m​atrix.org> Argh, pico-debug does it, and you dont need the other pi to be connected, oh well, that was a large waste of time soldering stuff together because I don't have proper jumper cables...
<re_irc> <@w​illeml:m​atrix.org> I should have asked first lol
<re_irc> <@w​illeml:m​atrix.org> Measure twice cut once...
<re_irc> <@t​herealprof:m​atrix.org> Yeah, I just noticed that pico-debug could potentially work protocol-wise.
<re_irc> <@t​herealprof:m​atrix.org> Not sure that'll result in a frustration free experience though.
<re_irc> <@t​herealprof:m​atrix.org> Argh... `LLVM ERROR: Cannot select: t19: i32 = ARMISD::SSAT t2, Constant:i32<32>, t4`
<re_irc> <@t​herealprof:m​atrix.org> Why not, LLVM, why not?!?
<re_irc> <@w​illeml:m​atrix.org> https://github.com/majbthrd/DapperMime/ this is it I think
<re_irc> <@t​herealprof:m​atrix.org> willeml: Yes, that's the one. I've distributed a .uf2 binary a while ago since building wasn't superefficient. Not sure what has happened to the code since then.
<re_irc> <@w​illeml:m​atrix.org> Do you still have that binary?
<re_irc> <@w​illeml:m​atrix.org> Because (like it was building picoprobe) the building seems complicated, and also, even with gigabit internet, its still taking over 5 minutes to clone the git repos
<re_irc> <@w​illeml:m​atrix.org> Awesome, thank you, you still beat the git clone even though it had a 5 minute head start lol
<re_irc> <@t​herealprof:m​atrix.org> Yeah, I had the same experience, that's why I shared the binary. Use at your own risk. 😉
<re_irc> <@t​herealprof:m​atrix.org> I'm also not sure how much of the probe-rs changes have been upstreamed already.
<re_irc> <@w​illeml:m​atrix.org> Well, that uf2 + rp-probe-run worked to flash blinky
<re_irc> <@w​illeml:m​atrix.org> so I am happy
<re_irc> <@t​herealprof:m​atrix.org> My last status was that you need to use the fork to talk to the Pico since it's using a rare mutlidrop SWD implementation.
<re_irc> <@t​herealprof:m​atrix.org> Cool.
<re_irc> <@w​illeml:m​atrix.org> Very slow to flash though, and I think rtt might be not working, though I probably just don't have it configured right
<re_irc> <@d​khayes117:m​atrix.org> Its been a while since I've used my Hifive1, and I am going insane with this error. What am I missing here? I get an error with `cargo run --example pmp_methods
<re_irc> <@d​khayes117:m​atrix.org> Finished dev [unoptimized + debuginfo] target(s) in 0.02s
<re_irc> <@d​khayes117:m​atrix.org> Running `riscv64-unknown-elf-gdb -q -x gdb_init target/riscv32imac-unknown-none-elf/debug/examples/pmp-methods`
<re_irc> <@d​khayes117:m​atrix.org> error: could not execute process `riscv64-unknown-elf-gdb -q -x gdb_init target/riscv32imac-unknown-none-elf/debug/examples/pmp-methods` (never executed)
<re_irc> <@t​herealprof:m​atrix.org> Is `riscv64-unknown-elf-gdb` in your search patch?
<re_irc> <@d​khayes117:m​atrix.org> Hmm, good point. Let me check.