<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>
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?
<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
<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
<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
<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