Page 1 of 1

SPI configuration confusion

Posted: Thu May 08, 2025 9:20 pm
by jcbless
I'm trying to figure out how to configure SPI - e.g. CPOL and CPHA choice. I find references in the code to CPOL and CPHA, but I really don't see how to use it (for example #define SPI_CR1_CPOL). It would seem that those would be bits as members of CR1, but see my next comment below about cr1 not seeming to exist in the code.

Also on Play Embedded I see cr1 and cr2 referenced as members of SPIConfig ( https://www.playembedded.org/blog/lever ... lications/ ), but yet in the code and doxygen documentation I don't see those fields anywhere.

Could you please provide some assistance?

Thanks,
John

Re: SPI configuration confusion

Posted: Thu May 08, 2025 9:31 pm
by Giovanni
Hi,

Those fields are registers initialization values, their documentation is in the STM32 reference manual. This is true for most drivers, configuration structures often contain fields named after the physical peripheral register names.

The HAL documentation is generic, it does not contain fields that are specific of a micro.

Giovanni

Re: SPI configuration confusion

Posted: Thu May 08, 2025 9:36 pm
by jcbless
Thanks for the quick response. Is there a way for me to apply that value via ChibiOS, or do I apply those bits directly to the register on the STM32?

Thanks,
John

Re: SPI configuration confusion

Posted: Thu May 08, 2025 10:23 pm
by jcbless
One thing that had been confusing me was that cr1 and cr2 were not directly in the definition of struct hal_spi_config, but I now see that in some files called hal_spi_lld.h there is a #define spi_lld_config_fields which brings in cr1 and cr2 which are uint16_t's.

I assume now that if I apply the bit definitions such as SPI_CR1_CPOL to cr1, that this must effectively turn on the desired bits. I'm still figuring this out, but I think I'm seeing it a little bit better now.

Thanks,
John

Re: SPI configuration confusion

Posted: Fri May 09, 2025 4:22 am
by Giovanni
Hi,

Correct, the LLDs export macros that add architecture-dependent fields to the "standard" structures.

The non-portability is encapsulated in those configuration structures, the rest of the HAL is portable cross-platform, it is possible to make applications running on different MCUs by simply putting the configuration data in a separate module.

Giovanni