starblue has joined #rust-embedded
starblue3 has quit [Ping timeout: 258 seconds]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 245 seconds]
fabic has joined #rust-embedded
x56 has quit [Ping timeout: 255 seconds]
x56 has joined #rust-embedded
fabic has quit [Ping timeout: 252 seconds]
vancz has quit [*.net *.split]
bpye has quit [*.net *.split]
bpye has joined #rust-embedded
vancz has joined #rust-embedded
emerent has quit [Ping timeout: 272 seconds]
emerent_ has joined #rust-embedded
emerent_ is now known as emerent
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 252 seconds]
fabic has joined #rust-embedded
dcz has joined #rust-embedded
neceve has joined #rust-embedded
GenTooMan has joined #rust-embedded
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 272 seconds]
<re_irc> <@a​damgreig:m​atrix.org> @room meeting time again! agenda is https://hackmd.io/E3N_NmMsTEqFx8v7bksJDw, please add anything you'd like to discuss, we'll start in 5min
<re_irc> <@a​damgreig:m​atrix.org> quiet today 👀
<re_irc> <@a​ltsegcat:m​atrix.org> I can be here
<re_irc> <@b​urrbull:m​atrix.org> 0.2.6
<re_irc> <@e​ldruin:m​atrix.org> burrbull: I'm on it
<re_irc> <@a​damgreig:m​atrix.org> cool, well, let's get started I guess
<re_irc> <@a​damgreig:m​atrix.org> quick announcement, dkhayes117 has joined the risc-v team 🎉
<re_irc> <@a​damgreig:m​atrix.org> welcome to the wg!
<re_irc> <@d​khayes117:m​atrix.org> Thank you!
<re_irc> <@a​damgreig:m​atrix.org> please don't hesitate to bring up any risc-v stuff in meetings, it doesn't usually get as much discussion as fixing all the cortex-m things :P
<re_irc> <@a​damgreig:m​atrix.org> ok, on to embedded-hal, last week we discussed the change of return type in https://github.com/rust-embedded/embedded-hal/pull/286 but decided to wait a week to see if japaric had any feedback on the intent of the original API
<re_irc> <@a​damgreig:m​atrix.org> but, I guess not; are we happy to merge it then?
<re_irc> <@e​ldruin:m​atrix.org> I am
<re_irc> <@e​ldruin:m​atrix.org> @there
<re_irc> <@t​herealprof:m​atrix.org> Yes.
<re_irc> <@t​herealprof:m​atrix.org> Let's do it.
<re_irc> <@e​ldruin:m​atrix.org> alright :)
<re_irc> <@b​urrbull:m​atrix.org> many responses on `cross`
<re_irc> <@b​urrbull:m​atrix.org> https://github.com/rust-embedded/cross/issues/574
<re_irc> <@a​damgreig:m​atrix.org> yea, it's very encouraging this last week!
<re_irc> <@t​herealprof:m​atrix.org> I left a note on the issue so we get the conflicts fixed.
<re_irc> <@a​damgreig:m​atrix.org> thanks therealprof
<re_irc> <@a​damgreig:m​atrix.org> for cross, we discussed last week adding people to the repo, but with this many volunteers we probably need a better way to coordinate
<re_irc> <@a​damgreig:m​atrix.org> a matrix room? an issue for discussions?
<re_irc> <@a​damgreig:m​atrix.org> open to any suggestions 👀 I was gonna post something on the issue thread after the meeting
<re_irc> <@e​ldruin:m​atrix.org> probably need some selection policy like contributions
<re_irc> <@a​damgreig:m​atrix.org> as far as I remember, none of the people who've volunteered to help have had any PRs accepted, I haven't checked for open PRs
<re_irc> <@a​damgreig:m​atrix.org> ok, well anyway please comment here if you have any thoughts, I'll write something up later today
<re_irc> <@a​damgreig:m​atrix.org> moving on to the e-h stuff, I don't think anything from last week was left waiting further discussion, but shall we revisit a couple? like inverting the trait layout now seems like it would work pretty well
<re_irc> <@e​ldruin:m​atrix.org> I also think it looks good
<re_irc> <@e​ldruin:m​atrix.org> idea credit goes to @Gra
<cr1901> inverting as in: blocking::spi -> spi::blocking?
<re_irc> <@e​ldruin:m​atrix.org> yes
<re_irc> <@e​ldruin:m​atrix.org> so we have stuff like `spi::Mode`
<re_irc> <@d​khayes117:m​atrix.org> That makes more sense to me as well
<cr1901> Yea, looks fine to me. I'll manage to update a few imports when ready
<re_irc> <@e​ldruin:m​atrix.org> also we may have more shared definitions in the future
<re_irc> <@e​ldruin:m​atrix.org> and the argument about people thinking first in peripheral, then execution mode makes a lot of sense
<re_irc> <@a​damgreig:m​atrix.org> and the main argument against was that if you "use spi::blocking" and "i2c::blocking" so that you could "impl blocking::Write" it would be confusing, but it seems like really that's unlikely and in any event it's easy to say "use spi" and then "impl spi::blocking::Write" or "use spi::blocking::Write as...
<re_irc> ... SpiWrite" or whatever
<re_irc> <@a​damgreig:m​atrix.org> sgtm anyway
<re_irc> <@e​ldruin:m​atrix.org> yeah I agree
<re_irc> <@g​rantm11235:m​atrix.org> Me too
<re_irc> <@a​damgreig:m​atrix.org> cool, any other e-h PRs to discuss?
<re_irc> <@g​rantm11235:m​atrix.org> I have a few short updates on https://github.com/rust-embedded/embedded-hal/issues/299
<re_irc> <@e​ldruin:m​atrix.org> go ahead
<re_irc> <@g​rantm11235:m​atrix.org> First, almindor has started implementing it for e310x-hal https://github.com/riscv-rust/e310x-hal/pull/37
<re_irc> <@g​rantm11235:m​atrix.org> The mutex stuff is a bit complicated, it might be a good idea to put some of that in a helper crate that can be shared between HALs
<re_irc> <@g​rantm11235:m​atrix.org> Second, I discovered an issue with shared-bus which re-enforces my belief that #299 (or something like it) is necessary https://github.com/Rahix/shared-bus/issues/23
<re_irc> <@e​ldruin:m​atrix.org> do you know about mutex-trait?
<re_irc> <@b​urrbull:m​atrix.org> We must don't lose possibility to use it in old way. Without overhead
<re_irc> <@e​ldruin:m​atrix.org> GrantM11235: That I did not think about either before
<re_irc> <@g​rantm11235:m​atrix.org> eldruin: I have heard of it, but I will need to read up on it again
<re_irc> <@a​bgeana:m​atrix.org> hi. at some point (e.g. in tag 0.2.5) there was a digital::v2::InputPin and others. did these traits disappear?
<re_irc> <@g​rantm11235:m​atrix.org> burrbull: My `ExclusiveDevice` example could be changed to hold chipselect low for the lifetime of the struct, which should allow for zero overhead
<re_irc> <@a​bgeana:m​atrix.org> abgeana: found it, nvm
<re_irc> <@a​lmindor:m​atrix.org> > First, almindor has started implementing it for e310x-hal https://github.com/riscv-rust/e310x-hal/pull/37
<re_irc> <@a​lmindor:m​atrix.org> as a note I implemented it in a way that's backwards compatible by allowing use of the entire `Bus` struct in exlusive mode, or constructing it for sharing and making the devices. So far it seems to work mostly well, we're ironing out some kinks and issues we found in the PAC while we tested this (bad reset...
<re_irc> ... values for delay registers etc.)
<re_irc> <@g​rantm11235:m​atrix.org> I also noticed that you assign a sequential `u16` identifier to each device to keep track of the current bus configuration. Have you tested how this performs versus unconditionally reconfiguring the bus each time?
<re_irc> <@a​lmindor:m​atrix.org> good point, I didn't yet. It just seemed to me most users will perform sequential operations of substantial size at least on the single threaded e310. My main issue for testing is that I lack SPI hw atm. I'm just doing logic analyzer checks and disasm helps at times
<re_irc> <@a​lmindor:m​atrix.org> (I only have 1 SPI display which is a no-cs variant to boot)
<re_irc> <@a​damgreig:m​atrix.org> if you just tie miso to mosi you can read back whatever you transmit, can be fun to test with
<re_irc> <@a​damgreig:m​atrix.org> doesn't help make sure the different CS signals are all right though...
<re_irc> <@a​lmindor:m​atrix.org> yeah, what we're seeing right now is that CS seems to be set correctly, but the delay register bugs caused some interesting side effect
<re_irc> <@a​lmindor:m​atrix.org> i'm basically letting my ST7789 driver "draw" and watch what's being sent to two instances via the analyzer for basic testing
<re_irc> <@a​lmindor:m​atrix.org> didn't do any "in" side transfer checks yet
<re_irc> <@a​damgreig:m​atrix.org> sounds like a good starting point for sure though
<re_irc> <@a​lmindor:m​atrix.org> it's promising, early capture is at http://objdump.katona.me/SPI_capture_shared_1_st7789.sal
<re_irc> <@a​lmindor:m​atrix.org> also in this case we don't control the SS pins, we let the HW do it for us but we consume them to keep things safe
<re_irc> <@a​lmindor:m​atrix.org> the e310 QSPI HW has 3 modes of CS operation, in case of sharing we use "AUTO" which means it sets the CS for each 8bit transfer
<re_irc> <@g​rantm11235:m​atrix.org> Does that release CS briefly in between each byte?
<re_irc> <@a​lmindor:m​atrix.org> yes
<re_irc> <@a​lmindor:m​atrix.org> and the timings are set via 2 delay registers which we found to be bugged in the PAC (reset value wrong)
<re_irc> <@a​lmindor:m​atrix.org> it used to be set to full 0 by .reset(), I didn't check if the definition file is at fault
<re_irc> <@a​damgreig:m​atrix.org> cool, I think that's just about it for today's agenda, I'll also try and push on that cortex-m 0.7 PR this week
<re_irc> <@a​damgreig:m​atrix.org> thanks for attending everyone!
<re_irc> <@a​damgreig:m​atrix.org> might be of interest to people, cargo has stabilised the feature to let you put linker arguments in build scripts https://github.com/rust-lang/cargo/pull/9557
<re_irc> <@a​damgreig:m​atrix.org> though as i understand it this is only for the build script of the crate that produces the binary, _not_ build scripts from dependencies
<re_irc> <@a​damgreig:m​atrix.org> so for embedded projects I think you would be able to put a line in your build.rs instead of in .cargo/config to add the linker script
<re_irc> <@a​damgreig:m​atrix.org> but e.g. cortex-m-rt still can't do it for you
<re_irc> <@a​lmindor:m​atrix.org> GrantM11235 "shared" mode works with my ST7789 so at least the basics don't break. Note that this display sadly has no CS pin so it's "always on". I basically draw to it twice using two driver instances
<re_irc> <@a​lmindor:m​atrix.org> here's a SPI echo-back of 0,1,2,3,4,5 u8 bytes using 1Mhz and 5Mhz in MODE 0 both (to keep analyzer happy, other modes work too tho): http://objdump.katona.me/spi_echo_012345.sal
<re_irc> <@a​lmindor:m​atrix.org> my analyzer starts to lose precision at ~4mhz tho :D
<re_irc> <@a​lmindor:m​atrix.org> heh actually no it can handle a bit more, I just had the sample rate too low, re-uploaded a better version
<re_irc> <@t​imbod7:m​atrix.org> I’ve been using openocd for my projects on stm32 hardware to date. I want to start using rtt for logging.
<re_irc> <@t​imbod7:m​atrix.org> This post provided some useful background, but didn’t point either way:
<re_irc> <@t​imbod7:m​atrix.org> https://albertskog.se/tag/cargo-embed/
<re_irc> <@t​imbod7:m​atrix.org> Should I look at cargo-embed or probe-run?
<re_irc> <@n​ewam:m​atrix.org> timbod7: I have been using `probe-run` and `defmt-test` and a real hacky script to trigger it:
<re_irc> <@n​ewam:m​atrix.org> I don't have a repo for the hacky script because it may be insecure (I do not feel great about the mechanism to prevent my local PC from running untrusted code), but if you're curious I can send it over.
<re_irc> <@t​imbod7:m​atrix.org> That’s cool - nice having GitHub CI connected to an embedded target
<re_irc> <@n​ewam:m​atrix.org> oh - I read your message again, realized I misread it as CI related.
<re_irc> <@n​ewam:m​atrix.org> For just regular development use I would recommend both `cargo-embed` and `probe-run`.
<re_irc> <@n​ewam:m​atrix.org> I find `probe-run` is better for testing because it handles automatic termination better, whereas `cargo-embed` is handles long-running processes better (I need to investigate why that is, but that has been my experience)
<re_irc> <@n​ewam:m​atrix.org> Whichever one you use make sure you have the latest version, each release has lots of bugfixes and improvements.
<re_irc> <@t​imbod7:m​atrix.org> Thank - I’ll try them both
<re_irc> <@h​enrik_alser:m​atrix.org> timbod7: Check out the awesome knurling app template https://github.com/knurling-rs/app-template
<re_irc> <@a​ltsegcat:m​atrix.org> What's knurling (in this context, I know about metal working)?
<re_irc> <@t​herealprof:m​atrix.org> A set of projects sponsored by Ferrous to improve Rust Embedded Tooling.
<re_irc> <@n​ewam:m​atrix.org> SEGFAULT (Lauren): Their introductory blog post is good: https://ferrous-systems.com/blog/knurling-rs/