<re_irc>
<@willeml:matrix.org> Any ideas on why that is happening or how to fix it?
<re_irc>
<@willeml:matrix.org> Looking in the epd waveshare repo there is nothing different on the requirements for that arg then on the other pins it wants...
<re_irc>
<@willeml:matrix.org> Oh, nevermind, I know whats wrong, I have already used the pin somewhere else, that its not supposed to be, I was confused by the way the error was written out
<re_irc>
<@thalesfragoso:matrix.org> willeml: The drivers on embassy usually take the raw pins
<re_irc>
<@thalesfragoso:matrix.org> willeml: What chip are you using and why do you need DelayUs ? Depending on the configuration on the chip clocks it won't be very precise with microseconds
<re_irc>
<@thalesfragoso:matrix.org> If it's just the wait for some initialization that might be okay, but it's for like OneWire, you might need to change a few configs or use another driver for the delay
<re_irc>
<@willeml:matrix.org> Trying to use that driver for my eink display (2.9"
<re_irc>
<@willeml:matrix.org> )
<re_irc>
<@thalesfragoso:matrix.org> Ok, should be fine, but if you encounter some problem, keep in mind that the default config for some chips on embassy won't give a good microseconds precision
<re_irc>
<@willeml:matrix.org> I think it actually wanted ms
<re_irc>
<@thalesfragoso:matrix.org> ms should be fine
GenTooMan has quit [Ping timeout: 255 seconds]
GenTooMan has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> Btw, I use code from that repo for the 4.2" EPD. It's perhaps the highest quality EH driver I've run across, and the maintainer is happy to add stuff. Eg I was able to add partial refresh to the 4.2
<re_irc>
<@firefrommoonlight:matrix.org> Be aware if you're not already that EPDs are a pain to program for, unless you want a full refresh each update. All sorts of subtle things to worry about if you want to keep refresh speed down
<re_irc>
<@firefrommoonlight:matrix.org> Eg dividing the main buffer into sub-buffers and only updating the parts of the screen you need, making sure the parts you don't update don't show wonky stuff when you refresh etc
tokomak has quit [Read error: Connection reset by peer]
<re_irc>
<@willeml:matrix.org> firefrommoonlight: How do I actually tell it to update? Because either my init code is bad (and maybe I am not usng the correct spi mode or the correct spi frequency) but nothing is being displayed...
<re_irc>
<@willeml:matrix.org> Oh, I simply missed a step...
<re_irc>
<@willeml:matrix.org> I updated the frame but did not display it...
starblue2 has quit [Ping timeout: 268 seconds]
<re_irc>
<@firefrommoonlight:matrix.org> You'll get it. What's your use case?
<re_irc>
<@willeml:matrix.org> I don't know, just fooling around, it works now that I am actually telling it to display stuff, probably going to design a calculator
<re_irc>
<@firefrommoonlight:matrix.org> I wouldn't use EPD unless it's especially suited to a specific use case
<re_irc>
<@willeml:matrix.org> What other eink displays are there?
<re_irc>
<@firefrommoonlight:matrix.org> I'm referring to eink in general
starblue2 has joined #rust-embedded
<re_irc>
<@willeml:matrix.org> Oh, yeah, I mostly just wanted one to play with
emerent has quit [Ping timeout: 255 seconds]
<re_irc>
<@willeml:matrix.org> But I was thinking it would be cool for a calculator
<re_irc>
<@firefrommoonlight:matrix.org> I'm releasing a product in a few weeks that uses the EPD I mentioned before. I'm happy with it, but getting the code working was a huge pain
emerent has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> The use case is continuously displaying properties of water that don't change often, with a battery life measured in months
<re_irc>
<@willeml:matrix.org> Oh that sounds pretty cool
<re_irc>
<@willeml:matrix.org> Water quality/chemical content I guess?
<re_irc>
<@firefrommoonlight:matrix.org> pH, temp, ORP, and conductivity
<re_irc>
<@firefrommoonlight:matrix.org> Although technically compatible with any ion-selective probe
fabic has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> I don't want to discourage you too much - maybe it would work for your calculator - but know what you're getting into
<re_irc>
<@willeml:matrix.org> firefrommoonlight: Good to know that it’s going to be hard lol, will make me less discouraged when it fails, thanks for the warning, though, so far after realizing some stupid mistakes I have made, full refresh is easy
<re_irc>
<@willeml:matrix.org> Hopefully figuring out partial refresh will be easier
<re_irc>
<@willeml:matrix.org> Can I do a single pixel refresh?
<re_irc>
<@firefrommoonlight:matrix.org> Yea, with partial refresh
<re_irc>
<@willeml:matrix.org> Partial refresh is looking complicated from what I can see in the epd driver
<re_irc>
<@willeml:matrix.org> Guess I am going to have to go hunting for examples
<re_irc>
<@willeml:matrix.org> firefrommoonlight: ooo, just got partial refresh working, its really cool
<re_irc>
<@willeml:matrix.org> Now I just need to move this over to my risc-v board or something, so I can have more space
<re_irc>
<@firefrommoonlight:matrix.org> Nice
<re_irc>
<@willeml:matrix.org> To bad embassy isnt on risc-v yet, maybe I should try doing that sometime...
<re_irc>
<@willeml:matrix.org> Trying to find pinout for redboard red-v...
<re_irc>
<@willeml:matrix.org> Like, is it the same as the non red-v redboard?
<re_irc>
<@almindor:matrix.org> willeml almost, the LED is different, hifive1 crate has now support for that
<re_irc>
<@willeml:matrix.org> I saw the PR 👍️ but I am looking for the correct SPI gpio pins
<re_irc>
<@almindor:matrix.org> I just got mine a week ago, it's e310 and works just like hifive1-revb without the BT/WIFI and with only one led and usb-c connection
<re_irc>
<@almindor:matrix.org> same
<re_irc>
<@almindor:matrix.org> you can use the pin! or pins! macro for that it works
<re_irc>
<@willeml:matrix.org> So just match the pins used in the macro?
<re_irc>
<@almindor:matrix.org> e.g. ` let mosi = pin!(pins, spi0_mosi).into_iof0();`
<re_irc>
<@willeml:matrix.org> oh
<re_irc>
<@willeml:matrix.org> cool
<re_irc>
<@willeml:matrix.org> The problem is that I don
<re_irc>
<@willeml:matrix.org> t know which hardware pins to wire up (where is mosi physically)
<re_irc>
<@almindor:matrix.org> ahh, same as hifive1, which is to say see the "digX" ones in the macro there
<re_irc>
<@almindor:matrix.org> digX is the numbering on the board
<re_irc>
<@almindor:matrix.org> so e.g. spi0_mosi goes to pin3, dig11 also goes to pin3
<re_irc>
<@willeml:matrix.org> Ohhh
<re_irc>
<@almindor:matrix.org> so it's pin 11 on the board, it's confusing but that's how it is, you can also check out the hifive1 pinout diagram
<re_irc>
<@willeml:matrix.org> Oh cool, thanks
<re_irc>
<@willeml:matrix.org> Trying to hook up the display will be much easier 😃
<re_irc>
<@willeml:matrix.org> Because I lack proper jumpers I had to improvise, and solder the wires onto pin headers and stick the pin headers into the redboard's receptacles
<re_irc>
<@willeml:matrix.org> Does the risk-v hal have an "empty" pin? (like the embassy `NoPin`)
<re_irc>
<@willeml:matrix.org> Looks like I can actually just use `()`
GenTooMan has quit [Ping timeout: 252 seconds]
<re_irc>
<@willeml:matrix.org> almindor: I have set everything up, but now when I run I get the following error: `Error: `.vector_table` section is missing`, does this mean that I have to create my own memory.x and build.rs?
GenTooMan has joined #rust-embedded
<re_irc>
<@almindor:matrix.org> > almindor: I have set everything up, but now when I run I get the following error: `Error: `.vector_table` section is missing`, does this mean that I have to create my own memory.x and build.rs?
<re_irc>
<@almindor:matrix.org> no that shouldn't be necessary, I don't recall seeing this error before
<re_irc>
<@almindor:matrix.org> are you using riscv-quickstart as template?
<re_irc>
<@willeml:matrix.org> kind of
<re_irc>
<@almindor:matrix.org> you're using "board-riscv" feature with the hifive1 crate right?
<re_irc>
<@willeml:matrix.org> I am trying to use probe-run instead of gdb
<re_irc>
<@willeml:matrix.org> almindor: yes
<re_irc>
<@almindor:matrix.org> hmm, I'm not too famliar with probe-run, if you try the gdb method will it link?
<re_irc>
<@willeml:matrix.org> Actually, no, I am using "board-redv"
<re_irc>
<@almindor:matrix.org> sorry, typo, board-redv is correct of coure :D
<re_irc>
<@willeml:matrix.org> error: could not execute process `riscv64-unknown-elf-gdb -q -x gdb_init target/riscv32imac-unknown-none-elf/debug/redboard_expirements` (never executed)
<re_irc>
<@willeml:matrix.org> Caused by:
<re_irc>
<@willeml:matrix.org> No such file or directory (os error 2)
<re_irc>
<@willeml:matrix.org> guess I need to install that toolchain
<re_irc>
<@almindor:matrix.org> right, but I think that's part linking now
<re_irc>
<@almindor:matrix.org> *past, damn it's getting too later here
<re_irc>
<@almindor:matrix.org> i wonder if probe-run needs the vector table section for something like allocations? sounds dynamic-ish :D
<re_irc>
<@almindor:matrix.org> I can look closer tomorrow it's getting too late here
<re_irc>
<@willeml:matrix.org> No worries, also, pain cargo build seems to work
<re_irc>
<@willeml:matrix.org> so I probably just have to use cargo flash or something
<re_irc>
<@almindor:matrix.org> you can also just copy the .hex file
<re_irc>
<@almindor:matrix.org> you can objcopy to hex and then just copy that to the hifive disk
<re_irc>
<@almindor:matrix.org> I don't have the hexification handy tho it's been ages since I used that
<re_irc>
<@willeml:matrix.org> Cool, I will try that, I was using objcopy to bin in another project, figuring this out should not be too hard
<re_irc>
<@willeml:matrix.org> Thanks for all the help!
<re_irc>
<@willeml:matrix.org> Awesome, its working, just needed to install JLinkGDBServer and the homebrew riscv-toolchain
<re_irc>
<@willeml:matrix.org> Kinda lame, but it works...
fabic has quit [Ping timeout: 255 seconds]
<re_irc>
<@wsalmon:matrix.org> Hi all, I think the person asking/answering https://stackoverflow.com/a/63142402 is trying to implment a protical called DShot, which i would also quite like to implment. I would like to do it for stm32f1 rather than stm32f4. i notice that for both https://github.com/stm32-rs/stm32f4xx-hal and...
<re_irc>
... https://github.com/stm32-rs/stm32f1xx-hal have dma implmented for several things but not for pwm. looking at the stack overflow example looks like the same registers exist on stm32f1. looking at page 409 etc of...
<re_irc>
<@dirbaio:matrix.org> changed it to use the released st7789 0.6, it just worked :D
radens has quit [Quit: Connection closed for inactivity]
ni has quit [Quit: WeeChat 2.8]
ni has joined #rust-embedded
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 246 seconds]
fabic has joined #rust-embedded
<re_irc>
<@almindor:matrix.org> > changed it to use the released st7789 0.6, it just worked :D
<re_irc>
<@almindor:matrix.org> is it same size framebuffer?
<re_irc>
<@dirbaio:matrix.org> 320x240
<re_irc>
<@almindor:matrix.org> yeah that's same, I wonder if there's any difference at all then
starblue2 has quit [Ping timeout: 252 seconds]
<re_irc>
<@dkhayes117:matrix.org> willeml: Probe-flash works for the HiFive1 RevB but it isn't optimized for riscv yet, it takes >18sec to flash. `cargo flash --protocol jtag --chip fe310-g002`
<re_irc>
<@almindor:matrix.org> i never used probe-rs before, seemed like just one more complicated thing that could break along the way
<re_irc>
<@dkhayes117:matrix.org> It wasn't that bad getting mine to flash, and I like it much better than using GDBServer. Once it is better optimized, I definitely will be using it more as well as defmt.
<re_irc>
<@yatekii:matrix.org> almindor: if it's complicated, it's a bug :) you can let us know if it is.
<re_irc>
<@yatekii:matrix.org> dkhayes117: we certainly have things to optimize, but for the generic ARM core & probe you should notice little to no difference to other tools :)
<re_irc>
<@almindor:matrix.org> oh I meant complicated in the sense of non-standard loader. If the jlink approach doesn't work with riscv/sifive boards I can be sure it's either out link scripts or an actual bug and go upstream. With probe-rs it'd be more digging.
<re_irc>
<@yatekii:matrix.org> almindor: I do not see the difference, but your call :)
<re_irc>
<@yatekii:matrix.org> well there is one difference: you can fix probe-rs yourself. no can do for segger :)
fabic has quit [Ping timeout: 258 seconds]
<re_irc>
<@almindor:matrix.org> of course, I'm not being critical, it's just that when I started the loading part was something we needed to "just work". We didn't even have the link scripts working or the board crate ready
<re_irc>
<@almindor:matrix.org> I'll def. check out probe-rs at some point
<re_irc>
<@henrik_alser:matrix.org> My embedded life has never been this nice and trouble free as since probe-rs, total gamechanger
<re_irc>
<@ryan-summers:matrix.org> Yeah, I have to admit, when I _do_ have issues, the fact that probe-rs is open sourced is a life saver
<re_irc>
<@henrik_alser:matrix.org> almindor: Try the knurling app template
<re_irc>
<@yatekii:matrix.org> almindor: no worries, I am not bothered by criticism :) I have no clue what your timeline etc looks like. But as of today and I'd dare say the entirety of 2021, most MCUs used in the community are quite stable with probe-rs :)
<re_irc>
<@yatekii:matrix.org> Also, critisism is very vital to improve :)
<cr1901>
Well, not enough love for msp430, and it's too much work to port mspdebug
<re_irc>
<@yatekii:matrix.org> because we still have a long way to go, admitedly
<re_irc>
<@adamgreig:matrix.org> hi @room, meeting time again! agenda is https://hackmd.io/2-wC0HQ7RleqJO0SWdRarQ, please add anything you'd like to announce or discuss and we'll start in 5min :)
<re_irc>
<@yatekii:matrix.org> cr1901: yeah sadly, that's a whole lot of work I guess. And something most of us do not use, which is why it sees very little work :(
<re_irc>
<@therealprof:matrix.org> `cargo-flash` and `probe-run` are nothing less than game changers.
<cr1901>
I can't do everything for msp430 sadly.
<re_irc>
<@yatekii:matrix.org> yeah same here :/ but now that I quit my job (well still working but not for long) I'll be looking to make this viable so I can put in full time work :)
<re_irc>
<@yatekii:matrix.org> Not sure how but yeah ^^
<re_irc>
<@adamgreig:matrix.org> ok, let's start the meeting 👋
<re_irc>
<@adamgreig:matrix.org> I don't have any announcements from this week, does anyone else?
<re_irc>
<@adamgreig:matrix.org> guess not! ok, let's go on to embedded-hal
<re_irc>
<@adamgreig:matrix.org> last week we chatted about perhaps inverting the modules so that blocking::spi becomes spi::blocking; eldruin has now made a PR for it: https://github.com/rust-embedded/embedded-hal/pull/298
<re_irc>
<@eldruin:matrix.org> I did not write a proper description though
<re_irc>
<@eldruin:matrix.org> I did it as an experiment to see how it would look like
<re_irc>
<@eldruin:matrix.org> I'm not convinced it is a great thing
<re_irc>
<@yatekii:matrix.org> Aren't most libs doing it that way as well?
<re_irc>
<@eldruin:matrix.org> yatekii: any examples?
<re_irc>
<@adamgreig:matrix.org> eldruin: are you mainly worried about the user experience where they end up with lots of `blocking` modules in-scope?
<re_irc>
<@eldruin:matrix.org> yes
<re_irc>
<@adamgreig:matrix.org> yea, I didn't think of that last week but it does seem quite unergonomic
<re_irc>
<@eldruin:matrix.org> other than that it looks more correct to have an execution-model-independent place for independent definitions like the spi mode
<re_irc>
<@adamgreig:matrix.org> yea
<re_irc>
<@eldruin:matrix.org> but you have to reexport everything again in the blocking/ nb submodules to ease impots
<re_irc>
<@eldruin:matrix.org> well you do not have to
<re_irc>
<@yatekii:matrix.org> eldruin: consider me corrected, I am not sure anymore. https://docs.rs/reqwest/0.11.4/reqwest/ for example has it like we do it now.
<re_irc>
<@eldruin:matrix.org> but then you need to import the spi mode from a place, then some traits from other place
<re_irc>
<@eldruin:matrix.org> idk, it's a bit weird
<re_irc>
<@grantm11235:matrix.org> Would it be better if the modules were called something like `e_h::blocking::blocking_spi` ?
<re_irc>
<@eldruin:matrix.org> uh redundant names sound bad
<re_irc>
<@adamgreig:matrix.org> seems like on balance blocking::spi which re-exports top-level common spi things like mode is the best way after all then :/
<re_irc>
<@eldruin:matrix.org> sorry not trying to be hurtful, thanks for the proposal (I only have a hand)
<re_irc>
<@adamgreig:matrix.org> ok, well the PR is open if anyone else has feedback, thanks for writing it up eldruin!
<re_irc>
<@grantm11235:matrix.org> This is only a problem if the user does `use e_h::spi::blocking`, but not if they do `use e_h::spi` or `use::spi::blocking::Write`, right?
<re_irc>
<@eldruin:matrix.org> maybe it is not a problem at all
<re_irc>
<@eldruin:matrix.org> as I said I'm just not convinced
<re_irc>
<@adamgreig:matrix.org> you have to import traits fully by name to use their methods, right?
<re_irc>
<@adamgreig:matrix.org> or perhaps not if you're just putting a bound on your own impl
<re_irc>
<@eldruin:matrix.org> that's actually a great point adamgreig
<re_irc>
<@eldruin:matrix.org> ah yes that
<re_irc>
<@adamgreig:matrix.org> but I guess not the end of the world to have `where T: spi::blocking::Write` in that case
<re_irc>
<@eldruin:matrix.org> yeah that would be fine
<re_irc>
<@adamgreig:matrix.org> if anything it's quite explicit
<re_irc>
<@adamgreig:matrix.org> so maybe you just wouldn't `use e_h::spi::blocking` ever
<re_irc>
<@eldruin:matrix.org> maybe yeah
<re_irc>
<@grantm11235:matrix.org> Or
<re_irc>
<@grantm11235:matrix.org> ```rust
<re_irc>
<@grantm11235:matrix.org> where T: Write
<re_irc>
<@grantm11235:matrix.org> // ...
<re_irc>
<@grantm11235:matrix.org> use e_h::spi::blocking::Write
<re_irc>
<@eldruin:matrix.org> It occurred to me that it would be good to have such a place for the associated errors as well, which is another PR, so there are more use cases for it than spi mode
<re_irc>
<@adamgreig:matrix.org> oh yea, true, since those are shared also
<re_irc>
<@adamgreig:matrix.org> be annoying to end up with e_h::spi containing shared stuff and then also e_h::spi::blocking and e_h::spi::nb for the actual traits
<re_irc>
<@grantm11235:matrix.org> There are a few other things that could be moved, like `adc::nb::Channel`
<re_irc>
<@eldruin:matrix.org> That one maybe too, yes
<re_irc>
<@eldruin:matrix.org> but I was unsure if a blocking ADC would rather select the channel differently
<re_irc>
<@grantm11235:matrix.org> We could also use a flatter file structure where `src/spi.rs` has `blocking` and `nb` modules inside it
<re_irc>
<@adamgreig:matrix.org> sure, though much of a muchness I guess, you could have `src/spi.rs` and `src/spi/blocking.rs` too or whatever
<re_irc>
<@grantm11235:matrix.org> It might make sense to keep spi separate, but it definatly make sense for the modules that only have `blocking` or vise versa
<re_irc>
<@adamgreig:matrix.org> there's been some good discussion and points for and against on the PR thread so it might be worth just keeping that going, but if anyone wants to say anything about it now please also go ahead
<re_irc>
<@grantm11235:matrix.org> I would prefer to keep the discussion of that in the PR so that it doesn't completely derail the meeting 🤣
<re_irc>
<@grantm11235:matrix.org> Unless anyone has any questions that they really want to ask now
<re_irc>
<@firefrommoonlight:matrix.org> > i never used probe-rs before, seemed like just one more complicated thing that could break along the way
<re_irc>
<@firefrommoonlight:matrix.org> What alternatives are available, other than openOCD, that include debugging?
<re_irc>
<@therealprof:matrix.org> I didn't see the rest of the discussion. Had to read up on it. 😉
<re_irc>
<@grantm11235:matrix.org> I have a small nit-pick with the changelog, but otherwise I think it is good to merge
<re_irc>
<@eldruin:matrix.org> please add a comment about it on the PR
<re_irc>
<@adamgreig:matrix.org> it's there as a suggestion
<re_irc>
<@grantm11235:matrix.org> yup
<re_irc>
<@adamgreig:matrix.org> (maybe Lachlan Sneff for that)
<re_irc>
<@eldruin:matrix.org> ah ok
<re_irc>
<@adamgreig:matrix.org> anything else for e-h this week?
<re_irc>
<@therealprof:matrix.org> It's time to wrap it up and ship it.
<re_irc>
<@lachlansneff:matrix.org> Suggestion is good, will merge it
SomeWeirdAnon has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> therealprof: while big PRs keep coming in every week?
<re_irc>
<@therealprof:matrix.org> Yes, otherwise we'll keep procrastinating for more years.
<re_irc>
<@adamgreig:matrix.org> might be worth getting to a decision on the outstanding major PRs and shipping a final prerelease for HALs to do some trial implementations of?
<re_irc>
<@therealprof:matrix.org> Absolutely. There're already some branches supporting the previous prereleases.
<re_irc>
<@adamgreig:matrix.org> I think it should be fairly simple and no-one's asked for anythign else to be backported, so we can at least get that out
<re_irc>
<@adamgreig:matrix.org> I am waiting to hear who's on the tools team email list -> I can post the issue asking for new maintainers for cross -> I can add that to the blog -> we can post the next newsletter
<re_irc>
<@therealprof:matrix.org> adamgreig: c*ckblocked by Travis
<re_irc>
<@adamgreig:matrix.org> yea... unless you're already doing it eldruin I'll swap showcase to GHA after the meeting
<re_irc>
<@eldruin:matrix.org> that would be great, I have not done it yet
<re_irc>
<@adamgreig:matrix.org> 👍️ will do
<re_irc>
<@therealprof:matrix.org> BTW: There's a new zola release, seems to have ton of interesting stuff in but I think we removed the version pinning?
<re_irc>
<@adamgreig:matrix.org> I guess I'll find out real soon 😅
<re_irc>
<@adamgreig:matrix.org> I noticed new release but haven't had time to see if we'd want to update any of our stuff
<re_irc>
<@therealprof:matrix.org> Just a heads-up that it might be more than a quick glance and merge action.
<re_irc>
<@adamgreig:matrix.org> ok, I guess that's it for today then, thank you everyone!
<re_irc>
<@grantm11235:matrix.org> While everyone is here, I have a pre-pre-pre-RFC for ya
<re_irc>
<@grantm11235:matrix.org> Should the e_h spi traits represent a peripheral connected over an spi bus, or the whole bus itself?
<re_irc>
<@grantm11235:matrix.org> I think that the former would be more useful, but we really only have the latter at the moment
<re_irc>
<@grantm11235:matrix.org> Which is why we need things like shared-bus (which comes with it's own problems)
<re_irc>
<@firefrommoonlight:matrix.org> Could you provide an example of how that would be used in practice, ie what the use case is?
<re_irc>
<@firefrommoonlight:matrix.org> Ie something a generic driver would impl vice a HAL? How would it interface with the HAL?
<re_irc>
<@grantm11235:matrix.org> It might look something like this
<re_irc>
<@grantm11235:matrix.org> ```rust
<re_irc>
<@grantm11235:matrix.org> let spi1 = hal::Spi1::take();
<re_irc>
<@grantm11235:matrix.org> let sensor_spi = spi1.add_device(sensor_cs_pin, MODE_2, MegaHertz(1));
<re_irc>
<@grantm11235:matrix.org> let lcd_spi = spi1.add_device(lcd_cs_pin, MODE_1, MegaHertz(20));
<re_irc>
<@grantm11235:matrix.org> The HAL would take care of the cs pins and it would have some kind of mutex to keep `lcd_spi` and `sensor_spi` from being used at the same time
<re_irc>
<@grantm11235:matrix.org> `lcd_spi` and `sensor_spi` would both impl e_h traits
<re_irc>
<@firefrommoonlight:matrix.org> That solves some problems. At a glance, looks like a nice idea
<re_irc>
<@grantm11235:matrix.org> The downside is that the HAL would need to reconfigure (or at least check) the cs pin, the mode, the speed, etc... every time a hal method is called
<re_irc>
<@bobmcwhirter:matrix.org> and `.add_device` seems... allocate-y
<re_irc>
<@grantm11235:matrix.org> I don't think it would be, any data could be stored in `lcd_spi`
<re_irc>
<@dkhayes117:matrix.org> almindor I will do some more testing on the pmpcfg methods tonight to address my `into_config()` idea. (In case you didn't see my PR comment). Any opinions are welcomed.
<re_irc>
<@grantm11235:matrix.org> Also, "some kind of mutex" is a lot of handwaving on my part
<re_irc>
<@firefrommoonlight:matrix.org> Agree - implementation details will be important
<re_irc>
<@firefrommoonlight:matrix.org> Another challenge is that when building generic interfaces, you need buy-in from both HALs and driver makers
<re_irc>
<@rahix:matrix.org> GrantM11235: the code you showed above looks very similar to something I had in mind for `shared-bus`
<re_irc>
<@rahix:matrix.org> if the `embedded-hal` traits could provide the necessary API to implement it ontop of (i.e. API for doing the configuration), I think we'd get nice separation of concerns.
<re_irc>
<@grantm11235:matrix.org> I think that functionality belongs in the HALs tbh. There are too many possible configuration options for it to be in e_h.
<re_irc>
<@grantm11235:matrix.org> Though shared-bus might still be useful in the HALs to reduce boilerplate
<re_irc>
<@rahix:matrix.org> hmm, that's a good point, the config should stay hal-specific
<re_irc>
<@grantm11235:matrix.org> rahix: By the way, did you see the `Reconfigurable` trait that I mentioned yesterday?
<re_irc>
<@rahix:matrix.org> interesting, although where would you fit e.g. CS & mode into it? As you wrote above, that needs to be HAL specific so it can't be visible in `Lcd` really
<re_irc>
<@almindor:matrix.org> > @almindor I will do some more testing on the pmpcfg methods tonight to address my `into_config()` idea. (In case you didn't see my PR comment). Any opinions are welcomed.
<re_irc>
<@almindor:matrix.org> sure thing, I have to read some docs to get back into things either way if I want to review this properly
<re_irc>
<@grantm11235:matrix.org> rahix: Anything that impl's the spi traits would need to be able to handle that, anything that uses the spi traits can assume that it is taken care of
<re_irc>
<@rahix:matrix.org> right, but how does the type discern between all possible settings? For some things you could get away with const-generics, but that erases all possibility of runtime decided settings, I think
<re_irc>
<@rahix:matrix.org> but it does lead to some interesting ideas, I'll have to think about this more...
<re_irc>
<@grantm11235:matrix.org> `spi1::add_device()` would return a HAL-specific struct that has all of the config in it, either as const-generics or just as struct members
<re_irc>
<@grantm11235:matrix.org> The HAL could also offer an `add_device_exclusive_bus` method that consumes the bus and only needs to set the configuration once
<re_irc>
<@rahix:matrix.org> GrantM11235: Maybe we should open a separate issue for discussing "shared SPI bus with different settings", to keep track of all the ideas floating around?
<re_irc>
<@rahix:matrix.org> GrantM11235: I'm a bit hesitant to offload this all onto the HAL maintainers. I think we need a solution where the HAL just provides implementation of the basic bus interaction, `embedded-hal` provides traits to abstract over this interaction generically, and third-party crates like `shared-bus` can provide...
<re_irc>
... sharing solutions ontop. That way you can always build your own if the existing ones don't fit your bill. If this all becomes part of the HAL crates, we're locking users into certain designs unnecessarily.
<re_irc>
<@grantm11235:matrix.org> First we need to decide whether the spi traits should represent a single device or the whole bus, after that I think everything will fall into place
<re_irc>
<@rahix:matrix.org> I think it should represent the MCU-side peripheral without any notion of devices on a bus (pretty much like it does now). This way the HALs stay most flexible in regards to further layers of abstraction.
<re_irc>
<@hisham92:matrix.org> Un te bijouterie nu l L see zee is h in s* !R ou j' j' ; ou o le unGrantM11235 il him je okmynu
<re_irc>
<@rahix:matrix.org> no more time today though, let's continue another time (maybe in an issue on GH to keep track?)
<re_irc>
<@grantm11235:matrix.org> I am drafting a GH issue about using the spi traits to represent a single bus, I'll post a link once I finish it
<re_irc>
<@rahix:matrix.org> thanks!
<re_irc>
<@dbrgn:matrix.coredump.ch> In a custom `#[panic_handler]` on cortex-m, does it make sense to disable interrupts for the entire handler body? (I'm using panic-persist to store panic info, set the wakeup timer and then go into standby. This should avoid very fast battery drain of the device when a panic loop occurs.)
<re_irc>
<@almindor:matrix.org> > > <willeml> I am trying to use probe-run instead of gdb
<re_irc>
<@almindor:matrix.org> > Probe-flash works for the HiFive1 RevB but it isn't optimized for riscv yet, it takes >18sec to flash. `cargo flash --protocol jtag --chip fe310-g002`
<re_irc>
<@almindor:matrix.org> >
<re_irc>
<@almindor:matrix.org> I tried this but I get `Error 0: Trying to write flash, but no suitable flash loader algorithm is linked to the given target information` not sure what that means exactly
<re_irc>
<@adamgreig:matrix.org> interesting, some nightly CIs are failing because `no_mangle` is now incompatible with `deny(unsafe_code)`
<re_irc>
<@adamgreig:matrix.org> sensible for sure, shame we never had "unsafe attributes"
<re_irc>
<@adamgreig:matrix.org> huh... actually it's also failing on the stable CI, I guess nevermind
<re_irc>
<@adamgreig:matrix.org> in fact I fixed this on master back in march -_-
<re_irc>
<@thalesfragoso:matrix.org> So, cortex_m::peripherals::SYST has this `is_precise()` method, what does it really say ?
<re_irc>
<@thalesfragoso:matrix.org> My F0S returns false :/
<re_irc>
<@adamgreig:matrix.org> it's more or less meaningless
<re_irc>
<@thalesfragoso:matrix.org> And I wasn't able to do onewire with the systick, but not sure if that has to do with it, or it's just because the routine for the delay takes too much time to set-up
<re_irc>
<@adamgreig:matrix.org> it just tells you if the manufacturer put a number into the calibration value register that accurately reflects how many systicks in 10ms
<re_irc>
<@adamgreig:matrix.org> which ST don't because the clock speed is variable