<firefrommoonligh> > here we go again... using the F4 HAL, what's the easiest way to change timer frequency so that I don't have to destroy the timer and create it every time I change it?
<firefrommoonligh> Fork the HAL, and add something like this: https://github.com/David-OConnor/stm32-hal/blob/main/src/timer.rs#L294
<firefrommoonligh> therealprof: You have the power: Thoughts on adding that quickly? IMO you can just add and immediately merge a PR to fix that and the >1S timer limitation
<firefrommoonligh> Could knock it out quickly
<firefrommoonligh> * therealprof: You have the power: Thoughts on adding that? If I understand correctly, you have the privalege to add and immediately merge a PR to fix that and the >1s timer limitation
<firefrommoonligh> * therealprof: Thoughts on adding that? If I understand correctly, you have the privalege to add and immediately merge a PR to fix that and the >1s timer limitation
<firefrommoonligh> * therealprof: Thoughts on adding that? If I understand correctly, you have the privileges to add and immediately merge a PR to fix that and the >1s timer limitation
<firefrommoonligh> * > here we go again... using the F4 HAL, what's the easiest way to change timer frequency so that I don't have to destroy the timer and create it every time I change it?
<firefrommoonligh> Fork the HAL, and add something like this: https://github.com/David-OConnor/stm32-hal/blob/main/src/timer.rs#L291
<firefrommoonligh> https://github.com/stm32-rs/stm32f4xx-hal/issues/260 is also a clean kill
<thalesfragoso[m]> richardeoin: I noticed you don't send the `cmdtrans` bit when sending a command that will start a data transfer
<thalesfragoso[m]> * richardeoin: I noticed you don't set the `cmdtrans` bit when sending a command that will start a data transfer
<therealprof[m]> firefrommoonlight: Everytime I read "fork the HAL" a shiver runs down my spine, stop doing that. What exactly is your ask?
mtthwmeyer[m] has quit [Quit: Idle for 30+ days]
yruama_lairba[m] has quit [Quit: Idle for 30+ days]
jkristell[m] has quit [Quit: Idle for 30+ days]
<Albru[m]> That reminds me that I should maybe PR fixes for the timer ARR miscalculation...
<Albru[m]> I would really like to see all the HALs having the same API where possible so that everyone gets the benefits when better API is designed...
jkristell[m] has joined ##stm32-rs
<korken89[m]> Wow, the chip shortage seems to the STM32s hard
<korken89[m]> * Wow, the chip shortage seems to hit the STM32s hard
<agg> yea...
<korken89[m]> All MCUs in our products are like 53 weeks away
<agg> a bit surprising since ST have some of their own fabs but I understand they had some strikes in 2020 that caused trouble too?
<agg> I think a bunch of STM32s are TSMC
<korken89[m]> Yeah
<korken89[m]> I wonder how chip companies takes this
<agg> I'm having most trouble with stupid parts like ldos, can phys, little smps controllers...
<korken89[m]> I mean, if they can manufacture chips, how do they make money?
<korken89[m]> * I mean, if they can't manufacture chips, how do they make money?
<agg> they are all manufacturing as fast as they can I think
<korken89[m]> Yeah
<agg> just a funny chain of stupid accidents and disasters all along the semiconductor supply chain
<korken89[m]> Plus I guess "big shots" vacuumed the market to secure supply as well
<agg> fires, winter storms, strikes, covid, apparently some shennigans with automotive customers cancelling orders, high demand for consumer stuff, etc
<agg> yea once it got bad you can see everyone hoovering distributor stock up
<korken89[m]> The semiconductor super-storm
<agg> octopart had these horrifying charts a couple months back https://imgur.com/a/7rFEjYc
<agg> global inventory across all the distributors they track
<korken89[m]> Jebus
<agg> I've gotten lucky in that the 0.8mm BGA STM32s seem less in-demand
<korken89[m]> It's a full no-no-no-no on that one
<agg> so I've been able to get a few F4 and H7 in those packages
<korken89[m]> <agg "I've gotten lucky in that the 0."> We just got hit on the HS probe
<korken89[m]> Seems like we can only make 130 of 200
<agg> jeez
<agg> you'd think it would be 0 or 200
<agg> it's not like you need 10000
<korken89[m]> Yeah
<agg> amazed you've found 130 of them tbh
<korken89[m]> "Luckily" we only have 120 orders
<agg> hah
<agg> some luck
<korken89[m]> So we can fill the orders, but no stock :(
<diondokter[m]> :(
<agg> anything else tricky to get?
<diondokter[m]> Yeah, this situation sucks
<korken89[m]> Youknow random ICs as you say
<korken89[m]> I have switched LDO
<korken89[m]> Ideal diode
<korken89[m]> USB connector
<agg> yeppp
<agg> same pcb or did it need a respin?
<agg> some optimists think it will be better in like 4-6 months, others are saying it's going to get worse until 22, big suck
<korken89[m]> Same PCB luckily
<agg> good year to focus on the software i guess
<korken89[m]> Yeah
<korken89[m]> "Well we don't have hardware" xD
<agg> luckily we sell about 30 stm32s worth of stuff per year so it's not the biggest disaster
<korken89[m]> Nice
<agg> otoh that means the most I can justify stockpiling is like, 5 stm32s, lol
<agg> ecp5 also proving a challenge
<korken89[m]> Any installation we do in the company usually means 500 STM32s needed
<korken89[m]> I'm getting creative now
<agg> weirdly found a bunch of speed grade 8, 85k LCs briefly at digikey
<agg> mine now
<korken89[m]> Nice :D
<agg> i only needed 12k and grade 6, lol
<korken89[m]> Wizard hat on, how to go from fully utilized 48 pin to 32 pin (which has stock)...
<agg> hah
<korken89[m]> That will be the weekends issue
<agg> hate having to do engineering work to work around stupid supply chain problems
<korken89[m]> Haha
<korken89[m]> Yeah
<agg> but i guess something something necessity, invention, etc
<agg> just so long as it _does_ eventually go back to normal
<korken89[m]> Yeah
<korken89[m]> Please recover soon IC industry
<agg> I heard rumours of a passives shortage in q4 :X
<agg> 2018's waking nightmare
Lumpio[m] has joined ##stm32-rs
<Lumpio[m]> oo so this exists
<agg> o/
<Lumpio[m]> yo
<agg> on freenode too
<firefrommoonligh> I'm asking that you fix timers on the HALs you're a maintainer of instead of ignoring PRs and issues that can be fixed in minutes
<firefrommoonligh> > firefrommoonlight: Everytime I read "fork the HAL" a shiver runs down my spine, stop doing that. What exactly is your ask?
<Lumpio[m]> <agg "octopart had these horrifying ch"> Oh very nice
<Lumpio[m]> Luckily I'm not in charge of any volume production...
WinniSimon[m] has joined ##stm32-rs
<firefrommoonligh> Yea - I've been trying to be flexible about MCU and footprint in the meanwhile, and have been hand-soldering ones bought from Digikey
<agg> I think digikey are dribbling out stock to stop someone buying it all
<agg> a few parts they had '30' left and I bought 20 and it went down to 10, and then two days later back to 30
<firefrommoonligh> If so, I'm thankful for that
<firefrommoonligh> OH FUCK the MCU I'd been using is now out
<firefrommoonligh> I'm so fucked
<firefrommoonligh> Maybe if i change footprint or something
<firefrommoonligh> * I'm so screwed
<agg> gotta buy it as soon as it's in stock, lol
<firefrommoonligh> I'm about to YOLO some L412s (Had been using 442s) and hope it works
<firefrommoonligh> Had already changed from 443 in a diff footprint because of this once...
<firefrommoonligh> Skim of user manual says it'll be fine
<firefrommoonligh> *mayb enot
<firefrommoonligh> I'm looking at this now with an eye more towards "What MCU is in stock, has the features I need, isn't too expensive, and ideally has the same footprint as the existing design" rather than choosing the *right* tool for the job
<firefrommoonligh> Are there any known PAC anomalies for DMA? Running into issues where DMA_CCR is missing on F3 and G0, and L5 is missing most fields on DMA_CCR.
<dirbaio[m]1> CCR is blockified in that one, it's in ch1.cr, ch2.cr...
<firefrommoonligh> Oh my - thank yoU!
<dirbaio[m]1> there are 2 completely different versions of DMA out there though (real different, not pac inconsistencies)
<dirbaio[m]1> most are DMAv1. F4, F7, H7 are DMAv2
<dirbaio[m]1> what DMAv1 calls "channels", DMAv2 calls "streams"
<firefrommoonligh> my chan cfg code is already a DRY disaster
<dirbaio[m]1> and DMAv2 also has "channels" but they're something entirely different 🤣
<firefrommoonligh> I noticed H7 is completely diff - didn't try to tackle it
<firefrommoonligh> Didn't realize F4 was also that one
<firefrommoonligh> I have no idea what I'm doing here, but hopefully that will change after enough of this?
<dirbaio[m]1> in embassy i'm going to call it "channels" for both 🤷‍♂️
<firefrommoonligh> I'm just going through RM recipes
<firefrommoonligh> Agree, if funtionality is equiv
<firefrommoonligh> I'm goign to try to get compiled/working code, then see if there's a better way to do the API
<dirbaio[m]1> because all drivers (uart, spi, i2c..) will use dma, and the naming change would propagate absolutely everywhere otherwise :(
<dirbaio[m]1> it's soooooo unfortunate
<dirbaio[m]1> WHY, st, why did you have to change naming on something so basic?!
<firefrommoonligh> For now, I have the same structure as every other peripheral, ie owning the DMAx reg block, with a `config_channel` fn that other modules call
<firefrommoonligh> TBH I'm grateful that this name being diff is an exception to the rule
<agg> I don't understand why F4 has v2
<firefrommoonligh> That's a surprise!
<firefrommoonligh> It's leapfrogging much newer variants
<firefrommoonligh> Even G4 and L5 seem compatible roughly with the code I wrote for L4
<firefrommoonligh> (I do wonder if there's a pac bug in L5...)
<agg> the "v2" with streams+channels lets you select which peripheral (input channel) will be able to send a DRQ to that stream (v1 channel)
<agg> on v1 with only channels, all the DRQs are OR'd, afaict, so no selection
<agg> I think that's basically the only fundamental difference?
<agg> the actual implementation is different too of course
<dirbaio[m]1> > DRQs are OR'd
<dirbaio[m]1> so you simply can't use 2 periphs that map to the same channel at all?
<dirbaio[m]1> * > DRQs are OR'd
<dirbaio[m]1> so you simply can't use 2 periphs that map to the same channel at all?
<dirbaio[m]1> or is there some muxing in the periph side instead of the dma side?
<agg> well kinda
<agg> you can't do that on v2 either except often there's multiple mappings
<agg> looking at f1 atm for example, it looks like most peripheral DRQs are only present on one channel
<agg> in which case yes, you could only use a single source for any of those, because each channel can only be figured with one set of memory addresses
<agg> on the f4, many sources (peripherals) appear in different streams (often as the same channel number)
<agg> eg f405 SPI3_RX is channel 0 on both stream 0 and stream 2
<agg> so you could use either stream with it, having configured that stream to use channel 0
<agg> but on f1, spi1_rx only appears on channel 2, so you couldn't use SPI1 RX DMA at the same time as USART3_TX for instance
<agg> but on f4, if you're using stream 0 and stream 2 for I2C1_RX and I2C3_RX, you couldn't use SPI3_RX DMA at all (at least, you'd have to time-share)
<agg> but you could maybe stick I2C1_RX onto stream 5 instead, freeing s0 to use with spi3_rx
<agg> I guess that's why they do this. the f4/f7/h7 are "high performance" parts, and get the fancier DMA with muxes that is more configurable but takes more silicon
<agg> the other families are not "high performance" parts, and get the lower-power/cheaper/smaller v1 DMA peripheral
<dirbaio[m]1> I see :)
<agg> working out what DMA assignments you can use to not have to time share was a classic start-of-project activity for me on f4
<agg> alongside EXTI interrupts since you get one per number
<agg> might end up using SPI6 instead of SPI3 for example, which was often on the same pins, to make the DMA assignments work out
<agg> I believe stcubemx has a tool for this too
<dirbaio[m]1> given DMA is quite restricted especially on DMAv1 chips
<dirbaio[m]1> would it make sense to provide both async-dma and async-cpucopy apis in embassy?
<dirbaio[m]1> we do plan to impl the blocking e-h traits with cpu copy
<agg> guess so, yea
<agg> you can't always use DMA
<agg> it's just much better if you can
<dirbaio[m]1> but async only with DMA for now, but I can see that being a problem :S
<agg> at least doing the async-cpucopy ones should be fairly easy?
<dirbaio[m]1> not sure
<dirbaio[m]1> async cpu-copy would copy data to DR from the irq
<dirbaio[m]1> it's easy, what i'm not so sure is how to support both without duplicating lots of code
<agg> yea :/
<dirbaio[m]1> also that'd mean there's one IRQ for each word, would that be too much spam?
<dirbaio[m]1> if it's a fast SPI for example
<dirbaio[m]1> if the time to enter/exit the irq is more than the time to tx 1 word
<dirbaio[m]1> then it won't really be async anymore haha
<dirbaio[m]1> and probably slower than sync blocking
<agg> depends on the clock rates I guess, usually 1 small irq for each word is ok
<agg> if it's not, you probably need to be using dma anyway
<agg> (or not use the async bit and use the blocking e-h impl)
<agg> not much you can do about it anyway
<peauters[m]> firefrommoonlight are you doing any PWM with DMA? I had a use case for this, but haven't gotten around to looking at it yet
<firefrommoonligh> No
<firefrommoonligh> I am not using DMA on any projects - am learning and building it into HAL so I'll be able to on future projects
<peauters[m]> ahhhh cool
<chmanie[m]> I'm looking for an example on how to use `serial.read()` in a non-blocking way. I found [this code](https://github.com/tonarino/panel-firmware/blob/bc93b95460187b7a608a25f2d9d72a58b284dd34/src/serial.rs#L56) but it doesn't seem to define interrupts and when trying this myself I'm running into `Overrun` errors. It seems the way to go is with using the `nb` library? Sorry if any of this is obvious, but I can't find any
<chmanie[m]> answers on my own.
<firefrommoonligh> *nvm that's blocking
<firefrommoonligh> Set up a `Mutex<RefCell<[u8;n]>>>`, and write it using the interrupts
<firefrommoonligh> * Set up a static `Mutex<RefCell<[u8;n]>>>`, and write it using the interrupts
<firefrommoonligh> I think you're looking for this to enable the interrupt: `self.regs.cr1.modify(|_, w| w.rxneie().set_bit());`
<firefrommoonligh> Ie the Receiver Not Empty interrupt
<firefrommoonligh> Then in the ISR, clear the flag: `self.regs.rqr.write(|w| w.rxfrq().set_bit())`
<firefrommoonligh> * Ie the Read Not Empty interrupt
<firefrommoonligh> Access the buffer mutex (post here if you don't know how to do that), and write to it one bit at a time
<chmanie[m]> Thanks, firefrommoonlight , I'll try!
<firefrommoonligh> * Set up a static `Mutex<RefCell<[0_u8;n]>>>`, and write it using the interrupts
<firefrommoonligh> * Set up a `static Mutex<RefCell<[0_u8;n]>>>`, and write it using the interrupts
<chmanie[m]> So that's relatively straightforward, yet not using any of the libs I mentioned (that's fine but I wanted to know whether these are just outdated or not really supported anymore), sorry it's just a lot to sort out when jumping in
<chmanie[m]> * So that's relatively straightforward, yet not using any of the libs I mentioned (that's fine but I wanted to know whether these are just outdated or not really supported anymore), sorry it's just a lot of information to sort out when jumping in
<firefrommoonligh> * Access the buffer mutex (post here if you don't know how to do that), and write to it one word at a time
<chmanie[m]> Thank you, that's very helpful
<Albru[m]> totally offtopic question: usb spec says the differential data pair should use 28 awg wire, would it be bad if I used 26 or 24 awg instead?
<Albru[m]> * totally offtopic question: usb spec says that differential data pair should use 28 awg wire, would it be bad if I used 26 or 24 awg instead?
<adamgreig-m> No it's fine
<adamgreig-m> Uh, I guess I should qualify that a bit
<adamgreig-m> Certainly fine for FS, you should probably twist it but still fine for HS, you need to take a lot more care at SS
<Albru[m]> yea, it's gonna be for FS and I think it should be twisted (I'm not the one buying it anyway, so I don't really know nor care)
<Albru[m]> it's just that finding plain usb wire (28awg twisted pair with 24awg normal power wires) is tricky
<adamgreig-m> FS isn't even really differential
<Albru[m]> interesting
<Albru[m]> I think making custom cables is kinda silly, but I guess it's fine for FS anyway and mechanical keyboards people love it
unpaid_bill[m] has quit [*.net *.split]
ServerStatsDisco has quit [*.net *.split]
uep[m] has quit [*.net *.split]
Gireesh[m] has quit [*.net *.split]
jacobrosenthal[m has quit [*.net *.split]
braincode[m] has quit [*.net *.split]
ryan-summers[m] has quit [*.net *.split]
JimCrossley[m] has quit [*.net *.split]
firefrommoonligh has quit [*.net *.split]
erdemu[m] has quit [*.net *.split]
sh3rm4n[m] has quit [*.net *.split]
disasm[m] has quit [*.net *.split]
thalesfragoso[m] has quit [*.net *.split]
gdamjan[m]1 has quit [*.net *.split]
f_punk[m] has quit [*.net *.split]
M9names[m] has quit [*.net *.split]
theJPster has quit [*.net *.split]
jamesmunns[m] has quit [*.net *.split]
<chmanie[m]> Especially the braided ones!
ServerStatsDisco has joined ##stm32-rs
unpaid_bill[m] has joined ##stm32-rs
braincode[m] has joined ##stm32-rs
erdemu[m] has joined ##stm32-rs
jamesmunns[m] has joined ##stm32-rs
jacobrosenthal[m has joined ##stm32-rs
gdamjan[m]1 has joined ##stm32-rs
f_punk[m] has joined ##stm32-rs
ryan-summers[m] has joined ##stm32-rs
Gireesh[m] has joined ##stm32-rs
uep[m] has joined ##stm32-rs
disasm[m] has joined ##stm32-rs
theJPster has joined ##stm32-rs
M9names[m] has joined ##stm32-rs
thalesfragoso[m] has joined ##stm32-rs
firefrommoonligh has joined ##stm32-rs
sh3rm4n[m] has joined ##stm32-rs
JimCrossley[m] has joined ##stm32-rs
ServerStatsDisco has quit [Max SendQ exceeded]
WinniSimon[m] has quit [Ping timeout: 246 seconds]
kevlan[m] has quit [Ping timeout: 246 seconds]
jduchniewicz has quit [Ping timeout: 246 seconds]
monacoprinsen[m] has quit [Ping timeout: 245 seconds]
barafael[m] has quit [Ping timeout: 245 seconds]
diondokter[m] has quit [Ping timeout: 245 seconds]
mindtree[m] has quit [Ping timeout: 245 seconds]
peauters[m] has quit [Ping timeout: 245 seconds]
Albru[m] has quit [Ping timeout: 258 seconds]
hargonix[m] has quit [Ping timeout: 250 seconds]
yatekii[m] has quit [Ping timeout: 250 seconds]
Lumpio[m] has quit [Ping timeout: 250 seconds]
dirbaio[m]1 has quit [Ping timeout: 260 seconds]
TeXitoi[m] has quit [Ping timeout: 248 seconds]
andres[m] has quit [Ping timeout: 248 seconds]
thalesfragoso[m] has quit [Ping timeout: 276 seconds]
f_punk[m] has quit [Ping timeout: 276 seconds]
M9names[m] has quit [Ping timeout: 276 seconds]
jamesmunns[m] has quit [Ping timeout: 276 seconds]
thezoq2[m] has quit [Ping timeout: 245 seconds]
delnoch[m] has quit [Ping timeout: 245 seconds]
theunkn0wn1[m] has quit [Ping timeout: 245 seconds]
GrantM11235 has quit [Ping timeout: 245 seconds]
jhillyerd[m] has quit [Ping timeout: 245 seconds]
DerFetzer[m] has quit [Ping timeout: 245 seconds]
korken89[m] has quit [Ping timeout: 245 seconds]
ctron[m] has quit [Ping timeout: 245 seconds]
adamgreig-m has quit [Ping timeout: 248 seconds]
jamwaffles[m] has quit [Ping timeout: 248 seconds]
AnsgarSchmidt[m] has quit [Ping timeout: 248 seconds]
squire0412[m] has quit [Ping timeout: 258 seconds]
xoviat[m]1 has quit [Ping timeout: 258 seconds]
allexoll[m] has quit [Ping timeout: 258 seconds]
therealprof[m] has quit [Ping timeout: 245 seconds]
stratom[m] has quit [Ping timeout: 258 seconds]
HannoBraun[m] has quit [Ping timeout: 258 seconds]
henrik_alser[m] has quit [Ping timeout: 258 seconds]
timokrgr[m] has quit [Ping timeout: 258 seconds]
jkristell[m] has quit [Ping timeout: 247 seconds]
chmanie[m] has quit [Ping timeout: 245 seconds]
Sijmen has quit [Ping timeout: 247 seconds]
riskable[m] has quit [Ping timeout: 245 seconds]
tonke[m] has quit [Ping timeout: 247 seconds]
rjo has quit [Ping timeout: 246 seconds]
BobMcWhirter[m] has quit [Ping timeout: 250 seconds]
unpaid_bill[m] has quit [Ping timeout: 276 seconds]
erdemu[m] has quit [Ping timeout: 276 seconds]
wallacejohn[m] has quit [Ping timeout: 258 seconds]
ejpcmac has quit [Ping timeout: 258 seconds]
uep[m] has quit [Ping timeout: 276 seconds]
Gireesh[m] has quit [Ping timeout: 276 seconds]
jacobrosenthal[m has quit [Ping timeout: 276 seconds]
ryan-summers[m] has quit [Ping timeout: 276 seconds]
braincode[m] has quit [Ping timeout: 276 seconds]
firefrommoonligh has quit [Ping timeout: 276 seconds]
gdamjan[m]1 has quit [Ping timeout: 276 seconds]
JimCrossley[m] has quit [Ping timeout: 276 seconds]
theJPster has quit [Ping timeout: 276 seconds]
sh3rm4n[m] has quit [Ping timeout: 276 seconds]
TimSmall has quit [Ping timeout: 248 seconds]
disasm[m] has quit [Ping timeout: 276 seconds]
dreamcat4_ has quit [Ping timeout: 248 seconds]
yusefkarim[m] has quit [Ping timeout: 248 seconds]
M9names[m] has joined ##stm32-rs
unpaid_bill[m] has joined ##stm32-rs
thalesfragoso[m] has joined ##stm32-rs
f_punk[m] has joined ##stm32-rs
jamesmunns[m] has joined ##stm32-rs
delnoch[m] has joined ##stm32-rs
stratom[m] has joined ##stm32-rs
ctron[m] has joined ##stm32-rs
dirbaio[m]1 has joined ##stm32-rs
mindtree[m] has joined ##stm32-rs
yatekii[m] has joined ##stm32-rs
jduchniewicz has joined ##stm32-rs
Lumpio[m] has joined ##stm32-rs
ctron[m] has quit [Ping timeout: 245 seconds]
jamesmunns[m] has quit [Ping timeout: 246 seconds]
delnoch[m] has quit [Ping timeout: 245 seconds]
yatekii[m] has quit [Ping timeout: 245 seconds]
unpaid_bill[m] has quit [Ping timeout: 245 seconds]
thalesfragoso[m] has quit [Ping timeout: 245 seconds]
Lumpio[m] has quit [Ping timeout: 258 seconds]
mindtree[m] has quit [Ping timeout: 258 seconds]
dirbaio[m]1 has quit [Ping timeout: 258 seconds]
M9names[m] has quit [Ping timeout: 258 seconds]
jduchniewicz has quit [Ping timeout: 276 seconds]
stratom[m] has quit [Ping timeout: 276 seconds]
f_punk[m] has quit [Ping timeout: 276 seconds]
adamgreig-m has joined ##stm32-rs
andres[m] has joined ##stm32-rs
jamwaffles[m] has joined ##stm32-rs
TeXitoi[m] has joined ##stm32-rs
allexoll[m] has joined ##stm32-rs
chmanie[m] has joined ##stm32-rs
squire0412[m] has joined ##stm32-rs
henrik_alser[m] has joined ##stm32-rs
HannoBraun[m] has joined ##stm32-rs
timokrgr[m] has joined ##stm32-rs
thezoq2[m] has joined ##stm32-rs
jkristell[m] has joined ##stm32-rs
jhillyerd[m] has joined ##stm32-rs
korken89[m] has joined ##stm32-rs
DerFetzer[m] has joined ##stm32-rs
barafael[m] has joined ##stm32-rs
WinniSimon[m] has joined ##stm32-rs
theunkn0wn1[m] has joined ##stm32-rs
GrantM11235 has joined ##stm32-rs
peauters[m] has joined ##stm32-rs
kevlan[m] has joined ##stm32-rs
diondokter[m] has joined ##stm32-rs
hargonix[m] has joined ##stm32-rs
riskable[m] has joined ##stm32-rs
xoviat[m]1 has joined ##stm32-rs
Albru[m] has joined ##stm32-rs
Sijmen has joined ##stm32-rs
AnsgarSchmidt[m] has joined ##stm32-rs
therealprof[m] has joined ##stm32-rs
firefrommoonligh has joined ##stm32-rs
uep[m] has joined ##stm32-rs
erdemu[m] has joined ##stm32-rs
gdamjan[m]1 has joined ##stm32-rs
Gireesh[m] has joined ##stm32-rs
sh3rm4n[m] has joined ##stm32-rs
braincode[m] has joined ##stm32-rs
ryan-summers[m] has joined ##stm32-rs
jacobrosenthal[m has joined ##stm32-rs
JimCrossley[m] has joined ##stm32-rs
theJPster has joined ##stm32-rs
monacoprinsen[m] has joined ##stm32-rs
BobMcWhirter[m] has joined ##stm32-rs
ejpcmac has joined ##stm32-rs
rjo has joined ##stm32-rs
tonke[m] has joined ##stm32-rs
wallacejohn[m] has joined ##stm32-rs
TimSmall has joined ##stm32-rs
dreamcat4_ has joined ##stm32-rs
disasm[m] has joined ##stm32-rs
yusefkarim[m] has joined ##stm32-rs
ServerStatsDisco has joined ##stm32-rs
ctron[m] has joined ##stm32-rs
jamesmunns[m] has joined ##stm32-rs
mindtree[m] has joined ##stm32-rs
Lumpio[m] has joined ##stm32-rs
dirbaio[m]1 has joined ##stm32-rs
M9names[m] has joined ##stm32-rs
delnoch[m] has joined ##stm32-rs
yatekii[m] has joined ##stm32-rs
<firefrommoonligh> In addition to thalesfragoso 's comment, `regs` is the `pac::USARTx` register block. We pass this reg block's PAC representation to the `Usart` peripheral struct on construction. It owns the struct, so we don't need a raw pointer
<firefrommoonligh> In contrast, other HALs do use `unsafe`- wrapped raw pointers here, so they can use an abstraction where you split up `Tx` and `Rx` structs.
unpaid_bill[m] has joined ##stm32-rs
thalesfragoso[m] has joined ##stm32-rs
<chmanie[m]> Ah, yes, I just saw that!
<chmanie[m]> OK, so it's an API design decision
<firefrommoonligh> I'm following a self-made convention of having the peripheral struct own the regs like this as a rule partly for consistency among peripheral modules, and partly because I'm not good enough with memory management to know when I can get away with raw pointers
<firefrommoonligh> Yep!
<firefrommoonligh> Ie I always call the reg field `regs` for consistency
<chmanie[m]> Yeah that makes sense
<firefrommoonligh> * In addition to thalesfragoso 's comment, `regs` is the `pac::USARTx` register block. We pass this reg block's PAC representation to the `Usart` peripheral struct on construction. The struct owns it, so we don't need a raw pointer
stratom[m] has joined ##stm32-rs
jduchniewicz has joined ##stm32-rs
<chmanie[m]> I honestly prefer the way of not splitting, that gives you easier access to the regs for custom trait implementations on top of the HAL
<chmanie[m]> But who am I to judge
f_punk[m] has joined ##stm32-rs
<firefrommoonligh> If you check the [Contributing section in the readme](https://github.com/David-OConnor/stm32-hal), I describe this convention, and provide an example barebones module
<firefrommoonligh> This is entirely subjective, but I think at least establishing this pattern will make maintenance and code review easier
<dirbaio[m]1> what about structs that own "part" of a peri?
<dirbaio[m]1> llike a GPIO pin, DMA channel...
<firefrommoonligh> GPIO is the glaring exception where I break the rule
<firefrommoonligh> DMA, you actually don't need to break it!
<firefrommoonligh> Check out the module I have for an example... granted, it's the worst piece of DRY I've ever written or seen
<chmanie[m]> <firefrommoonligh "If you check the [Contributing s"> Thanks for the link, this looks interesting