Skip to content

Serial.print as HEX should ALWAYS print 2 chars per byte; it omits leading zeroes [imported] #40

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
cmaglie opened this issue Nov 15, 2012 · 11 comments
Assignees

Comments

@cmaglie
Copy link
Member

cmaglie commented Nov 15, 2012

This is Issue 1097 moved from a Google Code project.
Added by 2012-11-05T10:22:49.000Z by [email protected].
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Medium

Original description

What steps will reproduce the problem?
1.If byte or integer variables are printed with serial.print or serial.println with the HEX output format option leading zeroes are not printed:
byte reading5 = 0x0F;
byte reading6 = 0x00;
byte reading7 = 0xF0;
.............
Serial.print("reading5 = ");
Serial.println(reading5, HEX);
Serial.print("reading6 = ");
Serial.println(reading6, HEX);
Serial.print("reading7 = ");
Serial.println(reading7, HEX);


and the result is:
reading5 = F
reading6 = 0
reading7 = F0

What is the expected output? What do you see instead?

The output for HEX should always be one char per nibble; leading zeroes matter. With the data above, calling:
Serial.print("0x");
Serial.print(reading5, HEX);
Serial.print(reading6, HEX);
Serial.println(reading7, HEX);

yields 0xF0FO where it should display 0x0F00FO; the value is totally changed by omission of the leading zero.

What version of the Arduino software are you using? On what operating
system? Which Arduino board are you using?
Arduino 1.0.1, WinXP (current, fully updated), Duemilinove

Please provide any additional information below.

Same behaviour with Arduino 1.0 and using the Arduino serial monitor or SecureCRT interface.

I can't think of any reason to omit leading zeroes when using the HEX format. In cases like this, where a sequence of bytes is read from a device that represents a multi-byte return value, and you want to see the real value returned it gives incorrect results. One could assemble the bytes into a LONG and then call the function, but I think that most who use the HEX format would like to see all their nibble values with any size data. The examples in the Arduino reference sidestep the issue by not showing any example with a leading zero ;-)
http://arduino.cc/en/Serial/Print

@technikadonis
Copy link

Very important to solve this. Should not be dificult!
Fix it please

@darrylp1per
Copy link

the thread on http://forum.arduino.cc//index.php?topic=179111.0 has some idears for this call

in particular, the changes I listed here
http://forum.arduino.cc//index.php?topic=179111.msg1385295#msg1385295

based on my altered code found last posted here
http://forum.arduino.cc//index.php?topic=179111.msg1334253#msg1334253

gives you the insight to a working solution, that fits in easily.

@fake-name
Copy link

Jesus christ, how has this issue been open for four years?

@cmaglie
Copy link
Member Author

cmaglie commented Mar 21, 2017

Changing the default behaviour of Print(..., HEX) is a backward incompatible change, it will suddenly break all existing sketches that relies on the current behaviour of Print (i.e. to print just the HEX value without leading zeros). Just this argument is enough to mark this issue as wont-fix.

Moreover, printing the leading zeros may be good for some kind of applications but not for others... what if I really want to print just the single hex number without the leading zero?

@fake-name
Copy link

Printing a hex byte without the leading zero doesn't even make sense.

If you want that, you want a print nybble function.

At minimum, there needs to be a way to format hex data in the correct manner, right now we're stuck with an intermediate snprintf().

@clivepengelly
Copy link

Been tearing my hair out with this. Thinking that something is wrong with my code, but it's the hex formatting.

@Tijgerd
Copy link

Tijgerd commented Sep 21, 2017

if HEX is an ENUM
can't they just ad: HEX_LEADINGZERO to the enum and make every call to Serial.print(hexVal,HEX_LEADINGZERO) return a HEX format with leading zero...?

@Tijgerd
Copy link

Tijgerd commented Sep 22, 2017

@macsimski
Copy link

Hi, Macsimski here from the future. stumbled upon this bug while getting unexpected results from my sketch, and YES, it is a bug. if previous sketches break because of the fix for this bug, so be it.

The behavior now is inconsistent and i vote for it to be resolved to always print at least two ascii chars for one byte.

@Tijgerd
Copy link

Tijgerd commented Jul 3, 2019

@macsimski 1,5 years ago I made a backward compatible bug fix arduino/Arduino#6750 but still no-one did anything.
They say the Serial.print() should be a simple and easy-to-use function..
But in my opinion, a HEX value printed in an environment targeting micro controllers should always print a multiple of two ASCII chars (as you said).

only downside; after 1,5 years my original pull-request isn't matching the current branch of Arduino anymore :(

@JimDrewGH
Copy link

JimDrewGH commented Jul 5, 2020

A HEX byte is always represented as two ASCII characters. Whoever maintains this code should use Wiki, Google, Yahoo, or perhaps jump into a time machine to see that this has been the case for more than 50 years. This needs to be fixed, even if you have to make some #DEFINE CORRECT_HEX to achieve it.

When the upper nybble of a HEX byte has a value <=9 then that has to be output as a "0". Otherwise a string of HEX bytes like 0A0A0A0A will be output as AAAA, and that is clearly wrong. The work around of comparing the value of the byte to be <=9 and outputting a "0" manually before the (value, HEX) is annoying and should not be something that needs to be done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants