Mr_Electronico has quit [Remote host closed the connection]
Mr_Electronico has joined ##stm32-rs
Mr_Electronico has quit [Remote host closed the connection]
Mr_Electronico has joined ##stm32-rs
adjtm_ has left ##stm32-rs ["Leaving"]
<peauters[m]>
on the subject on ssd1306, the problems I was having with getting my display to work when plugging in the usb have been fixed by not trying to write to the display until a little while after init
<peauters[m]>
not got my scope yet to check, but I believe it is something to do with the 3v3 line being a little late/less stable when the usb is just plugging in, which is causing an issue on the ssd1306 chip
<peauters[m]>
so a small delay before init seems to have "fixed" it
<peauters[m]>
thanks for all the help all =oD
<dirbaio[m]>
so, regarding "channel" vs "stream": thoughts on always calling it "channel"?
<dirbaio[m]>
not in the pac, in the hal
<dirbaio[m]>
(pac always sticks with names from the RM)
<dirbaio[m]>
it's "channel" in all chips except "stream" in DMA v2 which is only in f4, f7, h7
<dirbaio[m]>
a hal that changes names based on cargo features would suck 🤣
<dirbaio[m]>
so
<dirbaio[m]>
is it correct that in f1 pins are remapped "together" and in all the other families they're remapped "individually"?
<adamgreig-m>
uh
<adamgreig-m>
sooooort offffff
<adamgreig-m>
in f1 pins are remapped
<adamgreig-m>
in everything else pins can be put into AF mode and then an AF option chosen, there's no "default" map
<dirbaio[m]>
I mean, in f1 USART1 can do (tx=PA4, rx=PA5) or (tx=PB9, rx=PB10), but not mix, like (tx=PA4, rx=PB10)?
<dirbaio[m]>
while in others there's a "list" of valid rx pins and valid tx pins and you can choose any combination?
<adamgreig-m>
well other packages also have a thing called remapping
<adamgreig-m>
e.g. many F0s can remap PA9/10 to become PA11/12
<dirbaio[m]>
oh shit =D
<adamgreig-m>
the F1 remap is a bit messier, you can usually "partially" or "fully" remap
<adamgreig-m>
but yes, in a simplistic sense the whole peripheral has a default set of output pins and you can instead remap to the alternate set of output pins
<adamgreig-m>
sometimes, you can remap just some of them
<dirbaio[m]>
I found XMLs in CubeMX listing all the AFs
<dirbaio[m]>
and yep they look very different for F1
<dirbaio[m]>
lol why didn't we find that the other day? 🤣
<adamgreig-m>
huh, go figure
<dirbaio[m]>
these xmls are hooooooorrible :D
<dirbaio[m]>
let's turn that into yaml and then into rust
<dirbaio[m]>
the generated code would be stuff like
<dirbaio[m]>
impl Instance for USART3
<dirbaio[m]>
impl TxPin<USART3> for PA8
<dirbaio[m]>
where would that go? not in the metaPAC because it doesn't have the singletons
<dirbaio[m]>
but that'd mean code generation in the HAL
<dirbaio[m]>
or maybe it should go in the new mythical "peripherals" crate?
<thalesfragoso[m]>
<dirbaio[m] "so, regarding "channel" vs "stre"> If we can make both public interfaces for DMA equal, then maybe that's okay, otherwise I don't see a problem in having different naming, since the interface itself would be different
<dirbaio[m]>
dunno, they'll be "similar" but probably not equal
<thalesfragoso[m]>
Isn't SPI the same perilheral as I2S ?
<therealprof[m]>
Not quite but similar.
<thalesfragoso[m]>
Hmm, I thought they were the same, like SPI in I2S mode
<thalesfragoso[m]>
As in, not using both at the same time
<therealprof[m]>
It really would need to be the same peripheral for that to work.
<thalesfragoso[m]>
Or maybe that was a nordic thing
<therealprof[m]>
Would need to check the documentation to tell for sure. 😉
<therealprof[m]>
Okay, it's actually the same.
<thalesfragoso[m]>
> The SPI interface provides two main functions, supporting either the SPI protocol or the I2S
<thalesfragoso[m]>
audio protocol. By default, it is the SPI function that is selected. It is possible to switch the
<thalesfragoso[m]>
interface from SPI to I2S by software.
<thalesfragoso[m]>
From the F401 manual
<dirbaio[m]>
ah right
<dirbaio[m]>
great, so the data needs more cleanup
<dirbaio[m]>
I guess they gave 2 names to the same AF for developer "convenience"
<therealprof[m]>
Up to 6 SPIs (45 Mbits/s), 2 with muxed full-duplex I2S for audio class accuracy via internal audio PLL or external clock
<dirbaio[m]>
also this
<dirbaio[m]>
PA0:
<dirbaio[m]>
TIM2_CH1: 1
<dirbaio[m]>
TIM2_ETR: 1
<therealprof[m]>
That combination is somewhat typical.
tedfernau has joined ##stm32-rs
<dirbaio[m]>
f303 and f303e have different af mappings lol
<therealprof[m]>
Not too familiar with that line but ST likes to have oddballs in their families...
<dirbaio[m]>
but there's no svd for that..?
<therealprof[m]>
🤷🏻♂️
<dirbaio[m]>
for example
<dirbaio[m]>
stm32f303vctx uses the "f303" mappings
<dirbaio[m]>
stm32f303vetx uses the "f303e" mappings
<dirbaio[m]>
the "e" variant seems to add FMC and i2s/spi/etc stuff.. and *remove* some stuff?
<dirbaio[m]>
parts of this dataset look a bit fishy :(
<therealprof[m]>
So it's the 413 of the F3 line? 😀
<dirbaio[m]>
it does match the datasheet...
<dirbaio[m]>
datasheets are probably generated from that data
<therealprof[m]>
I have no reason to doubt it's correct. They probably had to change a few things to include more flash and RAM and they probably decided to say: Why not throw some other stuff around?
<dirbaio[m]>
🤷♂️ I guess i'll trust it
<therealprof[m]>
Pretty much every family has such oddballs.
<dirbaio[m]>
it's just so strange
<therealprof[m]>
(except for the latest G/U ones for now)
<therealprof[m]>
Yeah, not for them. "It's just software" is a huge thing in the MCU world.
<dirbaio[m]>
f303xE has COMP2_OUT on PA2/PA12/PB9
<dirbaio[m]>
f303xC has COMP2_OUT on PA2/PA7/PA12/PB9
<therealprof[m]>
As long as the hardware is compatible...
<dirbaio[m]>
they just removed PA7
<dirbaio[m]>
* they just removed PA7, for no apparent reason
<dirbaio[m]>
the AF number is not reused for anything else
<dirbaio[m]>
and that's the ONLY thing removed in C->E
<therealprof[m]>
Either an oversight or they had to shuffle stuff around to make room for the additional flash/RAM.
<dirbaio[m]>
so weird 🤷♂️
<therealprof[m]>
I guess once you go down the "let's have hundreds of different chips and also listen to customer wishes" route, that's what you get.
<dirbaio[m]>
and they're still the same SVD
<dirbaio[m]>
I think we're missing SVDs
<dirbaio[m]>
there's only one f303 svd
<therealprof[m]>
"Hey guys, we need this chip, it's like a F303 but just slightly different... oh and here's the order for 1M chips"... [employee fires up the HDL designer]
<dirbaio[m]>
🤣
<dirbaio[m]>
(employee2 copypastes the XMLs and edits a few random things)