Skip to main content
Pavel A.
Super User
January 8, 2018
Question

CubeMX does not allow user defines that are not number or string

  • January 8, 2018
  • 2 replies
  • 1246 views
Posted on January 08, 2018 at 01:14

Suppose that a hardware developer wants to pass in a Cube file some info for a fellow programmer.

For example tell which UART or GPIO pin to use: 

&sharpdefine RS232_UART  USART4

&sharpdefine LED_PIN  (GPIOB, 10)

But Cube won't allow this. It understands only literal numbers and quoted strings.

It will allow 

&sharpdefine RS232

_UART 'USART4' - but this is completely useless for the purpose.

How hard would be enabling any user definition text in the Cube code generator?

Regards,

 - pa

#cube-mx
This topic has been closed for replies.

2 replies

Vasile Guta_Ciucur
Senior
January 8, 2018
Posted on January 08, 2018 at 06:56

Any pin definition can be set in the graphical view of the microcontroller and is included in the main.h when the code is generated. When I do my own libraries, I decide a standard for naming the pins used in my library, a standard that any user that use my library must follow (of course, I include a comment that describe this obligation in my library's header)

As for any other 'parameters', I do defines before including the headers of my libraries (and mentioned in the library documentation). By example, a device that use I2C, in the main.c file I indicate which I2C peripheral the device should use via a #define before include:

#include <main.h>
#define device_x_use_I2C1
#include 'device_x_library_header.h'
�?�?�?�?�?�?

Inside the 'device_x_library_header.h' file I do:

#ifdef device_x_use_I2C1
 //use the I2C1 parameter in your I2C functions
#else
 //use the I2C2 parameter in your I2C functions
#endif�?�?�?�?�?

I use CubeMX for generating the required initialization code but I use my own 'repository of libraries' built upon LL drivers. I find the pin naming mechanism in the CubeMX to be enough in providing user standardized libraries, without adding something inside CubeMX.

What I would like to have in the 'Project settings' window is a possibility to define a relative path to my (user) repository of libraries/headers.

Pavel A.
Pavel A.Author
Super User
January 8, 2018
Posted on January 08, 2018 at 12:07

Hi Vasile,

Of course ifone has a .h filehe can put anything there. Butmy hardware developers use only the cube to select pins, map pins to on-chip devices, set GPIO pin modes and so on. From them I receive only .ioc files.

#define device_x_use_I2C1

is good enough though. Thank you.

-- pa

Andrew Neil
Super User
January 8, 2018
Posted on January 08, 2018 at 16:06

#define LED_PIN  (GPIOB, 10)

But how would you actually use that in your code?

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
Pavel A.
Pavel A.Author
Super User
January 8, 2018
Posted on January 08, 2018 at 16:38

Neil.Andrew

‌ - This will require some macro on the programmer's side, like, er....

#define MY_GPIO_INIT(g,p) { .m_gpio = g, .m_pin = p }

struct { GPIO_typedef *m_gpio, uint16_t m_pin } my_pin = MY_GPIO_INIT(LED_PIN);

We just need some simple conventionwith the h/w guy, easy to understand and remember

By the way,he canspecify the active pin state too:

#define LED_PIN (GPIOB, 10, 1)

...

#define MY_GPIO_INIT(g, p, s) { .m_gpio = g, .m_pin = p, m_on_state = s }

struct { GPIO_typedef *m_gpio, uint16_t m_pin,bool m_on_state } my_pin = MY_GPIO_INIT(LED_PIN);

-- pa

Andrew Neil
Super User
January 8, 2018
Posted on January 08, 2018 at 16:44

pavel a wrote:

This will require some macro on the programmer's side,

Exactly - that's all outside the scope of CubeMX.

I guess you could make a utility that parses the CubeMX output to create this sort of thing ...

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.