<firefrommoonligh>
And re that earlier chat about hardware vs internal PUs on I2C: I guess this works, and is even recommended in teh datasheet, for this part, and nothing else on the line!
<dirbaio[m]>
are there chips with "half full" GPIO ports?
<dirbaio[m]>
like a port that only has pins 0-4, and not more
<dirbaio[m]>
* like a port that only has pins 0-4, and not up to the usual 16
<dirbaio[m]>
and if so can I just "ignore" that?
<dirbaio[m]>
and just generate N 16-pin ports?
<firefrommoonligh>
I haven't encountered any... What leads you to think this exists?
<adamgreig-m>
dirbaio: I've never seen the gpio peripheral not have all the fields, even though usually many are not bonded out
<dirbaio[m]>
👍️
<firefrommoonligh>
The GPIO reg block is very consistent across families
<firefrommoonligh>
with some minor naming differences on fields
<adamgreig-m>
the RMs almost invariably document "GPIOx_ODR (x=A..F)"
<adamgreig-m>
or, more than F, there can be loads
<firefrommoonligh>
Some have G and H
<adamgreig-m>
but the point is it doesn't then distinguish
<firefrommoonligh>
Actually... Not sure if G is a thing
<dirbaio[m]>
<firefrommoonligh "I haven't encountered any... Wha"> the ST curse, it makes me doubt everything now :S
<firefrommoonligh>
H can be
<adamgreig-m>
the one I'm using now goes up to K
<firefrommoonligh>
Holy fuck
<adamgreig-m>
even F1s have that I think? at least F4s defo do
<firefrommoonligh>
I've never messed with anything with more than 48 pins... which could explain things!
<adamgreig-m>
yea, on those you only get H as the HSE pins PH0/PH1 usually
<adamgreig-m>
this one is 265 pins, lol
<adamgreig-m>
honestly it's not as bad as it sounds, most of them are ground or 3v3 or 1v8 or whatever
<adamgreig-m>
and the AF tables thin out a lot after port D, so they're usually just high-order FMC pins, LTDC pins, and general I/O
<dirbaio[m]>
oh yeah the FMC is a pin monster :o
<firefrommoonligh>
Yea. The Osc pins are sometimes named pH, sometimes PF depending on family, but USUALLY map to the same pins
<adamgreig-m>
32 data pins plus like 24 address pins plus clock, 4 chip selects, we, oe, it's a bunch lol
<adamgreig-m>
happily I can mux address and data in this case adn only need 16 bit, so it's 16 addr/data pins, 3 more address-only pins, clk, we, and en
<adamgreig-m>
this is actually the one thing I use stm32cubemx for, current WIP: https://imgur.com/a/GlxW9Ht
<dirbaio[m]>
so many balls... I bet the PCB routing is fun too
<adamgreig-m>
check out PA0_C, PA1_C, etc dirbaio, lol
<adamgreig-m>
I don't think you need to care about them probably...
<dirbaio[m]>
wut, what are these
<adamgreig-m>
honestly the pcb routing is great with bga
<adamgreig-m>
<firefrommoonligh "And re that earlier chat about h"> yea, a few simpler i2c parts are happy for the clock to be a strict input, so the hardware can drive it push-pull even, not sure if the stm32 supports that though
<adamgreig-m>
you could investigate if your system works with output type pushpull and no resistor at all
<adamgreig-m>
then you'd just need to swap between output-set-low and AF
<firefrommoonligh>
Ooh, cool idea. I was surprised to see that wording in the datasheet - as you correctly guessed by my code reverting to OpenDrain. Will try leaving as PushPull and see if it still works
<firefrommoonligh>
*I already yanked the resistor from the design and prototype board on SCL, although still have it on SDA
<firefrommoonligh>
Oh I see you mean no internal pull either.. will try
<firefrommoonligh>
OH... wow
<firefrommoonligh>
It works!
<firefrommoonligh>
Note that if I leave it open drain without the internal PU enabled, it doesn't
<firefrommoonligh>
So I have SDA configured normally as opendrain with hardware PU. SCL is now always PushPull Output, with floating pull, and no hardware PU. And I alternate between OutputType to manually set low in low-power mode, and Alternate (AF4) for normal I2C comms
<firefrommoonligh>
* So I have SDA configured normally as opendrain with hardware PU. SCL is now always PushPull Output, with floating pull, and no hardware PU. And I alternate between Modes of Output to manually set low in low-power mode, and Alternate (AF4) for normal I2C comms
<adamgreig-m>
Nice! The only time you can't do this is if a device on your i2c bus uses clock stretching, where the device pulls the clock low
<adamgreig-m>
Many devices do not do this, so the clock line is a strict input and can be driven push-pull by the stm32
<firefrommoonligh>
That's great to know - I figured this was a quirk of this device
<adamgreig-m>
You can't generally assume it for i2c but it's often the case and generally documented if so
<firefrommoonligh>
Btw, with a mujltimeter, I can confirm SCL reads 0 when in sleep mode. So this appears to be set up per that config. Thank you so much
<adamgreig-m>
👍
<dirbaio[m]>
do devices that use clock stretching document that fact?
<dirbaio[m]>
in general I mean
<adamgreig-m>
<dirbaio[m] "do devices that use clock stretc"> I can't make promises for all i2c devices but yes usually