genpaku has quit [Read error: Connection reset by peer]
genpaku has joined #rust-embedded
crabbedhaloablut has quit [Quit: No Ping reply in 180 seconds.]
crabbedhaloablut has joined #rust-embedded
explore has quit [Quit: Connection closed for inactivity]
<re_irc>
<9names (@9names:matrix.org)> yruama_lairba: I think you did have a point here yruama_lairba, we are missing context. but you've got the cause wrong - it's not that we haven't read what you said - it's that you haven't actually provided sufficient context.
<re_irc>
you're clearly reading these terms from some document that the vendor provided, but we don't know which one. you've never mentioned which stm32 you're using, nor which audio hardware you're interfacing with. I'm sure you're correct and the document is vague, but we can't help you decipher it if we don't even know what it is saying.
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<ian_rees> yruama_lairba: I've been in that area recently (not in an STM32 context, but Linux DAI drivers) and have not got a better answer than guess and check really, but if you do find a nice guide I'd love to reference it! Basically, I think these are all quite similar formats for synchronous serial audio data, and the differences are mainly to do with how the "frame sync"/"word select" signal relates to the...
<re_irc>
... "slots"/"channels" in a "frame" of data, and how the frames are encoded. I'm not sure on how your chip will differentiate between PCM/DSP/TDM - at a guess there will be one bit pulse on frame sync at the start of each frame for DSP and TDM (TDM might be on first bit, DSP last bit of previous slot), where PCM might have the word select at a 50% duty cycle - high for one channel and low for the other.
<re_irc>
<ian_rees> Is there a way to suppress cargo doc warnings like "warning: unresolved link to "nF`` when the doc string looks like "#[doc = " Capacitance Tip to Ring [nF]"]"? I'm using bindgen from build.rs, and the library sticks a lot of units in square brackets...
<re_irc>
<ian_rees> * \"nF`"when the doc string looks like"#[doc = " Capacitance Tip to Ring [nF]"]`?
<re_irc>
<ian_rees> Is there a way to suppress cargo doc warnings like "warning: unresolved link to \"nF`"when the doc string looks like"#[doc = " Capacitance Tip to Ring [nF]"]`? I'm using bindgen from build.rs, and the library sticks a lot of units in square brackets...
<re_irc>
<9names (@9names:matrix.org)> should be able to escape the brackets, right?
<re_irc>
<ian_rees> * "nF"" when the doc string looks like"#\[doc = " Capacitance Tip to Ring \[nF\]"\]\"?
<re_irc>
<ian_rees> * like"#[doc = " Capacitance Tip to Ring [nF]"]"? I'm using bindgen from build.rs, and the library sticks a lot of units in square brackets... (sorry for edits - battling escapes)
<re_irc>
<9names (@9names:matrix.org)> oh. you don't really want to insert another post-process step, just ignore the warnings. got it
<re_irc>
<ian_rees> yeah, but that would be a lot of edits in a library that I just want to make bindings to
<re_irc>
How are "get_duty" / "set_duty" meant to interact with currently disabled channels? Should a disabled channel have a (possibly non-zero) duty-cycle, which just doesn't appear at the output, or should the duty cycle of a disabled channel be implicitly zero? Or is the behavior implementation-defined?
<re_irc>
<jannic> Current behavior of the rp2040 implementation is obviously broken, "set_duty" implicitly enables the PWM, and a subsequent "enable" disables it again, because the value stored in the struct doesn't get updated by "set_duty". But I'm unsure about the correct way to fix this.
<re_irc>
<dirbaio> that trait is removed in 1.0, I wouldn't invest too much effort in it
<re_irc>
<jannic> Good point :-)
<re_irc>
<dirbaio> the docs on it don't say anything about how it's supposed to behave lol
<re_irc>
<dirbaio> but intuitively i'd say yes, a channel has independent "duty" and "enabled" settings
<re_irc>
<dirbaio> so you can enable/disable without "losing" the duty value
<re_irc>
<dirbaio> honestly i'd simply not impl the PWM trait in the HAL
<re_irc>
<ryan-summers> Is there any plan for when 1.0 should get released? It seems like it's been alpha for like 2 years at this point
<re_irc>
<ryan-summers> Seems.... odd
<re_irc>
<dirbaio> and have inherent methods for everything with the behavior that makes more sense for the HW
<re_irc>
<dirbaio> * most
<re_irc>
<ryan-summers> Indeed, 1.0.0-alpha.1 was released June 16th, 2020
<re_irc>
<dirbaio> lol
<re_irc>
<ryan-summers> When are the meetings again? Might have to attend the next one and ask
<re_irc>
<ryan-summers> Huh, the WG page doesn't even list the meeting time
<re_irc>
<dirbaio> tuesdays 8pm CET/CEST
<re_irc>
<dirbaio> discussion is usually on GH though
<re_irc>
<dirbaio> honestly I think embedded-hal has a "scope" problem
<re_irc>
<Daniel> Hi all, I ran into esp-rs' http abstraction https://github.com/esp-rs/embedded-svc/tree/master/src/http and wonder if any other project has attempted something similar, I was planning on working on a heapless http abstraction that could also be used in non embedded projects(e.g. use a hyper backend on a server app) but it would be nice if this kind of abstraction is part of the bigger ecosystem(embedded-nal?)
<re_irc>
<9names (@9names:matrix.org)> dirbaio: too much, too little, or just poorly defined?
<re_irc>
- the nb vs async thing forces it to answer the question "which execution model is best?" which is essentially impossible to get consensus on.
<re_irc>
<dirbaio> it tries to do too much. For example
<re_irc>
- Traits for very complex stuff like CAN. (which again, should they be blocking, nb, async..?)
<re_irc>
- IoPin forces it to answer the question "should GPIOs have typestates or not?" (ie does changing from input to output change the pin's type) which again is very nontrivial, there's no single best answer.
<re_irc>
<dirbaio> combine that with the "it is 1.0 so it has to be perfect so we don't have to do breaking changes ever again" design paralysis
<re_irc>
<dirbaio> and the result is, very understandably, it never gets released :(
<re_irc>
<dirbaio> * it'll never be done
<re_irc>
<dirbaio> we can't even decide how to do uart read :joy
<re_irc>
<dirbaio> (that PR is about async, but the same design issues apply to blocking uart read. There's no blocking uart read triat now!)
<re_irc>
<dirbaio> I think the way to unblock this is to AGGRESSIVELY cut scope. Cut everything out that's unclear.
<re_irc>
<dirbaio> - Cut CAN out into a separate crate.
<re_irc>
- Remove IoPin
<re_irc>
<dirbaio> - Cut CAN out into a separate crate.
<re_irc>
- Cut nb traits out into a separate crate. Leave the main embedded-hal crate for blocking only. Having multiple crates is _fine_.
<re_irc>
- Remove IoPin
<re_irc>
- Don't do UART read for now.
<re_irc>
<dirbaio> and release embedded-hal 1.0 with just the basics: GPIO, blocking SPI, blocking I2C, blocking UART write. That's it.
<re_irc>
<dirbaio> that's what 99% of the drivers use anyway!
<re_irc>
<9names (@9names:matrix.org)> i think there's another thing we can do: stop calling it 1.0. make it eh 0.3, allow it to be just another release, that we can move on from if we need to make breaking changes.
<re_irc>
<timokrgr> > - Cut CAN out into a separate crate.
<re_irc>
> please no :D took me almost two years to get into embedded-hal
<re_irc>
<ryan-summers> I think I'm in agreement there. There's vast portions of the embedded-hal I've never used and have no intention of ever using. And having written drivers, things like nb just get in the way
<re_irc>
<timokrgr> but yeah whatever is required to unblock is fine with me
<re_irc>
<ryan-summers> It'd be interesting to do a review of things that use the e-h and see what's _actually_ being used by the community and what's just bloat
<re_irc>
<dirbaio> re doing EH 0.3: imo it is nice that we _do_ 1.0-freeze the traits that ARE "done, finished", so that drivers that only use them (ie most drivers) do get stable traits
<re_irc>
<ryan-summers> Does semver allow you to _add_ new APIs in minor revs?
<re_irc>
<ryan-summers> I think it does?
<re_irc>
<diondokter> Yes
<re_irc>
<ryan-summers> You just can't delete
<re_irc>
<diondokter> You cannot change existing API's including deleting
<re_irc>
<diondokter> I.E. Existing users mustn't break
<re_irc>
<ryan-summers> I think the aversion to 0.3 is that any release impacts a _lot_ of users
<re_irc>
<ryan-summers> And if you release too often, the versions start conflicting for end-users
<re_irc>
<ryan-summers> e.g. if one crate wants 0.2 and another wants 0.3
<re_irc>
<Campbell He> I think 0.x means you can do many breaking changes including deleting? (I'm not an expert though
<re_irc>
<ryan-summers> Yeah, 0.x is a special case
<re_irc>
<diondokter> AFAIK, cargo handles it the same as 0.MAJOR.MINOR instead of MAJOR.MINOR.PATCH
<re_irc>
<jannic> And in the end it doesn't help if we are formally semver compatible but fragment the ecosystem by so many incompatible releases that nothing can be combined.
<re_irc>
<ryan-summers> But I think dirbaio made a good point about 1.0-freezing the APIs that we _know_ are good. It's an interesting approach where you add-as-things-settle
<re_irc>
<ryan-summers> So you can break through the release-paralysis
<re_irc>
In minor bumps you're allowed to add stuff only
<re_irc>
<dirbaio> 1.x -> 2.x is a major bump. 1.0.x -> 1.1.x is a minor bump.
<re_irc>
0.x is handled as if the 0 wasn't there: 0.1.x -> 0.2.x is a major bump, 0.1.1 -> 0.1.2 is a minor bump.
<re_irc>
in major bumps you're allowed to add, change, remove, break, whatever
<re_irc>
<jannic> How about a list of typical drivers, and of popular MCUs that we really want to support, and make those the goal for 1.0?
<re_irc>
When all the exemplary drivers can be implemented using the HAL, and they can be provided on all MCUs (or there is a good reason it can't be done at all, eg. the MCU just doesn't have the necessary interface), 1.0 can be released.
<re_irc>
<dirbaio> IMO the problem with having so much stuff in the "main" "embedded-hal" crate is that if you want to do a breaking change in one of the things, you have to major-bump the whole crate
<re_irc>
<jannic> And of course 1.0 should not contain anything which is not used by those drivers.
<re_irc>
<dirbaio> which breaks ALL the drivers and HALs
<re_irc>
<dirbaio> unless you do horrible semver-tricks
<re_irc>
<dirbaio> jannic: IMO we're already there for the "basics" I listed above (and years away from being there for the other stuff, like async or can)
<re_irc>
<dirbaio> (perhaps the only unclear thing is the i2c transaction stuff..)
<re_irc>
<ryan-summers> Honestly, I think there's a lot of stuff that should be stripped from the hal, such as timers, watchdog, adc, but it looks like those are already removed for 1.0
<re_irc>
<dirbaio> timers are a complex problem because there _are_ use cases for them in HAL-independent drivers
<re_irc>
<dirbaio> but yeah, watchdog? WHY would you want to use a watchdog from a hal-independent driver? :D
<re_irc>
<ryan-summers> Yeah, but they're incredibly flexible, which is _awful_ for genericism
<re_irc>
<ryan-summers> There's a billion ways to use a timer peripheral
<re_irc>
<dirbaio> yeah
<re_irc>
<ryan-summers> I think to approach a HAL-independent driver that needs timers is to use something like e.g. embedded-time and clocking
<re_irc>
<dirbaio> I think we do want some timer traits
<re_irc>
<ryan-summers> Anything _super_ sensitive to time likely can't be abstracted away from hardware
<re_irc>
<dirbaio> but the right way to design it would be starting from "what do drivers want", not "what can the hardware do"
<re_irc>
<ryan-summers> Have you seen any crates that use the "e-h::timer::*" traits as an example?
<re_irc>
<ryan-summers> I personally have not yet
<re_irc>
<ryan-summers> And whenever I've written time-based crates, I used "embedded-time" traits
<re_irc>
<dirbaio> not many, but I think it's due to the "Duration unconstrained associated type" problem
<re_irc>
1- Delay for a given duration -- solved by the Delay trait
<re_irc>
2- Measure time -- unsolved
<re_irc>
<dirbaio> what do drivers want? I think there's 2 broad categories:
<re_irc>
<ryan-summers> Yeah, I think (2) should remain external tools (like fugit, embedded-time) until a good solution arises
<re_irc>
<jannic> > IMO the problem with having so much stuff in the "main" "embedded-hal" crate is that if you want to do a breaking change in one of the things, you have to major-bump the whole crate
<re_irc>
That's a good point indeed. What about having separate crates "embedded-hal-gpio", "embedded-hal-spi", ... and "embedded-hal" just depends on those and re-exports the traits. That way, drivers which just need, say, an SPI interface, could depend on "embedded-hal-spi" and would not be affected by a breaking change in "embedded-hal-i2c". And a firmware author can still just depend on "embedded-hal" and find all documentation in a...
<re_irc>
... single place.
<re_irc>
<dirbaio> perhaps that's too much splitting :D
<re_irc>
<ryan-summers> Do you think so? I almost like the idea
<re_irc>
<dirbaio> if we do know gpio/uart/i2c/spi are stable, it's fine to have them in a single EH1.0 crate
<re_irc>
<ryan-summers> But _are_ they stable?
<re_irc>
<ryan-summers> There's been a lot of change from 0.2.7 to 1.0
<re_irc>
<9names (@9names:matrix.org)> but then do we have an eh-unproven crate for the rest of them? or do they remain as separate crates until proven, so they can both be used and evolved?
<re_irc>
<dirbaio> I've been implementing a lot of drivers using 1.0 SPI and I'd say yes
<re_irc>
<dirbaio> it's solved all the pending concerns. "error kind" is solved, shared bus problem is solved, CS problem is solved, "can the impls buffer" is solved
<re_irc>
<dirbaio> uart write is solved I'd say, what problems could it have? 😂
<re_irc>
<ryan-summers> Yeah, but it's also not yet been deployed to the wider ecosystem and is very different from the existing impl
<re_irc>
<dirbaio> gpio is been stable since forever
<re_irc>
<dirbaio> the _only_ thing is IMO i2c should be refactored into bus/device traits too
<re_irc>
<ryan-summers> It's always hard to gauge what others are going to do with a trait.
<re_irc>
<dirbaio> uh when do you call things "stable" then?
<re_irc>
<ryan-summers> A valid point
<re_irc>
<dirbaio> it's been in alpha for a way, people are shipping drivers and HALs with it
<re_irc>
<ryan-summers> Maybe just take an opinion and run with it until it doesn't work anymore
<re_irc>
<ryan-summers> Good points all around :)
<re_irc>
<dirbaio> * while,
<re_irc>
<jannic> I'm quite sure we'll find _some_ usability issue where we'd need to do a breaking change shortly after releasing 1.0 :-) And that doesn't depend on how long we wait with the release.
<re_irc>
<dirbaio> "we won't release it until it's seen widespread testing" and "it hasn't seen widespread testing because it's not released yet" is a chicken-and-egg
<re_irc>
<ryan-summers> jannic: I think that's been the logic driving the e-h alpha releases
<re_irc>
<ryan-summers> To avoid that problem
<re_irc>
<jannic> Yes but it doesn't cover all use cases as some users will stay with 0.2.x until 1.0.0 is released.
<re_irc>
<dirbaio> i'd say at this point people who're fine with alphas have already played with it enough, and people who won't touch alphas won't play with it even if we leave it a few years more in alpha :)
<re_irc>
<9names (@9names:matrix.org)> > shared bus problem is solved
<re_irc>
does shared bus allow devices to run at different frequencies?
<re_irc>
<9names (@9names:matrix.org)> or is that "solved" by making it a user problem?
<re_irc>
<ryan-summers> I don't think that's a problem that needs solving imo
<re_irc>
<ryan-summers> That's something I've never seen done in a professional design
<re_irc>
<dirbaio> it's "kinda" solved, the traits leave room for impls to support dynamic freq change
<re_irc>
<dirbaio> there's no trait for it, but it can be added later
<re_irc>
<ryan-summers> That's an interesting question though - who _is_ the target audience? For example, SPI frequency change isn't something that industry would want, but I could totally see that as being needed by a maker.
<re_irc>
<ryan-summers> Anyways, I need to eventually get work done and I'm great at distracting myself
<re_irc>
<dirbaio> why is spi freq change "bad"?
<re_irc>
<ryan-summers> It's not bad per-se, it's just generally not done in a professional design unless something went pretty hard sideways. A hardware engineer is likely going to just select different design characteristics, different ICs, or attach it to a second bus
<re_irc>
<dirbaio> a chip might glitch if it sees too-high-freq stuff for another chip in MOSI, even if CS is not asserted?
<re_irc>
<ryan-summers> I doubt a chip cares at all what it sees on MOSI/MISO when CS is deasserted
<re_irc>
<ryan-summers> The enable signal is a good state reset for silicon
<re_irc>
<firefrommoonlight> ryan-summers: The EH project has a policy for new traits that they must have an existing use case, ie a driver that implements the trait. I think the intent makes sense, but doesn't go far enough - it should be demonstrated in a practical firmware
<re_irc>
<ryan-summers> I2C on the other hand is definitely susceptible to those problems
<re_irc>
<dirbaio> I could totally see a "professional" design doing that if aiming for low cost (ie not $100k high-end quantum lab equipment 😉)
<re_irc>
<firefrommoonlight> I am considering dropping embedded-hal support in my HAL (it's currently behind a feature gate which I don't activate in my projects). Its model works on simple examples, but I've been unable to fit it into firmware
<re_irc>
<firefrommoonlight> Not working with DMA alone is a deal breaker
<re_irc>
<firefrommoonlight> And passing in EH traits as args doesn't work when you need a HAL or project-defined periph struct or module to configure things beyond what EH supports
<re_irc>
<ryan-summers> DMA essentially precludes the traits anyways though. You just set up DMA and it does the SPI for you and fills a buffer with the read/write data
<re_irc>
<ryan-summers> Ah, but I see your point in that you can't write a generic driver with it
<re_irc>
<firefrommoonlight> I just don't see the use case other than "Let's build a rust ecosystem! Look what you can do!". There's a bridge between that and "Here's an embedded device programmed using Rust" that EH has been IMO unable to cross
<re_irc>
<dirbaio> what's the problem with DMA? it works great with the async traits 🤔🤔🤔
<re_irc>
(and the blocking traits, but it's quite pointless).
<re_irc>
<firefrommoonlight> I mean insofar as the EH traits don't currently support it
<re_irc>
<firefrommoonlight> I leave open the question whether a future redesign of EH could address this and other things. The benefit of a practical EH would be nice, ie generic drivers. My critique is about the current impl, and I don't have a plan for a future impl that addresses this
<re_irc>
<dirbaio> if you want to do complex circular doublebuffered DMA streaming then the traits don't work, yeah
<re_irc>
<dirbaio> but that's a non-goal for the traits
<re_irc>
<firefrommoonlight> It sounds like the async version may be more viable, but I can't comment since i don't have experience there
<re_irc>
<firefrommoonlight> (Anecdotally, I've been using about 2/3 linear vice circular DMA)
<re_irc>
<firefrommoonlight> * normal
<re_irc>
<dirbaio> the goal is supporting writing hal-independent drivers for stuff like sensors, displays, converters, expanders, whatever
<re_irc>
<firefrommoonlight> I don't see the use case other than "Let's build a rust ecosystem! Look what you can do!". There's a bridge between that and "Here's an embedded device programmed using Rust" that EH has been IMO unable to cross
<re_irc>
<dirbaio> and they're working great for that IMO
<re_irc>
<dirbaio> what drivers are you writing that you're finding the traits don't work?
<re_irc>
<firefrommoonlight> dirbaio: I concur this is a nice goal. I don't know how to make it happen, and don't think the EH lib does this
<re_irc>
<firefrommoonlight> My current code is tied tightly with hardware, which brings inflexibility. I don't see a better alternative ATM
<re_irc>
- SPI IMU with GPIO interrupt pin
<re_irc>
- UART RC link
<re_irc>
- Uart on-screen display overlay
<re_irc>
<firefrommoonlight> So, here's a sample of hardware I'm using on my flight-controller:
<re_irc>
<jannic> IMHO it currently works quite well if the requirements are not too special. Stuff like "I just want to read this sensor every now and then, I don't care much about performance" just works. Of course, if you want to get as much as possible out of your hardware, you will run into limitations.
<re_irc>
<dirbaio> hmm, so for example for the three i2c things, why don't the traits work for you?
<re_irc>
- SPI IMU with GPIO interrupt pin
<re_irc>
- Uart on-screen display overlay
<re_irc>
<firefrommoonlight> So, here's a sample of hardware I'm using on my flight-controller:
<re_irc>
<dirbaio> you must be doing i2c reads/writes, the traits can do that
<re_irc>
<firefrommoonlight> jannic: I can't fit the blocking EH traits into any of those uses above
<re_irc>
<firefrommoonlight> There are a number of sensors, and I can't use EH for any of them
<re_irc>
<firefrommoonlight> dirbaio: DMA
<re_irc>
<firefrommoonlight> I agree though - bus reads and writes are the best suited for a trait
<re_irc>
<firefrommoonlight> I think those are fixable
<re_irc>
<dirbaio> you want to use DMA because you can't afford blocking?
<re_irc>
<dirbaio> * have
<re_irc>
<firefrommoonlight> Correct. There is no reason to block, and it would have adverse affects on system performance
<re_irc>
<firefrommoonlight> Some of them are circular, ie continuously read from ADCs, RC unit etc
<re_irc>
<dirbaio> I see!
<re_irc>
<firefrommoonlight> While the IMU readings are non-circular read of 7 measurements upon receiving a GPIO signal for data ready
<re_irc>
<dirbaio> so by "the traits don't support DMA" you actually mean more "don't support not blocking"
<re_irc>
<dirbaio> I know you really don't like async... but async solves exactly that 😅
<re_irc>
<firefrommoonlight> Or the OSD is a one-off DMA write of a pile of data on a fixed interval
<re_irc>
<firefrommoonlight> Yea - I've really tried there! I can't do it
<re_irc>
<firefrommoonlight> But I concur it helps here with making usable traits
<re_irc>
<dirbaio> same for GPIO interrupts, with async you can "loop { pin.wait_for_low().await; process_stuff() }"
<re_irc>
<jannic> There will always be use cases where the abstractions of a HAL are too limiting. And nobody is forced to use EH. It's not like the availability of EH prevents talking to the hardware directly. (It's different with an OS where the API also provides a security boundary and non-privileged software just can't avoid using the API)
<re_irc>
<dirbaio> making a trait for GPIO interrupts (or for interrupts in general) without async is really hard, there's a few issues about it
<re_irc>
<firefrommoonlight> jannic: I've found this to be nearly every one I encounter
<re_irc>
<firefrommoonlight> * most
<re_irc>
<dirbaio> it plain doesn't work. For many reasons. Rust plainly hates callbacks, and chip makers do tons of cursed stuff like sharing a HW IRQ for multiple purposes
<re_irc>
<dirbaio> vs if you abstract at a slightly higher level (futures + wakers) it works, because you can have the HAL deal with the cursedness
<re_irc>
<dirbaio> +and expose a more "standard" interface
<re_irc>
<firefrommoonlight> The main shared IRQ thing I've found is the EXTI on stm32 (Although I realize there are others, often indicated in their name). Ie sharing all ports, and sometimes a range. I've been working around itn when it pops up by checking the interrupts flags. Not idea, but works
<re_irc>
<firefrommoonlight> * range of pin nums.
<re_irc>
<firefrommoonlight> * ideal,
<re_irc>
<dirbaio> it works with a hardware-specific API, but you can't traitify it
<re_irc>
<firefrommoonlight> jannic: Could you provide an example where EH traits have worked for you?
<re_irc>
<firefrommoonlight> dirbaio: Yea - this is my trouble
<re_irc>
<dirbaio> but with async you _can_ traitify it
<re_irc>
<firefrommoonlight> For example, I'm prepared to use 2 diff IMUs due to suspect availability. I have a module for each, plus a shared module. I comment out lines like so to switch.
<re_irc>
use imu_icm42688 as imu;
<re_irc>
// use imu_ism as imu;
<re_irc>
<firefrommoonlight> Quick+dirty, but best I've got atm
<re_irc>
<firefrommoonlight> And make the API identical for the 2 modules
<re_irc>
<firefrommoonlight> Only works out because I control the code for both. Ie not ideal for sharing code as OSS
<re_irc>
<dirbaio> that's something else, you'd need a trait for the IMU api there, not for i2c
<re_irc>
<firefrommoonlight> Yea - could do that too. At cost of some code complexity and verbosity
<re_irc>
<dirbaio> I do that for in-tree drivers too
<re_irc>
<firefrommoonlight> I think that would make more sense if the number of variants increased. Ie it forces the APIs to be the same
<re_irc>
<dirbaio> but I try to make these drivers still use the i2c/spi/gpio traits
<re_irc>
<firefrommoonlight> I will continue to evaluate Async btw as it evolves
<re_irc>
<dirbaio> for example I've written drivers for RFID reader chips
<re_irc>
<dirbaio> one was from ST, so the demo board had an STM32. Wrote the driver using the i2c traits using the embassy-stm32 impl. Got the driver working on the demo board.
<re_irc>
<dirbaio> Then the prototype boards arrived, which use an nRF. Switched to embassy-nrf i2c impl, not changing one line in the driver. It Just Worked on the first try.
<re_irc>
<dirbaio> this is why the traits are awesome :D
<re_irc>
<dirbaio> and it used "wait_for_low()" for gpio irqs, so the mcu could sleep while waiting, so it was low-power
<re_irc>
<dirbaio> worked with EXTI on STM32, and GPIOTE on nRF, plug-and-play :)
<re_irc>
<dirbaio> you can't do that without async, because the way gpio irqs work in nrf and stm32 are completely different
<re_irc>
<jannic> firefrommoonlight: Well to be honest the stuff I write is mostly trivial and could probably as well be written with micropython or similar. Kind of the stuff you usually find for arduino. I just like rust more than the other languages.
<re_irc>
<firefrommoonlight> I encourage you to evaluate whether the traits will work outside this context
<re_irc>
<firefrommoonlight> I concur they work in it
<re_irc>
<firefrommoonlight> dirbaio: Yea - big adv of traits
<re_irc>
<firefrommoonlight> My hack has been (as before with IMUs) to make (or in case of nRF) modify HALs to use similar APIs when able, but this is fragile/doesn't scale
<re_irc>
<jannic> I don't doubt you are correct that they don't work for your use case, and it's quite likely that your use case is representative for most professional usages. If EH could be improved to fit your use case, that would be great! But if it's not possible (or we don't know how), that doesn't make EH useless.
<re_irc>
<dirbaio> re your list firefrommoonlight :
<re_irc>
SPI trait (async if you can't afford blocking) and async gpio WaitForX.
<re_irc>
<dirbaio> +(there's a "read one adc pin blocking" trait but I guess your ADC use is more advanced than that)
<re_irc>
<9names (@9names:matrix.org)> on the other side, i've seen many of commercial devices using nodemcu or raspberry pi + python that would be adequately served by existing traits.
<re_irc>
not every device is ultra-low-power, or anything close to hard real-time. as hard as this can be for some to imagine.
<re_irc>
<dirbaio> you can traitify lots of stuff (not all, but that was never the goal of embedded-hal!) :)
<re_irc>
<9names (@9names:matrix.org)> -of
<re_irc>
<dirbaio> rpis are great if you want to sell support contracts! gotta get that sweet sweet money for replacing dead SDs
crabbedhaloablut has quit [Ping timeout: 268 seconds]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<firefrommoonlight> dirbaio: I'm glad those are working for async traits! It sounds like this is a key adv of async
<re_irc>
<firefrommoonlight> Non-blocking without async is reliant on explict DMA and interrupt APIs, which as you've said, don't play nicely with traits
<re_irc>
<firefrommoonlight> esp re IRQs
<re_irc>
<firefrommoonlight> And I'm not sure how well they'd scale to other (eg non Arm) targets
<re_irc>
<firefrommoonlight> I've only used ARM, so this limits my perspective, while traits here must work beyond that
<re_irc>
<dirbaio> riscv's without vectored interrupts.. hehe 😰
<re_irc>
<firefrommoonlight> Btw, I should clarify that I'm using a blocking API for onboard flash, which is used for config. And it takes a while to write/erase. Currently only due this while plugged into a PC for configuring, but this would probably be a disaster airborne.
<re_irc>
<firefrommoonlight> * do
<re_irc>
<dirbaio> yeah onboard flash sucks for realtime
<re_irc>
<dirbaio> in the stm32's with dual bank you can write to bank2 while running from bank1 without staling, which is nice
<re_irc>
<dirbaio> in the ones that don't... you simply can't, you have to use external flash/eeprom: D
<re_irc>
<dirbaio> * flash/eeprom :D
<re_irc>
<firefrommoonlight> Nice. The 2 targets here are dual bank, but I haven't messed with that yet
<re_irc>
<firefrommoonlight> (The G4 one is configurable as either dual or single with an option bit... not sure if the technique you described works there too?)
<re_irc>
<dirbaio> I wonder, if you run fully from RAM, can you do nonblocking flash writes even on single-bank chips? 🤔
<re_irc>
<dirbaio> probably yes?
<re_irc>
<firefrommoonlight> Good Q
<re_irc>
<firefrommoonlight> I don't know how to do fancy things with firmware storage, but would like to learn
<re_irc>
<firefrommoonlight> I've jus been leaning on probe-run, minimal memory.x config, and letting it load the program onto onboard flash
<re_irc>
<firefrommoonlight> From how ST is moving from 2Mb to 1Mb internal flash, but Octospi on their new H7s makes me think these will be useful soon
<re_irc>
<firefrommoonlight> (I still don't know what octospi is, although the RM has a lot of details)
<re_irc>
<firefrommoonlight> And it's backwards compatible with QSPI
<re_irc>
<ryan-summers> dirbaio: From my experience, yes. If the processor isn't using the flash and is executing from RAM, the flash controller won't issue wait-states to the processor
<re_irc>
<ryan-summers> I _think_ I did this a number of years ago on an ATSAM, but it was a long time ago
<re_irc>
<dirbaio> I hope splitting "nb" won't be controversia. To be clear I'm not proposing removing it, it'll keep getting maintained alongside the main EH crate
<re_irc>
<dirbaio> * controversial.
<re_irc>
<dirbaio> so the main "embedded-hal" crate only has blocking traits, and there's separate crates "embedded-hal-nb", "embedded-hal-async" for each "execution model"
<re_irc>
<dirbaio> so they can be bumped (or deprecated :D) independently
<re_irc>
<jannic> Sounds good - even from a usability POV. If I'm writing a firmware where blocking is fine, I probably only care about blocking APIs and all this "nb" stuff is just confusing. Perhaps document that we encourage drivers and HAL implementations to implement all of them, where sensible? Of course we can't force anybody, but just stating that it's good to implement all of them would help IMHO, to avoid fragmentation.
<re_irc>
<dirbaio> maybe it'd be even better if "embedded-hal-nb", "embedded-hal-async" stay as separate crates forever?
<re_irc>
<dirbaio> * forever, even
<re_irc>
<dirbaio> makes the api clearer yep
<re_irc>
<dirbaio> because once, say, "embedded-hal-async" is stable, if we "merge" it back into "embeddeed-hal" that'd be another round of breaking changes and confusion, for little benefit (?)
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
<re_irc>
<dirbaio> these 3 PRs unblock 1.0 I think :D
explore has joined #rust-embedded
<re_irc>
<adamgreig> Did we already talk about splitting out CAN? I'm less sure about removing that, it's different from nb (and indeed it used to be its own embedded-can crate before we chose to merge it into e-h)
<re_irc>
<dirbaio> hasn't been discussed, no
<re_irc>
<dirbaio> I'm spontaneously proposing it because it's a good thing IMO, but i'm happy to split just "nb" as well
<re_irc>
<dirbaio> note the CAN trait has an "nb" variant too. we could move that to the "-nb" crate and leave the blocking one in the main one yeah
<re_irc>
<dirbaio> is blocking CAN usable in the real world though?
<re_irc>
<dirbaio> seems to me in even the most basic applications you'll want some sort of timeouts or periodic activity... and you can't do that with blocking rx
<re_irc>
<diondokter> There isn't? Oh, well then it's probably something to not have until it has been figured out for UART too
<re_irc>
<diondokter> * until/if
<re_irc>
<dirbaio> yeah... but then we should have only CAN TX in the main crate? that's not very useful
<re_irc>
<dirbaio> (vs tx-only uart which at least is useful for logging)
<re_irc>
<diondokter> Yeah, I guess splitting it out is a decent option
<re_irc>
<diondokter> For the blocking interface at least
<re_irc>
<dirbaio> yeah.. that was my though process. Just it out into embedded-hal-can until we have it figured out lol
<re_irc>
<dirbaio> * "embedded-hal-can"
<re_irc>
<dirbaio> or if we decide we don't want the blocking trait then put it in "embedded-hal-nb" only
<re_irc>
<dirbaio> either way, I don't think the current blocking trait is ready to be in the main EH1.0
<re_irc>
<adamgreig> Hmm worth pondering for sure. Usually hardware receives into a buffer so I'd expect a receive function that can say nothing to see yet but that's not what the current trait is documented to do
<re_irc>
<adamgreig> Busy atm but it looks like plenty to talk about this evening anyway
<re_irc>
<Noah> Hey folks, I am still running into "undefined reference to `rust_eh_personality'" when going over rust 1.59. like what could cause this; I am kind of confused
<re_irc>
<dirbaio> can you post a repro?
<re_irc>
<mabez> Noah: panic = "abort" in cargo.toml?
<re_irc>
<diondokter> Noah: Are you compiling for the right target?
<re_irc>
You get that when compiling for your PC when you have #[no_std] and #[no_main]
<re_irc>
<Noah> Hmm but this always worked. We did not change source. It runs on 1.59 but fails on 1.60 and subsequent
<re_irc>
<Noah> dirbaio: will be hard I guess :D
<re_irc>
<Noah> its mangled with C and C++
<re_irc>
<dirbaio> oh no
<re_irc>
<Noah> so this happens when we link the rust lib (no_std) to C ...
<re_irc>
<dirbaio> you have rust lib in a c bin?
<re_irc>
or C lib in a rust bin?
<re_irc>
<Noah> rust lib C bin
<re_irc>
<dirbaio> and you get the error when linking the C bin?
<re_irc>
<dirbaio> +Rust lib or
<re_irc>
<dirbaio> you have crate-type=staticlib?
<re_irc>
<jannic> Maybe this long standing bug? https://github.com/rust-lang/rust/issues/56152 Perhaps triggered by some change in the optimizer? Judging from the ticket comments, it depends on optimization whether the bug is triggered.
<re_irc>
<dirbaio> oooh Noah try building with "-Zbuild-std=core"
<re_irc>
<James Munns> Hey luojia65 or disasm (or anyone else), do you have a good bare metal example of adding a PLIC interrupt handler for a RISC-V target?
<re_irc>
<Noah> hmm that would require nightly tho, no? dirbaio
<re_irc>
<dirbaio> yes... :S
<re_irc>
<James Munns> I've managed to get it ENABLED, and I see the interrupt pending bit is active in the PLIC, but I can't get a handler to actually trigger (I have a defined "MachineExternal" handler)
<re_irc>
<Campbell He> James Munns: you mean in OS?
crabbedhaloablut has quit [Ping timeout: 268 seconds]
<re_irc>
<James Munns> Happy for any example, right now I'm trying to write an interrupt handler using the d1-pac though :D
<re_irc>
Besides, I haven't use d1's timer either. So I have no idea if it is working in the right way. 😅
<re_irc>
<James Munns> Yeah, I was just trying to see if the interrupt pending flag was set? (the timer interrupt is 75, so that's bit 11 of idx 2)
<re_irc>
<James Munns> I'm not actually trying to claim it yet, I just want to see a panic when the actual interrupt occurs :p
<re_irc>
<Campbell He> I don't get how "MachineExternal" would be triggered.
<re_irc>
In my understanding, when the interrupt occurs ("mip" & "mie" != 0), the "pc" should be modified by hardware to "mtvec". I haven't find a code setting "mtvec".
<re_irc>
<James Munns> antoinevg helped me find it, I was missing "mie::set_mext()"
<re_irc>
<Campbell He> Oh, I found out. It is handled by "riscv-rt"
<re_irc>
<James Munns> I'm not sure about "mtvec", maybe that's something done automatically by "riscv-rt"?
<re_irc>
<James Munns> look, it's an interrupt sandwich:
<re_irc>
T0 DONE
<re_irc>
<Noah> dirbaio: this seems to fix it.
<re_irc>
why does it not happen on my mac tho but under linux? I am so confused
<re_irc>
<dirbaio> no idea 🤷 ... in my experience, "rust lib inside C bin" is CURSED
<re_irc>
<Noah> but what does the flag actually do
<re_irc>
<Noah> I mean I know what it does but no clue why it fixes it?
explore has quit [Quit: Connection closed for inactivity]
twopoint718 has joined #rust-embedded
twopoint718 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<re_irc>
<jannic> If your lib is compiled with "panic=abort", this recompiles core with that flag, so the unwind code isn't included, so eh_personality is no longer referenced. I guess.
<re_irc>
<Noah> the question is why this became relevant now
<re_irc>
<dkhayes117> James Munns: You will be in machine mode by default. You have to use an "mret" instruction to get to user mode after setting mpp bit in mstatus to user mode. You also set mpie and clear mie bits mstatus. Mepc will hold the entry point of your user level code and at least 1 PMP entry is required.
<re_irc>
<jannic> Perhaps you only use functions which didn't panic in 1.59, and one of those got a new code path in 1.60 which could panic?
<re_irc>
<dkhayes117> +in
twopoint718 has joined #rust-embedded
<re_irc>
<jannic> If you really want to know, you could objdump the lib where the linking fails and try to find the reference to "rust_eh_personality".
rardiol has joined #rust-embedded
causal has joined #rust-embedded
twopoint718 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<re_irc>
<Noah> jannic: hmmmm that is a good though!
<re_irc>
<Noah> jannic: i will do that!
<re_irc>
<Noah> thanks!
<re_irc>
<adamgreig> room meeting time again! agenda is https://hackmd.io/pJfT_xYcTWyJ7-u1xkwn5Q, please add anything you'd like to discuss or announce and we'll start in 5 minutes 👋
rardiol has quit [Ping timeout: 245 seconds]
<re_irc>
<heksa> James Munns: Oh no, I could've told you that immediately D: missed a good opportunity to help out. I keep a Renode RISC-V virtual prototype around when working with interrupts (QEMU surely works too). It's nice to verify your code on an ideal RISC-V before trying out a platform, since some of the interrupts specs have only recently hardened and platforms are sometimes idiosyncratic.
<re_irc>
<adamgreig> ok, let's start!
<re_irc>
<adamgreig> only brief announcements this week: a ton of PRs merged on svd2rust which may be worth checking out but no release yet, and thanks jannic for tidying up the wg readme
<re_irc>
<adamgreig> any other announcements from the last week?
<re_irc>
<jannic> I hope the updates are correct - I didn't find the agenda posted in git for a long time.
<re_irc>
<adamgreig> yea, we used to make an issue in advance but it was very rarely used, so I stopped doing it
<re_irc>
<adamgreig> ok, well if there's any other announcements please just shout, in the meantime dirbaio has dropped a ton of embedded-hal PRs which are worth some discussion
<re_irc>
<adamgreig> the concept here is to keep the "embedded-hal" as only blocking traits, and then have "embedded-hal-async" and "embedded-hal-nb" provide traits for non-blocking models
<re_irc>
<adamgreig> the alternative is to have all the traits inside "embedded-hal", as we have previously, probably split up by modules like "embedded_hal::spi::blocking", "embedded_hal::spi::asynch", etc
<cr1901>
I'm fine with the PR
<re_irc>
<adamgreig> we've discussed this idea a bit beforehand, and it's how the async traits are currently (because they can't be stabilised just yet), so in that sense the proposal is to just not eventually merge the async traits into the main crate
<re_irc>
<newam> I think it makes sense. Splitting up the EH into more crates is a common enough idea thrown around. The line between nb/non-nb seems sensible, and lines up with what has already been done for async.
<re_irc>
<adamgreig> this also means if we did want to deprecate using nb (or just leave it as "finished" and not generally used), the nb stuff doesn't get in the way of everything else
<re_irc>
<adamgreig> I think the main downside from my point of view is that drivers and hals might not want to pull in three different crates to implement three different sets of traits...
<re_irc>
<adamgreig> ...but in a sense they already have this problem with the blocking and nb traits anyway
<re_irc>
<eldruin> adamgreig: I think I like the idea of splitting out -nb precisely for this reason
<re_irc>
<dkhayes117> Makes sense to me to break them out
<re_irc>
<eldruin> the different execution models do not mix that well anyway
<re_irc>
<adamgreig> yea, as an end user I guess you tend to just use one
<re_irc>
<adamgreig> though I still worry about how much it will be annoying for driver authors if they have to implement two/three traits?
<re_irc>
<dirbaio> for HAL authors you mean?
<re_irc>
<jannic> They already have to implement the traits separately, now.
<re_irc>
<jannic> They only come from the same crate.
<re_irc>
<eldruin> adamgreig: yeah that is definitely annoying
<re_irc>
<adamgreig> hmm, I guess I have two points, one is that by splitting out nb we probably de-prioritise it enough that we might be just deprecating it de facto because hals are probably less likely to bother with it vs when it's part of the same crate? hard to predict that though, and if no hals want to implement nb then it's probably a good signal it's not working, while if users do want nb the hals will probably do it
<re_irc>
<adamgreig> and the second is how it looks as a driver author wanting to implement support for some device via blocking/async/nb
<re_irc>
<adamgreig> "implement traits" is probably the wrong word to use, "use" maybe
<re_irc>
<jannic> Is the actual change more than importing another crate and changing the "use" statements? The actual code stays the same.
<re_irc>
<adamgreig> yea, the code stays the same, it's just a bit more friction to depend on another crate
<re_irc>
<adamgreig> I don't think it's a serious negative and on balance the positives probably outweigh it, just wondering aloud
<re_irc>
<eldruin> there is a separate versioning and so on
<re_irc>
<dirbaio> when writing a driver you pick a single execution model
<re_irc>
<dirbaio> so for example if your driver is async you'd import just EHA (or at most EHA+EH if you want GPIO)
<re_irc>
<dirbaio> but certainly never EHA+EHNB :P
<re_irc>
<adamgreig> unless you wanted to support users from any model?
<re_irc>
<eldruin> not really, you can mix in some nb here and there but otherwise be blocking and you may want to support async as well
<re_irc>
<adamgreig> like, do you imagine we end up with ssd1309 on crates.io and also ssd1309-async?
<re_irc>
<dirbaio> I meant when writing a driver
<re_irc>
<dirbaio> when writing a HAL yes, if you want to be max compatible you'd import and impl EH+EHA+EHNB
<re_irc>
<adamgreig> I mean when writing a driver too
<re_irc>
<jannic> Async because it's better if it's available, "nb" for users which still hate async?
<re_irc>
<dirbaio> adamgreig: this is kinda what's happening now, yep..
<re_irc>
<adamgreig> so the goal is driver authors should all use EHA, and EH end-users should use an adaptor to use those drivers?
<re_irc>
<adamgreig> (and nb users get stuffed I guess...? or an async->nb adaptor as we've sort of considered talking about)
<re_irc>
<adamgreig> a driver author could also just have an async and a blocking driver in the same crate, right?
<re_irc>
<eldruin> adamgreig: yes, just put them in separate modules or so
<cr1901>
adamgreig: This is my plan for tcn75a
<re_irc>
<eldruin> it is just that you need to duplicate a lot of code, including docs and so on
<re_irc>
<jannic> I think all those models are possible, and that doesn't change whether we split EH or not.
<re_irc>
<dirbaio> eldruin: so like "pub async fn read_light(&mut self) -> NbResult<LightData, Error<E>> {"
<re_irc>
at first glance it seems very very odd to me to do that 😂
<re_irc>
<eldruin> you do not want to block for 800ms integration time if not ready
<re_irc>
<adamgreig> jannic: well, I'm sort of wondering if we do have "use async by default, use adaptors for blocking" then embedded-hal should probably be async and embedded-hal-blocking exist alongside it :P
<re_irc>
<eldruin> seems fine to me to return "would block"
<re_irc>
<dirbaio> eldruin: it wouldn't block would it? it'd "async block" so other stuff can still run
<re_irc>
<adamgreig> but point taken, it doesn't really affect the split
<re_irc>
<eldruin> dirbaio: in the async world not, but I am using the blocking traits there
<re_irc>
<eldruin> my point was that the use case of blocking+nb+async all in the same driver exists
<re_irc>
<dirbaio> ohh is it an artifact of how "maybe_async_cfg" works? i've never used
<re_irc>
<dirbaio> +it
twopoint718 has joined #rust-embedded
<re_irc>
<jannic> We could stay neutral and have "embedded-hal-blocking", "embedded-hal-nb" and "embedded-hal-async".
<re_irc>
<dirbaio> anyway i'd say it's not very idiomatic. if you're using async, that fn should return when the thing is done. not "would block, try again later". that's the whole point of async
<re_irc>
<dirbaio> "async+nb" in the same driver shouldn't exist IMO
<re_irc>
<eldruin> dirbaio: no, I wrote it blocking, with some nb for things that take long. then somebody proposed adding async support
<re_irc>
<eldruin> sure, but blocking + nb do and separately async, but if it is all the same driver, you have all three
<re_irc>
<eldruin> anyway I am not sure this example would help us much
<re_irc>
<adamgreig> I fear we're getting off the point thanks to my stupid question, but it seems like on the whole splitting out the nb traits and then keeping async its own crate seems ok?
<re_irc>
<adamgreig> the other thing in that PR is removing the CAN traits to embedded-hal-can crate
<re_irc>
<eldruin> yes
<re_irc>
<eldruin> about CAN I am not sure. we just merged it :D
<re_irc>
<adamgreig> for history, it was originally embedded-can, https://crates.io/crates/embedded-can, timokrgr's, then once it was stable and implemented in HALs we merged it into e-h
<re_irc>
<jannic> But only in the still experimental alpha version, right?
<re_irc>
<adamgreig> but of course we can change it or remove it for 1.0, like many other traits
<re_irc>
<adamgreig> I feel like ultimately it should be in embedded-hal / embedded-hal-async, not live indefinitely in a separate crate
<re_irc>
<adamgreig> and in that case, maybe there's no point creating embedded-hal-can when embedded-can already exists
<re_irc>
<adamgreig> but ideally maybe we can fix the couple of small questions and keep it in 1.0?
<re_irc>
<dirbaio> maybe the more general q is "do all traits go in the main EH crate?"
<re_irc>
<adamgreig> yea, indeed
<re_irc>
<eldruin> it depends on "nb" though
<re_irc>
<dirbaio> regardless of "nb", assume we're only talking about blocking traits for now
<re_irc>
<adamgreig> like, we don't want embedded-hal-spi, right?
<re_irc>
<adamgreig> would you have embedded-hal-spi-async? or embedded_hal_spi::{blocking, asynch, nb}?
<re_irc>
<adamgreig> jk... unless.......
<re_irc>
<dirbaio> especially for more complex stuff
<re_irc>
<dirbaio> CAN is significantly more complex than any other trait
<re_irc>
<adamgreig> is it?
<re_irc>
<adamgreig> like, the CAN nb trait is just a transmit and a receive fn
<re_irc>
<chemicstry> yes, EH is missing a lot of can features, required by some protocols like timestamping, replacing queue frames by priority, loopback etc
<re_irc>
<adamgreig> sure, but that's true of all the EH traits by design
<re_irc>
<eldruin> the protocol sure, but there is just one trait with a custom frame and error
<re_irc>
<adamgreig> the uart trait doesn't have a way to set the baud rate, the spi trait can't set cpha/cpol, etc etc
rardiol has joined #rust-embedded
<re_irc>
<eldruin> +types
<re_irc>
<dirbaio> iiuc timestamping is something a hal-independent driver would use
<re_irc>
<adamgreig> queue priority is an implementation issue and I don't think the trait would need to be involved?
<re_irc>
<dirbaio> * use?
<re_irc>
<adamgreig> timestamping could be nice, but it's not fundamental to CAN and a lot of things won't need it
<re_irc>
<jannic> And "spi/blocking.rs" has more LOC than "can/*.rs" combined.
<re_irc>
<adamgreig> I guess it's clear we don't have a complete answer for every CAN use case, but the basic stuff we do have does seem to be already useful
<re_irc>
<dirbaio> jannic: mostly docs and boilerplate :P
<re_irc>
<dirbaio> adamgreig: so my question is: are we SURE we won't need any breaking change for the whole "embedded-hal 1.0" lifetime (ie, in forever)?
<cr1901>
I don't think we'll ever be sure
<re_irc>
<dirbaio> yes but
<re_irc>
<dirbaio> for SPI, the protocol is super simple, it's just shifting bits in/out. it's obvious the traits are "complete", anything else you might want to add is not missing features in the SPI protocol, they're "stuff you build on top of SPI" which is out of scope of EH
<re_irc>
<adamgreig> I think we can be sure enough that what we have would be useful to a lot of people and maybe some non-breaking additions
<re_irc>
<dirbaio> gpio, delays etc are even simpler
<re_irc>
<jannic> Is there a meaningful number of drivers implemented for it?
<re_irc>
<adamgreig> the 0.2 SPI traits were "complete" and now they're totally different for 1.0, though
<re_irc>
<dirbaio> adamgreig: they weren't, there were tons of open issues about CS management and "clarify timing"
<re_irc>
<adamgreig> I guess similarly we were happy with the traits enough to put them into 0.2 as a stable release
<re_irc>
<adamgreig> we could also punt CAN from e-h 1.0 to get rid of the blocker, add them back in 1.1 or whatever, like "time"
<re_irc>
<dirbaio> +and bus sharing
<re_irc>
<adamgreig> but my feeling is the currently open issues are more or less resolvable and it's useful to have something standard
<re_irc>
<dirbaio> what's the advantage of merging absolutely everything into the main crate?
<re_irc>
<adamgreig> heck, even if you just have the CAN frame trait that everyone could interoperate with
<re_irc>
<adamgreig> hmm
<re_irc>
<dirbaio> like
<re_irc>
<adamgreig> yea, I guess the question is what's the downside of having a separate embedded-hal-can crate anyway
<re_irc>
<eldruin> discoverability
<re_irc>
<dirbaio> the goal of merging "embedded-can" into "embedded-hal" was to "make it official" I guess
<re_irc>
<adamgreig> sure, but if you're interested in CAN you'll probably find it and/or we can link to it from the lib.rs docs
<re_irc>
<dirbaio> so the traits gain "more weight" and more HALs/drivers use them?
<re_irc>
<adamgreig> yea
<re_irc>
<jannic> If we mention it from the top-level docs I'd say it's quite discoverable.
<re_irc>
<adamgreig> and indeed you still get that with an embedded-hal-can crate
<re_irc>
<adamgreig> I guess you'd have nb, async, blocking modules inside?
<re_irc>
<dirbaio> the WG can still "make a trait official" while having it in a separate crate
<re_irc>
<adamgreig> in the same way the embedded-hal-async traits are
<re_irc>
<dirbaio> and the separate crates can be major-bumped as needed, and mature at their own pace
<re_irc>
<adamgreig> so what _do_ we keep in embedded-hal{,-async,-nb} vs gets its own crate? i2c and spi and uart are simple/common enough to live there, while complicated can/? go to their own crate?
<re_irc>
<dirbaio> without having to major-bump the main EH crate which would be quite disruptive
<re_irc>
<dirbaio> i'd say yeah
<re_irc>
<adamgreig> I don't fully like the asymmetry between e-h, e-h-async, e-h-nb having three exec models of the common traits, but e-h-can::{blocking,nb,asynch} having them in one there, but...
<re_irc>
<adamgreig> i like it better than having e-h-can-async etc, lol
<re_irc>
<adamgreig> what else might go somewhere besides gpio,uart,i2c,spi...delay?
<re_irc>
<dirbaio> core crate has the core traits: gpio, uart, i2c, spi, delay, timer (maybe adc, pwm, but i'm less convinced that these are useful in hal-agnostic drivers)
<re_irc>
which is the stuff literally EVERYONE uses
<re_irc>
then there's crates for specialized stuff: embedded-hal-can, embedded-dma, embedded-storage, embedded-i2s
<re_irc>
<dirbaio> adamgreig: yeah I agree its not very nice...
<re_irc>
<disasm> adamgreig: USB?
<re_irc>
<adamgreig> there was rng, watchdog, pwm
<re_irc>
<adamgreig> USB, ethernet could be things
<re_irc>
<adamgreig> perhaps embedded-can is the better crate name in that case?
<re_irc>
<dirbaio> disasm: I don't think adding an usb trait into a "1.0, will never be majorbumped" crate is a good idea
<re_irc>
<dirbaio> it's like the most complex thing ever
<re_irc>
<jannic> PCIe?
<re_irc>
<adamgreig> :D
<re_irc>
<newam> jannic: Well there's only 3 vendors for gen 4 PCIe PHYs anyway soooo
<re_irc>
<dirbaio> adamgreig: wasn't that the crate name before the merge? 😅
<re_irc>
<adamgreig> thunderbolt, only one vendor right :P
<re_irc>
<adamgreig> yea, it was
<re_irc>
<dirbaio> we're coming full circle aren't we
<re_irc>
<adamgreig> so basically it would be "move the embedded-can crate into the embedded-hal repo and maintain it in the wg hal team, published to embedded-can"
<re_irc>
<dirbaio> maybe?
<re_irc>
<adamgreig> like embedded-dma etc
<re_irc>
<eldruin> I think it could stay in its own repo
<re_irc>
<adamgreig> I mean I guess it could be a separate repo if you wanted yea
<re_irc>
<eldruin> r-e/embedded-can
<re_irc>
<adamgreig> but we've been enjoying putting things in the same repo recently, shrug
<re_irc>
<dirbaio> there's another issue about keeping it in EH1.0: the can receive in the blocking trait is blocking
<re_irc>
<eldruin> yeah but if they will never be merged then it may be better to leave them live their lives
<re_irc>
<timokrgr> catching up on the log, I can unarchive the "embedded-can" or even transfer it into the hal org crate if required
<re_irc>
<adamgreig> I guess see what timokrgr thinks too, embedded-can is his crate
<re_irc>
<adamgreig> ah good timing! hi
<re_irc>
<adamgreig> there have been other changes to the traits since they were moved to embedded-hal right? so it might make sense to just split them out into a new repo
<re_irc>
<adamgreig> or transfer the repo and update the traits, whatever really
<re_irc>
<eldruin> alternatively, we could just publish a new version of it
<re_irc>
<timokrgr> yeah there were some small changes / corrections between "embedded-can" v0.3 and the "embedded-hal" version
<re_irc>
<timokrgr> going for an embedded-can v0.4 which mirrors the current embedded-hal traits would be a possibility
<re_irc>
<eldruin> maybe embedded-can gets to 1.0 before e-h does...
twopoint718 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<re_irc>
<dirbaio> about visibility, we could have an "index" of trait crates? in the embedded-hal README, and/or in the awesome-embedded-rust repo
<re_irc>
<timokrgr> I was not pushing on the CAN traits anymore because I do not use them myself… so probably no quick 1.0
<re_irc>
<timokrgr> but if somebody feels like working on it sure :)
<re_irc>
<eldruin> yeah we would definitely need some kind of index in e-h I would say
<re_irc>
<adamgreig> maybe links from the embedded-hal docs too?
<re_irc>
<adamgreig> timokrgr, would you mind adding me as an owner to the embedded-can crate then?
<re_irc>
<adamgreig> ok, we're out of time to discuss dirbaio's other PRs this week, but thank you for all the insightful discussion everyone!
<re_irc>
<timokrgr> adamgreig: done
<re_irc>
<adamgreig> next week: brand new i2c traits!
<re_irc>
<adamgreig> thanks!
<re_irc>
<dirbaio> I'll update the PR to remove CAN instead
<re_irc>
<dirbaio> adamgreig: hopefully by then I'll have one HAL+driver impl working 😅
<re_irc>
<adamgreig> timokrgr: ah, I meant on crates.io (run "cargo owner --add adamgreig" from the repo)
<re_irc>
<timokrgr> oh lol
<re_irc>
<dirbaio> or will the CAN crate live in the e-h repo?
<re_irc>
<adamgreig> dirbaio: I think discuss on the PR?
<re_irc>
<heksa> Announcing: our (CompEng / SoC Hub at Tampere University) RISC-V MPSoC is out from fab, and wake up's been mostly successful. I think we can bring-up RustSBI/Linux on it if our interrupt lines are not too crossed. We've also started design & verification of the next hardware iteration, which means we get to think about generalizing our workflows across two similar designs, making use of IP-XACT + svd2rust.
_whitelogger has joined #rust-embedded
<re_irc>
<disasm> ...wow
<re_irc>
<heksa> It's summer vacation season around here so we're mostly getting tooling ready for autumn, and I feel like I should be writing papers not code, but it's very exciting.
<re_irc>
<disasm> What are the specs? Is it open?
<re_irc>
<heksa> Not open, though we use lots of FOSS HW components, most notably Ibex (PULP platforms legacy version).
<re_irc>
<heksa> In fact, it's pretty rough getting the some of the software into GitHub because of having to manage all the IP, but I think we'll get the most important parts out
<re_irc>
<heksa> It's got three RISC-V processing subsystems: one Ibex for boot, one PULPissimo for embedded programming, Ariane for high-performance computing. Additionally, we have an NVDLA AI accelerator implementation, an internally developed DSP, C2C for off-chip memory and maybe something I forgot.
<re_irc>
<heksa> I think one of our accelerators was dead from fab, but I'd need to confirm. Probably a design error.
<re_irc>
<heksa> The three RISC-V systems can all read & write, but the interrupts architecture is a little funky in places. Additionally, we failed to implement a UART on the high-performance core, which is hilarious, and makes debugging a little tricky. It can borrow other system's UARTs though.
<re_irc>
<disasm> Does it allow more traditional debugging?
<re_irc>
<heksa> OpenOCD/JTAG/GDB? Yes.
<re_irc>
<heksa> there's been some issues writing from JTAG to AXI, but the JTAG can order the core around to do the writes and everything seems to be working out
<re_irc>
<heksa> Implementing (and fixing legacy) software is mostly a pain. The level of documentation available for open-source hardware components varies a lot.
<re_irc>
<heksa> We have the SDKs for the embedded cores which usually work, but there's been issues with basics such as the very special UART hardware. We have companies doing the hardware, but my team at the university is currently the best resourced software development unit, so we spend a lot of time porting/fixing C SDK features and implementing Rust HALs.
<re_irc>
<heksa> disasm: One cool thing is that we use FPGA's extensively. You can get FPGA implementations from GitHub that are very close to our implementations of some of the subsystems.
<re_irc>
<disasm> I'm not sure if I have FPGA large enough to run this :D
<re_irc>
<heksa> If you write something for e.g. https://github.com/lowRisc/ibex, it probably runs on our two smaller CPUs. The core interrupts indexing is different though.
<re_irc>
<heksa> Those two fit on at least ZCU103.
<re_irc>
<heksa> The boot core fits on PYNQ-Z1, and shares architecture with the medium performance core.
<re_irc>
<heksa> I guess I should mention that https://github.com/rust-embedded/riscv-rt runs on all of the cores almost out of the box. You need to disable the branch that checks for mhartid, because of a hardware bug (or a feature, depending on who you ask).
<re_irc>
<disasm> heksa: Hmm, what kind of bug? Too large hartid?
<re_irc>
<heksa> The original source (PULPissimo) uses the CPU as part of a cluster of CPUs, so the HART ID is computed in RTL code. It ends up being 992 for both of our smaller cores, which is not ideal.
<re_irc>
<heksa> We've been trying to lobby for fixing that for the next hardware iteration, but the hardware designers are understandably concerned about changing... anything :D
<re_irc>
<disasm> Oh nice :D
<re_irc>
<heksa> I think the specification says pretty clearly that the IDs should be different for each core, and the core responsible for boot should be assigned 0.
<re_irc>
<disasm> Yep. Yet it may not work well for booting Linux, that's why it uses hart lottery
<re_irc>
<disasm> On HiFive Unmatched, for example, the core with hartid=0 is not capable of booting Linux
<re_irc>
<disasm> * Unleashed,
<re_irc>
<heksa> That would be the same for us. I think we need to go through at least 4-5 layers of boot to get there.
<re_irc>
<heksa> We're looking a lot towards HiFive Unleashed actually, when designing the next iterations.
<re_irc>
<heksa> (unsurprisingly, perhaps)
<re_irc>
<disasm> Heh, this stuff is so interesting, too bad I rarely find time to play with RISC-V SoCs
<re_irc>
<disasm> I'm mostly fond of task-oriented SoCs though, putting SERV concoctions to FPGAs to solve different tasks
<re_irc>
<newam> I'm curious, does a language specification add anything with respect to safety or is this just a requirement for qualification?
<re_irc>
<adamgreig> I think the primary purpose of putting that together is to work towards iso 26262 qualification, but there's hope it will nevertheless prove useful in teasing out edge cases and such for rust-lang the project
<re_irc>
The reddit comments were enlightening, there was some Q&A there.
<re_irc>
<GrantM11235> adamgreig: (sorry I missed the meeting) What are the downsides to this? Is it just more maintenance burden and less discoverability?
<re_irc>
<adamgreig> yea, I guess so
<re_irc>
<adamgreig> more fragmentation of things that hopefully don't need to be separate
<re_irc>
<GrantM11235> (of course it is easy for me to say "just" more maintenance burden when I'm not the one who has to do it 😅)
<re_irc>
<GrantM11235> What if we kept the e-h crate and re-exported all the sub crates in it?
<re_irc>
<GrantM11235> Then you could choose to use e-h-spi v1.0 if you need stability or you could use the re-export in e-h v42.3 if you want everything in the same place
rardiol has quit [Ping timeout: 268 seconds]
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
rardiol has joined #rust-embedded
rardiol has quit [Client Quit]
<re_irc>
<chrysn (@chrysn:matrix.org)> adamgreig: I don't think it's possible in that direction, as the async generally has intermediate state which nb can't. And it's not possible in the other direction because there is no waker passed.
<re_irc>
There might be an idiom that is nb-ish-but-takes-a-waker that can produce both (limiting the author to not creating intermediate state), but I'm not convinced enough that nb has any benefit over async (when run on a very stupid executor with a no-op waker) to drive that.
twopoint718 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
<re_irc>
<chrysn (@chrysn:matrix.org)> dirbaio: I think it's a quality mark of a good async function to have just one await point, and so little state and side effects before the await point that it gets optimized into the style of nb. But given how effortlessly any state is managed with async, I'm not sure whether that has benefits beyond theoretical purity.
<re_irc>
<chrysn (@chrysn:matrix.org)> (And if multiple await points necessary, while it can still be made nb-style, I don't see how to tell that to the compiler in any other way than to manually build the state machine, which is iffy and needs _very_ convincing benchmarks to justify).
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]