Migration from SPL to HAL on STM32

To be fair to ST changing function names for an entirely new API does make sense. A new API call that has the same name implies it works with exactly the same inputs, maintains the same invariants internally including the same register changes and returns the same values to the caller.

Unless you know the internal code is exactly the same (in which case, why create a new library?) using the same name leads to a false sense of security. If the same names were used but with different results there'd be as many or more complaints the names weren't altered.

While I question many of the design decisions made in HAL/Cube I don't think the ST programmers are lazy or incompetent. You are not aware of all the design goals imposed on the team, many of which are obviously non-technical in nature. A good commercial product engineer has to work within a much broader scope than just writing code.

Conversion from SPL is intended to be handled by the LL library. If there are no APIs in the LL for your application I'm sure it was an economic rather than technical decision not to add support. I chose to maintain my own SPL library rather than convert to LL and HAL, also on economic grounds due to size of code base when moving to newer STM32 families. If I change a library function then I do change the name as well.

If you want free software you have to pay the price for it, in this case accepting what's decided for you. I'm sure ST would be happy to code an application customized just for you, assuming you want to pay the substantially large costs involved.

Jack Peacock

> These two identifiers contain EXACTLY the same information, only diff is the capitalization and a few underscores.

Here's the old definitions:

typedef struct {
	volatile uint32_t Status;
	uint32_t ControlBufferSize;
	uint32_t Buffer1Addr;
	uint32_t Buffer2NextDescAddr;
} ETH_DMADESCTypeDef;
 
typedef struct {
 volatile ETH_DMADESCTypeDef *FS_Rx_Desc; /*!< First Segment Rx Desc */
 volatile ETH_DMADESCTypeDef *LS_Rx_Desc; /*!< Last Segment Rx Desc */
 volatile uint32_t Seg_Count; /*!< Segment count */
} ETH_DMA_Rx_Frame_infos;

And here's the new:

/** 
 * @brief ETH DMA Descriptors data structure definition
 */ 
 
typedef struct 
{
 __IO uint32_t Status; /*!< Status */
 
 uint32_t ControlBufferSize; /*!< Control and Buffer1, Buffer2 lengths */
 
 uint32_t Buffer1Addr; /*!< Buffer1 address pointer */
 
 uint32_t Buffer2NextDescAddr; /*!< Buffer2 or next descriptor address pointer */
 
 /*!< Enhanced ETHERNET DMA PTP Descriptors */
 uint32_t ExtendedStatus; /*!< Extended status for PTP receive descriptor */
 
 uint32_t Reserved1; /*!< Reserved */
 
 uint32_t TimeStampLow; /*!< Time Stamp Low value for transmit and receive */
 
 uint32_t TimeStampHigh; /*!< Time Stamp High value for transmit and receive */
 
} ETH_DMADescTypeDef;
 
/** 
 * @brief Received Frame Informations structure definition
 */ 
typedef struct 
{
 ETH_DMADescTypeDef *FSRxDesc; /*!< First Segment Rx Desc */
 
 ETH_DMADescTypeDef *LSRxDesc; /*!< Last Segment Rx Desc */
 
 uint32_t SegCount; /*!< Segment count */
 
 uint32_t length; /*!< Frame length */
 
 uint32_t buffer; /*!< Frame buffer */
 
} ETH_DMARxFrameInfos;

Similar? Sure. But they aren't the exact same, as you claim. Changing the name seems justified to me.