Why AF input as push-pull?

[turboscrew]

Posted on September 02, 2017 at 20:14

What is the idea that in many cases alternate function inputs are configured as 'alternate function push-pull'? In most cases it seems to work, but why? From the documents I've got the idea that the inputs are always going to the alternate function and the 'alternate function' output mode affects only the output drivers. Whether or not the alternate function actually reads the inputs, is a different story.

Like:

 /**SPI1 GPIO Configuration
 PA5 ------> SPI1_SCK
 PA6 ------> SPI1_MISO
 PA7 ------> SPI1_MOSI
 */
 GPIO_InitStruct.Pin = GPIO_PIN_5|GPIO_PIN_6|GPIO_PIN_7;
 GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
 GPIO_InitStruct.Pull = GPIO_NOPULL;
 GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
 GPIO_InitStruct.Alternate = GPIO_AF5_SPI1;
 HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

The picture in most manuls is like this:

[Tesla DeLorean]

Posted on September 02, 2017 at 20:54

There are multiple ways to configure things, the AF_PP/AF_OD just enables the peripheral to control more of the options. It generally means you don't have to think so hard when configuring the the pin, the peripheral gets to decide if it's an INPUT, OUTPUT, or BIDIRECTIONAL, and when it is whichever.

For SPI, the state is going to depend on whether the peripheral is configured as a Master or a Slave.

[turboscrew]

Posted on September 03, 2017 at 00:15

Both MISO and MOSI are configured

GPIO_MODE_AF_PP.

[S.Ma · Accepted solution]

Posted on September 03, 2017 at 06:29

If someone needs to dynamically change the Gpio nature, push pull maybe a good option for spi. Example is to generate a spi assisted SWD debug bus: some bits are done by spi, some are by sw. Or spi 3 wire bidirectional data line such as in motion mems. For I2C, open drain is probably prefferable.