<re_irc>
<@yruama_lairba:matrix.org> hi, can i expect that any decent hal implement DelayUs<u8> ?
<re_irc>
<@yruama_lairba:matrix.org> and i wonder what is the idiomatic way to build an object requiring a delay provider, because i guess if i pass it by value, this cannot be shared
<re_irc>
<@yruama_lairba:matrix.org> can a delya provider can be reused for several object ?
<re_irc>
<@9names:matrix.org> I've usually seen it done like this
<re_irc>
<@9names:matrix.org> I don't think I've needed to share delay sources yet though, sounds fun
<re_irc>
<@yruama_lairba:matrix.org> i mean, i need a delay for a very stupid thing, it's to garantee a pin is turned on long enougth between 2 subsequent call to the same method
<re_irc>
<@9names:matrix.org> sounds like you need a timer?
<re_irc>
<@yruama_lairba:matrix.org> i just need something providing a delay more than 20ns
<re_irc>
<@firefrommoonlight:matrix.org> I use a similar chip called the Max31865 for RTD readings. Works great and no fuss
<re_irc>
<@firefrommoonlight:matrix.org> And configurable for any sort of RTD wiring configuration and PT100 or PT1000. No complains
<re_irc>
<@firefrommoonlight:matrix.org> yruama_lairba:matrix.org: What are you doing specifically?
<re_irc>
<@yruama_lairba:matrix.org> i'm writing a hal to configure wm8731 codec
<re_irc>
<@9names:matrix.org> if it's only for nanoseconds and only during init i'd probably just create a new cortex_m::delay::Delay for it, and not worry about sharing at all
<re_irc>
<@yruama_lairba:matrix.org> i need a short delay for spi communication because i need to toggle CS pin between each message
<re_irc>
<@lachlansneff:matrix.org> How do you use the Delay struct to do ns delays? Seems like it doesn't have a method of doing that?
<re_irc>
<@yruama_lairba:matrix.org> Lachlan Sneff: i need 20ns at least. Using 1µ is fine
<re_irc>
<@adamgreig:matrix.org> for 20ns maybe you can just call `cortex_m::asm::nop()` or `cortex_m::asm::delay()`
<re_irc>
<@adamgreig:matrix.org> that's like two clock cycles at 100MHz clock
<re_irc>
<@9names:matrix.org> but that does mean your driver is now cortex_m only
<re_irc>
<@adamgreig:matrix.org> that is true
<re_irc>
<@adamgreig:matrix.org> I guess having a "cycle count" duration for the new embedded-hal might be a good idea after all
<re_irc>
<@yruama_lairba:matrix.org> i prefer getting a 1µs delay and keep thing abstract
<re_irc>
<@adamgreig:matrix.org> you might find you don't need to do anything though
<re_irc>
<@adamgreig:matrix.org> probably enough time will naturally occur
<re_irc>
<@adamgreig:matrix.org> and 1us might waste a lot of time or limit communication rate
<re_irc>
<@adamgreig:matrix.org> still, if it's just for configuration-time and not really at runtime, maybe it doesn't matter
<re_irc>
<@yruama_lairba:matrix.org> > you might find you don't need to do anything though
<re_irc>
<@yruama_lairba:matrix.org> this is what i initially thought, but i think i encounter a bug related to this
<re_irc>
<@yruama_lairba:matrix.org> yes, it's just configuration, there is actully very feww data to transmit
<re_irc>
<@yruama_lairba:matrix.org> and i actually don't know what is the maximum transmission speed of the wm8731 chip
<re_irc>
<@yruama_lairba:matrix.org> maybe it's given by "SCLK pulse cycle time"
starblue1 has quit [Ping timeout: 252 seconds]
<re_irc>
<@9names:matrix.org> based on that timing diagram, yes, that would be the limit
starblue1 has joined #rust-embedded
flatwhatson has joined #rust-embedded
dcz has joined #rust-embedded
fabic has joined #rust-embedded
PyroPeter has quit [Ping timeout: 260 seconds]
PyroPeter has joined #rust-embedded
<re_irc>
<@lachlansneff:matrix.org> If I’m getting just a few, different boards that have a bga component, does it make sense to reflow it at home or to use a pcba service?
hosewiejacke has joined #rust-embedded
hosewiejacke has quit [Client Quit]
dcz has quit [Ping timeout: 264 seconds]
dcz has joined #rust-embedded
fabic has quit [Ping timeout: 252 seconds]
flatwhatson has quit [Read error: Connection reset by peer]
flatwhatson has joined #rust-embedded
dcz has quit [Ping timeout: 246 seconds]
fabic has joined #rust-embedded
dcz has joined #rust-embedded
fabic has quit [Ping timeout: 265 seconds]
fabic has joined #rust-embedded
<re_irc>
<@yruama_lairba:matrix.org> i'm back agian about my timer, if i understand correctly the 9names example, every method using a delay require a delay provider as parameter...
<re_irc>
<@yruama_lairba:matrix.org> unfortunatly, this can be apllyied to my thing because it mess all abstraction i'have done
<re_irc>
<@yruama_lairba:matrix.org> :( i'll guess i should duplicate all my interface depending i'm need this delay or not
<re_irc>
<@9names:matrix.org> not sure the best way to deal with that problem
<re_irc>
<@yruama_lairba:matrix.org> at fisrt, i should ensure the issue i get i really related to a too fast pin toggle
<re_irc>
<@9names:matrix.org> yep! best to see if it's really a problem before you invest lots of time into solving it
dcz has quit [Ping timeout: 252 seconds]
<re_irc>
<@almindor:matrix.org> Delay is typically required in drivers, especially after the initial resets. This is where the duplicit delay traits make a mess.
<re_irc>
<@dirbaio:matrix.org> in today's "cursed ISP routers" episode... an ISP router that responds to DHCP requests with BOTH NAK and ACK
<re_irc>
<@dirbaio:matrix.org> of course it makes smoltcp explode
<re_irc>
<@dirbaio:matrix.org> how am I supposed to fix this
<re_irc>
<@dirbaio:matrix.org> all I can think of is completely ignoring NAKs lol
<re_irc>
<@jorgeig:matrix.org> dirbaio:matrix.org: Some days I wonder how the internet even works...
<re_irc>
<@dirbaio:matrix.org> Same🤣🤣
dcz has joined #rust-embedded
<re_irc>
<@yruama_lairba:matrix.org> almindor: duplicit delay traits ? what are talking about ?
<re_irc>
<@ruabmbua:matrix.org> Hey! I am having an issue with the cortex_m_rt RT feature. Linker tells me, I have missing interrupt vectors.
<re_irc>
<@ruabmbua:matrix.org> I enabled the RT feature of my pac crate, normally that was always enough to supply the interrupt vectors.
<re_irc>
<@ruabmbua:matrix.org> The pac was freshly generated with svd2rust, newest available version
<re_irc>
<@ruabmbua:matrix.org> The error is somewhat strange, linker does not actually print any link errors,but just the ERROR(cortex-m-rt): The interrupt vectors are missing
<re_irc>
<@dirbaio:matrix.org> ruabmbua: can you post the output of `cargo tree --format '{p} {f}'`?
<re_irc>
<@ruabmbua:matrix.org> device.x is there in the pac crate
<re_irc>
<@dirbaio:matrix.org> do you have at least one `use gd32e230_pac` in your main crate?
<re_irc>
<@dirbaio:matrix.org> if there's no `use` for a crate at all, it won't get passed to the linker which might cause that issue
<re_irc>
<@ruabmbua:matrix.org> wow
<re_irc>
<@ruabmbua:matrix.org> that`s it. guess extern crate syntax was better right ? ^^
<re_irc>
<@dirbaio:matrix.org> `extern crate` is kinda deprecated
<re_irc>
<@ruabmbua:matrix.org> If I had just started using it O_o
<re_irc>
<@dirbaio:matrix.org> newer equivalent is `use gd32e230_pac as _`
<re_irc>
<@dirbaio:matrix.org> it's common to use it with crates like `panic-halt`, `defmt-rtt` etc, crates that you want to get linked in but never call directly
<re_irc>
<@ruabmbua:matrix.org> b.t.w. there is a chance, that I will finally start my official first rust project at work :D. All dev`s are in on it, just need a confirmation from the boss.
<re_irc>
<@ruabmbua:matrix.org> -> to clarify: first **embedded** rust project
fabic has quit [Ping timeout: 252 seconds]
<re_irc>
<@almindor:matrix.org> yruama_lairba:matrix.org: DelayMs and DelayUs being two separate traits in the (pre-1.0) embedded-hal making it possible for HAL implementors to make one but not the other and a driver to not be usable then
<re_irc>
<@dirbaio:matrix.org> and even worse they can implement `DelayMs<u16>` but not `DelayMs<u8>`, etc
<re_irc>
<@almindor:matrix.org> yeah it's really worth skipping for 1.0 IMO
<re_irc>
<@dirbaio:matrix.org> yeah.... :S
<re_irc>
<@almindor:matrix.org> i'm also starting to think we should look at it from the clock ticks perspective, at least "internally" somehow, maybe force a clock ticks "base unit" and then delay_ns and delay_ms should cover the overall use cases
<re_irc>
<@almindor:matrix.org> coz right now e.g. on the e310/riscv we approximate but the best you can do is ~30us
<re_irc>
<@almindor:matrix.org> there's also the "sleep" vs "delay" which I think should also be addressed in the hal
<re_irc>
<@dirbaio:matrix.org> "sleep" sounds like the core actually sleeps, instead of busylooping
<re_irc>
<@almindor:matrix.org> yes, which is what I implemented using the core's sleep methods but with same trait just called the thing "Sleep"
<re_irc>
<@therealprof:matrix.org> I think sleep is quite a misnomer (also in the unix world).
<re_irc>
<@almindor:matrix.org> I did the mtimecmp stuff
<re_irc>
<@almindor:matrix.org> it does save battery tho :D
<re_irc>
<@pinealservo:matrix.org> Trying to combine high precision timing and real-time clock behavior into a single general-purpose time abstraction is actually really hard and a lot of code.
<re_irc>
<@almindor:matrix.org> I think there are many issues with the current abstraction right now
<re_irc>
<@almindor:matrix.org> 1. two traits
<re_irc>
<@almindor:matrix.org> 2. many internal types <u8> vs <u32>
<re_irc>
<@almindor:matrix.org> 3. precision clashes on various cores (e.g. not possible to go < some us etc.)
<re_irc>
<@almindor:matrix.org> 4. precision clash on abstraction wrt. primitive sizes (e.g. how many nanoseconds?)
<re_irc>
<@pinealservo:matrix.org> I recommend to take a look at the Linux kernel abstractions for it; I was able to (with a good bit of work) get a highly accurate & precise 1588 time sync going on an embedded Linux board, but it's definitely not trivial and you've got to be able to account for a lot of different hardware designs.
<re_irc>
<@pinealservo:matrix.org> The Linux stuff is severe overkill for most situations but it's at several generations of refinement now and at least gives an impression of the range of things to be considered.
<re_irc>
<@therealprof:matrix.org> There's definitely a lot that can be done. The problem is really creating a generic abstraction covering a lot of ground.
<re_irc>
<@therealprof:matrix.org> (without adding a ton of complexity)
<re_irc>
<@almindor:matrix.org> we could also split it into separate things
<re_irc>
<@almindor:matrix.org> it doesn't make sense to use the same abstraction for busy delays as for longer term "sleeps"
<re_irc>
<@almindor:matrix.org> for our use cases I think 99% of the time it's "driver needs to delay after reset" kind of thing, which is in ns/us/ms territories
<re_irc>
<@therealprof:matrix.org> almindor: I agree. But I think we need to make sure everyone is on the same page wrt to what "sleep" and what "delay" means.
<re_irc>
<@almindor:matrix.org> I also fail to see the appeal of Delay<u8> fo rexample
<re_irc>
<@therealprof:matrix.org> As I said In my eyes they're completely different things.
<re_irc>
<@dirbaio:matrix.org> "Delay" is "block for at least X time, no promises on power consumption or anything"
<re_irc>
<@pinealservo:matrix.org> Knowing what a solution that takes into account a lot of the existing complexities and is compatible with a wide range of hardware at least gives an idea of what lower-level pieces you might build to avoid ruling out the more comprehensive solution.
<re_irc>
<@dirbaio:matrix.org> there could be a marker trait for "LowPowerDelay" or something that asserts "this delay impl is low power"
<re_irc>
<@dirbaio:matrix.org> but that's a separate issue to the time types imo
<re_irc>
<@almindor:matrix.org> I think sleeps should be completely separate
<re_irc>
<@therealprof:matrix.org> dirbaio:matrix.org: Yes, and if the implementation is able to sleep for a good bit of that time I'd call that an happy accident.
<re_irc>
<@dirbaio:matrix.org> still I dunno what the use for LowPowerDelay would be
<re_irc>
<@almindor:matrix.org> sleeps will never be completely precise either IMO so they should be considered a problem of its own
<re_irc>
<@dirbaio:matrix.org> a driver requiring LowPowerDelay would be quite rude
<re_irc>
<@almindor:matrix.org> polling a sensor?
<re_irc>
<@dirbaio:matrix.org> if i want to waste power the driver should let me
<re_irc>
<@therealprof:matrix.org> A sleep could be precise.
<re_irc>
<@therealprof:matrix.org> Quite a bit of technology is counting on "race-to-sleep" and precision wake up to get to low power.
fabic has joined #rust-embedded
<re_irc>
<@almindor:matrix.org> dirbaio:matrix.org: agreed, the use cases for sleep are IMO different and mostly out of driver
<re_irc>
<@dirbaio:matrix.org> what's the difference between sleep and delay for you almindor ?
<re_irc>
<@dirbaio:matrix.org> lowpower?
<re_irc>
<@dirbaio:matrix.org> or you mean something else?
<re_irc>
<@almindor:matrix.org> low power polling sensor kind of thing, e.g. beehive sensor controller that saves things on periods
<re_irc>
<@almindor:matrix.org> power modes can be too aggressive sometimes if you need high enough granularity but low enough so that you can still "softsleep"
<re_irc>
<@dirbaio:matrix.org> hmm
<re_irc>
<@dirbaio:matrix.org> yeah abstracting over that will be hard :D
<re_irc>
<@almindor:matrix.org> I think that should be separate tho, I think the "Delay" trait should simply be "blocking, probably busyloop delay" with some promises
<re_irc>
<@therealprof:matrix.org> I think that's also the main characterstic difference between sleep and delay: for delay the defining element is the sleep duration, for sleep the main characterstic is the wakeup time.
<re_irc>
<@almindor:matrix.org> do you guys think as first step it'd make sense to limit the delay "primitive" to u32 or is u16 required for 16bit platforms?
<re_irc>
<@almindor:matrix.org> I guess the question is: would it be possible to de-generify the storage type?
<re_irc>
<@dirbaio:matrix.org> maybe...
<re_irc>
<@tangojuliett:matrix.org> How do I get started with rp-rs and the Adafruit Macropad?
<re_irc>
<@firefrommoonlight:matrix.org> Use the timing mechanism suitable for the situation and hardware avail. I don't think there's a good way to make it a generic trait
fabic has quit [Ping timeout: 264 seconds]
<re_irc>
<@firefrommoonlight:matrix.org> Individual use cases are usually too specific
<re_irc>
<@firefrommoonlight:matrix.org> *The generic blocking delays are fine for rough prototyping etc
<re_irc>
<@therealprof:matrix.org> TJ Peden: Where to begin? 😅
<re_irc>
<@therealprof:matrix.org> Have you checked out #rp-rs:matrix.org ?
<re_irc>
<@tangojuliett:matrix.org> That makes sense, I'll start there
emerent has quit [Ping timeout: 264 seconds]
emerent has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> hi room ! meeting time again, though I've just walked in the door so am putting an agenda together now... we'll start in ~5min 👋
<re_irc>
<@therealprof:matrix.org> Just finished watching the CTCFT recording... 😉
<re_irc>
<@adamgreig:matrix.org> it was 2-3am my time and i was v tired lol
<re_irc>
<@therealprof:matrix.org> You did great. 😉
<re_irc>
<@adamgreig:matrix.org> if anyone objects to my description of what we do i am sorry in advance
<re_irc>
<@therealprof:matrix.org> adamgreig: I think that was a great and accurate summary of what we do.
<re_irc>
<@adamgreig:matrix.org> ok, let's get started!
<re_irc>
<@adamgreig:matrix.org> no announcements from me, does anyone have anything to announce?
<re_irc>
<@hargonix:matrix.org> I have won the fight against the magnetometer on the micro:bit and the last PR to get the discovery microbit version done (content wise) is now only pending on the publication of a documentation change so I can link to it. So I guess we could get started looking into setting up this dual book hosting thingy we talked about the other week? Though I dont know at all what has to be done in order to get that set..
<re_irc>
... up
<re_irc>
<@therealprof:matrix.org> thejpster is spending paid time to work on rp2040 support.
<re_irc>
<@adamgreig:matrix.org> cool! yea, let's look into that, I think we can just extend the CI scripts to build two books in two directories perhaps
<re_irc>
<@therealprof:matrix.org> adamgreig: Yes, and maybe add a bipolar landing page?
<re_irc>
<@adamgreig:matrix.org> yep, landing page highlighting the new one and just linking to the second for people who have the old board
<re_irc>
<@adamgreig:matrix.org> we can use the docs homepage as a template for it
<re_irc>
<@adamgreig:matrix.org> (and probably just link directly to the new book from the docs homepage)
<re_irc>
<@therealprof:matrix.org> I don't quite remember but was the discovery book also linked from the Rust bookshelf?
<re_irc>
<@dkhayes117:matrix.org> I talked with mabez, and he mentioned Espressif is spinning up a new ESP32-C3 Dev board and asked for input for supplied peripherals etc. We suggested mimicking the STM discovery / Microbit boards. I think this board will be the one to go with for the RISC-V addition to the discovery book once available :D
<re_irc>
<@therealprof:matrix.org> therealprof:matrix.org: Nope, it isn't. Only the embedded book.
<re_irc>
<@therealprof:matrix.org> Maybe we should start crossreferencing. 😉
<re_irc>
<@adamgreig:matrix.org> we do already, right? the book links to discovery etc
<re_irc>
<@hargonix:matrix.org> i know for sure that the discovery book links to the other ones
<re_irc>
<@therealprof:matrix.org> Yeah, under other resources. Hm, a bit oldfashioned maybe. 😅
<re_irc>
<@adamgreig:matrix.org> could add a link in the intro text too
<re_irc>
<@adamgreig:matrix.org> anyway, cool, hargonix maybe let's chat later about getting dual rendering working? probably best to get something working locally and then work out the CI, I can have a go or help with it
<re_irc>
<@adamgreig:matrix.org> might need a confusing git merge to get the new stuff into the same timeline as the old stuff 🤔
<re_irc>
<@hargonix:matrix.org> I have to admit I have no clue how the deployment of our book and website works^^
<re_irc>
<@adamgreig:matrix.org> i know too much about it, so together... perfect
<re_irc>
<@hargonix:matrix.org> xdd
<re_irc>
<@adamgreig:matrix.org> next up on the agenda, the topic of splitting up the cortex-m crate into a PAC and HAL and intrinsics has come up again and I still think it's a good idea, I think especially starting by getting a svd file and svd2rust generated PAC (though we can argue about svd2rust vs chiptool vs ral...), is anyone interested in helping with such a thing?
<re_irc>
<@adamgreig:matrix.org> there's already a template svd that has most registers but not fields, I think the initial bulk of the work would be getting field definitions sorted, I'm also sure there are some existing svds floating around with a lot of peripherals filled in
<re_irc>
<@therealprof:matrix.org> Interest: a lot, time: nope.
<re_irc>
<@hargonix:matrix.org> I would be interested when the discovery thing is finally fully through but idk exactly when that is
<re_irc>
<@adamgreig:matrix.org> 👍️ I'll see if I can put together more of a structure and drop a few reminders in the chat too to see if people want to jump in
<re_irc>
<@adamgreig:matrix.org> would be nice to finally get cortex-m using the same PAC APIs as the chip peripherals
<re_irc>
<@firefrommoonlight:matrix.org> dkhayes117:matrix.org: The discovery board peripherals vary wildly depending on which one
<re_irc>
<@firefrommoonlight:matrix.org> Chrono is perhaps the nicest date/time library in any language, supports no std, and has clean copy types including Duration
<re_irc>
<@adamgreig:matrix.org> that's just core::time::Duration with some sign bits
<re_irc>
<@eldruin:matrix.org> I hesitate about removing delay because there is no clear successor and publishing a 1.0 where a basic building block for a blinky is not included looks like a regression.
<re_irc>
<@adamgreig:matrix.org> we _could_ keep DelayUs and DelayMs for that role but if we do have a fledgling plan for a new duration trait that would allow us/ms/etc that would be nicer for delay
<re_irc>
<@dirbaio:matrix.org> what when we get the "good" design for how to deal with durations?
<re_irc>
<@hargonix:matrix.org> There are also chips that expect drivers to wait a certain amount of time to do some internal steup etc. before talking to them again so those drivers would be broken as well without a Delay abstraction
<re_irc>
<@adamgreig:matrix.org> worst case you deprecate DelayUs and DelayMs and leave them in, perhaps implemented in terms of the new design
<re_irc>
<@almindor:matrix.org> eldruin:matrix.org: I'd say then remove DelayMs and make it all DelayUs, the current status to me would be a disaster in v1.0
<re_irc>
<@dirbaio:matrix.org> eh1.0 without Delay is quite useful to a lot of people already
<re_irc>
<@eldruin:matrix.org> yeah I brought that up as well
<re_irc>
<@thejpster:matrix.org> As a general item
<re_irc>
<@adamgreig:matrix.org> thejpster:matrix.org: sure thing, could you add it to the agenda?
<re_irc>
<@adamgreig:matrix.org> for the separate buffers, is there any remaining points of disagreement beyond the Read trait on SPI?
<re_irc>
<@adamgreig:matrix.org> I still feel like just making the transmitted data implementation-defined should be fine for that, heh
<re_irc>
<@dirbaio:matrix.org> almindor: +1'
<re_irc>
<@dirbaio:matrix.org> updated the PR description (naming is now Transfer, not ReadWrite)
<re_irc>
<@eldruin:matrix.org> I'm fine with that being implementation defined. the PR looks good to me
<re_irc>
<@dirbaio:matrix.org> also, related to that
<re_irc>
<@dirbaio:matrix.org> is Transactional a good idea?
<re_irc>
<@firefrommoonlight:matrix.org> I do lots of things with embedded, but have 0 use for embedded Hal, and am not sure what the use is
<re_irc>
<@dirbaio:matrix.org> every new "kind of transfer" needs to be added to it, which is a breaking change
<re_irc>
<@thejpster:matrix.org> Turns out, yes, I can edit HackMD on mobile Firefox. What a time to be alive.
<re_irc>
<@adamgreig:matrix.org> truly we live in the future
<re_irc>
<@almindor:matrix.org> is `Should Transactional gain Read, Transfer (not-inplace) support?` answered?
<re_irc>
<@eldruin:matrix.org> Ah, I missed that, thanks
<re_irc>
<@therealprof:matrix.org> I don't have a opinion about #287, if it works for you that's good enough for me.
<re_irc>
<@almindor:matrix.org> IMO transactional should have both options in the set then
<re_irc>
<@adamgreig:matrix.org> dirbaio:matrix.org: do you think there might be other kinds of transfer?
<re_irc>
<@dirbaio:matrix.org> I dunno, probably not I guess
<re_irc>
<@eldruin:matrix.org> the default implementations should be removed I guess
<re_irc>
<@dirbaio:matrix.org> eldruin:matrix.org: ah yeah that's before the rebase
<re_irc>
<@dirbaio:matrix.org> lemme update it
<re_irc>
<@eldruin:matrix.org> ok you can do that after the meeting
<re_irc>
<@eldruin:matrix.org> maybe we can discuss more topics?
<re_irc>
<@eldruin:matrix.org> delay or some other PR
<re_irc>
<@adamgreig:matrix.org> I'd like to keep the last ten minutes for thejpster's point, but we could discuss another for a few minutes first
<re_irc>
<@adamgreig:matrix.org> last time we started talking about a potential delay trait that could accommodate a lot of use cases, did that get anywhere?
<re_irc>
<@adamgreig:matrix.org> can't tell if it's genius or sort of a cop-out where we just shunt the "how to represent time" problem to users, heh
<re_irc>
<@almindor:matrix.org> i think the most optimistic we can hope for is the decision of whether to remove Delay from e-h 1.0 at this point
<re_irc>
<@adamgreig:matrix.org> I feel like in practice enough things use delay that not having it in 1.0 would be a pretty big barrier to people actually updating to 1.0?
<re_irc>
<@adamgreig:matrix.org> this is definitely not an accurate survey of e-h-using crates though
<re_irc>
<@almindor:matrix.org> i'd be completely happy if we were at least able to make it a single trait instead of two
<re_irc>
<@adamgreig:matrix.org> though I totally take dirbaio 's point that leaving just like DelayUs around as a bad smell isn't a great solution either
<re_irc>
<@almindor:matrix.org> just combine DelayUs and DelayMs into one trait
<re_irc>
<@adamgreig:matrix.org> I guess that is _better_ :P
<re_irc>
<@adamgreig:matrix.org> even if we ended up with deprecated DelayUs and Delay by 1.1
<re_irc>
<@adamgreig:matrix.org> it would presumably be super easy for people to upgrade DelayUs->Delay
<re_irc>
<@eldruin:matrix.org> yay suffixes
<re_irc>
<@dirbaio:matrix.org> delay, with hardcoded us and hardcoded u32?
<re_irc>
<@adamgreig:matrix.org> oh, just call it delay, limit it to µs resolution and u32, and call it done?
<re_irc>
<@adamgreig:matrix.org> that's like 1.5 hour maximum delay?
<re_irc>
<@dirbaio:matrix.org> I'd reserve the "Delay" name for the final good real delay
<re_irc>
<@adamgreig:matrix.org> but keep a compromise DelayUs for now?
<re_irc>
<@almindor:matrix.org> so DelayUs with u32 for e-h 1.0 as a basic placeholder for existing code everyone mostly uses then?
<re_irc>
<@almindor:matrix.org> and Delay using probably custom Time for post 1.0
<re_irc>
<@dirbaio:matrix.org> DelayUs with fixed u32 is a nice compromise yeah
<re_irc>
<@adamgreig:matrix.org> smells like it could be a good compromise in that no one is going to be totally pleased with it but it's hard to fully object lol
<re_irc>
<@thejpster:matrix.org> Works for me
<re_irc>
<@eldruin:matrix.org> yeah I can live with that
<re_irc>
<@dirbaio:matrix.org> works great for the "wait for chip to initialize" usecase which is the vast majority of usecases currently
<re_irc>
<@thejpster:matrix.org> So, imagine you've bought a new Embedded board
<re_irc>
<@thejpster:matrix.org> Your know a little Rust - enough to be dangerous
<re_irc>
<@thejpster:matrix.org> What do we imagine a "first class" experience is, for this person.
<re_irc>
<@thejpster:matrix.org> Doing Embedded rust on the board, if that's not clear
<re_irc>
<@thejpster:matrix.org> What can we do right, or what should we not do, to ensure they tell all their friends that embedded Rust is great
<re_irc>
<@thejpster:matrix.org> I have thoughts around documentation, flashing tools, etc. But I'd like to hear what we should do and what we should not do.
<re_irc>
<@dkhayes117:matrix.org> A well-documented HAL with useful examples. The quickstart repos are really nice.
<re_irc>
<@eldruin:matrix.org> blinky runs on your board with 1 command. You can step-debug through the code in your editor of choice, possibly VSCode with 1-click setup
<re_irc>
<@thejpster:matrix.org> Bearing in mind a lot of the code won't be REWG owned. But maybe we can give advice to the chip orgs.
<re_irc>
<@dirbaio:matrix.org> blinky is 5 lines, not 30
<re_irc>
<@hargonix:matrix.org> With the tooling thats around right now that'd be for me:
<re_irc>
<@hargonix:matrix.org> - We have a PAC + HAL + drivers for all the chips on the board bundled into a BSP like the microbit one
<re_irc>
<@hargonix:matrix.org> - cargo-embed/probe-run already support the chip
<re_irc>
<@hargonix:matrix.org> - We have examples on at least the most relevant bits on the board (This is incredibly important, I talk to a lot of beginners who are frustrated about the lack of examples in some HALs because they cannot read the docs.rs good enough yet)
<re_irc>
<@thejpster:matrix.org> Dirbaio: how about five lines of code, 30 lines of comments
<re_irc>
<@almindor:matrix.org> code is not the main issue IMO
<re_irc>
<@dirbaio:matrix.org> yeah I mean 5 lines of code inside main{}
<re_irc>
<@almindor:matrix.org> the biggest blockers for new embedded people are things like flashing methods
<re_irc>
<@thejpster:matrix.org> So for flashing, we have probe-run, the RP2040 fork of probe run. esp-rs have a tool I think
<re_irc>
<@dkhayes117:matrix.org> The `.constrain()` type things are not good imho
<re_irc>
<@thejpster:matrix.org> What do the Nordic and ST people do?
<re_irc>
<@dirbaio:matrix.org> Nordic, ST is usually via a probe, with probe-rs
<re_irc>
<@mabez:matrix.org> thejpster:matrix.org: we have a tool (for flashing over serial) but are also adding probe-rs support too :)
<re_irc>
<@dirbaio:matrix.org> flashing via an USB bootloader is really annoying
<re_irc>
<@thejpster:matrix.org> I don't understand what constrain does that :new(p.THING) cannot.
<cr1901>
thejpster: There's a "quick" way to add msp430 support to probe-rs, but I haven't had time to impl it yet
<cr1901>
FWIW
<re_irc>
<@adamgreig:matrix.org> (for dev boards like the ST nucleos and discovery boards, cargo-embed/probe-run just work fine too, including rtt)
<re_irc>
<@cuno555:matrix.org> Provide a simple and quick and reliable setup experience, until first success experience. Small number of tools to install, configuration / build setup hassles. In the code itself: small number of small dependencies that lead to small code footprint.
<re_irc>
<@dkhayes117:matrix.org> mabez:matrix.org: espflash 1.0 was just released I think
<re_irc>
<@thejpster:matrix.org> cr1901 - excellent! Arm most not be the only first class option.
<cr1901>
But I do not have the bandwidth to reimplement mspdebug in Rust.
<cr1901>
So there would be an external tool involved even if it's at the process boundary
<re_irc>
<@dirbaio:matrix.org> setup should be
<re_irc>
<@dirbaio:matrix.org> - git clone example project
<re_irc>
<@dirbaio:matrix.org> - plug in board USB
<re_irc>
<@hargonix:matrix.org> There'd at least be the part where you have to install the proper target arch either manually or with a script in there as well
<re_irc>
<@dirbaio:matrix.org> with rust-toolchain.toml you can install targets and components automatically
<re_irc>
<@thejpster:matrix.org> Certainly having to install GCC and binutils is not first class
<re_irc>
<@adamgreig:matrix.org> what's missing from that list dirbaio?
<re_irc>
<@thejpster:matrix.org> TIL rust-toolchain
<re_irc>
<@adamgreig:matrix.org> i feel like that's basically already how it works
<re_irc>
<@almindor:matrix.org> probe-rs is great, except when it's not. I don't think there's a good unified way which sucks (e.g. on RiscV boards probe-rs is brokenly-slow atm.)
<re_irc>
<@eldruin:matrix.org> thejpster:matrix.org: especially for windows people
<re_irc>
<@adamgreig:matrix.org> what needs gcc and binutils these days?
<re_irc>
<@thejpster:matrix.org> They have enough problems already
<re_irc>
<@almindor:matrix.org> riscv quickstart uses binutils/gdb and jlink
<cr1901>
adamgreig: msp430 needs gcc/binutils for the linker
<re_irc>
<@adamgreig:matrix.org> ah, got it
<cr1901>
thejpster: The problem w/ mspdebug is that it's GPL. There's too many contributors that would have to relicense their code to link it in as a library
<re_irc>
<@thejpster:matrix.org> Rp-rs aren't shipping compiled boot blobs yet, so need as
<re_irc>
<@thejpster:matrix.org> Or a rewrite in Rust, that fits in 254 bytes
<cr1901>
so that would imply having to compile mspdebug binary as part of probe-rs
<re_irc>
<@adamgreig:matrix.org> can't the rp crate ship a binary blob to solve that?
<re_irc>
<@adamgreig:matrix.org> a la cortex-m/cortex-m-rt's binary asm
<re_irc>
<@dirbaio:matrix.org> adamgreig: project templates are "for any chip". HALs have examples but they don't have the full "project structure" ready to go. You currently have to
<re_irc>
<@almindor:matrix.org> dirbaio:matrix.org: you also need .cargo/config to link properly
<re_irc>
<@thejpster:matrix.org> Hmm, going from example to crate is an interesting and non trivial step
<re_irc>
<@adamgreig:matrix.org> hmm
<re_irc>
<@thejpster:matrix.org> Learning to move Dev-deps up to deps
<re_irc>
<@adamgreig:matrix.org> I feel like you git clone the HAL and run "cargo run --example blinky"
<re_irc>
<@adamgreig:matrix.org> and that's it?
<re_irc>
<@adamgreig:matrix.org> the HAL crate can already have a working .cargo/config.toml
<re_irc>
<@dirbaio:matrix.org> yeah but that doesn't get you a "standalone project"
<re_irc>
<@thejpster:matrix.org> That's step 1
<re_irc>
<@hargonix:matrix.org> no they mean setting up your own crate that uses the HAL as a librayr
<re_irc>
<@almindor:matrix.org> no, hal isn't good enough you need a .cargo/config + linkage and memory choices for example
<re_irc>
<@adamgreig:matrix.org> ah, sure
<re_irc>
<@thejpster:matrix.org> But you want to make your own code next.
<re_irc>
<@almindor:matrix.org> it's core -> hal -> board -> quickstart
<re_irc>
<@adamgreig:matrix.org> some of the HALs definitely already have .cargo/config and memory.x sorted for you
<re_irc>
<@adamgreig:matrix.org> basically you're saying you want a XXX-hal-quickstart crate for each HAL, that is a little demo project using the HAL?
<re_irc>
<@hargonix:matrix.org> memory.x is also a thing that might be confusing to beginners, to a total embeddd beginner the content just looks sort of magical? And they might not realize they
<re_irc>
<@hargonix:matrix.org> a) need it as well
<re_irc>
<@hargonix:matrix.org> b) where to get it
<re_irc>
<@thejpster:matrix.org> Actually, yes. We should be consistent about who supplies memory.x
<re_irc>
<@thejpster:matrix.org> Also, wtf is it a .x file
<re_irc>
<@almindor:matrix.org> I think there are 4 layers tho right? 1. core 2. hal 3. board 4. "glue/quickstart"
<re_irc>
<@adamgreig:matrix.org> not sure .ld would be any less confusing
<re_irc>
<@thejpster:matrix.org> Everyone else calls it a .ld for
<re_irc>
<@almindor:matrix.org> oh and name it .ld please
<re_irc>
<@adamgreig:matrix.org> lol
<re_irc>
<@adamgreig:matrix.org> I stand corrected I guess
<re_irc>
<@thejpster:matrix.org> Like, vscode knows what an .ld is
<re_irc>
<@dirbaio:matrix.org> I had never seen .x before rusting
<re_irc>
<@thejpster:matrix.org> Oof, now that's a breaking change
<re_irc>
<@thejpster:matrix.org> Maybe wanna squeeze that in before 1.0
<re_irc>
<@hargonix:matrix.org> Ok so memory.x -> memory.ld + central source of memory.ld, that's something rather trivial we can do right now/ in the next weeks right?
<re_irc>
<@almindor:matrix.org> "prefer .ld in upcoming release chains" :P
<re_irc>
<@thejpster:matrix.org> Of... cortex-m-rt? I can't remember which crate does the magic
<re_irc>
<@adamgreig:matrix.org> renaming memory.x to memory.ld will be a huge breaking change
<re_irc>
<@adamgreig:matrix.org> requiring a new breaking release of cortex-m-rt
<re_irc>
<@almindor:matrix.org> it's not necessary
<re_irc>
<@almindor:matrix.org> i'd ask new setups to use .ld only
<re_irc>
<@hargonix:matrix.org> there could e.g. be an archive of memory.ld/memory.x on the wg webpage people can just pick their thingy from
<re_irc>
<@almindor:matrix.org> I think more importantly we should standardize the crates structure
<re_irc>
<@thejpster:matrix.org> Ooh, a web version of cargo template
<re_irc>
<@almindor:matrix.org> and which one is responsible for which linking parts
<re_irc>
<@adamgreig:matrix.org> that seems like something that should be provided by the family orgs, not the wg
<re_irc>
<@dkhayes117:matrix.org> When I started, memory.x wasn't that vewing to me. the `x` extension is a little weird, but it was obvious what it was for to me
<re_irc>
<@thejpster:matrix.org> Tick RP2040
<re_irc>
<@thejpster:matrix.org> Tick Pico
<re_irc>
<@adamgreig:matrix.org> (as many HALs already do)
<re_irc>
<@almindor:matrix.org> well .ld is "correct" coz we use gnu linker script specifically but it's really a non-point. I was kinda joking with the rename. I'd just prefer new things use it
<re_irc>
<@thejpster:matrix.org> I wonder if there's a way to get the chip orgs together more often, to share examples and ideas
<re_irc>
<@adamgreig:matrix.org> I think many of them hang out in here but we don't have any sort of organised meetings or anything
<re_irc>
<@thejpster:matrix.org> Also, is it ok to cargo install from build.rs?
<re_irc>
<@thejpster:matrix.org> Or should you tell the user to run cargo install a tool they need
<re_irc>
<@almindor:matrix.org> thejpster:matrix.org: why not npm while we're at it? :P
dcz has quit [Ping timeout: 246 seconds]
<re_irc>
<@thejpster:matrix.org> Or let them work it out from "probe-run not found"
<re_irc>
<@adamgreig:matrix.org> hopefully they're following some kind of guide
<re_irc>
<@adamgreig:matrix.org> so it seems reasonable to ask them to install everything you need at once
<re_irc>
<@adamgreig:matrix.org> you'll need to tell them how to install rust, right?
<re_irc>
<@dirbaio:matrix.org> just opening a project in an IDE can trigger build.rs
<re_irc>
<@almindor:matrix.org> good dependency documentation solves that issue, part of the quickstart crate preferably
<re_irc>
<@dirbaio:matrix.org> it's super rude to modify system-wide things in build.rs
<re_irc>
<@adamgreig:matrix.org> gracefully handling the error and suggesting how to install something sounds nice though
<re_irc>
<@adamgreig:matrix.org> dirbaio: whatever, even proc macros can install stuff system-wide
<re_irc>
<@adamgreig:matrix.org> "do-not-open.rs"
<re_irc>
<@dirbaio:matrix.org> yup, but... *rude*
<re_irc>
<@adamgreig:matrix.org> (to be clear I completely agree, installing stuff inside build.rs or a proc-macro sounds bad lol)
<re_irc>
<@adamgreig:matrix.org> oops, we're over time for the meeting and I have to run, but please feel free to continue discussing, thanks everyone!
<re_irc>
<@thejpster:matrix.org> Ok, this was useful! I will try to look back at the logs later
<re_irc>
<@dirbaio:matrix.org> I guess downloading things into `target/` would be *okay but meh*
<re_irc>
<@thejpster:matrix.org> Unless anyway was taking notes...
<re_irc>
<@dirbaio:matrix.org> but installing system-wide pls no
<re_irc>
<@hargonix:matrix.org> I did consider to do that for a moment :p
<re_irc>
<@adamgreig:matrix.org> no 💀I was about to cop out and say in the minutes to check the logs, hah
<re_irc>
<@adamgreig:matrix.org> if anyone wants to write some notes up quickly in the agenda I'll leave it for a few minutes before PRing the minutes
<re_irc>
<@adamgreig:matrix.org> otherwise I'll just add a link to the logs when I get back :P
<re_irc>
<@therealprof:matrix.org> adamgreig: I don't recall having seen that ever pre-Rust...
<re_irc>
<@thejpster:matrix.org> Can't argue with Cool Bear
<re_irc>
<@adamgreig:matrix.org> At least the logs are just a static html page instead of having to log in to slack lol
<re_irc>
<@mabez:matrix.org> thejpster:matrix.org: FYI If a recurring meeting, or some other channel of communication comes up for chip org level discussion please ping me, I'd be interested in getting involved :)
<re_irc>
<@thejpster:matrix.org> I think my takeaway from this is to make a bunch of fully fledged crate examples, not just single example/foo.rs examples.
<re_irc>
<@thejpster:matrix.org> mabez:matrix.org: It feels like a meeting of the chiefs of five warring clans
<re_irc>
<@thejpster:matrix.org> When the moon is full they set aside their differences and meet to show off their finest Markdown
<re_irc>
<@therealprof:matrix.org> FWIW: nRF crates have been moving away from single file examples...
<re_irc>
<@thejpster:matrix.org> First Tuesday of the month, after the REWG meeting?
<re_irc>
<@thejpster:matrix.org> The standing agenda item is: What's new in your org? Show me your best HAL / Example / Quickstart. 10 minutes each, tops.
<re_irc>
<@hargonix:matrix.org> That would imply the org itself can agree on a best X...
<re_irc>
<@grantm11235:matrix.org> dirbaio:matrix.org: You forgot to pass `&mut gpioa.crl`
<re_irc>
<@dirbaio:matrix.org> oh and `&mut rcc.exticr`
<re_irc>
<@thejpster:matrix.org> They must fight that out amongst themselves
<re_irc>
<@dirbaio:matrix.org> and for that you need to constrain() and freeze() rcc too!
<re_irc>
<@hargonix:matrix.org> dirbaio:matrix.org: nah some HALs just implicitly do that via RCC::ptr() inside of the function and dont require you to pass it, are you really expecting that we are able to construct consistent GPIO APIs?
<re_irc>
<@dirbaio:matrix.org> and freezing rcc requires .freezinate() and .constrangle() PWR too
<re_irc>
<@dirbaio:matrix.org> so your blinky is now 30 lines
<re_irc>
<@thejpster:matrix.org> Let's not forget that design decisions almost always have some thought behind them
<re_irc>
<@thejpster:matrix.org> And if they seem odd, it's probably just not the thoughts we've had
<re_irc>
<@jannic:matrix.org> How about abstracting that away in a hardware abstraction layer abstraction layer?
<re_irc>
<@thejpster:matrix.org> That's just Arduino
<re_irc>
<@hargonix:matrix.org> it'd be more like a vendor abstraction layer
<re_irc>
<@dirbaio:matrix.org> these HAL design decisions come mainly from the PAC owned peripherals
<re_irc>
<@dirbaio:matrix.org> PAC owned peripherals do make a lot of sense
<re_irc>
<@dirbaio:matrix.org> but if they force HALs to have weird APIs are they really worth it?
<re_irc>
<@pinealservo:matrix.org> API quirks like those do cause onboarding friction, but changing them also causes friction and takes time. Constantly harping on them, especially in a sarcastic manner, is not very conducive to actually motivating change.
<re_irc>
<@therealprof:matrix.org> thejpster:matrix.org: Or maybe those thoughts have been conceived many years ago when there wasn't even a stable Rust version for embedded use around?
<re_irc>
<@dirbaio:matrix.org> I'm not "constantly harping" on anything
<re_irc>
<@firefrommoonlight:matrix.org> I'm a pain in the ass sometimes; sorry
<re_irc>
<@therealprof:matrix.org> The last 25 minutes or so were certainly not very constructive or friendly.
<re_irc>
<@dirbaio:matrix.org> I saw it as friendly poking fun at each other. fun pokes were directed at me and I definitely found it funny
<re_irc>
<@pinealservo:matrix.org> A lot of really careful thought went into the design of the PAC & HAL layers, but it was done a while ago and maybe not all the elements of the design are as useful as intended, or can be replaced with better things thanks to new language features. I don't think anyone disagrees on that level; it's the "where to go from here" and "how to get there" that's tricky, because despite the quirks, the existing...
<re_irc>
... APIs are both *useful* and *used*, and just tossing them aside is difficult.
<re_irc>
<@thejpster:matrix.org> This is why I think it is useful to have a forum to share "this is our best".
<re_irc>
<@firefrommoonlight:matrix.org> I love the (nRF and STM32) PACs, and most of the spears I have are at ST SVD errors underlying them that they fix one bug at a time
<re_irc>
<@therealprof:matrix.org> dirbaio:matrix.org: It's not "friendly poking fun" when relative newcomers are mocking designs created years ago. There're people from that time around and some do find it hurtful to be "criticised" like that.
<re_irc>
<@thejpster:matrix.org> Hot news just in
<re_irc>
<@thejpster:matrix.org> "In parallel, we’ll be exploring whether we can use a memory safe language for parts of Chrome in the future. The leading contender is Rust, invented by our friends at Mozilla."
<re_irc>
<@firefrommoonlight:matrix.org> I think it's more stubbornness against reconsidering old decisions that triggers this
<re_irc>
<@firefrommoonlight:matrix.org> That's what drove some of my angst at lease
<re_irc>
<@pinealservo:matrix.org> I'm sure it can seem pretty frustrating to see resistance to change, but it's not necessarily "stubbornness" that's driving the resistance.
<re_irc>
<@firefrommoonlight:matrix.org> I can't remember who said this earlier in today's chat, but another cause of different design decisions is different use cases. It's too easy to assume other people's are the same as your own
<re_irc>
<@pinealservo:matrix.org> When you maintain an open source project that's serving as a foundational piece for other things to build on, *stability* is a prime consideration and it takes time to manage significant changes, even when you really want to make them.
<re_irc>
<@firefrommoonlight:matrix.org> I'm with you
<re_irc>
<@firefrommoonlight:matrix.org> But if I don't already have a big old codebase, I'm not going to use or contribute to an API that doesn't work for me
<re_irc>
<@firefrommoonlight:matrix.org> And this isn't a problem
<re_irc>
<@pinealservo:matrix.org> Actually having users is a double-edged sword. :)
<re_irc>
<@dirbaio:matrix.org> therealprof:matrix.org: 1. It makes for a very unfriendly and unwelcoming community if "relative newcomers" opinions are worth less because they're "relative newcomers".
<re_irc>
<@dirbaio:matrix.org> 2. "mocking" is a very strong word. I strongly reject the claim I've "mocked" anything.
<re_irc>
<@dirbaio:matrix.org> 3. My criticism has always been constructive. Every time I've criticized some design decision, I've come up with alternatives. Hours-long discussions of pros and cons have been had, in this channel and in GitHub. I've always been "X has problems A, B, If you do Y instead, these problems are mitigated, while keeping the advantages C and D of X". I've never said "X sucks, I don't like it".
<re_irc>
<@dirbaio:matrix.org> 4. Such constructive discussions haven't taken place at the above "poking fun" because they've happened in the past and our respective opinions are clear. Claiming I'm being "not constructive" because of it is disingenuous at best, misleading at worst.
<re_irc>
<@firefrommoonlight:matrix.org> Dude, just ignore him
<re_irc>
<@firefrommoonlight:matrix.org> He's a troll
<re_irc>
<@firefrommoonlight:matrix.org> He will NEVER change his opinion on anything
<re_irc>
<@firefrommoonlight:matrix.org> Sorry, you're right
<re_irc>
<@firefrommoonlight:matrix.org> I'll take my own advice
<re_irc>
<@dkhayes117:matrix.org> If I came off as "mocking" that was certainly not my thought pattern. My apologies if taken as such.
<re_irc>
<@pinealservo:matrix.org> I don't always agree with therealprof but he's been doing a pretty large share of the maintenance work on core embedded rust stuff for a long while now, which is a pretty thankless and difficult task, and one which provides a good bit of insight. I am grateful to him and appreciate his view, and I also appreciate the enthusiasm and fresh ideas of the relative newcomers, and I'd like to see conversation...
<re_irc>
... here move in a direction that's mutually beneficial rather than to see grudges building up.
<re_irc>
<@pinealservo:matrix.org> Nobody's *indending* to be dismissive or hurtful, or so I hope, but it's clear that some things are being *interpreted* that way, and I'm just bringing this up in the hopes that the awareness of such will help people to avoid being misinterpreted in the future.
<re_irc>
<@jannic:matrix.org> I didn't interpret what dirbaio and others wrote above as mocking somebody. But I understand it could be seen as such. Also, my sentence about "abstracting over HALs" could be read as dismissive. Sorry, it was not meant that way.
<re_irc>
<@therealprof:matrix.org> > 2. "mocking" is a very strong word. I strongly reject the claim I've "mocked" anything.
<re_irc>
<@therealprof:matrix.org> I'm not going to discuss this any further and yes, you didn't start it, but I definitely consider
<re_irc>
<@therealprof:matrix.org> > more like Pin<'A', 1, Input<Pull<Up>>> lately
<re_irc>
<@therealprof:matrix.org> a blow below the waist.
<re_irc>
<@firefrommoonlight:matrix.org> I can change the topic to some obscure wall of technical questions if y'all would like
<re_irc>
<@thalesfragoso:matrix.org> I'm pretty sure most (if not all) of the criticism here was constructive and with good intentions. But we might have to be a little more careful on the tone, I personally don't care about general tone, because I know you folks and I know you don't meant any harm.
<re_irc>
<@thalesfragoso:matrix.org> However, not everyone here is familiar with all faces, which can cause problems. I recently read some discussion on an unrelated Discord server, where a Rust newcomer, when asked, said that the HAL ecosystem was a **train wreck** and even the rust embedded community admitted that
<re_irc>
<@dirbaio:matrix.org> therealprof: you know full well why I hold the opinions I hold
<re_irc>
<@dirbaio:matrix.org> YOU have been part of such discussions
<re_irc>
<@dirbaio:matrix.org> discussions where we discussed the technical pros and cons of singletons, typestates, const generics, etc etc
<re_irc>
<@dirbaio:matrix.org> after such discussions we still have different opinions. We value different things in the present tradeoffs. That's 100% fine, I have absolutely no problem with that.
<re_irc>
<@roedimqf:ruhr-uni-bochum.de> thejpster:matrix.org: As a hobbyist programmer i loved ivmarkov/rust-esp32-std-hello as a starting point for an embedded project. Though i missed some examples on how to use the embedded periphery like GPIOs. For example, is this the way to go?
<re_irc>
<@dirbaio:matrix.org> What I DO have a problem with is you then claiming I'm being "non-constructive", "mocking", etc
<re_irc>
<@dirbaio:matrix.org> You know full well the above messages refer to these hours long *constructive* discussions you've been part of
<re_irc>
<@thalesfragoso:matrix.org> So, given that, even if you folks are worried about making things better for newcomers and attract more people, we might end up doing the opposite if not being careful with the tone
<re_irc>
<@dirbaio:matrix.org> you're taking my messages out of context to make them appear as something they're not
<re_irc>
<@dirbaio:matrix.org> to people that don't have such context
<re_irc>
<@roedimqf:ruhr-uni-bochum.de> firefrommoonlight: do you mean this Pin `use esp_idf_hal::gpio::Pin;`?
<re_irc>
<@firefrommoonlight:matrix.org> Sort of. I'm referring to general API design, but yes, that is how I've set up the HALs I use
<re_irc>
<@firefrommoonlight:matrix.org> Substituting the first section of that import
<re_irc>
<@therealprof:matrix.org> dirbaio: Do I really need to put my admin/moderator hat on and hand out an official warning to make you understand that people are offended when you make fun of their APIs (also known as mocking)? I am personally hurt by that and you can't claim that it is fun all all around when the people you're making fun off are not laughing with you!
<re_irc>
<@dirbaio:matrix.org> fun has been made of my APIs too
<re_irc>
<@dirbaio:matrix.org> I honestly think you're overreacting
<re_irc>
<@firefrommoonlight:matrix.org> See?
<re_irc>
<@firefrommoonlight:matrix.org> Sorry
<re_irc>
<@firefrommoonlight:matrix.org> This is bull
<re_irc>
<@firefrommoonlight:matrix.org> This guy has a 100% asshole to content ratio
<re_irc>
<@thejpster:matrix.org> I'm not standing for that. Completely unacceptable.
<re_irc>
<@hargonix:matrix.org> Can't we all just calm down a little bit?
<re_irc>
<@eldruin:matrix.org> firefrommoonlight:matrix.org: whatever your opinion, this comment is not acceptable
<re_irc>
<@pinealservo:matrix.org> Saying "Your joking hurt my feelings" is *not* an accusation of ill intent; it's a notification of how words landed. It's a key stage in conflict resolution. It's *hard to admit* and it's usually done to try to improve communication rather than to make the other person feel bad.
<re_irc>
<@pinealservo:matrix.org> Nevertheless, it's also *hard to hear* especially if you didn't intend to make them feel bad.
<re_irc>
<@dirbaio:matrix.org> pinealservo: I agree with that "in a vacuum", if there was no context/precedents
<re_irc>
<@dirbaio:matrix.org> but there's already a long (year+) history of therealprof throwing varied accusations at me whenever "alternative HAL APis" are discussed
<re_irc>
<@dirbaio:matrix.org> even when the discussions on the table are not "api X has room for improvement"
<re_irc>
<@dirbaio:matrix.org> but merely "look at this prototype thing I wrote"
<re_irc>
<@pinealservo:matrix.org> Apportioning blame is usually not very helpful either, although again it's a very understandable response.
<re_irc>
<@dirbaio:matrix.org> "forking by default", me making "proprietary fork"s, "try to coerce people into using it", "creating confusion"
<re_irc>
<@dirbaio:matrix.org> "reinventing the wheel"
<re_irc>
<@dirbaio:matrix.org> and today "mocking" and being "nonconstructive"
<re_irc>
<@dirbaio:matrix.org> I've had enough of it, this is why I push back
<re_irc>
<@pinealservo:matrix.org> Were you not mocking the API? Was it really constructive?
<re_irc>
<@dirbaio:matrix.org> pinealservo: as I said, the above "mocking" refers to past discussions that *were* constructive, where lots of alternative ideas were discussed, weighing the technical pros and cons for each
<re_irc>
<@dirbaio:matrix.org> AND HE KNOWS IT
<re_irc>
<@dirbaio:matrix.org> he was part of these discussions
<re_irc>
<@dirbaio:matrix.org> so it's not like out of the blue I've come and mocked things
<re_irc>
<@pinealservo:matrix.org> I understand you feel *justified* in doing those things. You're frustrated and you feel like your point of view is not being respected. Nevertheless, reacting by mocking is still hurtful.
<re_irc>
<@dirbaio:matrix.org> I disagree I've mocked anything
<re_irc>
<@pinealservo:matrix.org> I'm not saying that *you* have not also been hurt. I'm suggesting that this style of response to that is likely to undermine your goals.
<re_irc>
<@dirbaio:matrix.org> I have *not* been hurt by the memes / poking fun
<re_irc>
<@dirbaio:matrix.org> I found it funny
<re_irc>
<@dirbaio:matrix.org> and they were directed quite a lot at me
<re_irc>
<@pinealservo:matrix.org> That's not what I meant.
<re_irc>
<@yatekii:matrix.org> wow nice, drama++
<re_irc>
<@pinealservo:matrix.org> From what you've been saying, what I see is that you've been hurt by what you see to be a repeated dismissal of your ideas and accusations that you are trying to split the community. Or if not hurt, then at least frustrated.
<re_irc>
<@hargonix:matrix.org> he's been kicked, no point in continuing for now at least
<re_irc>
<@adamgreig:matrix.org> I kicked firefrommoonlight for egregious violation of the code of conduct, though he's welcome to rejoin and isn't banned (for a first warning)
<re_irc>
<@newam:matrix.org> In other news `const_panic` has just entered the final comment period for stabilization :D
<re_irc>
<@hargonix:matrix.org> does that allow const fns to panic then?
<re_irc>
<@newam:matrix.org> Yup!
<re_irc>
<@newam:matrix.org> And const parameters in generics too (I think(
<re_irc>
<@hargonix:matrix.org> Is that useful for us in a way?
<re_irc>
<@therealprof:matrix.org> hargonix:matrix.org: Yes, and also allows invalid branches in a match statement within a `const fn` to panic.
<re_irc>
<@newam:matrix.org> Very, take a look at R3. Const functions are the way you can do compile time configuration, similar to getting a user to fill in a header file in C.
<re_irc>
<@hargonix:matrix.org> aahh and the panics are then like a compiler_error! right?
<re_irc>
<@hargonix:matrix.org> well a conditional one
<re_irc>
<@therealprof:matrix.org> hargonix:matrix.org: ^ that
<re_irc>
<@hargonix:matrix.org> cool cool
<re_irc>
<@therealprof:matrix.org> So instead of a `Pin<'Z', ...>` turning implicitly into a `Pin<'A', ...>` we can just say: "Nah, that's not a thing".
<re_irc>
<@dkhayes117:matrix.org> therealprof I appreciate your hard work for embedded rust! dirbaio I appreciate you too! And the community as a whole! (Official and unofficial) Lets continue to build awesome embedded rust 💪
sauce has quit [Quit: sauce]
sauce has joined #rust-embedded
<re_irc>
<@yruama_lairba:matrix.org> hi, with rtic, i'd like to know what are the field of a context ?
<re_irc>
<@newam:matrix.org> You can use `cargo expand` to see the macro output.
<re_irc>
<@lachlansneff:matrix.org> therealprof:matrix.org: How does const panic let you do this?
<re_irc>
<@yruama_lairba:matrix.org> in fact, what i really want to know is where i can find the core peripherals
<re_irc>
<@therealprof:matrix.org> lachlansneff:matrix.org: The const constructor contains a match turning the character into an offset. Without const panic the outcome of each of the branches has to be of the same type so some kind of offset.
<re_irc>
<@lachlansneff:matrix.org> therealprof:matrix.org: Is there any code that shows that working?
<re_irc>
<@pinealservo:matrix.org> The context passed to the function you mark with #[init] gets the peripherals in some of its fields; that doc link describes the situation. There are some working examples in various HAL repositories and in the rtic repos as well, I think.
<re_irc>
<@pinealservo:matrix.org> There's also a RTIC-specific channel here: #rtic:matrix.org
<re_irc>
<@lachlansneff:matrix.org> Ah, I get it now :)
<re_irc>
<@therealprof:matrix.org> If you try to put some sort of `panic!` into the remainder arm you'd get a nice warning that const panicking is not stable yet. 😉
<re_irc>
<@yruama_lairba:matrix.org> does RTIC provide something implementing DelayUs ?
<re_irc>
<@yruama_lairba:matrix.org> because, i saw "SYST" may be unavailable with and this is the only thing i know implementing delay
<re_irc>
<@therealprof:matrix.org> Lachlan Sneff: The ability of doing real assertions on a variety of expressions at compile time is huge. At the moment you have to do crude hacks to coerce the compiler into computing crazy expressions to bomb out with a error.
<re_irc>
<@lachlansneff:matrix.org> It seems to me like most of the power would be waiting for const where clauses or whatever those end upbeing
<re_irc>
<@pinealservo:matrix.org> The execution model of RTIC isn't really designed around arbitrary delays in the middle of tasks; it has a scheduler designed around executing some task at a point in the future or scheduling periodic tasks.
<re_irc>
<@yruama_lairba:matrix.org> sh*t i thought my bug was related to a delay issue, but it change nothing
<re_irc>
<@therealprof:matrix.org> Not quite sure how much the RFC will unlock though, haven't had time to read it. Whether it's really just the plain `panic!` and/or related functions and you have to figure out how to do the necessary `const` calculations yourself or whether this goes all the way to allowing a variety of assertions directly.
<re_irc>
<@yruama_lairba:matrix.org> i have a codec, and it work randomly, i don't understand what's wrong