<davidmpye[m]>
Is anyone aware if there are any gotchas using the sequential-storage crate with the rp2040, specifically using a section of its main flash for it? My understanding is that interrupts etc have to be disabled while writing it, but that embassy_rp flash driver handles that.
<diondokter[m]>
It should work just fine
<diondokter[m]>
I do remember an efficiency thing, lemme look that up
<adamgreig[m]>
well, let's begin; I don't have any announcements, does anyone else?
<diondokter[m]>
Expect a new sequential-storage release tomorrow with better cache customizability and a new page state cache that is fixed size and doesn't grow with the amount of pages
<bartmassey[m]>
I just posted in the minutes; looking for comments on possibly deprecating our old Rust Raspberry Pi OS tutorial in favor of the updated version Phil Oppermann and I have been working on sometime soon. I think we're going to take a hiatus after we finish cleaning up, having achieved feature parity with the original.
<bartmassey[m]>
(Plus some nice new things.)
therealprof[m] has joined #rust-embedded
<therealprof[m]>
Ooh nice, haven't seen new stuff from Phil for a while.
<bartmassey[m]>
Yeah, he and I have been working on this for I think a year or so, meeting weekly. It's been fun.
<bartmassey[m]>
We were hoping to extend it further, and may take a break and do so, but getting things where we wanted them was more than we expected.
<adamgreig[m]>
sounds good to me
<adamgreig[m]>
quiet week I think, anyone have any other points to discuss?
<adamgreig[m]>
back to sweltering in the heat here in england at least
<GrantM11235[m]>
I have a few thoughts about the ADC traits, but I don't know if i509vcb is around
<GrantM11235[m]>
My main question is whether there is enough of a use case for generic drivers that need to consume these traits
<bartmassey[m]>
I can't tell you how pro I am for having ADC traits. As somebody who writes a lot of generic embedded audio code…
<bartmassey[m]>
Yeah.
<bartmassey[m]>
DAC is more confusing, because as far as I can tell nobody puts in DACs anymore, because "PWM is good enough". So probably need traits for both DAC and PWM.
<adamgreig[m]>
as in, you're writing libraries that would ideally be given a generic "ADC" trait object and use it to get samples from an ADC?
<bartmassey[m]>
(HW manufacturers: please put flash DACs in. It's not that much HW, and is so much nicer.)
<bartmassey[m]>
Yes, that.
<adamgreig[m]>
what's the utility of having an ADC trait vs having the library user provide the samples?
<GrantM11235[m]>
It seems like the proposed ADC traits aren't very good for that use case, because you need to manually ask for each sample
<bartmassey[m]>
Just convenience, mostly. But also the library then gets to choose the amount of buffering. One alternative is to have the user provide an iterator that produces samples: that has some minor issues but is what I currently tend to do. Yes, I am assuming ADC traits should have a way to request a block of samples, as most ADCs will DMA for this.
<adamgreig[m]>
if only we had Stream
<i509vcb[m]>
For context digital control systems have been the main reason I unearthed the trait discussion.
<i509vcb[m]>
Although I can see justification for buffering
<bartmassey[m]>
I think there's a broader philosophical discussion we should have eventually. To what extent do we want to provide traits for most/all of the peripheral classes that almost every part has? If we do, how much should we worry about the existence of "weird" peripheral instances messing things up? There's a bunch of stuff to think about; maybe we should write a brief note on principles and put it somewhere?
<i509vcb[m]>
I feel one of the hard parts here is my idea of what is ideal some what runs at odds with the embassy hals where those can't even implement the traits because the application has to do synchronization of the underlying hardware
<i509vcb[m]>
Leaning more towards a nursery crate with this discussion
<GrantM11235[m]>
I think in previous discussions we decided that the e-h traits aren't meant to be the way an end user interacts with their hardware, they exist so that people can write generic drivers that work with any hardware
<adamgreig[m]>
yea, that's been the long-standing position
<adamgreig[m]>
HALs should/would generally offer functions for people writing code that uses the HAL, which can be idiosyncratic to the hardware, and would also implement the e-h traits on their structs as appropriate to allow their users to also use them with generic drivers for things like chips attached via spi/i2c
<GrantM11235[m]>
So the question isn't about how to represent ADC hardware, its about what a generic driver author needs so that they don't have to worry about different hardware
<bartmassey[m]>
Aren't those the same question, though?
<GrantM11235[m]>
Do we even need a trait to represent ADC hardware specifically? In the case of a one shot adc, why not just use `FnMut() -> u32`?
<adamgreig[m]>
yea, I think there's a question about what the trait can do besides "give me a sample"
<diondokter[m]>
You need some info about bit width
<adamgreig[m]>
if it gets more complicated, like "give me a buffer" or "arrange a sample rate" or questions about bit depth...
<diondokter[m]>
But the interface could always just left align
<i509vcb[m]>
Bit width came up because I got very annoyed with having to tell every single drive bit width
<i509vcb[m]>
s/drive/driver/
<adamgreig[m]>
ah but then do we have to agree on u32 vs u16 for the underlying samples too... which is then a pain if the adc wants to dma into a buffer
<diondokter[m]>
Not a problem for single-shot
<adamgreig[m]>
still, maybe a combination of bit width, sample rate, and some way to provide samples is convenient
<diondokter[m]>
But for stream, yeah
<bartmassey[m]>
The obvious things are width, latency, sample rate for multisample, volts / step I think.
<i509vcb[m]>
Multisample I'm not sure should be part of the same trait as single shot
<GrantM11235[m]>
If you don't know how a bit of precision relates to voltage, current, speed, or whatever, does it really matter what the bit width or alignment is?
<diondokter[m]>
Also, what to do about ADC's that can measure negative values? Or where a 0 sample is the most negative and the halfway point is the real zero?
<bartmassey[m]>
I would note on the "it's for drivers" question that it seems quite common in my experience for applications to interact with at least some kind of peripherals through the Embedded HAL trait interface rather than the device interface: GPIO and time being the most obvious examples I think?
<bartmassey[m]>
diondokter: Yeah, the trait would need to indicate what the top and bottom of the range are, probably. I think we can generally assume linear ADCs, and that they directly measure voltage?
<bartmassey[m]>
I don't understand why single-shot and multisample would be seperate traits, rather than just separate methods?
<bartmassey[m]>
s/seperate/separate/
<GrantM11235[m]>
It kinda sucks to use e-h for gpio directly in your application, you need to import the traits and deal with them returning `Result<T, Infaillible>`. It is way nicer to just use the HAL directly
<bartmassey[m]>
(I guess that if the ADC was nonlinear the impl could linearize it. Huh.)
<adamgreig[m]>
yea, I think a few older HALs still only implement the traits and no direct methods, but on the whole I think most HALs do offer direct methods that are more user-friendly
<jannic[m]>
e-h not only allows for generic drivers, but also for generic documentation. And then people follow that documentation, even though the hardware specific functions would be more user friendly.
<adamgreig[m]>
bartmassey[m]: probably the whole way the hal sets the chip up will be different between on-demand sampling and continuous, perhaps timer-driven regular sampling into a dma buffer with blocks being passed around
<adamgreig[m]>
so I could see hal authors using different types and wanting to implement different traits on them?
<i509vcb[m]>
Hardware in my case lets you pick between hardware oversampling or none when you start a sample
<adamgreig[m]>
that's a bit hypothetical though
<i509vcb[m]>
* a sample per entry in sequence
<bartmassey[m]>
I guess I can imagine separate traits, but it seems like separate types would be sufficient? Like we do with PWM usually? Yeah, oversampling is worth thinking about. Anyhow, what I guess I'm converging on is that a bunch of design work probably still needs to be done? Does that sound about right? I'm super-happy to give my two cents whenever anyone requests it if this moves forward.
<GrantM11235[m]>
When it comes to dealing with a stream of samples, I don't think it should be tied to the concept of an ADC. The samples could come from i2s, usb, network, or a file. In some cases, I guess you could say that's just ADC with more steps
<adamgreig[m]>
yea indeed, though it's a stream of samples plus some metadata about scale, frequency, size etc I suppose
<adamgreig[m]>
but is it useful to have a trait to encapsulate what we think is enough of that metadata vs having each library write their own interface for it?
<bartmassey[m]>
And the ability to request those things. I can't really do that with a file of samples.
<bartmassey[m]>
My dream is "give me 128 samples sampled at 48000 sps. set the adc range to 1V P-P and tell me what my sample range is" — something like that.
<GrantM11235[m]>
I guess my recommendation is for library authors to define their own traits and ask users to implement those traits with the primitives provided by their HAL. If multiple libraries define similar traits, then I think it makes sense to try to turn them in to an embedded-hal trait
<adamgreig[m]>
yea.. it's not obvious what shape the trait should take yet I think and we're likely to get it wrong by designing it in a vacuum
<adamgreig[m]>
are there any existing examples?
<adamgreig[m]>
I have to run, back in a few minutes, thanks everyone!
<bartmassey[m]>
We're out of time anyhow. If folks still want to play around with ADC traits, let me know how I can help. We could eventually produce a nursery crate with traits and implementations for some common chips, and see what it looked like.
<bartmassey[m]>
Thanks for the great discussion. I have to go also.
<bartmassey[m]>
👋
nikomatsakis[m] has joined #rust-embedded
<nikomatsakis[m]>
D'oh! I wanted to join the meeting today but I missed it. I've been working on something I want to share with y'all. It's ok, though, it's not 100% ready yet. But the basic idea is that I've been adapting the https://github... (full message at
<DnielBuga[m]>
what's your plan to not turn this into an infinite timesink on your end?
<DnielBuga[m]>
s/on/for/, s/your end/you/
bandini has quit [Quit: WeeChat 4.9.2]
<nikomatsakis[m]>
<DnielBuga[m]> what's your plan to not turn this into an infinite timesink on your end?
<nikomatsakis[m]>
Depends what you mean! Keeping the battery pack in sync with the repo isn't too hard, but what I'd prefer to do is to have you all take ownership of the battery pack. I think the repo could be derived from the battery pack easily enough.
<nikomatsakis[m]>
nikomatsakis[m]: This is a draft blog post explaining the vision:
<nikomatsakis[m]>
That said, in the shorter term, I guess what I would like (once it's available) is for people to give it a try and see if it's useful! Maybe link to it.
<DnielBuga[m]>
well, if this is supposed to become one template to rule them all, keeping it up to date and the different pieces cross-compatible will be a colossal task
<DnielBuga[m]>
esp-generate is enough of a burden even within one ecosystem, let alone between HALs of this variety
<nikomatsakis[m]>
I'm not sure what you mean by one template to rule them all, it's basically just an easier way to add dependencies to your project.
<DnielBuga[m]>
ah okay so I got the scope wrong
<nikomatsakis[m]>
i.e., what you can do is select the libraries you want from the menu and cargo bp will add them in. It *can° also have templates and things, I think for that I would probably break it out into other battery packs. My hope is that this tool can become a useful utility to bring some structure to the "awesome X" repo pattern.
sroemer has quit [Quit: WeeChat 4.7.2]
toric has quit [Remote host closed the connection]