Explanation

using '/' and '%' it could be much more efficient.

anyhow as to the OP's question, I totally agree with Al

Erik

using '/' and '%' it could be much more efficient.

anyhow as to the OP's question, I totally agree with Al

Erik

"using '/' and '%' it could be much more efficient."

Not always. It depends on processor support for integer division - still lacking in some new processors.

Ok.. i did a small study on th eoperators and here is what i understood. I also tried to do an example s.. see bottom... But i am getting wrong result. Can anyone help??

u16 WORDToBCD3(u16 value)
{
u16 bcdhigh = 0;// initializing bcdhigh as zero
while (value >= 100) //Checking if it is a 3 digit number
{
bcdhigh++;//If it is a 3 digit number , then value of bcdhigh is incremented i.e now it is = 1
value -= 100; // The variable value has now new content which is value - 100
}
bcdhigh <<= 4; // means Bitwise left shift assignment. It shift bcdhigh left by 4 bits

while (value >= 10) // Checking if it is a 2 digit number
{
bcdhigh++;//value of bcdhigh is incremented
value -= 10;// means value = value - 10
}
return (bcdhigh << 4) | value; // it returns the value  of (Bitwise left shift i.e all bits in bcdhigh

shifted left by 4 bits) OR each bit in value
}

Example lets take value = 102
then while (102 >= 100)
bcdhigh= 1 ( in binary 1)
value = 102 -100 i.e 2 ( in binary 0010)
bcdhigh <<= 4; means 10000

returning value = 10000 OR 0010 which gives a binary value of 0b10011100011000 ( decimal equivalent = 10008) ????

Am i wrong somewhere???

Am i wrong somewhere???

yes, get a 'C' book and study it.

This is about as elementary as it can get

Erik

Some suggestions here: blog.antronics.co.uk/.../

so you have the value 102.
While it is >= 100, the code should increment (add 1) to the BCD number, and strip 100 from the number.

So 102 -> 2.
And BCD number 0->1 (binary 1)

Then it's time to try the "ten" digit.
<<= 4 means shift left four steps.
So the BCD number 1 * 16 = 16 (binary 10000).

Next repeat while the number is >= 10.
2 < 10, so nothing to do.

Then it's time to processed the "one" digit.
<<= 4 once again means shift left four steps.
So the BCD number 16 * 16 (binary 10000 << 4) = 256 (binary 100000000).

Now the code could have iterated while the reminder of the number was larger than zero. But no need to.

The reminder is 2 - binary 10.

So combine the already accumulated BCD number (256 dec or 100000000 bin) with the value 2 dec or 10 bin.

256 bit-or 2 is same as 100000000 bin bit-or 10 which is 100000010 which is 258.

258 decimal (or 100000010 binary) is the same as 102 hexa-decimal. So now we have the same digits but in a hexadecimal number, as we originally had in a decimal number. That's exactly what we would have expected when converting the number into BCD format, i.e. binary coded decimal - one decimal digit stored per nibble (half-byte).

>binary coded decimal - one decimal digit stored per nibble (half-byte).

Should be referenced as
BCD numbers normally occupy one byte per decimal digit.
packed BCD numbers use half byte or nibble for a decimal digit and in a byte are stored two decimal digits.

en.wikipedia.org/.../Binary-coded_decimal
academic.evergreen.edu/.../bcd.htm

This process of representation of a value to the binary system is called encoding.
So, the actual value of a byte(8bits) or a word(16bits) varies along with the encoding used to store the information.

Thank you all.. especially Westermark reply helped me a lot to undertand it very clearly..