Migration from SPL to HAL on STM32

[Aasdf.1]

I'm migrating an ST driver file from the old standard peripheral library to the new HAL system. Here's and one example of many identifiers I'm having to replace:

Old: ETH_DMA_Rx_Frame_infos

New: ETH_DMARxFrameInfos

These two identifiers contain EXACTLY the same information, only diff is the capitalization and a few underscores. Why did the PhD's at ST deem it necessary to change all the identifiers between the old and new libraries in this trivial way??? ALL THIS DOES IS CAUSE YOUR CUSTOMERS HOURS OF EDITING HELL.

I'm picturing some MBA sitting in his corner cubicle angling to make his mark in the cubicle farm at ST corporate. "Hmmm... How can I get noticed? I know! I'll reformat all the identifiers in the new HAL code in such a revolutionary way that I'll get a reserved parking place near the front door! That's it!!!"

Gawd! Doesn't any one of you engineers have a damn lick of common sense???

[Jack Peacock_2]

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

[TDK]

> 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.