<thalesfragoso[m]>
dirbaio the peripherals in the stm32-data aren't the ones we will use, right ? I mean in the chips yaml
oaky_ has joined ##stm32-rs
oaky_ has quit [Remote host closed the connection]
oaky has joined ##stm32-rs
oaky_ has joined ##stm32-rs
oaky has quit [Ping timeout: 260 seconds]
oaky_ has quit [Quit: Leaving]
<dirbaio[m]>
Not dure what you mean, they're all the periperals, but nly the ones that match to a regs yaml have the "block" key
<firefrommoonligh>
Does anyone here have experience with H7? Trying to figure out if I'm setting up the clocks right. AFAIK to get the basics working it's the same as other STM32s, but there are a few extra prescalers (Like the D1C, and 2 more APB scalers / speeds), a divider on HSI, and a CSI input source
<firefrommoonligh>
And some extras you can presumably skip for the broadest use cases
<dirbaio[m]>
this reads only the reg yamls for now
<dirbaio[m]>
if you read the chip yamls from that and convert them to Device instances and put them in the IR, the codegen should just work
<dirbaio[m]>
ah except not because it's commented due to a refactor hehe
<dirbaio[m]>
dunno, if you want to have a look go ahead
<dirbaio[m]>
I still have a few days more of work left in that python script :P
<thalesfragoso[m]>
Hmm, I have almost no experience with svd2rust, might be something to start, but maybe I will just try to generate more peripherals, let's see
<dirbaio[m]>
also i'm going to group all the chips by "RPN
<dirbaio[m]>
* also i'm going to group all the chips by "RPN"
<dirbaio[m]>
so the cargo features would be `STM32F411RE` and not `STM32F411RETx`
<dirbaio[m]>
yaml format won't change
<thalesfragoso[m]>
Got it, take your time, I'm quite short on time these days, so I'm not in a hurry
<thalesfragoso[m]>
But I will try to look at a few things
<firefrommoonligh>
Is this re the meta-pac? How far along is it?
<dirbaio[m]>
still setting up scaffolding :P
<thalesfragoso[m]>
Yes, it's going, but there's even a PoC with a HAL driver
<dirbaio[m]>
embassy has gpio+exti hehe :P
<dirbaio[m]>
but no PoC of actually working on multiple chips
<dirbaio[m]>
on the cargo features, wanted to do just `stm32f411` like now
<dirbaio[m]>
but it seems some chips do have differences
<dirbaio[m]>
and there's no usartv3, so for exmaple the H7s are there but are unusable
<dirbaio[m]>
and as we add more regblocks, more peripherals and chips will gradually become usable
<firefrommoonligh>
I think you'll find a number of H7-specific exceptions to rules that otherwise work
<firefrommoonligh>
Well, at least for RCC and PWR
<firefrommoonligh>
The general structure of those is similar to the others, but there are a number of additional features and complications
<firefrommoonligh>
and for RCC, even the equivalent features are in diff registers, for both core clock config, and periph clock en/rst
<firefrommoonligh>
the PWR settings are mjuch more complex
<dirbaio[m]>
yeah these will probably be per-family...
<dirbaio[m]>
for uart we can do usartv1, usartv2, usartv3
<dirbaio[m]>
like
<dirbaio[m]>
for rcc it'll have to be rcc-f1, rcc-f3, rcc-f4, rcc-f7, rcc-h7, rcc-l0.. blah blah
<firefrommoonligh>
I think for both, you may consider 3 basic variants: F3/4, L/G, and H7
<dirbaio[m]>
or even rcc-f411
<firefrommoonligh>
You could possibly maybe merge it into H7 and non-H7
<dirbaio[m]>
let's hope not 🤣
<firefrommoonligh>
f411's the stripped down one right? I ended up jus feature-gating out things it didn't have
<dirbaio[m]>
but even if not everything is super-ultra-merged it's still OK
<firefrommoonligh>
I didn't plan to support f4 since it's pretty old and twice-superceded, but it's popular in the Rust community
<dirbaio[m]>
because we can still edit stuff to make it consistent
<dirbaio[m]>
so in HALs even if it's a different type eg for f7 and h7, we can make register names as similar as possible
<firefrommoonligh>
I think you'll have good luck on that with peripheral clocks
<firefrommoonligh>
For those, it's often the same functionality, in different (or differently-named) reg blocks
<firefrommoonligh>
Although H7 has more of those blocks
<dirbaio[m]>
yeah, dunno
<dirbaio[m]>
another way would be to just turn them all into u32 arrays
<firefrommoonligh>
I was able to merge most of the RCC periph en/rst stuff into a single macro since last we talkd about it, but I don't know if that's applicable to PAC-level
<dirbaio[m]>
and then have another yaml with
<dirbaio[m]>
GPIOA:
<dirbaio[m]>
rcc_enable_bit: 55
<dirbaio[m]>
rcc_reset_bit: 43
<firefrommoonligh>
That sounds like a good plan, ie another mapping
<dirbaio[m]>
that's an actual "x" in product name, not placeholder 🤣
<therealprof[m]>
<firefrommoonligh "I didn't plan to support f4 sinc"> I've no idea what gave you this idea. It's neither superceded nor is it only popular in the Rust community. It's one of the most sold STM32 series in the world, pretty much only outnumbered by the F1.
<dirbaio[m]>
lol stm32g0bxx and stm32g0cxx are missing from stmcufinder :D
<firefrommoonligh>
I can't see any reason to use f4 on a new project over h7
<firefrommoonligh>
* I can't see any reason to use f4 on a new project over one of the G or Hs
<therealprof[m]>
I can see a ton of reasons not to use the G or the H models and use anything else including F4 instead. 🤷🏻♂️
<therealprof[m]>
G4 is a lower cost/renewed version of the F3.
<firefrommoonligh>
For many projects, anything in the lineup will work, but given a choice, I'll go with the updated and improved ones
<barafael[m]>
G4 is nice, but do take a look at the errata :) for me, regarding flash and ADC/DMA there is some important info there
<therealprof[m]>
For most projects F4 is already overkill so going H7 doesn't make any sense.
<firefrommoonligh>
I think this discussion is too general; doesn't have much meaning outside specific projects
<dirbaio[m]>
GD32F1 it is
<therealprof[m]>
<firefrommoonligh "I think this discussion is too g"> Well, you started it...
<firefrommoonligh>
Originally mentioned in ref to new HAL support
<therealprof[m]>
F4 is a nice middle of the road MCU. It does pack a decent punch, it is well known and supported, comes in reasonable packages even hobbyists can handle and is it available everywhere. All of which is contributing to it's huge success.
<therealprof[m]>
* F4 is a nice middle of the road MCU. It does pack a decent punch, it is well known and supported, comes in reasonable packages even hobbyists can handle and is it available everywhere. All of which is contributing to its huge success.
<therealprof[m]>
TBH if I don't know where a project will be going, starting the design with a F4 pretty much the only sane choice.
<firefrommoonligh>
Yikes
<firefrommoonligh>
Sounds like I stepped on a nerve
<therealprof[m]>
I won't comment on that... 😏
<dirbaio[m]>
what's the 'extra' letter some chips have?
<dirbaio[m]>
for example STM32L552RET6 -> STM32L552RET6P
<therealprof[m]>
The last one is the "grade"
<dirbaio[m]>
* for example STM32L552RET6 -> STM32L552RET6P or STM32L552RET6Q
<dirbaio[m]>
yea that'd be the `6`, but there's sometimes an extra letter
<dirbaio[m]>
and as far as I can tell, it's the "fuck you" letter
<dirbaio[m]>
most of these are just packaging changes, shuffling pins around, removing some IOs to add more power...
<therealprof[m]>
Usually the last letter is the binning grade. i.e. commercial, military, no idea what else....
<dirbaio[m]>
but some are removing entire peripherals
<dirbaio[m]>
or even changing die which changes the AF mapping and stuff :O
<therealprof[m]>
Hm, beats me then. 😀
<dirbaio[m]>
I was hoping to just group chips by `name[..11]` but nope 🤣
<dirbaio[m]>
STM32L552RET6 -> STM32L552RET6P removes the SDMMC peripheral
<dirbaio[m]>
that definitely has to be reflected in the PAC :(
<dirbaio[m]>
the more I dig into this, the more I regret it :rofl
<dirbaio[m]>
* the more I dig into this, the more I regret it 🤣
<therealprof[m]>
Could still be binning.
<dirbaio[m]>
maybe! if the sdmmc peripheral failed tests.. these are same die
<dirbaio[m]>
others aren't
<dirbaio[m]>
anyway the PAC for the xP should not have SDMMC... or should I just say "fuck it" and ignore it?
<therealprof[m]>
Exactly, though it seems weird why SDMMC would be a binning criteria.
<therealprof[m]>
More likely some big company said: We don't need that, can we get a special edition without that?
<dirbaio[m]>
STM32L552RET6 -> STM32L552RET6Q removes some IOs and adds VDDSMPS VLXSMPS VSSSMPS pins
<dirbaio[m]>
* STM32L552RET6 -> STM32L552RET6Q removes some IOs and adds VDDSMPS VLXSMPS VSSSMPS, V15SMPS pins
<therealprof[m]>
<dirbaio[m] "anyway the PAC for the xP should"> Well, as a matter of fact, if it's the same the peripheral will be available in hardware. It's pretty unlikely they're going to laser fuse it. That'd cost a shitload of money.
<therealprof[m]>
Additional power supply pins will only affect the signal stability but not the software or functionality.
<dirbaio[m]>
ooh in the xP variant they removed the only pin with SDMMC1_CMD function, to make room for VDD12 pins
<therealprof[m]>
There you go.
<dirbaio[m]>
and then since SDMMC1 was unusable they decided to remove it
<therealprof[m]>
More like declare unusable...
<dirbaio[m]>
aha so in L5, P means extra VDD12 pins, Q means SMPS pins
<therealprof[m]>
Quite possible.
<therealprof[m]>
Nothing you should be concerned about.
<dirbaio[m]>
worst I've found is STM32L151CBTx -> STM32L151CBTxA
<therealprof[m]>
I think it is possible that ST might fuse memory or flash to create lower MSRP parts but fusing peripherals would be way too expensive. I think you can could on equal die == equal functionality.
<therealprof[m]>
* I think it is possible that ST might fuse memory or flash to create lower MSRP parts but fusing peripherals would be way too expensive. I think you can count on equal die == equal functionality.
<dirbaio[m]>
and other stml151/l152
<dirbaio[m]>
that's different die, different AF mappings, different IP versions
<dirbaio[m]>
different C headers even
<dirbaio[m]>
...WHY?
<dirbaio[m]>
there's a few pairs like that in L151/L152.. for each pair, one is NRND and the other is Active
<dirbaio[m]>
but in some it's the -A version that gets NRND and in some it's the non-A
<dirbaio[m]>
wtf
<therealprof[m]>
That's the thing I also don't get... but then again naming is said to be the hardest part in computer science. 😉
<thalesfragoso[m]>
F4 seems to be a middle ground between the G series and the H, and middle ground is always good
<thalesfragoso[m]>
H7 comes with cortex-M7 which brings some more concerns/complexity
<firefrommoonligh>
The clock tree alone on H7 is substantially more complex than anything else
<firefrommoonligh>
Does LSE have any power-saving advantages over LSI when the RTC is used to periodically wake up from low-power modes? Or does it just provide better accuracy for the RTC?