Suggestion: peripheral handle label should also generate compile-time usable definition

[RAltm]

Hi,
peripheral handles, either the dedicated ones or the labeled ones are usable only during runtime, they're filled with data at the initialization. However, it would be practical to also get a compile-time usable definition as well.

So, for example if I label timer 3 as 'MyTimer', we'll get

#define MyTimer htim3

It would be practical to also get something like this:

#define _MyTimer_ TIM3

This would give access to e.g. register addresses at compile time. For example, if I want to create a pointer table to the timer CCRs, I can write:

volatile const uint32_t *TabCcrPtr[] = {
		&_MyTimer_->CCR1,
		&_MyTimer_->CCR2,
		&_MyTimer_->CCR3,
		&_MyTimer_->CCR4
};

The idea is to have shorter code using tables because it's not needed to use switch statements, etc.

Regards

[Andrei Chichak]

What you are looking for is the User Constants tab in CubeMX.

You have two options, use the "Add Peripheral Handle Label" button to give a name to the timer (or SPI or UART...peripheral), or use the "add" button to add a name for the channel, or whatever you need.

Basically, yeah, it's there.

[RAltm]

Hello Andrei,

---

@Andrei Chichak wrote:

What you are looking for is the User Constants tab in CubeMX.

You have two options, use the "Add Peripheral Handle Label" button to give a name to the timer (or SPI or UART...peripheral), or use the "add" button to add a name for the channel, or whatever you need.

Basically, yeah, it's there.

---

This needs to create the user constant seperately. What I'm suggesting is that the compile-time usable definition is created automatically when creating a handle label. 

Regards

[Andrew Neil]

---

@RAltm wrote:

This needs to create the user constant seperately.

---

I don't see what you mean by that?

The feature you're suggesting does exist; it's just optional.

Currently, the option is disabled by default; Perhaps what you're saying is that should be enabled by default?

[Andrei Chichak]

There is a basic tradeoff here. You can either just try it and see if it suits your purposes, or if ST requires you to enter a name for your peripheral people will complain loudly and then even more people will complain that the #defines are bloating their code (even though defines have never been placed in binaries since the the 70s).

[RAltm]

---

@Andrei Chichak wrote:

There is a basic tradeoff here. You can either just try it and see if it suits your purposes, or if ST requires you to enter a name for your peripheral people will complain loudly and then even more people will complain that the #defines are bloating their code (even though defines have never been placed in binaries since the the 70s).

---

I don't get that point. People can't complain because my suggestion adds one additional #define if they create a handle label. So, at that point they already accepted an additional #define (and obviously they need it, otherwise they wouldn't create a handle label). A second #define wouldn't hurt.

Regards

[TDK]

I don't think the added burden of another feature to support is worth the minimal improvement in functionality here. You can use htim3.Instance to get the registers at run time. HAL isn't built to care about optimizing at this level.

[Andrei Chichak]

@RAltm "People can't complain because my suggestion adds one additional #define if they create a handle label."

People will complain if you build CubeMX into CubeIDE. People will complain if you take CubeMX out of CubeIDE.

People will complain if you change the gcc version.

People will complain if you add a feature even though gcc will remove it in the preprocessor. People will complain that the HAL is too big and checks too much. People will complain that LL doesn't do enough and needs to check more. People will complain that stuff in the HAL is too big even though they don't use it and the linker will not put it into their object file.

People will complain.

[RAltm]

@TDK 

---

I don't think the added burden of another feature to support is worth the minimal improvement in functionality here. You can use htim3.Instance to get the registers at run time. HAL isn't built to care about optimizing at this level.

---

As mentioned I wanted it at compile-time, not run-time.

@Andrei Chichak 

---

People will complain.

---

I see... they'll also complain if there's nothing to complain, right?

Well, it was just meant as a suggestion. At the end it's up to ST if they'll implement it (provided that they recognize the suggestion). No need to discuss it further.

Regards