<yusefkarim[m]>
I seem to be doing something wrong, getting this error: `svdtools.patch.UnknownTagError: ('field', 'Enabled')`
<yusefkarim[m]>
Would love if someone familiar with svd2rust, etc could guide me haha, I'll keep trying until then
<yusefkarim[m]>
* Would love if someone familiar with svd2rust, etc could guide me haha, I'll keep trying for now
<wallacejohn[m]>
yusefkarim: It may seem a little strange, but you currently cannot put the field enumerations in the same block in which the fields are added. The field enumerations are typically separated out into a separate file in the top-level `peripherals/` directory, and then included in the device file with the `_include` tag. The fields themselves (with description, bit width/offset, etc.) are usually described in
<wallacejohn[m]>
`devices/common_patches/` or in the device file itself as you are doing now. Take a look at the bottom of the original `stm32f401.yaml` file for some example includes to follow for both `common_patches/` and `peripherals/`. If you're still stuck, just let us know.
<yusefkarim[m]>
Aha, I see now! Thank you very much. Should be able to figure it out now. I can maybe make a file in `common_patches` then
<yusefkarim[m]>
wallacejohn: Thanks for your detailed response and time. I made a pull request, hopefully didn't do anything too silly. Cheers!
<yusefkarim[m]>
* wallacejohn: Thanks for your detailed response and time. I made a pull request, hopefully didn't do anything to silly. Cheers!
andres[m] has quit [*.net *.split]
kevlan[m] has quit [*.net *.split]
javier_varez[m] has quit [*.net *.split]
theJPster has quit [*.net *.split]
dirbaio[m] has quit [*.net *.split]
dreamcat4_ has quit [*.net *.split]
sbe2021[m] has quit [*.net *.split]
gdamjan[m]1 has quit [*.net *.split]
jamwaffles[m] has quit [*.net *.split]
strawman[m] has quit [*.net *.split]
Albru[m] has quit [*.net *.split]
wallacejohn[m] has quit [*.net *.split]
JimCrossley[m] has quit [*.net *.split]
ryan-summers[m] has quit [*.net *.split]
HannoBraun[m] has quit [*.net *.split]
diondokter[m] has quit [*.net *.split]
mtthwmeyer[m] has quit [*.net *.split]
jkristell[m] has quit [*.net *.split]
allexoll[m] has quit [*.net *.split]
yusefkarim[m] has quit [*.net *.split]
TeXitoi[m] has quit [*.net *.split]
agg has quit [*.net *.split]
strawman[m] has joined ##stm32-rs
kevlan[m] has joined ##stm32-rs
yusefkarim[m] has joined ##stm32-rs
wallacejohn[m] has joined ##stm32-rs
mtthwmeyer[m] has joined ##stm32-rs
sbe2021[m] has joined ##stm32-rs
andres[m] has joined ##stm32-rs
TeXitoi[m] has joined ##stm32-rs
theJPster has joined ##stm32-rs
ryan-summers[m] has joined ##stm32-rs
jamwaffles[m] has joined ##stm32-rs
JimCrossley[m] has joined ##stm32-rs
HannoBraun[m] has joined ##stm32-rs
javier_varez[m] has joined ##stm32-rs
dirbaio[m] has joined ##stm32-rs
allexoll[m] has joined ##stm32-rs
Albru[m] has joined ##stm32-rs
jkristell[m] has joined ##stm32-rs
gdamjan[m]1 has joined ##stm32-rs
diondokter[m] has joined ##stm32-rs
dreamcat4_ has joined ##stm32-rs
agg has joined ##stm32-rs
strawman[m] has quit [Ping timeout: 243 seconds]
Sijmen has quit [Ping timeout: 246 seconds]
bob_twinkles[m] has quit [Ping timeout: 246 seconds]
DerFetzer[m] has quit [Ping timeout: 246 seconds]
thezoq2[m] has quit [Ping timeout: 246 seconds]
barafael[m] has quit [Ping timeout: 246 seconds]
adamgreig-m has quit [Ping timeout: 246 seconds]
xoviat[m] has quit [Ping timeout: 245 seconds]
andres[m] has quit [Ping timeout: 258 seconds]
therealprof[m] has quit [Ping timeout: 245 seconds]
gdamjan[m]1 has quit [Ping timeout: 258 seconds]
javier_varez[m] has quit [Ping timeout: 258 seconds]
jamwaffles[m] has quit [Ping timeout: 258 seconds]
Mathias[m] has quit [Ping timeout: 245 seconds]
uep[m] has quit [Ping timeout: 245 seconds]
wallacejohn[m] has quit [Ping timeout: 244 seconds]
diondokter[m] has quit [Ping timeout: 244 seconds]
HannoBraun[m] has quit [Ping timeout: 244 seconds]
jkristell[m] has quit [Ping timeout: 244 seconds]
mtthwmeyer[m] has quit [Ping timeout: 244 seconds]
TeXitoi[m] has quit [Ping timeout: 244 seconds]
allexoll[m] has quit [Ping timeout: 244 seconds]
JimCrossley[m] has quit [Ping timeout: 244 seconds]
ryan-summers[m] has quit [Ping timeout: 244 seconds]
Albru[m] has quit [Ping timeout: 244 seconds]
delnoch[m] has quit [Ping timeout: 252 seconds]
f_punk[m] has quit [Ping timeout: 252 seconds]
squire0412[m] has quit [Ping timeout: 248 seconds]
theunkn0wn1[m] has quit [Ping timeout: 248 seconds]
korken89[m] has quit [Ping timeout: 248 seconds]
wassasin[m] has quit [Ping timeout: 248 seconds]
jhillyerd[m] has quit [Ping timeout: 248 seconds]
kevlan[m] has quit [Ping timeout: 256 seconds]
sbe2021[m] has quit [Ping timeout: 256 seconds]
theJPster has quit [Ping timeout: 256 seconds]
mindtree[m] has quit [Ping timeout: 245 seconds]
yusefkarim[m] has quit [Ping timeout: 245 seconds]
firefrommoonligh has quit [Ping timeout: 252 seconds]
AnsgarSchmidt[m] has quit [Ping timeout: 244 seconds]
dirbaio[m] has quit [Ping timeout: 258 seconds]
dreamcat4_ has quit [Ping timeout: 258 seconds]
cyrusmetcalf[m] has quit [Ping timeout: 276 seconds]
wuglu[m] has quit [Ping timeout: 276 seconds]
Gireesh[m] has quit [Ping timeout: 276 seconds]
timokrgr[m] has quit [Ping timeout: 276 seconds]
mkoeppchen[m] has quit [Ping timeout: 276 seconds]
disasm[m] has quit [Ping timeout: 276 seconds]
jduchniewicz1 has quit [Ping timeout: 252 seconds]
TimSmall has quit [Ping timeout: 246 seconds]
M9names[m] has quit [Ping timeout: 246 seconds]
ctron[m] has quit [Ping timeout: 246 seconds]
ejpcmac has quit [Ping timeout: 248 seconds]
jamesmunns[m] has quit [Ping timeout: 248 seconds]
BobMcWhirter[m] has quit [Ping timeout: 276 seconds]
hargonix[m] has quit [Ping timeout: 252 seconds]
GrantM11235 has quit [Ping timeout: 252 seconds]
riskable[m] has quit [Ping timeout: 252 seconds]
henrik_alser[m] has quit [Ping timeout: 252 seconds]
peauters[m] has quit [Ping timeout: 252 seconds]
rjo has quit [Ping timeout: 252 seconds]
jacobrosenthal[m has quit [Ping timeout: 245 seconds]
morgan[m]1 has quit [Ping timeout: 245 seconds]
yatekii[m] has quit [Ping timeout: 245 seconds]
tonke[m] has quit [Ping timeout: 245 seconds]
braincode[m] has quit [Ping timeout: 245 seconds]
t4d1[m] has quit [Ping timeout: 245 seconds]
MathiasKoch[m] has quit [Ping timeout: 245 seconds]
thalesfragoso[m] has quit [Ping timeout: 276 seconds]
M9names[m] has joined ##stm32-rs
adamgreig-m has joined ##stm32-rs
dreamcat4_ has joined ##stm32-rs
dirbaio[m] has joined ##stm32-rs
TimSmall has joined ##stm32-rs
jduchniewicz has joined ##stm32-rs
jhillyerd[m] has joined ##stm32-rs
delnoch[m] has joined ##stm32-rs
GrantM11235 has joined ##stm32-rs
morgan[m]1 has joined ##stm32-rs
therealprof[m] has joined ##stm32-rs
henrik_alser[m] has joined ##stm32-rs
peauters[m] has joined ##stm32-rs
timokrgr[m] has joined ##stm32-rs
Albru[m] has joined ##stm32-rs
rjo has joined ##stm32-rs
DerFetzer[m] has joined ##stm32-rs
xoviat[m] has joined ##stm32-rs
t4d1[m] has joined ##stm32-rs
andres[m] has joined ##stm32-rs
theunkn0wn1[m] has joined ##stm32-rs
firefrommoonligh has joined ##stm32-rs
mindtree[m] has joined ##stm32-rs
yatekii[m] has joined ##stm32-rs
korken89[m] has joined ##stm32-rs
uep[m] has joined ##stm32-rs
gdamjan[m]1 has joined ##stm32-rs
wassasin[m] has joined ##stm32-rs
f_punk[m] has joined ##stm32-rs
squire0412[m] has joined ##stm32-rs
jamesmunns[m] has joined ##stm32-rs
HannoBraun[m] has joined ##stm32-rs
ryan-summers[m] has joined ##stm32-rs
wallacejohn[m] has joined ##stm32-rs
jamwaffles[m] has joined ##stm32-rs
ejpcmac has joined ##stm32-rs
javier_varez[m] has joined ##stm32-rs
yusefkarim[m] has joined ##stm32-rs
MathiasKoch[m] has joined ##stm32-rs
hargonix[m] has joined ##stm32-rs
ctron[m] has joined ##stm32-rs
disasm[m] has joined ##stm32-rs
JimCrossley[m] has joined ##stm32-rs
tonke[m] has joined ##stm32-rs
AnsgarSchmidt[m] has joined ##stm32-rs
mtthwmeyer[m] has joined ##stm32-rs
thezoq2[m] has joined ##stm32-rs
allexoll[m] has joined ##stm32-rs
riskable[m] has joined ##stm32-rs
mkoeppchen[m] has joined ##stm32-rs
Gireesh[m] has joined ##stm32-rs
TeXitoi[m] has joined ##stm32-rs
wuglu[m] has joined ##stm32-rs
jkristell[m] has joined ##stm32-rs
kevlan[m] has joined ##stm32-rs
theJPster has joined ##stm32-rs
braincode[m] has joined ##stm32-rs
BobMcWhirter[m] has joined ##stm32-rs
diondokter[m] has joined ##stm32-rs
sbe2021[m] has joined ##stm32-rs
thalesfragoso[m] has joined ##stm32-rs
jacobrosenthal[m has joined ##stm32-rs
barafael[m] has joined ##stm32-rs
cyrusmetcalf[m] has joined ##stm32-rs
strawman[m] has joined ##stm32-rs
Mathias[m]1 has joined ##stm32-rs
bob_twinkles[m] has joined ##stm32-rs
Sijmen has joined ##stm32-rs
sbe2021[m] has quit [Quit: Idle for 30+ days]
andres[m] has quit [Quit: Idle for 30+ days]
Albru[m] has quit [Quit: Idle for 30+ days]
dkm[m] has joined ##stm32-rs
_whitelogger has joined ##stm32-rs
yruama_lairba[m] has joined ##stm32-rs
<yruama_lairba[m]>
hello, i have quesiton about the stm32f446RE (64pins) : is possible to use FMC with external ram ?
<yruama_lairba[m]>
my question may look stupid, but i really don't understand how the FMC can interface with external device on this version of f446 series since it can't expose addresse and data lines
<henrik_alser[m]>
For anyone interested in the internal pullup for i2c topic above, i got curious to what could be the reason why we had so different experiences, so i did a quick measurement on my home setup using 2k2 pullups vs the internal ~40k on the stm32f411. All of my oled screens actually had onboard 10k pullups installed, so couldnt test with those, so i connected it to the i2c control interface for an audio codec breakout.
<henrik_alser[m]>
Here are the waveforms for SCL feeding straight into the device pin (~10pF?) on a 4pF breadboard, plus the 10x probe (9.5pF)
<henrik_alser[m]>
I was not able to get it to respond at 400k using the internal pullups for this particular device, so i guess apparently some devices are less sensitive than others...
<adamgreig-m>
<yruama_lairba[m] "hello, i have quesiton about the"> I don't *think* the 64 pin ones expose the fmc
<henrik_alser[m]>
(...so just a heads up before you’re throwing them all out)
<adamgreig-m>
I wonder if just most of the oleds have the 10ks and so it usually works with the internal ones anyway
<adamgreig-m>
(but would also just work without)
<firefrommoonligh>
Thx for wisdom on I2c internal PUs. I've been using external 10Ks @ 100Khz, and they seem to work. I'm interested in internals since in general reducing part count makes board design easier, and I use them for things like buttons.
<firefrommoonligh>
I've read in several sources to always use hardware PUs on I2C lines, and am certainly open to a challenge on that
<firefrommoonligh>
(The reasoning I've heard most often is to prevent bogus signals on the bus when the MCU is off or in a low-power mode that disables the PUs)
<firefrommoonligh>
Your point about different resistors is on top of that
<firefrommoonligh>
* Your point about different resistances is on top of that
<henrik_alser[m]>
The bus capacitance charges up through the PU resistance, so it’s an RC time constant
<yruama_lairba[m]>
adamgreig: i don't see anything in datasheet saying there is no FMC pin for 64 pin f446
<yruama_lairba[m]>
i fact, i was wandring if the FMC could with external memories throught a serial communication, but i don't find something stating this
<firefrommoonligh>
Could this be a feature that's subvariant-specific? Most periphs and their registers are family-level, but some have finer distinctions. These are usually noted in the RM with notes though.
<firefrommoonligh>
If that's the case, maybe the answer is to include it in the PAC, and expect the user to know if they have it or not
<firefrommoonligh>
The HALs will often break into finer variant-distinctions than PACs, and address it this way. I've elected not to in the multi-family HAL, for simplicity. (Ie I only differentiate at the levels the PAC does)
<yruama_lairba[m]>
Found, apparently, it's possible to map a SPI flash into the MCU address space
<yruama_lairba[m]>
but it's flash only, it doesn't interest me since i'm searching for external RAM option
<adamgreig-m>
I think that's just for the qspi peripheral not the fmc?
<yruama_lairba[m]>
adamgreig: don't know if it's related with fmc or not
<yruama_lairba[m]>
adamgreig: i think you're right, the 64 pin stm32f446 don't expose FMC pin, i can't set those pins on FMC_* function inside stm32CubeMX
<adamgreig-m>
Yea, I don't think any of the fmc AFs are available until 100pin
<firefrommoonligh>
So this is something available on some packages but not others? If so, I'd add it
<therealprof[m]>
<dirbaio[m] "okay it was wrong pull... it now"> Classic.
<therealprof[m]>
<firefrommoonligh "So this is something available o"> ? Sure, if your package doesn't have a specific pins exposed you can't use it externally. Shouldn't come as a surprise I'd assume?
<therealprof[m]>
It is (at least for the F series) still available internally so can still configure and use it in software.
<firefrommoonligh>
I'm proposing going through with the PAC addition, if this is in fact why it was ommitted initially
<adamgreig-m>
(what pac addition?)
<firefrommoonligh>
Oops unregard. I mixed up things
<yruama_lairba[m]>
i didn't understood everything, but the stm32f446 have a FMC to map external memory on MCU address. But according to datasheet, for the 64 pin version, some FMC pins aren't exposed making it (i think) unusable
<adamgreig-m>
yea. the FMC pins are mostly on GPIOD and GPIOE, and the 64-pin package only really exposes A, B, and C, so the FMC is not usable
<adamgreig-m>
even if it was, you'd need to use so many pins for the memory there wouldn't be much left for anything else...
<adamgreig-m>
hmm, maybe? i used the fmc on something last year with 16-bit data and 12-bit address and it used 33 pins in total, so there'd be a handful leftover even on a 64 pin package even after taking off power/swd/etc, but still not much
<adamgreig-m>
(and you probably want more than 12 address pins usually...)
<yruama_lairba[m]>
adamgreig: at some time, i wandered if FMC was supporting some "serial communication" with external memory, this would be drastically reduced the amount of used pin
<adamgreig-m>
it only supports 8, 16, or 32-bit wide parallel memories, with separate or multiplexed address lines
<adamgreig-m>
it does support synchronous operation so you could imagine sort of cheating to use it for serial but you'd have to do more work in software to deserialise a bit out of each byte
<adamgreig-m>
the qspi peripheral memory-maps external qspi flash, which has a special operating mode where you just stream addresses and data without needing to do other commands (the rp2040 uses this for example)
<yruama_lairba[m]>
i'm not used with those technics, but i guess writing and reading memory take more time with a serial bus
<adamgreig-m>
yea, though qspi can have up to 4 data pins which makes it sorta parallelish :p
<adamgreig-m>
and because it's synchronous it can go very fast, whereas many of the external memories you use with an fmc are non-synchronous and kinda slow
<adamgreig-m>
the QSPI can go like 133MHz so >500Mbps of bandwidth
<adamgreig-m>
your external 16-bit memory might be 30MHz which is the same total bandwidth
<adamgreig-m>
(probably your external memory can do more like 60 or even 80MHz so it is still faster... but uses a lot more pins)
<yruama_lairba[m]>
i don't know what synchronous/asynchronous memory means...
<adamgreig-m>
synchronous means "has a clock" basically, and all the operations happen on clock edges - like spi
<adamgreig-m>
asynchronous is the opposite, you just drive some state onto the pins and some time later it's completed, and the specification is to do with the timing you have to meet
<adamgreig-m>
of course, the interface is still "synchronous" to the stm32 internal clock, but that clock isn't driven to the external memory
<yruama_lairba[m]>
ok, synchronous mean shared clock
<adamgreig-m>
it doesn't inherently make it faster, but most modern high-speed interfaces are synchronous because it gets very difficult to get the timing to work out otherwise
<yruama_lairba[m]>
yeah, i remenber now, i had a sort of conferences about fully asynchronous device
<yruama_lairba[m]>
*i mean i was in the audience
<adamgreig-m>
they are kinda cool because they're often much lower power but it seems like they're very very hard to design
<yruama_lairba[m]>
you need to rebuild everything for asynchronous this, elementary block, design tool ...
<yruama_lairba[m]>
power is not the only benefit of this kind of chip, you also a less EMI emission (usefull for rf).
<yruama_lairba[m]>
there is also benefits for security, they resist to side channel attacks