[UNO Q} - Serial.print of a float or double prints ovf

[KurtE]

A Forum user, reported this on the Forum:
https://forum.arduino.cc/t/uno-q-println-float-or-double-results-in-ovf/1442618

I modified it slightly so I could also try running in on the GIGA (under zephyr). It worked correctly on the GIGA, but failed on the UnoQ. I am running Arduino IDE 2.3.8, current version of boards, actually I ran it using build with current sources.

#ifdef ARDUINO_UNO_Q
#include <Arduino_RouterBridge.h>
#endif
void setup() {
#ifdef ARDUINO_UNO_Q
  Bridge.begin();
#endif
  Serial.begin(115200);
}

void loop() {
  float f = 39.3;
  double d = 55.9;
  int i = 3141;
  char print_buf[128];

  Serial.print("float f = ");
  Serial.println(f); /* ovf */
  if (snprintf(print_buf, sizeof(print_buf), "float f = %f using snprintf", f)) {
    Serial.println(print_buf);
  }

  Serial.print("double d = ");
  Serial.println(d); /* ovf */
  if (snprintf(print_buf, sizeof(print_buf), "double d = %f using snprintf", d)) {
    Serial.println(print_buf);
  }

  Serial.print("int i = ");
  Serial.println(i);

  delay(10000);
}

On UNO Q:

float f = ovf
float f = 39.299999 using snprintf
double d = ovf
double d = 55.900000 using snprintf
int i = 3141

On Giga:

float f = 39.30
float f = 39.299999 using snprintf
double d = 55.90
double d = 55.900000 using snprintf
int i = 3141

[mjs513]

@KurtE

Yeah - just ran into this same issue with using Serial on 0.55.0

ovf
 
 
XV Lidar Controller Firmware Version 1.4.0
GetSurreal.com 
 
PWM pin: 3
Target RPM: ovf
Max PWM: ovf
Min PWM: ovf
PID Kp: ovf
PID Ki: ovf
PID Kd: 0.00
SampleTime: 20
Motor Enable: 1
Show Raw Data: 1
Show Dist Data: 0
Show RPM Data: 0
Show Time Interval: 0

happens with both floats and doubles.

[KurtE]

@mjs513 @pillo79 - This is strange, in that this is NOT zephyr code. This is in ArduinoCore-API print.cpp
I mucked up printFloat:

size_t Print::printFloat(double number, int digits)
{
  if (digits < 0)
    digits = 2;

  size_t n = 0;
  printk("PrintFloat(%f, %d) %f %f\n", number, digits, 4294967040.0, -4294967040.0);
  if (isnan(number)) return print("nan");
  if (isinf(number)) return print("inf");
  if (number > 4294967040.0) { printk(">\n"); return print ("ovf");}  // constant determined empirically
  if (number <-4294967040.0) { printk("<\n"); return print ("ovf");}  // constant determined empirically

  // Handle negative numbers
  if (number < 0.0)
  {
     n += print('-');
     number = -number;
  }

  // Round correctly so that print(1.999, 2) prints as "2.00"
  double rounding = 0.5;
  for (uint8_t i=0; i<digits; ++i)
    rounding /= 10.0;

  number += rounding;

  // Extract the integer part of the number and print it
  unsigned long int_part = (unsigned long)number;
  double remainder = number - (double)int_part;
  n += print(int_part);

  // Print the decimal point, but only if there are digits beyond
  if (digits > 0) {
    n += print(".");
  }

  // Extract digits from the remainder one at a time
  while (digits-- > 0)
  {
    remainder *= 10.0;
    unsigned int toPrint = (unsigned int)remainder;
    n += print(toPrint);
    remainder -= toPrint;
  }

  return n;
}

Note: I also added #include <Arduino.h> to get printk to compile...

The Arduino output to Serial shows same error:

float f = ovf
float f = 39.299999 using snprintf
double d = ovf
double d = 55.900000 using snprintf
int i = 3141

And the printk output

PrintFloat(39.299999, 2) 4294967040.000000 -4294967040.000000
>
PrintFloat(55.900000, 2) 4294967040.000000 -4294967040.000000
>

So it is bailing at: if (number > 4294967040.0) { printk(">\n"); return print ("ovf");} // constant determined empirically

[KurtE]

@iabdalkader @mjs513 ...

It appears to have a problem maybe with linker fixups, maybe using some helper functions?
If I do the comparison in the same function, it works, if it is done within a call it fails?

#ifdef ARDUINO_UNO_Q
#include <Arduino_RouterBridge.h>
#endif
void setup() {
#ifdef ARDUINO_UNO_Q
  Bridge.begin();
#endif
  Serial.begin(115200);

  delay(1000);

  float f = 39.3;
  double d = 55.9;

  printk("\n\n*******************************************************\n");
  printk("inline %f > %f? %d\n", f, 4294967040.0, (f > 4294967040.0)? 1 : 0);
  printk("inline %f > %f? %d\n", d, 4294967040.0, (d > 4294967040.0)? 1 : 0);

  print_through_function(f);
  print_through_function(d);
}

void  print_through_function(double val) {
  printk("though function %f > %f? %d\n", val, 4294967040.0, (val > 4294967040.0)? 1 : 0);
  printk("*******************************************************\n");
}

void loop() {
  delay(1000);
}

The Output shows the comparison > works properly with the inline the setup function, but not with through function.

*******************************************************
inline 39.299999 > 4294967040.000000? 0
inline 55.900000 > 4294967040.000000? 0
though function 39.299999 > 4294967040.000000? 1
*******************************************************
though function 55.900000 > 4294967040.000000? 1
*******************************************************

Maybe related to:
#453

[pillo79]

Well done @KurtE, took me a couple days to figure out the exact reason (and I did not see your post until now, would have helped!).
The __aeabi_* wrappers have a peculiar binary interface, so they must be called with delicate assembly code, otherwise the argument values will be silently corrupted by the C compiler.
Have a fix ready, will test tomorrow!

[KurtE]

@pillo79 Sounds good, I had a quick and dirty hack, that appeared to work at least in my quick tests.

kurte@KurtXPS8950:~/git/ArduinoCore-zephyr$ git diff
diff --git a/cores/arduino/llext_wrappers.c b/cores/arduino/llext_wrappers.c
index 65d72340..70290970 100644
--- a/cores/arduino/llext_wrappers.c
+++ b/cores/arduino/llext_wrappers.c
@@ -145,8 +145,10 @@ W1(float, sqrtf, float)
 W1(float, tanf, float)

 /* compiler double helper functions */
+#ifndef ARDUINO_UNO_Q
 W2(double, __aeabi_dadd, double, double)
 W2(int, __aeabi_dcmpgt, double, double)
+#endif

 /* stdio.h */
 W1(int, puts, const char *)
diff --git a/loader/llext_exports.c b/loader/llext_exports.c
index b5075247..3f2e5069 100644
--- a/loader/llext_exports.c
+++ b/loader/llext_exports.c
@@ -320,12 +320,21 @@ FORCE_EXPORT_SYM(__aeabi_ddiv);
 FORCE_EXPORT_SYM(__aeabi_dmul);
 FORCE_EXPORT_SYM(__aeabi_d2f);
 FORCE_EXPORT_SYM(__aeabi_fcmpun);
+#if defined(CONFIG_BOARD_ARDUINO_UNO_Q)
+FORCE_EXPORT_SYM(__aeabi_dadd);
+#else
 extern double __aeabi_dadd(double, double);
 EXPORT_LIBC_SYM(__aeabi_dadd);
+#endif
 FORCE_EXPORT_SYM(__aeabi_fcmple);
 FORCE_EXPORT_SYM(__aeabi_idiv);
+#if defined(CONFIG_BOARD_ARDUINO_UNO_Q)
+FORCE_EXPORT_SYM(__aeabi_dcmpgt);
+#else
 extern int __aeabi_dcmpgt(double, double);
 EXPORT_LIBC_SYM(__aeabi_dcmpgt);
+#endif
+
 FORCE_EXPORT_SYM(__aeabi_dsub);
 FORCE_EXPORT_SYM(__aeabi_i2d);
 FORCE_EXPORT_SYM(__aeabi_uidiv);
kurte@KurtXPS8950:~/git/ArduinoCore-zephyr$

That was got rid of the wrapper I think for the Q. I figured something as such.
When I found some sources online for these functions, they took a data type of float64, which I did not see anywhere.

Also wondered if differences between UNO and Portenta and Giga, is that UNO has hardware floating point (but not double) where maybe the STM32H74x does?

[pillo79]

Verified on the UNO Q - the linked PR will properly forward the __aeabi_ functions on all ARM boards. 👍

differences between UNO and Portenta and Giga, is that UNO has hardware floating point (but not double) where maybe the STM32H74x does?

Exactly - the UNO is the one that needs those calls because there is no hardware implementation for 64-bit (double, long long) maths. The issue was visible on the UNO because it relied on those, while the H7 has 64-bit hardware floating point support so the compiler translates maths directly to machine code.

[iabdalkader]

On an older branch I think I get expected output:

int i = 3141
float f = 39.30
float f = 39.299999 using snprintf
double d = 55.90
double d = 55.900000 using snprintf

  *******************************************************
  inline 39.299999 > 4294967040.000000? 0
  inline 55.900000 > 4294967040.000000? 0
  though function 39.299999 > 4294967040.000000? 0
  *******************************************************
  though function 55.900000 > 4294967040.000000? 0
  *******************************************************

main:

*******************************************************
inline 39.299999 > 4294967040.000000? 0
inline 55.900000 > 4294967040.000000? 0
though function 39.299999 > 4294967040.000000? 1
*******************************************************
though function 55.900000 > 4294967040.000000? 1
*******************************************************

So what changed? Could it have been linking to those abi functions from another source before we exported them?

[KurtE]

@iabdalkader - yep you are right, on the older branch minus that change you get the correct results.

However without those changes, if you load the example: velocity_mode for the Dynamixel2Arduino library and build it,
it completes. the builds, it does give you compiler warnings like:

d:\Arduino\libraries\Dynamixel2Arduino\src\utility\slave.cpp: In member function 'bool DYNAMIXEL::Slave::setPortProtocolVersion(float)':
d:\Arduino\libraries\Dynamixel2Arduino\src\utility\slave.cpp:93:14: warning: implicit conversion from 'float' to 'double' to match other operand of binary expression [-Wdouble-promotion]
   93 |   if(version == 2.0){
      |      ~~~~~~~~^~~~~~
d:\Arduino\libraries\Dynamixel2Arduino\src\utility\slave.cpp:95:20: warning: implicit conversion from 'float' to 'double' to match other operand of binary expression [-Wdouble-promotion]
   95 |   }else if(version == 1.0){
      |            ~~~~~~~~^~~~~~
d:\Arduino\libraries\Dynamixel2Arduino\src\Dynamixel2Arduino.cpp: In member function 'bool Dynamixel2Arduino::ping(uint8_t)':
d:\Arduino\libraries\Dynamixel2Arduino\src\Dynamixel2Arduino.cpp:175:37: warning: implicit conversion from 'float' to 'double' to match other operand of binary expression [-Wdouble-promotion]
  175 |         if(getPortProtocolVersion() == 1.0){
      |            ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
d:\Arduino\libraries\Dynamixel2Arduino\src\Dynamixel2Arduino.cpp: In member function 'bool Dynamixel2Arduino::setProtocol(uint8_t, float)':
d:\Arduino\libraries\Dynamixel2Arduino\src\Dynamixel2Arduino.cpp:235:14: warning: implicit conversion from 'float' to 'double' to match other operand of binary expression [-Wdouble-promotion]
  235 |   if(version == 1.0){
      |      ~~~~~~~~^~~~~~
d:\Arduino\libraries\Dynamixel2Arduino\src\Dynamixel2Arduino.cpp:237:20: warning: implicit conversion from 'float' to 'double' to match other operand of binary expression [-Wdouble-promotion]
  237 |   }else if(version == 2.0){
      |            ~~~~~~~~^~~~~~

There are also several ArduinoCore-zephyr library warnings as well:

In file included from D:\Arduino\hardware\arduino-git\zephyr\variants\arduino_uno_q_stm32u585xx/llext-edk/include/zephyr/include/zephyr/usb/usbd.h:20,
                 from D:\Arduino\hardware\arduino-git\zephyr\cores\arduino\usb_device_descriptor.c:10:
D:\Arduino\hardware\arduino-git\zephyr\variants\arduino_uno_q_stm32u585xx/llext-edk/include/zephyr/include/zephyr/usb/usbd_msg.h: In function 'usbd_msg_type_string':
D:\Arduino\hardware\arduino-git\zephyr\variants\arduino_uno_q_stm32u585xx/llext-edk/include/zephyr/include/zephyr/usb/usbd_msg.h:107:18: warning: comparison is always true due to limited range of data type [-Wtype-limits]
  107 |         if (type >= 0 && type < USBD_MSG_MAX_NUMBER) {
      |                  ^~
D:\Arduino\hardware\arduino-git\zephyr\cores\arduino\zephyrSerial.cpp: In member function 'virtual size_t arduino::ZephyrSerial::write(const uint8_t*, size_t)':
D:\Arduino\hardware\arduino-git\zephyr\cores\arduino\zephyrSerial.cpp:166:25: warning: comparison of unsigned expression in '< 0' is always false [-Wtype-limits]
  166 |                 if (ret < 0) {
      |                     ~~~~^~~
D:\Arduino\hardware\arduino-git\zephyr\cores\arduino\wiring_analog.cpp:59:77: warning: missing initializer for member 'adc_channel_cfg::differential' [-Wmissing-field-initializers]
   59 |         DT_FOREACH_PROP_ELEM(DT_PATH(zephyr_user), io_channels, ADC_DT_SPEC)};
      |                                                                             ^
D:\Arduino\hardware\arduino-git\zephyr\cores\arduino\wiring_analog.cpp:59:77: warning: missing initializer for member 'adc_channel_cfg::differential' [-Wmissing-field-initializers]
D:\Arduino\hardware\arduino-git\zephyr\cores\arduino\wiring_analog.cpp:59:77: warning: missing initializer for member 'adc_channel_cfg::differential' [-Wmissing-field-initializers]
D:\Arduino\hardware\arduino-git\zephyr\cores\arduino\wiring_analog.cpp:59:77: warning: missing initializer for member 'adc_channel_cfg::differential' [-Wmissing-field-initializers]
D:\Arduino\hardware\arduino-git\zephyr\cores\arduino\wiring_analog.cpp:59:77: warning: missing initializer for member 'adc_channel_cfg::differential' [-Wmissing-field-initializers]
D:\Arduino\hardware\arduino-git\zephyr\cores\arduino\wiring_analog.cpp:59:77: warning: missing initializer for member 'adc_channel_cfg::differential' [-Wmissing-field-initializers]
"C:\\Users\\kurte\\AppData\\Local\\Arduino15\\packages\\zephyr\\tools\\arm-zephyr-eabi\\0.16.8/bin/arm-zephyr-eabi-ar" rcs "C:\\Users\\kurte\\AppData\\Local\\arduino\\sketches\\6D18A50E49

But that is a different subject...

However when this sketch then loads, you will find out it won't run. In the Zephyr monitor window (Serial1),

*** Booting Zephyr OS build v4.2.0-48-g9d6762627f45 ***
*** Booting Zephyr OS build v4.2.0-48-g9d6762627f45 ***
[00:00:00.220,000] <err> elf: sym '__aeabi_dadd': relocation out of range (0x20009b22 -> 0x8000299)

[00:00:00.229,000] <err> llext: Failed to link, ret -8
Failed to load sketch, rc -8

I know that @mjs513 also had similar sketches that would fail to link as well.

But short answer is yes we should undo my fix as well it allowed the sketch to load, these functions did not work properly.

Or better yet use - @pillo79 fix and/or find ways to insure that we don't relocation out of range errors.

[pillo79]

So what changed? Could it have been linking to those abi functions from another source before we exported them?

@iabdalkader it's simpler - to fix the reloc-out-of-range a wrapper was added by Kurt before 0.55, but those RTABI functions pass arguments in r0-r3 and the C wrappers were clobbering the data. This all goes away with your reloc support, but for the moment we need the fix in #479.

[iabdalkader]

@pillo79 Yeah I gathered that, summarized everything here: #479 (comment)

It's just that I can no longer reproduce any of the issues reported, with @KurtE's fix removed. Not the old issues, not even the one reported above with Dynamixel2Arduino. I tried 3 examples from that library and I don't get any warnings, and all of them load fine.

That said, I still approved your fix.

[iabdalkader]

@KurtE You're right, velocity_mode does fail:

[00:00:00.219,000] <err> elf: sym '__aeabi_dadd': relocation out of range (0x20009ae6 -> 0x8000299)

[00:00:00.229,000] <err> llext: Failed to link, ret -8
Failed to load sketch, rc -8