Skip to main content
Pavel A.
Jan 8, 2018 12:14 AM UTC
Question

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

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.

7 replies

Vasile Guta_Ciucur
Senior
Jan 8, 2018 5:56 AM UTC
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
Jan 8, 2018 12:07 PM UTC
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
Jan 8, 2018 3:06 PM UTC
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
Jan 8, 2018 4:38 PM UTC
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
Jan 8, 2018 4:44 PM UTC
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.