MOD5213 iprintf() error for UL and ULL types?

[TomNB]

Since this thread was originally asking about the 5213, I would also like to note that there are different tool branches for different products. This is valid as of March 2020.

The 3.x branch is only for 5441x based devices (MOD5441x, SB800EX, NANO54415) and ARM devices (MODM7AE70). It has been out about a year and a half. It is IPv4/v6 dual stack. There is no relationship to this release and the 5213 non-network code set or tools.

The 2.9.x branch is the IPv4/v6 dual stack for 5441x based devices and all other non-ARM products

The 2.7.x branch is the IPv4 only stack for 5441x based devices and all other non-ARM products. We recommend customers use the 2.9.x branch for these products. If you want IPv4 only, you can just ignore the IPv6 functionality. There is no penalty is performance, and no extra coding in your application.

Some additional points:
1. If you are an existing customer and want to update from the 2.7.x branch or 2.8.x branch, we recommend 2.9.x. Updating to 3.x will require some code changes because the configuration system is different, among other things.

2. If you using an ARM product, you must use the 3.x branch.

[KE5FX]

Sorry, PEBKAC on that one. I looked at your example and saw that you were using %lld while I was using %Ld. avr-gcc works with %Ld, and this code was being reused from an old AVR project. The weirdness goes away with %lld. Thanks for the hint!

I've gotten too accustomed to GCC warning me about mismatches between format specifiers and the types actually being passed. This case fell through their cracks for some reason.

(I'm definitely using the right toolchain, this is just the thread that happened to crop up when I Googled the issue.)

[TomNB]

Thanks for the update and glad to hear its working for you. I knew you were using the right tool chain, just wanted to post that for anyone else reading the thread. Have a great weekend.

[joepasquariello]

KE5FX, according to the link below, the length specifier "L" (capital) is for long double only. For 64-bit (long long) integers, use "ll" and "ull".

Joe

https://en.cppreference.com/w/cpp/io/c/fprintf

[KE5FX]

Yeah my guess is that the legacy AVR code was relying only on the less-significant bytes to get printed.

You have to wonder what made the C implementers think it was a good idea for a language designed for hardware abstraction to use types like "int," "long," long long," rather than typenames with explicit bit widths baked in...

[joepasquariello]

Well, to be fair, it was designed 50 years ago, so they were on to something. Before C there was B, which was short for BCPL, so the next language just had to be called C. These were no-nonsense people, obviously. Now we have ... Python?

[KE5FX]

Well, to be fair, it was designed 50 years ago, so they were on to^H^H something.

There, fixed it.

[KE5FX]

One more issue with printf() that actually does appear to be a real bug (no pun intended):

Code: Select all

   printf("%g\n",4.25332E-14);
   printf("%G\n",4.25332E-14);
   printf("%g\n",4.25332);
   printf("%G\n",4.25332);
   printf("%g\n",-4.25332E-14);
   printf("%G\n",-4.25332E-14);
   printf("%g\n",-4.25332);
   printf("%G\n",-4.25332);

Expected result:

Code: Select all

4.25332e-14
4.25332E-14
4.25332
4.25332
-4.25332e-14
-4.25332E-14
-4.25332
-4.25332

Result on MODM7AE70 with NNDK 3.2 is:

Code: Select all

4.25332e-14
4.25332E-14
4.25332

-4.25332e-14
-4.25332E-14
-4.25332
-

I first noticed this with snprintf(), so it seems to affect the entire family of functions. Working around it for now by using the lowercase %g specifier, so not urgent, just FYI.

[pbreed]

You have an Ld
if should be an ld.

L is the format character for a Long Double IE 128bit floating point value.
Which the NetBurner printf does not support.

for longs (32bit)
ld lu lx lX

are the correct format chars.

for 64 bit values

llu lld llx llX

[KE5FX]

This is a different question -- sorry, I should've probably started a new thread for it. The %G specifier is definitely broken. Please see the message right above your reply.