<re_irc>
<@adamgreig:matrix.org> if you're using the stm32 SAI peripheral to talk to an external codec, and you're receiving audio data, you don't get to control when it's sampled, you get exactly the data you're given at the rate you are given it
<re_irc>
<@adamgreig:matrix.org> if you're talking about transmitting audio out of SAI, then yea, the SAI clock controls the sample rate and you just have to keep its FIFO filled up so it doesn't underflow
<re_irc>
<@adamgreig:matrix.org> if you were using an ADC or DAC to sample/output signals, using a timer to set the rate would be appropriate, and typically the timer has an internal connection to tell the ADC/DAC to move to the next sample (rather than using an interrupt which would add too much CPU load and jitter)
<re_irc>
<@firefrommoonlight:matrix.org> Thank you
<re_irc>
<@firefrommoonlight:matrix.org> In this case, I'm receieving, so will keep the SAI interrupt
<re_irc>
<@firefrommoonlight:matrix.org> I appreciate it
<re_irc>
<@firefrommoonlight:matrix.org> Current flow is SAI input -> DSP -> DAC output. May end up with an SAI output instead of DAC
<re_irc>
<@firefrommoonlight:matrix.org> Tim6 adn Tim7 are described as intended for that purpose. They appear unable to do more complex things, or trigger interrupts directly
<re_irc>
<@adamgreig:matrix.org> yea, tim6/7 are designed for generating a timebase for a dac, it's very easy to set the dac up to output samples via DMA but timed by the timer
fabic has joined #rust-embedded
emerent has quit [Ping timeout: 252 seconds]
emerent has joined #rust-embedded
<re_irc>
<@pinealservo:matrix.org> It seems weird to me that you'd take audio in through SAI but not send it back out via SAI, assuming it's still meant to be audio.
<re_irc>
<@firefrommoonlight:matrix.org> It's based on the parts I have onhand
<re_irc>
<@firefrommoonlight:matrix.org> Would like to move to that
<re_irc>
<@firefrommoonlight:matrix.org> And I'm learning audio from the basics, so have no idea what I'm doing. Got distracted for a while on H7 clocks too, which are a bit involved
<re_irc>
<@pinealservo:matrix.org> Oh, that's right, you're reading from a microphone rather than a codec.
<re_irc>
<@firefrommoonlight:matrix.org> Does SAI for input and output still make sense?
<re_irc>
<@firefrommoonlight:matrix.org> For realtime audio signal processing
<re_irc>
<@firefrommoonlight:matrix.org> I'll look into an I2s etc headphone amp. Any recs?
<re_irc>
<@pinealservo:matrix.org> Everything's generally synchronized to a MCLK
<re_irc>
<@firefrommoonlight:matrix.org> I was wondering what that was for. It seemed like an optional thing for non-I2S protocols
<re_irc>
<@firefrommoonlight:matrix.org> It also looks like you can do full duplex SAI without it by syncing blocks A and B, but I'm not too sure
<re_irc>
<@firefrommoonlight:matrix.org> I have MCLK disabled now. Currently getting maxxed out input from one I2S mic, and gibberish from another
<re_irc>
<@firefrommoonlight:matrix.org> but have a lot of troubleshooting left to do
<re_irc>
<@pinealservo:matrix.org> MCLK is generally the clock that all the other I2S clocks are derived from, as some multiple of the bit clock as required by the codec to do its sampling process.
<re_irc>
<@pinealservo:matrix.org> So your mic is generating the I2S clocks?
<re_irc>
<@pinealservo:matrix.org> The coded I have the most recent experience with is the SGTL5000; it's also got a headphone amp integrated.
<re_irc>
<@pinealservo:matrix.org> They're a whole other can of worms to get configured correctly, though.
<re_irc>
<@pinealservo:matrix.org> I have also used a variety of AKM and Cirrus Logic codecs.
<re_irc>
<@firefrommoonlight:matrix.org> Thank you for the detailed explanation
<re_irc>
<@firefrommoonlight:matrix.org> My SAI peripheral, configured as a Master receiver, is generating a (SCK and FS) clock
<re_irc>
<@firefrommoonlight:matrix.org> I have a pair of I2S mics on small boards with pins I've been experimenting with, but haven't gotten to work so far. I was pretty lost on how the SAI periph, digitial audio, and I2S in particular work, but now feel more comfortable with the basics
<re_irc>
<@firefrommoonlight:matrix.org> I was surprsied how easy it was getting the DAC peripheral to play a tone from headphones using just a timer, DMA, and the DAC
<re_irc>
<@firefrommoonlight:matrix.org> Eg using a pre-generated sine LUT
<re_irc>
<@firefrommoonlight:matrix.org> I'm a little fuzzy on what a codec is, although the MIC datasheets imply you don't need it
<re_irc>
<@firefrommoonlight:matrix.org> Right now, I'm using an SAI FIFO/FREQ interrupt to continuously read the SAI_ADR reg to a buffer, looping to the beginning when full
<re_irc>
<@pinealservo:matrix.org> A codec (in this context) is just an audio DAC + ADC in one chip, typically with some variant of I2S to talk to a controller or DSP and analog in/out on the other side.
<re_irc>
<@firefrommoonlight:matrix.org> Oh - thank you
<re_irc>
<@firefrommoonlight:matrix.org> I went with DAC as output since when I search for "i2s headphone amp" on Amazon etc, I don't come up with anything relevant
<re_irc>
<@pinealservo:matrix.org> Typically you can set up DMA to create a circular buffer of audio samples so your audio DSP code can have the right block size to deal with, etc.
<re_irc>
<@firefrommoonlight:matrix.org> Awesome. I think after getting the mic to work without DMA, doing it with DMA will be the next step
<re_irc>
<@firefrommoonlight:matrix.org> Well.. Might just dive in since I'm a bit stuck
<re_irc>
<@pinealservo:matrix.org> Something like the SGTL5000 is like the audio interface to a single board computer or a smartphone; it's got a fancy mixer and headphone amplifier and some fixed-function DSP processing, etc.
<re_irc>
<@pinealservo:matrix.org> You can pick up a board to experiment with one fairly easily; the Teensy Audio board uses it, as do some TI Launchpad audio interface boards. https://www.pjrc.com/store/teensy3_audio.html
<re_irc>
<@firefrommoonlight:matrix.org> Awesome. And that one linked would connect to STM32 SAI pins?
<re_irc>
<@pinealservo:matrix.org> Well, it's designed for a teensy board; you wouldn't be able to plug it straight in, but you could jumper the necessary signals over.
<re_irc>
<@firefrommoonlight:matrix.org> So, if I've got this straight: I2S etc microphone[s] input -> SAI block A -> DSP -> SAI (perhaps same periph) block B -> CODEC -> headphones?
<re_irc>
<@pinealservo:matrix.org> Yeah, that should work. The SAI-like peripherals tend to be super flexible (which is why they're so hard to figure out how to set up) but you can get just about any audio part to talk to them.
<re_irc>
<@firefrommoonlight:matrix.org> Hah, that makes sense
<re_irc>
<@firefrommoonlight:matrix.org> The RM has sections on configuring for PDM, SPDIF, and AC97. Figuring out the I2S settings (WHich I probably have at least 1 mistake with) was a bit of an adventure
<re_irc>
<@firefrommoonlight:matrix.org> I think the happy place is 2 slots (Left and right channel), set up the SAI clock so it's 256 * the sample freq (or 512 if you have a certain bit set), set the frame size to 64, and set the `fall` to 32 - this is a bit like a duty period, based on experimenting with a scope
<re_irc>
<@firefrommoonlight:matrix.org> And there's a Div setting you can use too in combination with your SAI periph clock if requried
<re_irc>
<@pinealservo:matrix.org> So, based on what you described there, the SAI clock is what you'd call MCLK. Sounds like you have 2 32-bit samples (or samples frames, anyway) with the traditional LRCLK that's high for one sample and low for the other.
<re_irc>
<@pinealservo:matrix.org> The other configurable bits tend to be justification of the sample in the frame and whether the first bit of a sample is delayed or not with regard to the frame sync.
<re_irc>
<@pinealservo:matrix.org> I used to be able to guess pretty well at what part of all that had been misconfigured by hearing the audio distortions created by them.
<re_irc>
<@firefrommoonlight:matrix.org> From what I can tell, MCLK is for external sync like you mentioned earlier. SCK is the main clock pulse that goes with SAI clock / DIV
<re_irc>
<@firefrommoonlight:matrix.org> But I could be mistaken
<re_irc>
<@firefrommoonlight:matrix.org> From what I gathered from the mic datasheets and STM RM
<re_irc>
<@firefrommoonlight:matrix.org> (Btw, switched the code to DMA, adn the latest is buffer not getting written and an underrun, but probably have a DMA code bug too)
<re_irc>
<@pinealservo:matrix.org> Well, you have 64 bit clock cycles per L/R pair of samples. So you need a div to get from the 256 or 512 multiple down to 64. The un-divided clock is what a codec wants as MCLK.
<re_irc>
<@firefrommoonlight:matrix.org> Maybe it's the same thing in this case, and different terminology?
<re_irc>
<@firefrommoonlight:matrix.org> The scope's showing the SCK line as my SAI1 freq of 112Mhz
<re_irc>
<@pinealservo:matrix.org> Probably just considers it "MCLK" when it's external.
<re_irc>
<@firefrommoonlight:matrix.org> Yea - that makes sense
<re_irc>
<@firefrommoonlight:matrix.org> I currently have the MCLK pin and setting disabled
<re_irc>
<@pinealservo:matrix.org> 112MHz sounds a little fast for a 48KHz sample rate.
<re_irc>
<@theunkn0wn1:matrix.org> Ive got a bit of a wierd question but I hope someone here might be able to help.
<re_irc>
<@theunkn0wn1:matrix.org> I have a logic board for a <domain specific, specialized tool>, which I need to embed into a larger project. We don't have the EE background to replicate the board or its functionality, so my plan is to embed the board as-is and mock its user-interface IO. The front-panel buttons I think i can replicate easily enough using a dozen GPIO pins.
<re_irc>
<@theunkn0wn1:matrix.org> My question is this: if the board has (what I believe to be) a DSI display connector coming out of it; is it possible to capture the display output and render it somewhere else (e.g. send it back to a raspberry pi to be rendered?
<re_irc>
<@theunkn0wn1:matrix.org> any and all pointers would be greatly appreciated
<re_irc>
<@firefrommoonlight:matrix.org> I'm not sure how or why that works quite yet
<re_irc>
<@pinealservo:matrix.org> It doesn't, for 2-channel I2S framing
<re_irc>
<@firefrommoonlight:matrix.org> Table 421. of the RM shows a frame length of 64 for 48Khz
<re_irc>
<@firefrommoonlight:matrix.org> But again, I'm not sure how that works
<re_irc>
<@firefrommoonlight:matrix.org> Althought wiht a 98.3Mhz SAI clock
<re_irc>
<@firefrommoonlight:matrix.org> hrmm
<re_irc>
<@firefrommoonlight:matrix.org> Tried 98Mhz; now getting 0s with no underrun
<re_irc>
<@pinealservo:matrix.org> Where's the datasheet for this i2s mic?
<re_irc>
<@firefrommoonlight:matrix.org> theunkn0wn1: DSI isn't a specific standard. I'd look at the datasheet, or find a dev sheet that publishes the schematic
<re_irc>
<@firefrommoonlight:matrix.org> Or try to reverse engineer the circuitry; it's probably a pile of caps with an inductor and some diodes. Voltage boost circuitry etc
<re_irc>
<@firefrommoonlight:matrix.org> Both seem equivalent, and have no registers to write etc
<re_irc>
<@firefrommoonlight:matrix.org> Just want you to set MSB first, and have some restrictions on the FS-to-WS clock ratios
<re_irc>
<@firefrommoonlight:matrix.org> And soft imply there's a limited range of sample rates available
<re_irc>
<@pinealservo:matrix.org> I think MIPI would disagree about DSI not being a standard.
<re_irc>
<@jorgeig:matrix.org> theunkn0wn1:matrix.org: with video buses, unless you have hardware on the other side to read it back, it's going to be painful if not impossible... AFAIK most DSI controllers output video and get touch/command inputs, so you can't just hook up the DSI output to a Pi's DSI input and capture it
<re_irc>
<@firefrommoonlight:matrix.org> I stand corrected
<re_irc>
<@theunkn0wn1:matrix.org> ouch.
<re_irc>
<@theunkn0wn1:matrix.org> jorgeig:matrix.org: I have both sides of the original hardware. But i don't have any manuals or technical documentation to work with ;|
<re_irc>
<@jorgeig:matrix.org> double ouch
<re_irc>
<@jorgeig:matrix.org> I'm sure there are things like DSI to HDMI boards or something like that that you could hook up to a video capture device
<re_irc>
<@theunkn0wn1:matrix.org> from what i can tell, the actual signal processing is going on inside a CLPD; which I have no idea how I would even begin reverse engineering.
<re_irc>
<@jorgeig:matrix.org> no idea if that's useful
<re_irc>
<@jorgeig:matrix.org> haha
<re_irc>
<@theunkn0wn1:matrix.org> haha
<re_irc>
<@theunkn0wn1:matrix.org> if only this thing's USB interface was documented
<re_irc>
<@theunkn0wn1:matrix.org> if i could drive the logic board from USB that would be grand
<re_irc>
<@theunkn0wn1:matrix.org> but i have no idea; given i don't have access to the vendor's software
<re_irc>
<@theunkn0wn1:matrix.org> The thing has a 8 bit ST MCU on it; but idk if its possible to extract the firmware from it
<re_irc>
<@jorgeig:matrix.org> it probably is
<re_irc>
<@jorgeig:matrix.org> which model?
<re_irc>
<@theunkn0wn1:matrix.org> Sec, trying to find it off my history
<re_irc>
<@pinealservo:matrix.org> Anyway, there do seem to be DSI to HDMI converter things available; I don't know how generic they are. Apparently DSI and CSI are also electrically-compatible, so it may be possible to just hook the DSI output to the Pi CSI input, but you'd probably want to make sure that's what it really is beforehand.
<re_irc>
<@pinealservo:matrix.org> 3.072MHz would be the correct bit clock for a pair of 32-bit sample frames.
<re_irc>
<@pinealservo:matrix.org> At 48KHz sample rate.
<re_irc>
<@jorgeig:matrix.org> theunkn0wn1:matrix.org: it doesn't seem to have any read prot features, so if you have a JTAG connector available, just try to read out the flash
<re_irc>
<@theunkn0wn1:matrix.org> jorgeig:matrix.org: don't have any obviously exposed JTAG ports; I would probably have to solder onto the MCU directly ;|
<re_irc>
<@theunkn0wn1:matrix.org> I will also have to get myself a JTAG connector as All i have lying around is a ST-Linkv2 on my stm32-nucleo boards.
<re_irc>
<@theunkn0wn1:matrix.org> any recommendations?
<re_irc>
<@pinealservo:matrix.org> Heh, it's an 8051.
<re_irc>
<@theunkn0wn1:matrix.org> 8052, according to this manual.
<re_irc>
<@firefrommoonlight:matrix.org> pinealservo: I think you nailed it
<re_irc>
<@firefrommoonlight:matrix.org> I'm getting a bunch of random numbers out of the SAI
<re_irc>
<@firefrommoonlight:matrix.org> That probalby means it's working!
<re_irc>
<@firefrommoonlight:matrix.org> I dropped the clock to 2Mhz
<re_irc>
<@pinealservo:matrix.org> "8051" is the common name for the mcs-51 family, as Intel originally called them. There are lots of numbers they go under.
<re_irc>
<@theunkn0wn1:matrix.org> ah. TOL.
<re_irc>
<@pinealservo:matrix.org> Intel doesn't make them anymore, but apparently everyone else does.
<re_irc>
<@theunkn0wn1:matrix.org> so this ST is a Intel 8051 clone?
<re_irc>
<@jorgeig:matrix.org> theunkn0wn1:matrix.org: if there's nothing evident, let's look for the non-evident ones haha - I'd start with any connector/pin on the board that you don't know what it's for and see if they are connected to the MCU's JTAG pins
<re_irc>
<@jorgeig:matrix.org> maybe you get lucky
<re_irc>
<@jorgeig:matrix.org> and it's low effort
<re_irc>
<@theunkn0wn1:matrix.org> There are two 6-pin connectors on the board that arn't connected to anything, it might be one of those 🤔
<re_irc>
<@theunkn0wn1:matrix.org> I have had very poor luck tracing on this board
<re_irc>
<@pinealservo:matrix.org> 2MHz gives a weird sample rate when you divide by 64; might bite you when you try to send it back out to a codec unless you do sample rate conversion.
<re_irc>
<@jorgeig:matrix.org> theunkn0wn1:matrix.org: take a look at page 194 of the ds
<re_irc>
<@jorgeig:matrix.org> it could be
<re_irc>
<@firefrommoonlight:matrix.org> Thanks for your help - heading to bed, and will work this more tomorrow. You'e already caught a critical error
<re_irc>
<@firefrommoonlight:matrix.org> I'll try 1.33Mhz etc. That should give 48K maybe
<re_irc>
<@theunkn0wn1:matrix.org> jorgeig:matrix.org: Do you also have a JTAG tool that you can recommend? I imagine i need something specific to connect to the JTAG port.
<re_irc>
<@jorgeig:matrix.org> any JTAG probe
<re_irc>
<@firefrommoonlight:matrix.org> Although this PLL is almost minned out
<re_irc>
<@jorgeig:matrix.org> I don't have any specific recommendation - whatever you can get easier and faster I guess!
<re_irc>
<@theunkn0wn1:matrix.org> thanks :D
<re_irc>
<@pinealservo:matrix.org> So, typically the 3 in "8032" would mean romless, meaning it needs to have an external parallel EEPROM or something to read its program from. But in this case, they call it that because the package contains two dies, one of which is a romless MPU and the other is a set of peripherals, including flash memory and RAM. :P
<re_irc>
<@theunkn0wn1:matrix.org> i believe i saw an EEPROM module on this board.
<re_irc>
<@theunkn0wn1:matrix.org> nope, thats an SRAM chip.
<re_irc>
<@pinealservo:matrix.org> If they've got enough pins, 8051 cores know how to do 8-bit bus cycles, although the data is multiplexed with the lower address bits so you need a transparent latch.
<re_irc>
<@pinealservo:matrix.org> firefrommoonlight: 3.072MHz is the correct bitclock rate for 2 32-bit 48KHz samples.
<re_irc>
<@pinealservo:matrix.org> Just multiply the sample rate by the count of bits you need to clock in.
<re_irc>
<@theunkn0wn1:matrix.org> Tore apart the device some more and got a identifying marker for the display that resolves to a datasheet... its not DSI.
<re_irc>
<@pinealservo:matrix.org> Apparently only the 80-pin uPSD parts expose the parallel bus lines and control signals; otherwise they're just used to communicate between the two dies internally.
<re_irc>
<@pinealservo:matrix.org> Does the datasheet say what it the signaling is for it?
<re_irc>
<@theunkn0wn1:matrix.org> yeah gimme a sec, trying to find an exact match
<re_irc>
<@theunkn0wn1:matrix.org> getting sheets for very similar identifiers..
<re_irc>
<@theunkn0wn1:matrix.org> ah the internet. the exact specifier is, apparently, a location in California...
<re_irc>
<@theunkn0wn1:matrix.org> its a dot matrix LCD
<re_irc>
<@theunkn0wn1:matrix.org> the exact identifier is `BTHQ128054AVC1-NS` but that yields no results on google :(
<re_irc>
<@pinealservo:matrix.org> Oh, yeah, those things.
<re_irc>
<@theunkn0wn1:matrix.org> the sticker on this is hard to read
<re_irc>
<@theunkn0wn1:matrix.org> they tried to print too much on too small a sticker lol
<re_irc>
<@pinealservo:matrix.org> Those are in fact designed to work with old-school 8-bit microcontrollers with 8-bit parallel busses.
<re_irc>
<@pinealservo:matrix.org> Although sometimes they can be put in a serial mode as well.
<re_irc>
<@theunkn0wn1:matrix.org> well, this thing *does* have an 8 bit MCU
<re_irc>
<@theunkn0wn1:matrix.org> the JTAG approach seems more practical than trying to interface with this
<re_irc>
<@pinealservo:matrix.org> So, the exact identifiers vary a lot based on stuff like whether it's a positive or negative panel and what color it is, etc.
<re_irc>
<@pinealservo:matrix.org> That datasheet looks close enough to experiment with. And the important bits are the pinout of the interface (you should be able to verify the grounds are in the right place, etc) and the controller it's connected to, which points to a datasheet: https://www.crystalfontz.com/controllers/UltraChip/UC1601S/421/
<re_irc>
<@theunkn0wn1:matrix.org> from what I can tell, the display connector is connecting to the SRAM module via an ESD protection IC.
GenTooMan has quit [Ping timeout: 240 seconds]
<re_irc>
<@theunkn0wn1:matrix.org> Either way, thanks for helping me understand what im looking at <3
<re_irc>
<@firefrommoonlight:matrix.org> Of note, the DAC can also output sawtooth directly with hardware
<re_irc>
<@firefrommoonlight:matrix.org> And the timer/DMA-circular-DAC LUT approach would work as well
<re_irc>
<@firefrommoonlight:matrix.org> (Quite different from I2S obviously)
dcz_ has quit [Ping timeout: 260 seconds]
fabic has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> Ok, got static that jumps when I make noise to output from the DAC; progress of some sort
<re_irc>
<@firefrommoonlight:matrix.org> Mainly from setting the SAI clock freq into the mic operating range as pinealservo identified
fabic has quit [Ping timeout: 265 seconds]
<re_irc>
<@firefrommoonlight:matrix.org> DMA is throwing errors instead of Transfer Completes, so that's the next step
dcz_ has joined #rust-embedded
xnor has quit [Changing host]
xnor has joined #rust-embedded
starblue has quit [Quit: WeeChat 3.0]
GenTooMan has quit [Ping timeout: 252 seconds]
GenTooMan has joined #rust-embedded
loki_val is now known as crabbedhaloablut
Foxyloxy has quit [Read error: Connection reset by peer]
Foxyloxy has joined #rust-embedded
fabic has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> room meeting time again! agenda is https://hackmd.io/0Qxq3TwNT7yWWhlVF0rj5w, please add anything you'd like to discuss and we'll start in 5min :)
<re_irc>
<@adamgreig:matrix.org> ok, let's get started, does anyone have any announcements?
<re_irc>
<@adamgreig:matrix.org> I don't remember anything from this week... let's move on and please shout if you think of anything later
<re_irc>
<@adamgreig:matrix.org> we have a topic we didn't get to last week, I think from eldruin, about commercial involvement, the first part is whether there's anything we might be able to suggest when people from companies reach out saying they'd like to help or get involved
<re_irc>
<@adamgreig:matrix.org> really I guess this applies to non-commercial people asking too, it's sort of the same question...
<re_irc>
<@eldruin:matrix.org> yeah, at the moment it's like "think about something yourself or go through all issues/PRs and think of something you would like to work on"
<re_irc>
<@eldruin:matrix.org> but I guess we would need a higher-level roadmap to be able to suggest something
<re_irc>
<@adamgreig:matrix.org> yea... the last time we tried to put together a more concrete road map it didn't get very much traction
<re_irc>
<@adamgreig:matrix.org> though I agree having one would make it much easier for new contributors to find somewhere to get involved
<re_irc>
<@adamgreig:matrix.org> perhaps it's time to try and assemble one again
<re_irc>
<@thejpster:matrix.org> I guess commercial types can contribute in two ways - they can offer time for people to do work, or they can offer money to either reward those who have done work, or pay for people to do (more) work.
<re_irc>
<@adamgreig:matrix.org> so far I think the offers we've had have mostly been the former
<re_irc>
<@thejpster:matrix.org> But we don't advertise that the latter is welcome?
<re_irc>
<@thejpster:matrix.org> Or is it even welcome?
<re_irc>
<@adamgreig:matrix.org> I don't even know if it is welcome, yea
<re_irc>
<@adamgreig:matrix.org> or at least, we don't have any way to distribute money, and handling it as a rust wg is probably tricky
<re_irc>
<@thejpster:matrix.org> I mean, I personally will exchange labour for currency
<re_irc>
<@thejpster:matrix.org> And I'm sure others will
<re_irc>
<@adamgreig:matrix.org> I would probably suggest just individuals get sponsored on patreon/github sponsors/whatever, but it's not something we'd be coordinating
<re_irc>
<@thejpster:matrix.org> But I don't know how you fairly distribute any incoming funds amongst the WG
<re_irc>
<@adamgreig:matrix.org> (for example knurling-rs and probe-rs both have some sponsors on github)
<re_irc>
<@eldruin:matrix.org> yeah I think we are too loosely coupled for financial stuff
<re_irc>
<@adamgreig:matrix.org> I guess there's "some company wants some feature to exist in a WG crate, they could pay someone to implement it"
<re_irc>
<@adamgreig:matrix.org> but probably not "they could pay the WG to pay someone to implement it"
<re_irc>
<@eldruin:matrix.org> exactly
<re_irc>
<@adamgreig:matrix.org> this hasn't really come up yet compared to "some engineer at a company wants to use more embedded rust, and wonders if they can get involved and help with contributions"
<re_irc>
<@eldruin:matrix.org> that person may be part of the WG or coordinate with the WG in how to do whatever but that is it
<re_irc>
<@adamgreig:matrix.org> yea
<re_irc>
<@adamgreig:matrix.org> certainly wouldn't have any problem with someone getting paid to contribute to wg stuff
<re_irc>
<@eldruin:matrix.org> yeah, it is great when you have people actually paid to do stuff
<re_irc>
<@yatekii:matrix.org> the question is: can you raise as much as is required to pay someone ;)
<re_irc>
<@yatekii:matrix.org> because we certainly can't on probe-rs :D
<re_irc>
<@yatekii:matrix.org> (and that's not to be ingrateful for the support in any way!!)
<re_irc>
<@adamgreig:matrix.org> oh, yea, I'm sure not, beyond stuff like a company wanting a specific feature and paying a specific person to specifically do it
<re_irc>
<@adamgreig:matrix.org> what do people think about trying to put together a wg-wide roadmap again?
<re_irc>
<@adamgreig:matrix.org> having it would probably help revitalise wg-level work and make it easier for people to get involved because there are specific things to do
<re_irc>
<@eldruin:matrix.org> yeah the problem with that approach is that they need to know what they want to do vs. sometimes they do not, and they reach to the WG for ideas
<re_irc>
<@dirbaio:matrix.org> companies would rather pay an employee to work on stuff the company needs
<re_irc>
<@adamgreig:matrix.org> but, the last time we tried to put together such a thing, there wasn't a huge appetite for it
<re_irc>
<@dirbaio:matrix.org> than donate to an opensource project for it to do "stuff"
<re_irc>
<@adamgreig:matrix.org> dirbaio: yea, sure, either pay an employee or basically pay some consultant, either way is fine for us but the wg doesn't touch any money
<re_irc>
<@dirbaio:matrix.org> and if the opensource project is accepting donations for implementing a particular thing then it becomes a consulting business
<re_irc>
<@almindor:matrix.org> you can have them "vote with money" on issues so there are pools for each issue? basically bug bounties for features
<re_irc>
<@almindor:matrix.org> then the implementor gets paid if they do it, not touching the wg itself, it's just a promise of the company to whomever implements it
<re_irc>
<@dirbaio:matrix.org> I've never seen such "bounty" systems work well :\
<re_irc>
<@dirbaio:matrix.org> they raise token amounts of money, like $10, $100
<re_irc>
<@yatekii:matrix.org> tbh, it's hard to see value in things that are kind of under the hood. the WG does ver fundamental work to run the excosystem, but people use the stuff a layer above and often barely notice it I guess :/
<re_irc>
<@dirbaio:matrix.org> not enough for someone to go out of their way and implement the feature
<re_irc>
<@almindor:matrix.org> i've seen bounties in the 5k range work fairly well :)
<re_irc>
<@yatekii:matrix.org> ohwow
<re_irc>
<@dirbaio:matrix.org> so what happens is the bounty stays there, and maybe 2 years later someone implements it, but because they need it themselves, not because of the bounty :P
<re_irc>
<@yatekii:matrix.org> I mean idk I would love if the work was actually sponsored because I think when ou can spend your entire day on it it moves much faster.
<re_irc>
<@dirbaio:matrix.org> and as a company putting up $x on a bounty sucks because you still don't know when/if someone will take it up and implement it
<re_irc>
<@almindor:matrix.org> yeah it needs some control, also the money should be reserved and that's another bag of chips. Funny enough cryptocurrencies could be used for this purpose, including the "timeout" aspect, but many people still mistruct this
<re_irc>
<@dirbaio:matrix.org> of if you pay for "part", you don't know how much time it'll take for enough money to pool for someone to look at it
<re_irc>
<@dirbaio:matrix.org> and if you're paying for "enough" yourself alone, you may as well pay a classic consultant
<re_irc>
<@almindor:matrix.org> indeed, it's not an easy problem to solve, bounties do make the disconnect possible tho
<re_irc>
<@almindor:matrix.org> the WG only organizes and oversees, never moves money aound
<re_irc>
<@dirbaio:matrix.org> because when you need something, you need it *now*
<re_irc>
<@bobmcwhirter:matrix.org> thejpster:matrix.org: Sorry I'm late in replying, but there are Commercial Entities that support what they can financially, when there's a known process. Knurling and probe-rs from my POV are supported by my employer.
<re_irc>
<@bobmcwhirter:matrix.org> time+effort-wise, embassy is also
<re_irc>
<@bobmcwhirter:matrix.org> so my vote is "make a process and make it known" and you might have more luck getting monetary support
<re_irc>
<@almindor:matrix.org> there are also existing "job markets" for "odd jobs" which can be another way to look at this, company can post a "job" for something to be done. No pooling then. It saves them the search for a contractor and we get all the "offers" in a central place for wg related work
<re_irc>
<@adamgreig:matrix.org> I wouldn't have thought we want to accept money for the wg or allow it to be sponsored on github anyway, though
<re_irc>
<@adamgreig:matrix.org> and I don't think the lack of money is causing slow wg crate development
<re_irc>
<@dirbaio:matrix.org> is "companies want to throw cash at the Rust Embedded ecosystem and can't" a problem we're having?
<re_irc>
<@adamgreig:matrix.org> no
<re_irc>
<@adamgreig:matrix.org> afaik
<re_irc>
<@dirbaio:matrix.org> I think the problem is "not enough companies are using Rust Embedded" :D
<re_irc>
<@almindor:matrix.org> dirbaio:matrix.org: that's definitely a worse problem to have :D
<re_irc>
<@adamgreig:matrix.org> or more acutely, it's hard for people to get involved in the wg and wg crates, perhaps in part because it's not clear how to get involved or what wants to be worked on
<re_irc>
<@bobmcwhirter:matrix.org> so we need to find out why that is, and how we can solve for it.
<re_irc>
<@dirbaio:matrix.org> and companies *are* throwing resources at the ecosystem. In manpower, not cash
<re_irc>
<@adamgreig:matrix.org> to be fair, I think a lot of attention is now going to higher-level concerns like the HALs, embassy, probe-rs, RTIC, etc, which is great and outside the wg's remit
<re_irc>
<@adamgreig:matrix.org> but if we want to progress wg things like svd2rust, cortex-m{,-rt}, etc, how do we get more involvement there?
<re_irc>
<@yatekii:matrix.org> ^ this :)
<re_irc>
<@dirbaio:matrix.org> and IMO "it's not clear what wants to be worked on" is not really a problem
<re_irc>
<@dirbaio:matrix.org> companies are not like "I want to work on whatever, what should I do"
<re_irc>
<@adamgreig:matrix.org> individuals from companies (and not from companies) have, though
<re_irc>
<@dirbaio:matrix.org> companies are like "I need X and svd2rust/cortex-m-rt/cross doesn't support it"
<re_irc>
<@yatekii:matrix.org> Also, for any contributions to be significant, I really think you also need to do lots of advertising etc :)
<re_irc>
<@disasm-ewg:matrix.org> Or maybe "I want to do X, how I should do it properly?"
<re_irc>
<@dirbaio:matrix.org> for the "I want to do X" IMO the process is working
<re_irc>
<@dirbaio:matrix.org> people ask in issues or in this chat, and PRs come in
<re_irc>
<@therealprof:matrix.org> dirbaio:matrix.org: I agree.
<re_irc>
<@richarddodd:matrix.org> How about somewhere where people can say "I want this and it doesn't exist yet" money could come later if necessary.
<re_irc>
<@richarddodd:matrix.org> Like a request list
<re_irc>
<@dirbaio:matrix.org> I can think of 2 reasons for there being not much traffic
<re_irc>
<@adamgreig:matrix.org> but it does not get many suggestions
<re_irc>
<@dirbaio:matrix.org> 1. lots of the REWG stuff Just Works, it's Done(TM)
<re_irc>
<@dirbaio:matrix.org> cortex-m, cortex-m-rt Just Work
<re_irc>
<@adamgreig:matrix.org> I'm also not completely convinced the process is ideal for the "I want to do X", I feel like often the answer is "you can't" or "it's a huge amount of work no one has done" or something
<re_irc>
<@richarddodd:matrix.org> I would think that when people want something they just go and do it.
<re_irc>
<@thejpster:matrix.org> dirbaio, yeah but they're not 1.0 though are they
<re_irc>
<@adamgreig:matrix.org> dirbaio:matrix.org: to their detriment now, I feel, given the things they don't do that would be nice
<re_irc>
<@adamgreig:matrix.org> same with svd2rust though, right? it just works and yet
<re_irc>
<@dirbaio:matrix.org> also about cross, it's unmaintained but the truth is It Works, I use it a lot. I wouldn't even notice it's unmaintained if I didn't look into the github 🤣
<re_irc>
<@dirbaio:matrix.org> and yeah about svd2rust
<re_irc>
<@dirbaio:matrix.org> this is the 2nd reason for not much traffic
<re_irc>
<@disasm-ewg:matrix.org> adamgreig: Yep, I already saw a few people struggling to understand a general process behind supporting a chip in Rust ecosystem. Probably this part is not documented properly.
<re_irc>
<@dirbaio:matrix.org> 2. the REWG is good at incorporating "incremental improvements", but not "full redesigns"
<re_irc>
<@dirbaio:matrix.org> "PACs having one owned singleton per SVD peripheral causes issues X, Y, Z. Moving them to HALs fixes them" is a gargantuan task
<re_irc>
<@dirbaio:matrix.org> to the point that people don't even try
<re_irc>
<@adamgreig:matrix.org> right, same problem with e.g. the cortex-m split into separate crates and/or using svd2rust to generate the register access, or cortex-m-rt plumbing vs porcelain concepts
<re_irc>
<@dirbaio:matrix.org> yup!
<re_irc>
<@adamgreig:matrix.org> any of the sufficiently big changes where what we have today works Well Enough, doing the technical work would be pretty hard, and then getting consensus harder
<re_irc>
<@adamgreig:matrix.org> is it a problem? is it hindering embedded rust adoption?
<re_irc>
<@adamgreig:matrix.org> it's hard to say from the inside how much of an issue it actually is, I guess
<re_irc>
<@dirbaio:matrix.org> uh
<re_irc>
<@thejpster:matrix.org> Not being C is still top of my "reasons why you can't write this for me in Rust" list
<re_irc>
<@adamgreig:matrix.org> but I'm sure at least one or two companies are basically doing their own thing for stuff like the cortex-m/-rt crates because they don't work for their use cases
<re_irc>
<@dirbaio:matrix.org> People often complain about all the constrain(), split(), `&mut cfgr` stuff in HALs
<re_irc>
<@dirbaio:matrix.org> especially newcomers
<re_irc>
<@bobmcwhirter:matrix.org> split() made sense to me, but to this day, I haven't grokked why it's called `constrain()`
<re_irc>
<@dirbaio:matrix.org> my first try using rust embedded was with stm32f1xx-hal
<re_irc>
<@dirbaio:matrix.org> and my first reaction was "WHAT THE FUCK is all this shit"
<re_irc>
<@adamgreig:matrix.org> if we had weekly stm32-rs meetings, I'm sure we could have this same discussion about the incredible amount of work to refactor all the HALs into a brave new unified future
<re_irc>
<@ryan-summers:matrix.org> I want to chime in that there's likely a significant subset of companies that would love to leverage the embedded-rust ecosystem, but can't due to standards requirements. E.g. for medical devices, IEC 62304 treats a lot of the embedded ecosystem as SOUP, and there's a ton of justification and analysis required to leverage it
<re_irc>
<@therealprof:matrix.org> adamgreig: Some companies also just love reinventing the wheel.
fabic has quit [Ping timeout: 260 seconds]
<re_irc>
<@ryan-summers:matrix.org> As a result, this means that it's often easier for a company to just rewrite it themselves instead in a proprietary fashion
<re_irc>
<@dirbaio:matrix.org> and lots of that complexity is caused by PACs having owned singletons
<re_irc>
<@adamgreig:matrix.org> ryan-summers: do they still use rust but just not existing crates, or end up not using rust?
<re_irc>
<@adamgreig:matrix.org> ah, yea, fair
<re_irc>
<@dirbaio:matrix.org> so I woud say that YES, that is hindering rust embedded adoption
<re_irc>
<@eldruin:matrix.org> grand redesigns is probably not the best thing to give to some newcomer, even if he is paid to do it. But maybe there is something like support for USB feature X would be great to have, which is fairly self-contained
<re_irc>
<@bobmcwhirter:matrix.org> the HAL macro-based impls is also... daunting to jump into at first.
<re_irc>
<@adamgreig:matrix.org> from what I hear it does depend a lot on how much of a hardass you think your auditor will be, i've seen some quite generous soup reviews lol
<re_irc>
<@thejpster:matrix.org> ugh, yeah, no common trait for each UART register block is a pain
<re_irc>
<@dirbaio:matrix.org> and
<re_irc>
<@dirbaio:matrix.org> all these issues are solvable
<re_irc>
<@adamgreig:matrix.org> (though i totally get you, for similar regulated stuff it's much easier to write something from scratch and be sure it's compliant than review an existing crate, and also in rust the existing crate probably has 10 more dependencies)
<re_irc>
<@ryan-summers:matrix.org> adamgreig: Often, this reasoning leads them to just use legacy C codebases unfortunately. That combined with their engineering talent being unexperienced in Rust
<re_irc>
<@bobmcwhirter:matrix.org> and things like ST's forums all discuss ST .c/.h code and examples, which doesn't help.
<re_irc>
<@ryan-summers:matrix.org> I've been starting discussions on new projects using Rust, and the SOUP argument is a tough sell
<re_irc>
<@bobmcwhirter:matrix.org> and stackoverflow is seldom helpful
<re_irc>
<@ryan-summers:matrix.org> SOUP = software of unknown providence
<re_irc>
<@dirbaio:matrix.org> when you have a hammer everything looks like a nail
<re_irc>
<@dirbaio:matrix.org> gpio typestates
<re_irc>
<@ryan-summers:matrix.org> So while the embedded ecosystem is great for many companies, it's not a great fit for companies that work with standards organizations and/or need regulatory approval
<re_irc>
<@dirbaio:matrix.org> const generics
<re_irc>
<@dirbaio:matrix.org> :P
<re_irc>
<@richarddodd:matrix.org> I've found the SO problem mitigated by the friendly and patient matrix room :)
<re_irc>
<@bobmcwhirter:matrix.org> something like <cough>Red Hat</cough> helps with SOUP stuff, since they follow a "if we ship it, we support it" (and patch it etc). But getting them on-board at that level would be a challenge. Or so I hear.
<re_irc>
<@adamgreig:matrix.org> ryan-summers:matrix.org: hopefully the ferrocene stuff might help with this, providing a pre-checked compiler and set of libraries, but it's outside the wg's scope
<re_irc>
<@dirbaio:matrix.org> richarddodd:matrix.org: I'd say the rust-embedded newcomers that DO come to this room are a minority, unfortunately!
<re_irc>
<@dirbaio:matrix.org> most newcomers are "wtf is constrain() and split()? I don't understand shit, I give up"
<re_irc>
<@bobmcwhirter:matrix.org> I do appreciate jamesmunns and everyone's "hey, be nice, we're not assholes here" mantra.
<re_irc>
<@ryan-summers:matrix.org> Yeah, 100% agreed adamgreig - I just wanted to bring up the aspect that the embedded ecosystem can't be leveraged by every company out there, which is unfortunate
<re_irc>
<@richarddodd:matrix.org> Is there a list of people publicly using Rust? I was on the Oxford Ionics page and wondered how many other companies there were
<re_irc>
<@adamgreig:matrix.org> that's actually the 2nd part of eldruin's agenda item, about collecting testimonials from commercial embedded rust users
<re_irc>
<@richarddodd:matrix.org> dirbaio:matrix.org: Yeah joining chat rooms is always intimidating and not everyone will do it
<re_irc>
<@bobmcwhirter:matrix.org> richarddodd: Red Hat has some server-side Rust stuff in play, and publicly does drogue.io, for some value of "public" and "does".
<re_irc>
<@adamgreig:matrix.org> but it's definitely pretty out of date now
<re_irc>
<@bobmcwhirter:matrix.org> but we're not End Users.
<re_irc>
<@dirbaio:matrix.org> I'd be happy to do a testimonial from Akiles
<re_irc>
<@richarddodd:matrix.org> Another option to get commercial together is a (virtual or otherwise) conference
<re_irc>
<@ryan-summers:matrix.org> I'm sure Quartiq would be interested as well
<re_irc>
<@adamgreig:matrix.org> richarddodd: I guess you mean specifically publicly using rust embedded? sooo many companies using rust for non-embedded stuff now
<re_irc>
<@adamgreig:matrix.org> perhaps if the people here who mentioned being interested would like to write up a few sentences, we could ask rust-lang to update the website
<re_irc>
<@adamgreig:matrix.org> which, wow, that's long
<re_irc>
<@richarddodd:matrix.org> The non embedded is FAANG + everyone else now I guess
<re_irc>
<@adamgreig:matrix.org> only one hit for `cryptocurrency` on that page 👀
<re_irc>
<@eldruin:matrix.org> ergo, long list for embedded is not a problem
<re_irc>
<@dirbaio:matrix.org> FAANG JS developers trying to learn the borrow checker
<re_irc>
<@disasm-ewg:matrix.org> adamgreig: They are busy making money!
<re_irc>
<@adamgreig:matrix.org> evidently!
<re_irc>
<@richarddodd:matrix.org> disasm-ewg:matrix.org: Making virtual money 💵
<re_irc>
<@bobmcwhirter:matrix.org> they prefer to call it "unrealized temporal gains"
<re_irc>
<@richarddodd:matrix.org> Weirdly I think that community and embedded do share a need for no_std
<re_irc>
<@adamgreig:matrix.org> anyway, thanks for all the offers for some commercial testimonials, having some new ones on the rust website would be great
<re_irc>
<@adamgreig:matrix.org> I'm not sure where we got to on the idea of developing a wg roadmap or otherwise encouraging more contributors though, heh
<re_irc>
<@adamgreig:matrix.org> I guess we need to assemble a hit squad of people determined to make a big svd2rust change or something
<re_irc>
<@thejpster:matrix.org> For &-refs or &mut refs?
ni has quit [Remote host closed the connection]
<re_irc>
<@grantm11235:matrix.org> thejpster:matrix.org: Mostly for &mut refs, but for example InputPin could be impl'd for immutable refs
<re_irc>
<@thejpster:matrix.org> I thought it was automatic for &mut refs? As in Rust will deref as much as is required.
<re_irc>
<@thejpster:matrix.org> I recall that std::io::{Write, Read} are impl on &Socket, because otherwise you would need to own the socket or have a mutable ref to it (all the io trait methods are &mut self).
<re_irc>
<@thejpster:matrix.org> It's a bit odd that you get an &mut ref to an &Socket, but it works.
<re_irc>
<@therealprof:matrix.org> Yeah, but I have serious doubts people will be happy to bloat e-h by adding proc-macro use.
<re_irc>
<@thejpster:matrix.org> But if T: Write, and I have an x: &mut T, I can already call x.write(), no?
<re_irc>
<@thalesfragoso:matrix.org> thejpster:matrix.org: Yes, but you can't pass it to a place that accepts T: Write
<re_irc>
<@grantm11235:matrix.org> thejpster:matrix.org: The purpose is to allow generic driver structs to take either owned peripheral structs or mut refs
<re_irc>
<@richarddodd:matrix.org> OT: I really would like to see syn distributed as at component by rustup so it's not such a big deal to add a proc macro
<re_irc>
<@richarddodd:matrix.org> therealprof:matrix.org: Hmm yeah you might be right
<re_irc>
<@thejpster:matrix.org> It feels like maybe Rust could impl that for you
<re_irc>
<@thejpster:matrix.org> Why would a function take a x: T where T: Write when it could take an x: &mut T?
<re_irc>
<@thejpster:matrix.org> I guess we have some drivers which want to own a pin/bus/peripheral for some period of time and then release it later, rather than receiving it by reference repeatedly.
<re_irc>
<@grantm11235:matrix.org> thejpster:matrix.org: I believe that it is sometimes easier for a driver struct to own the underlying peripheral to prevent self-reference problems
<re_irc>
<@grantm11235:matrix.org> At least I think that is what dirbaio told me a while ago
<re_irc>
<@dirbaio:matrix.org> forcing borrowing is super annoying
<re_irc>
<@dirbaio:matrix.org> if a driver does this
<re_irc>
<@dirbaio:matrix.org> the user is forced to do `struct MyUserStruct<'a>`. The lifetime "infects" the whole struct stack
<re_irc>
<@dirbaio:matrix.org> you can try using `'static` and put the `Uart<UART3>` in a static but that sucks
<re_irc>
<@thejpster:matrix.org> ah, right. Yeah, I end up putting lifetimes on a lot of things when I do this.
<re_irc>
<@almindor:matrix.org> ownership should be preferred where singleton of the resource is guaranteed, in other words if no sharing of the resources that the driver consumes should possible in general
<re_irc>
<@almindor:matrix.org> it's still a PITA problem, because even in those cases it's not clear cut. Say I make an SPI object from pins but one of them is the LED I want to blink at the end of the program to signal it's finished. There's no reason why I can't do this but now the drivers need to implement .release() -> Resource? so I can get the pin back
<re_irc>
<@dirbaio:matrix.org> allowing borrowing solves that :D
<re_irc>
<@almindor:matrix.org> yes but then forces the 'lifetime issue :)
<re_irc>
<@dirbaio:matrix.org> you drop the SPI object, which clears the borrow on the pins
<re_irc>
<@dirbaio:matrix.org> *allowing* borrowing, not *forcing* borrowing :)
<re_irc>
<@dirbaio:matrix.org> so
<re_irc>
<@almindor:matrix.org> oh that works but then it makes the driver pretty complex :D
<re_irc>
<@dirbaio:matrix.org> you can create the SPI with `PA5` or `&mut PA5`
<re_irc>
<@dirbaio:matrix.org> embassy does that :D
<re_irc>
<@almindor:matrix.org> I wonder if we could simplify this through standardization on the e-g level
<re_irc>
<@dirbaio:matrix.org> if you create it with owned pins like `PA5` you get a `Spi<'static, SPI4>`. With borrowed `&mut PA5` you get a `Spi<'a, SPI4>`
<re_irc>
<@almindor:matrix.org> yeah but you need to then drap the pins in some sort of OwnerOrBorrowed type wrapper right?
<re_irc>
<@almindor:matrix.org> "wrap"
<re_irc>
<@dirbaio:matrix.org> it uses a bit of haxx to get it to be zero-cost
<re_irc>
<@almindor:matrix.org> yeah hence the "driver then becomes difficult" part
<re_irc>
<@dirbaio:matrix.org> but it's not *that* difficult
<re_irc>
<@dirbaio:matrix.org> and then it *stores* the copy of the pin, as if it was owned
<re_irc>
<@dirbaio:matrix.org> so it's still zero-sized (even though `&mut PA5` isn't)
<re_irc>
<@almindor:matrix.org> I wonder if this kind of approach should be made standard for drivers that use embedded-hal
<re_irc>
<@dirbaio:matrix.org> but it's the copy that it obtained through `unborrow()`, so by the safety contract it's bound to not use it beyond the `'a` lifetime
<re_irc>
<@dirbaio:matrix.org> it only works for "dumb" singletons that don't contain state though
<re_irc>
<@almindor:matrix.org> right, hence your "upside down" approach to pin state
<re_irc>
<@dirbaio:matrix.org> it doesn't work for a "full" driver
<re_irc>
<@dirbaio:matrix.org> for full drivers you need to use the full &mut
<re_irc>
<@dirbaio:matrix.org> like
<re_irc>
<@dirbaio:matrix.org> embassy HAL driver: `Spi<'static>` owned, `Spi<'a>` borrowed
<re_irc>
<@dirbaio:matrix.org> because `my_hal::Spi` may contain state
<re_irc>
<@dirbaio:matrix.org> so you need the real `&mut`
<re_irc>
<@almindor:matrix.org> thing is even using full ownding and release is probably not so bad, except we have no way of forcing the interface
<re_irc>
<@almindor:matrix.org> drivers can become very "os unfriendly" right now
<re_irc>
<@dirbaio:matrix.org> APIs based on "release() / free()" are annoying too
<re_irc>
<@dirbaio:matrix.org> if you want to create/destroy that `MyDisplayDriver` on demand, you have to store a `Option<my_hal::Spi>` and take it out and put it back
<re_irc>
<@dirbaio:matrix.org> with borrowing you just borrow it
<re_irc>
<@bobmcwhirter:matrix.org> dirbaio:matrix.org: hey, I recognize that code!
<re_irc>
<@grantm11235:matrix.org> dirbaio:matrix.org: Of course, the display driver would be written as `MyDisplayDriver<SPI: e_h::Spi::blocking::Write>`
<re_irc>
<@dirbaio:matrix.org> yep
<re_irc>
<@dirbaio:matrix.org> the `&mut` blanket impls sound like a sound idea (heh)
<re_irc>
<@dirbaio:matrix.org> I can't think any reason why you would *not* want them
<re_irc>
<@dirbaio:matrix.org> HALs can no longer impl the traits for a `&mut`, but why'd they want to do that in the first place I dunno
<re_irc>
<@grantm11235:matrix.org> dirbaio:matrix.org: Well it is a PITA to do it manually, but other than that...
<re_irc>
<@dirbaio:matrix.org> hehehe :D
<re_irc>
<@grantm11235:matrix.org> Done! Only 388 lines 😬
<re_irc>
<@grantm11235:matrix.org> If anyone wants to write a quick summary of why that is useful, please feel free. I don't have the time right now.
creich_ has joined #rust-embedded
creich has quit [Ping timeout: 252 seconds]
dcz_ has quit [Ping timeout: 252 seconds]
crabbedhaloablut has quit [Ping timeout: 276 seconds]
crabbedhaloablut has joined #rust-embedded
<karlp>
isn't that what would be in the commit message? not the what, but they why/how?
<re_irc>
<@firefrommoonlight:matrix.org> bobmcwhirter:matrix.org: More specifically, the ST Community site posts largely assume official HAL
<re_irc>
<@firefrommoonlight:matrix.org> If they talked in the language of registers and writes, it would be more transparent
<re_irc>
<@firefrommoonlight:matrix.org> I also get the impression ST encourages use of HAL, and considers LL for advanced users, and IIRC isn't even supported on a number of their MCUs