[BUG] warning: "SERIAL_TX_BUFFER_SIZE" redefined

[pmjdebruijn]

Did you test the latest bugfix-2.0.x code?

Yes, and the problem still exists.

Bug Description

Marlin builds with a large list of warnings for the SKR E3 RRF board.

Happens with current 2.0.x and bugfix-2.0.x, the issue seems to have been introduced in 7773504 for 2.0.x

Bug Timeline

7773504

Expected behavior

No build warnings.

Actual behavior

Building in release mode
Compiling .pio/build/BIGTREE_E3_RRF/FrameworkArduinoVariant/PeripheralPins.c.o
Compiling .pio/build/BIGTREE_E3_RRF/FrameworkArduinoVariant/variant.cpp.o
<command-line>: warning: "SERIAL_RX_BUFFER_SIZE" redefined
<command-line>: note: this is the location of the previous definition
<command-line>: warning: "SERIAL_TX_BUFFER_SIZE" redefined
<command-line>: note: this is the location of the previous definition
Compiling .pio/build/BIGTREE_E3_RRF/FrameworkArduino/HardwareSerial.cpp.o
<command-line>: warning: "SERIAL_RX_BUFFER_SIZE" redefined
<command-line>: note: this is the location of the previous definition
<command-line>: warning: "SERIAL_TX_BUFFER_SIZE" redefined
<command-line>: note: this is the location of the previous definition
Compiling .pio/build/BIGTREE_E3_RRF/FrameworkArduino/HardwareTimer.cpp.o
<command-line>: warning: "SERIAL_RX_BUFFER_SIZE" redefined
<command-line>: note: this is the location of the previous definition
<command-line>: warning: "SERIAL_TX_BUFFER_SIZE" redefined
<command-line>: note: this is the location of the previous definition

Steps to Reproduce

No response

Version of Marlin Firmware

Marlin 2.0.9.1+81 (35df24e1) (2.0.x branch)

Printer model

Ender 3 Pro

Electronics

SKR E3 RRF V1.1

Add-ons

No response

Your Slicer

Prusa Slicer

Host Software

No response

Additional information & file uploads

No response

[thisiskeithb]

Please attach your configuration files.

[thinkyhead]

The BIGTREE_E3_RRF environment had -DSERIAL_RX_BUFFER_SIZE=255 before the cited commit.

[thinkyhead]

From my quickie investigation I note that the stm32f4_variant was removed and the STM32F4-based boards now just use the stm32_variant environment as their basis. That particular environment invokes the script stm32_serialbuffer.py which always adds DSERIAL_RX_BUFFER_SIZE=... to the build flags. Since the BIGTREE_E3_RRF environment is also setting that flag, it is being set twice in the command line, and this is probably the source of the warning. The solution might be to make this change:

build_flags         = ${stm32_variant.build_flags}
                      -DSTM32F407_5VX
-                     -DSERIAL_RX_BUFFER_SIZE=255
-                     -DSERIAL_TX_BUFFER_SIZE=255
+                     -DRX_BUFFER_SIZE=255
+                     -DTX_BUFFER_SIZE=255

[thinkyhead]

Following up on that, for any environment that doesn't define RX/TX_BUFFER_SIZE the stm32_serialbuffer.py script will add…

-DSERIAL_RX_BUFFER_SIZE=128
-DSERIAL_TX_BUFFER_SIZE=64
-DUSART_RX_BUF_SIZE=128
-DUSART_TX_BUF_SIZE=64

[ldursw]

The solution might be to make this change

@thinkyhead I agree. Instead of setting SERIAL_*X_BUFFER_SIZE directly I think it's better to set *X_BUFFER_SIZE so that other parts of the firmware can adjust accordingly. It may raise another warning if the user overrides the value in Configuration_adv.h, though.

[thinkyhead]

@ldursw — Actually there are some complications. We cannot use -DRX_BUFFER_SIZE=255 -DTX_BUFFER_SIZE=255 because these are set by the user in their configurations. Also, these are required to be powers of 2 (i.e., 256). The stm32_serialbuffer.py script is intentionally pulling the RX/TX_BUFFER_SIZE values from Configuration_adv.h and the default for TX_BUFFER_SIZE is 0 because in the past the transfer buffer was something you could turn off. (Ever since #11982 by @ejtagle that has not been an option.)

[thinkyhead]

The simplest workaround would be to change the script, so if SERIAL_*X_BUFFER_SIZE is already defined in the build flags, it should not be added again.

[thinkyhead]

OTOH… BIGTREE_E3_RRF is the only enviroment that wants to do its own thing. So, it could just skip that script altogether. However, it is not clear this is right, either, because presumably the values of RX_BUFFER_SIZE and TX_BUFFER_SIZE in the configurations are supposed to match up in some way to the SERIAL_*X_BUFFER_SIZE being provided to the platform HAL.

So my question is, is it okay in the case of the BIGTREE_E3_RRF for the platform HAL settings to not match the Marlin firmware settings?

[thinkyhead]

I posted the simple fix to get rid of the warning, but we may want to revisit this topic in future.