Binary vs. Hex in in source

[ledtester]

In some cases it makes sense to represent constants in octal.

And, in fact, you are using octal every time you type the literal 0 in C 

And 1 through 7

[ataradov]

And 1 through 7

Only if you type 01-07.

The point of that "fun fact" is that octal constants start with 0, which 0 itself does.

[gnuarm]

I've been wondering for a while why most programmers use hexadecimal in their source code when representing a register mapping or something similar where you need to convert back to binary to have any idea of what the line of code is doing (or have to re-convert when making a modification), such as when an IC uses each bit for a different function. I tend to just type out the binary representation instead (0b00101000 vs. 0x40).

Is there an advantage in using hexadecimal or is this just a learned habit?

0b01001010010100000100010101000111  -- what the heck is that?

0x4a504547 -- most experienced programmers will immediately recognize this is 4 uppercase ASCII characters

At least with C++14 you can write the binary literal as 0b0100'1010'0101'0000'0100'0101'0100'0111 which helps a little, but this isn't accepted by C, even with gnu extensions.

You have to wonder who thought apostrophes were a good idea for digit separators???  I code in Forth and VHDL.  VHDL uses underscores for this which is much more clear 0100_1101.  I have to tame Forth into working with underscores, but Forth will do anything you ask it to do.  You don't even need to ask nicely, you just need to let it know you mean business.
It's very hard to understand exactly which bit numbers are set in a long binary number without laboriously counting them. You might get away with it for an 8 bit number, but it's brutal for a 16 or 32 bit value.

[gnuarm]

Hex is easier to read and successfully write. Strings of 0s and 1s mean nothing.

"I want to set bits 1, 2 and 5", 0b00010011 or 0x13, for me it's the binary that's faster and clearer both to read and write.  But I've never been good at hex conversion in my head.

Equally "which bits are set by 0x44", requires either considerable brain cycles (or finding the calculator), while "which bits are set by 0b01000100" requires zero brain cycles because that's the answer already.

As others say though once you get past 8 bits then binary representation can get very unwieldy, humans are good with groups of between 7 to 10 things maximum, bits in this case, more than that and we lose track easily.

Maybe I'm unusual, but I do all manner of math in my head.  I don't have any trouble deciphering 0x44 as bits 6 and 2 set (0 based).  I can see it clearly.  It's the naming the bits as 6 and 2 I might have a bit of trouble with immediately.  Octal is also easy. 

Most of this discussion has been about C which I don't use.  In most languages hex works fine because the variable sizes are all multiples of 4 bits.  In VHDL you can't assign a 12 bit literal to a 10 bit signal or variable.  So you need to either use binary, or they did recently (2008) extend the language to have variable length literals, 10x"11A", but not all tools support every 2008 feature... yes, even 12 years later.

[SiliconWizard]

In VHDL you can't assign a 12 bit literal to a 10 bit signal or variable.  So you need to either use binary, or they did recently (2008) extend the language to have variable length literals, 10x"11A", but not all tools support every 2008 feature... yes, even 12 years later.

But VHDL, like ADA, supports underscores in numeric literals, and has for a long time, so as we said above, that helps. But underscores are not supported in ALL types of lterals, so that can be confusing.

For instance, they are for integer literals. For instance (for your example):
2#01_0001_1010#

They also are for bit vectors:
B"01_0001_1010"

Oddly, underscores are not supported for std_logic_vector, and that's probably why it's rarely seen in VHDL code, as many people tend to use std_logic_vector everywhere even when using other types would make more sense.

Note that the "&" operator in VHDL alleviates all this, if you don't have access to tools that support recent enough versions of VHDL. You can absolutely use it in literals.
That would be here:
"01" & "0001" & "1010", which is easier to read.

You can then combine bases too:
"01" & x"1A" works too.

Finally, if your constants are really decimal integers but you need to set std_logic_vector, using conversion functions is a lot easier to write, maintain and read (it's unfortunate IMHO that we still see engineers manually converting decimal to binary whereas the compiler can do it for you):
std_logic_vector(to_unsigned(282, 10))

You can always define a function for this if you find it cumbersome to type:

Code: [Select]

function Dec2SLV10(n : integer) return std_logic_vector is
begin
    return std_logic_vector(to_unsigned(n, 10));
end Dec2SLV10;

Many ways to skin a cat.

[Simon]

Baring in mind that I only write in C in Atmel studio. I always get the urge to write in binary when setting up a register so that you can look back at the datasheet and see quickly what it does. But now that I look to ARM 32 binary bits is fraught with trouble and you generally only want to set a few bits so then it makes sense to bit shift the few bit's required and binary can work well. I have never made any effort though to memorize hex.

I have often wanted a way of showing bit's in groups but the only way is to create a ton of macro's and even at 32 bit's it still get's hard. I suppose a space every 4 with a double space on every 8? ever 8 bits in a row is hard to read but if you do 4 bit splits it gets hard.

[PlainName]

so that you can look back at the datasheet and see quickly what it does

That's one of the problems with using magic bits - the code is meaningless without the datasheet, and often even with the datasheet you're looking at several pages to resolve what a register's bits do.

With macros you sure can fill up a header with them, yes. But the thing is you only need to check them once - after that you know what they are meant to do, and that they are the right ones. The only reason to look at the datasheet is to check that what it does is the function you want, not to keep reminding yourself of which bits to flip every time you come across an operation in your code.

[Simon]

This is why I spend several hours creating macro code full of comments that tell the future me how to set stuff up and give bits and register addresses meaningful names.

[PlainName]

The annoying thing is having done that for some new chip you find you only actually write to a couple of registers in the end. But good typing practice, anyway

[Simon]

Well it's work through the peripherals as you need them. Write the code for the configurations you need.

[PlainName]

I used to do 'em as I needed them, but found that some time later I would need something that wasn't there and the temptation to do a quick hack was very high. Plus it would mean getting the datasheets out and trying to remember what the naming scheme was the first time round, etc. Just less aggro later on to do it all in one go. And, after all, practice makes perfect

[Simon]

well as I am writing the macros for getting the whole thing to work in one mode I generally cover most of it and it's quicker to add what is missing as there is so much work already done.

[Siwastaja]

so that you can look back at the datasheet and see quickly what it does

That's one of the problems with using magic bits - the code is meaningless without the datasheet, and often even with the datasheet you're looking at several pages to resolve what a register's bits do.

With macros you sure can fill up a header with them, yes. But the thing is you only need to check them once - after that you know what they are meant to do, and that they are the right ones. The only reason to look at the datasheet is to check that what it does is the function you want, not to keep reminding yourself of which bits to flip every time you come across an operation in your code.

As I have explained in https://www.eevblog.com/forum/microcontrollers/migrating-from-avr-to-stm32/msg3441132/#msg3441132 , I have basically "given up" the idea that you could write, read and understand peripheral configuration register accesses just from the code alone. Definitely neither magic bit values, nor MACROS_WITH_THE_DATASHEET_ACRONYM do the job. You can come up with better macro names but then you have added another layer of naming to keep track of, and does it solve the problem, can you describe the bits and all their effects in just A_FEW_WORDS?

A long comment explaining what is done and why is the best (how? is trivial: by setting the bits as explained in the manual). In any case, whoever works with that code will need to work together with the manual, with the page(s) containing the register description open at very least, likely they need to look at the peripheral functional description as well.

[Simon]

Yea, I often copy datasheet text to the comments and reference the datasheet sections. The pain with writing to registers without renaming is finding the relevant bit in the datasheet but if you include the datasheet paragraph number you can navigate to it very quickly and re-educate yourself.

[Ian.M]

... as long as you also know the datasheet *VERSION*.   Page and paragraph numbers can move around when the IC manufacturer revises the datasheet. 

Does anyone know of an IDE that's capable of hotlinking a specific location in a document (not a source filetype) from a human readable reference in a source comment?

[Berni]

Yeah that is sort of an unsolved problem.

But i think as long as you use the same name of the C macro as the datasheet names the register it is good enough. You can just Ctrl+F the register in the datasheet, or most datasheets have register descriptions in a certain section in the table of contents. The names in there are also typically short enough to use. In case of overly short names that basically tell you nothing, then i like to add comments next to the macro definition with the full long name.

If you are doing any serious work on hardware driver code then you most likely have the datasheet already open anyway. So i don't see it as much of an inconvenience to look up the register documentation in there.

But i do admit that i love the help system in VisualStudio where i can just leave my cursor on the name of a function, press F1 and have the browser pop up with documentation on that function. If pressing F1 inside a hardware register name would open a datasheet on the right page that would be awesome (but i have never seen that one yet).

[Siwastaja]

... as long as you also know the datasheet *VERSION*.   Page and paragraph numbers can move around when the IC manufacturer revises the datasheet. 

ST does never update documentation. The only exception is when they decide to deprecate a brand-new product without warning without having to keep up with the promises of selling the part for 10 years, then they just erase all hints of the parts ever existing and reuse the complete part number for the new, incompatible part. Only in this case, documentation is changed. But this doesn't happen too often, thank god, so usually it's the same old documentation for the whole product life cycle.

The downside is, the documentation does not match the device behavior. It's written based on original pre-implementation planning, not how the device actually turned out, so mistakes are common and sometimes very significant. No matter how wrong, it's just never corrected. If you are lucky, they add an update to a separate "errata" sheet.

But you just found out an upside to all this: you can refer to it easily! That's definitely a bright side, you can explain in your documentation how the thing described on page 1234 is completely wrong and actually works in way xyz, and anyone can easily find page 1234.

[PlainName]

As I have explained in https://www.eevblog.com/forum/microcontrollers/migrating-from-avr-to-stm32/msg3441132/#msg3441132 ,

As I noted earlier, your specific circumstances my dictate otherwise. However, in principal I think the macro approach is being a scapegoat in your comments there.

For example, you say that you don't like the long and barely different names that produce walls of characters, and you're not alone! This is why I tend not to have such long or unwieldy macro (or function!) names. However, you do realise that if you have a number of macros being used like that you can combine them?

Code: [Select]

#define PERIPH_X_SETTING  (PERIPHERAL_X_CONFIG_REG_ASDFG | PERIPHERAL_X_CONFIG_REG_QWER | PERIPHERAL_X_CONFIG_REG_XYZ);

...

PERIPHERAL_X_CONFIG_REG = PERIPH_X_SETTING;
And, of course, using macros doesn't in any way prevent your from also dropping in appropriate comments. In fact, in this example you might have the comments with the macro definition so they don't break up the code later on.

Next, and I am not sure if this is a joke or not, you say that "a small one-letter mistake easily sneaks in and is hard to find". Actually, it might be very easy to find when the compiler throws a wobbly, but consider that a 1 or 0 mistake will likely not be found until your actual hardware doesn't do what it's meant to, which could be a looooong way down the line. Clearly, the answer here is not to junk macros completely but to choose names appropriately.

[BitsnBytes]

It's not just a habit it has obvious benefits. It is easy to type, less prone to human errors.

Biggest advantage that I think is, if two developers are talking it is much convenient to talk in HEX rather than binary 

[Simon]

But a 32 bit value in hex is still a mind boggling quantity unless it's something easy like all "F"'s in certain locations or "0"'s