Hello,
I am in the process of porting Riot to a board that uses an STM32. So far everything has gone relatively smoothly. I’ve run into an issue that I see two ways of fixing and was looking for some feedback. The current STM32F1 port supports processor models F103xB and F103xE. I am looking to add support for a few processors eventually but for now, F105xC.
The port includes what appears to be a relatively stock version of stm32f103xb.h from the CMSIS library. The header seems to have a few modifications or an older version that is a bit different. The specific issue I’m facing now, is that the old version defined this:
typedef struct { __IO uint32_t CR[2]; __IO uint32_t IDR; __IO uint32_t ODR; __IO uint32_t BSRR; __IO uint32_t BRR; __IO uint32_t LCKR; } GPIO_TypeDef;
and the new headers from CMSIS define this:
typedef struct { __IO uint32_t CRL; __IO uint32_t CRH; __IO uint32_t IDR; __IO uint32_t ODR; __IO uint32_t BSRR; __IO uint32_t BRR; __IO uint32_t LCKR; } GPIO_TypeDef;
As you can see, the CR[2] turned into a CRL and CRH. This causes obvious issues with the GPIO driver that was written around the CR[2] version.
The way I see it, there are two paths forward for future STM32 ports. Either modify the new CMSIS versions to comply with what RIOT was already written around. Or, update RIOT to better comply with new versions of CMSIS.
Please advise on what the best policy is here for this.
Sincerely, Anthony