MSP430FR59941: Error - #2633: Modifiers not allowed in printf_support

I think I found the project here: github.com/.../nnom_utils.c

apparently both top and predict_count are uint32_t and it looks like someone had a similar problem with printf-ing uint32_t here:

https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/202897/formatted-printing-with-sprintf-sorely-lacking-with-ccs5-for-msp430

but from experience, printf(), snprintf() are a huge waste of resources. I always avoid them and end up formatting numbers with custom functions like these ones:

https://github.com/rodan/reference_libs_msp430/blob/master/glue/generic/lib_convert.c

I know this would only help for a new project, but oh well.

Hello Urica, 

Thanks, this thread did help to solve the issue after I enabled the printf support to - 'full'. I am not sure if it's the best thing to have it enabled but it works for the time being. However, I had also found a temporary solution where-in I just removed the digit specifications from the printf - for eg. %02d was simply %d - while the project was built albeit with some warnings - I do face issues once the code is deployed on the controller as my main.c file fails to provide the output. I think the removal of the numbers only helps clear the syntax but the functionality of the code does seem to be affected by it. Just thought it'd be useful if I updated what I tried if someone faced a similar issue.

Thanks,

Siddhant

Yeah, I was not keen on using printf() either but since the library has already been pre-written and it would take a ton of effort to replace printf in almost all the other files - I was looking for an option that would simply resolve the printf issue. The thread that was suggested above does help but I also tried out another solution which I have mentioned below but I think that purely cures the syntax issue and is probably not helping my cause as the code does fail to work once loaded on to the MCU. Thanks for the other link - I will definitely have a look and see if it is possible to incorporate the same into my code.

those functions generate a null-ended string containing the conversion. one has to allocate a buffer

char itoa_buf[CONV_BASE_10_BUF_SZ];

and then use whatever printing function that takes a string argument on the conversion function (you need _utoa)

NNOM_Log("Accuracy: ");

NNOM_Log(_utoa(itoa_buf, (top * 100) / pre->predict_count));

NNOM_Log("\n");

then reuse the buffer for another conversion and so on. see tests/uart0 for an example.

like this you'll get rid of the printf-related conversions (and errors) even if the minimal implementation is used since it will only get strings.

unfortunately I saw that your project is quite chatty so I can feel your pain.

just remembered, in case the math calculations generated by your library are off, make sure to verify in your compiler settings the type of hardware multiplier supported by the target. for gcc the setting should be:

-mhwmult=f5series

see the equivalent for your compiler. IIRC in my case it defaulted to auto and it generated garbage, but this was a long time ago.

Thanks for the tip - I will check it and update it to the equivalent.