cancel
Showing results for 
Search instead for 
Did you mean: 

SPI vs GPIO - Alternate Functions (AF)

LucasStartTech
Associate

@Tesla DeLorean Hi! Thank you for helping me with the BOOTING process. However, I have a question about the peripherals. I am planning to control a TFT screen that requires 40 pins and RGB protocol. At first, I was planning to choose random GPIOs to build the protocol (I am trying to learn by making it rather than just applying something already built), and I noticed that if I choose to use LTDC, some pins light up, as well as for connectivity like SPI... The pins selected by the IDE to do such tasks have any special characteristics? do they toggle faster? or could I do just the same applying the protocol to any other random set of GPIOs?

1 ACCEPTED SOLUTION

Accepted Solutions

Sure, you can use GPIO pins to "bit-bang" any protocol you like (subject to performance limits) - but that requires you to code every single rising edge, delay, falling edge, and sample in code.

That's very heavy on you writing the code, and on the processor having to run it.

Therefore microcontrollers have dedicated hardware blocks for doing common things like SPI, I2C, UART, etc

That relieves both you of having to write, and the processor of having to execute, all that tedious bit-twiddling - you can just pass data to the SPI unit, and it handles it all in hardware.

And hardware can give much higher performance than "manually" twiddling bits by software.

This is general across all microcontrollers - not specific to ST or STM32


 

View solution in original post

11 REPLIES 11

Sure, you can use GPIO pins to "bit-bang" any protocol you like (subject to performance limits) - but that requires you to code every single rising edge, delay, falling edge, and sample in code.

That's very heavy on you writing the code, and on the processor having to run it.

Therefore microcontrollers have dedicated hardware blocks for doing common things like SPI, I2C, UART, etc

That relieves both you of having to write, and the processor of having to execute, all that tedious bit-twiddling - you can just pass data to the SPI unit, and it handles it all in hardware.

And hardware can give much higher performance than "manually" twiddling bits by software.

This is general across all microcontrollers - not specific to ST or STM32


 

STTwo-32
ST Employee

Hello @LucasStartTech 

Infact, the STM32CubeMX (Standalone version or the one integrated on the STM32CubeIDE) will give a selection of pins that have the necessary Alternate functions (or additional function) to make it work on a specific function (Slave select for SS for SPI, MOSI, MISO,...). Those details can be found on the Table of pin and ball definitions (table 10 of the DS9405 for the STM32F429)

Best Regards.

STTwo-32

 

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

I see, so instead of having me to interpret each signal, it is all done in the hardware already. Thank you!!


@STTwo-32 wrote:

details can be found on the Table of pin and ball definitions (table 10 of the DS9405 for the STM32F429)


@LucasStartTech it starts on page 53:

https://www.st.com/resource/en/datasheet/stm32f427vg.pdf#page=53

See also Table 12, alternate function mapping - from page 75:

https://www.st.com/resource/en/datasheet/stm32f427vg.pdf#page=75

@Andrew Neil, I saw this table already. Since I am new to hardware, I didn't know if the pins were assigned just because of the HAL function or if they actually have something more.

As you can see from the tables, each pin can be configured to a number of Alternate Functions (AFs).

The range of possible AFs on a given pin is fixed in the hardware.

Selecting which one of the available  AFs to use at a particular time is done by the software; eg, via HAL functions

This is shown diagrammatically in the Reference Manual; eg,

AndrewNeil_0-1736525651519.png

https://www.st.com/resource/en/reference_manual/rm0090-stm32f405415-stm32f407417-stm32f427437-and-stm32f429439-advanced-armbased-32bit-mcus-stmicroelectronics.pdf#page=275

 

PS:

Highlighting what's defined by hardware vs what's controlled by Software:

AndrewNeil_1-1736526087672.png

 

 

LucasStartTech
Associate

@Andrew Neil, I will take a look at this reference manual. I've been dedicating a lot of time to learn this since spring semester. I started with the atmega and now I am trying to learn this architecture. I wish I could read faster; all these manuals are very extensive :face_with_tears_of_joy:. 

 

Thank you for the help and patience!


@LucasStartTech wrote:

 I started with the atmega 


They are very much simpler devices - so a good place to start for learning!

You will still have seen the concept of Alternate Functions there - pins that can be used either as plain GPIO, or for things like UART, SPI, I2C.

But (certainly on the simpler AVRs) there's generally no more than one AF on a pin; so there's no need to decide between multiple different AFs - eg, simply enabling the UART turns its associated pins to the UART AF mode.