HAL driver CAN msg typedefs

[op_it]

Posted on October 16, 2015 at 19:24

I worked a lot with the StandardPeriphLib but now I try to migrate over to the HAL driver for new projects. The HAL driver come with a heavy overhead. For example, without any optimization level the function HAL_DMA_IRQHandler(...) compiles to a size of approx. 10kB Flash ... wow!

In real time applications I try keep the code as fast and small as possible. I came across some problems, when I tried to copy data to CAN-msg struct. In the past I usually used:

memcpy
(txMsg->Data, &some_data[0], 8);

But now with the HAL driver I got wrong data on the CAN-Bus. Why? They changed the type definition to:

typedef
struct
{
uint32_t StdId; 
uint32_t ExtId; 
uint32_t IDE; 
uint32_t RTR;
uint32_t DLC; 
uint32_t Data[8]; 
}CanTxMsgTypeDef;

I real don't get the point, why the Data field now is an uint32_t array. It does not reflact the CAN-Bus specification or not even the internal register structure. So can anybody explain this change? Copying data now will take much more time and much more memory. I have to rewrite a lot of code. #typedef #doctor-it-hurts-when-i-do-this #stm32cube #can

[Tesla DeLorean]

Posted on October 18, 2015 at 22:56

I have to rewrite a lot of code.

Makes me wonder why you have to migrate to HAL from SPL in the first place, the paradigm shift between the two is quite apparent from the outset.

The 32-bit values are probably easier to manage in ARM instructions, instead of a lot of pack-unpack operations at a bit level. You could review the source to see how it's used.

[markb]

Posted on October 19, 2015 at 19:19

Unusual for me to defend the HAL but for the F4 at least, that structure is defined like this:

typedef struct

{

  uint32_t StdId;    /*!< Specifies the standard identifier.

                          This parameter must be a number between Min_Data = 0 and Max_Data = 0x7FF */

  uint32_t ExtId;    /*!< Specifies the extended identifier.

                          This parameter must be a number between Min_Data = 0 and Max_Data = 0x1FFFFFFF */

  uint32_t IDE;      /*!< Specifies the type of identifier for the message that will be transmitted.

                          This parameter can be a value of @ref CAN_Identifier_Type */

  uint32_t RTR;      /*!< Specifies the type of frame for the message that will be transmitted.

                          This parameter can be a value of @ref CAN_remote_transmission_request */

  uint32_t DLC;      /*!< Specifies the length of the frame that will be transmitted.

                          This parameter must be a number between Min_Data = 0 and Max_Data = 8 */

  uint8_t Data[8];   /*!< Contains the data to be transmitted.

                          This parameter must be a number between Min_Data = 0 and Max_Data = 0xFF */

}CanTxMsgTypeDef;

I think it got changed from uint32_t to uint8_t a few releases ago.

[Andrei Chichak]

Posted on October 19, 2015 at 22:10

Quite bizarre, with my copy of the HAL (F4 1.8.0), that same struct has this form:

typedef struct
{
uint32_t StdId; /*!< Specifies the standard identifier.
This parameter must be a number between Min_Data = 0 and Max_Data = 0x7FF */
uint32_t ExtId; /*!< Specifies the extended identifier.
This parameter must be a number between Min_Data = 0 and Max_Data = 0x1FFFFFFF */
uint32_t IDE; /*!< Specifies the type of identifier for the message that will be transmitted.
This parameter can be a value of @ref CAN_Identifier_Type */
uint32_t RTR; /*!< Specifies the type of frame for the message that will be transmitted.
This parameter can be a value of @ref CAN_remote_transmission_request */
uint32_t DLC; /*!< Specifies the length of the frame that will be transmitted.
This parameter must be a number between Min_Data = 0 and Max_Data = 8 */
uint8_t Data[8]; /*!< Contains the data to be transmitted.
This parameter must be a number between Min_Data = 0 and Max_Data = 0xFF */
}CanTxMsgTypeDef;

What version of the HAL are you using? I'm going to defend the HAL. I had never used CAN before, but my project required a J1939 stack on top of CAN 2.0. I managed to get CAN messages going back and forth to a simulator in an hour or two. It works for me, extremely well actually, and CubeMX saved my EE about 3 weeks of pin shuffling when laying out a board. Perhaps you have the baby duck syndrome and you prefer the stuff you started with.

[Tesla DeLorean]

Posted on October 19, 2015 at 23:06

Perhaps you have the baby duck syndrome and you prefer the stuff you started with.

Probably directed at the OP, but his complaint that he basically has to refactor everything is valid, and part of why it's going to be hard to do a simple migration.

I think I've been doing this long enough to recognize the difference between a duck and a swan.

The callback methodology isn't something that's alien to me, but it and asynchronous calling, can lead to unexpected stacking and context, and limitations about what can and can't happen, and the tendency for people to spin in loops when they really should return and come back later.

My key issues with Cube/HAL:

Lot's of bugs, and really stupid amateurish ones.

The constant stream of poorly tested updates attempting to address the bugs, and changes in direction.

The desire to take a round problem, and flattening it into uniformity, with all the distortion that causes, and a lot of bulk/gyrations required to make things that are intrinsically different look/behave the same.

[Andrei Chichak]

Posted on October 20, 2015 at 00:52

... and there's a new version out (F4 1.9.0) with extremely generic release notes, essentially ''fixed everything''.