Converting BCD(mm) to BCD(inch)[SOLVED]

[Nominal Animal]

Metric systems are not needed for feed rate control and mark setting. Millimeters and inches are an option for displaying information, and are not suitable for controlling iron.
What you really need is a fractional binary number (an unsigned fixed-point integer). By the way, rounding in such calculations is always obtained naturally - approximation to zero. The error does not accumulate!!!

This is a common misunderstanding, related to the error in the difference of two measurements.  If we use A and B for the readings, C for the difference, and a and b for the error in each measurement, then
    C = (B + b) - (A + a) = B - A + (b - a)

The misunderstanding comes from the mistaken belief that (b - a) means the errors will cancel out and not accumulate when rounding towards zero, i.e. 0≤a<1, 0≤b<1.  Yet, this is no more true or false than for any other consistent rounding scheme (i.e, -0.5<a≤+0.5, -0.5<b≤+0.5).

The actual maximum error in C is obtained by considering the extreme cases of (b - a).

For rounding towards zero, these are when (b is almost one, a is zero) and (b is zero, a is almost one): -1 < b-a < +1.

For standard rounding, halfway up, they are when (b is almost half, a is negative half) and (b is negative half, a is almost half): -1 < b-a < +1.

Thus, as long as you use your rounding method consistently, the error in your measurements will stay the same.  If you expand the same examination to multiple measurements, you will find that the error bounds evolve the exact same way, too.

However, when we do mapping, proper selection of the rounding method to be used is crucial.  The best example of this is calculating a specific number in the Fibonacci series via rounding: \$F_n = \left\lfloor \frac{\varphi^n}{\sqrt{5}}\right\rceil, \quad n \ge 0, \quad \varphi = \frac{1 + \sqrt{5}}{2}\$.)

In the case here, conversion from hundredths-of-a-millimeter (or equivalently tens-of-micrometers) to even-ten-thousandths-of-an-inch (or equivalently five-thousandths-of-an-inch) is only bijective when rounding halfway up.

[DavidAlfa]

At this point, the code is rough, linear, and lengthy.  I will be using indirect addressing or a macro to avoid all the clutter from repeated sequences for each byte.

Looks perfectly fine? Why that obsession of optimizing something that doesn't need it?
I would understand this if it was the Voyager being updated at billion miles away, it's so far away that it can only do 16 bits per second!
But this, you'll get the mcu program done, close the device and forget about it, optimized or not.

[jpanhalt]

It's not an obsession.  I just enjoy the challenge and have no deadlines in the Winter.  I have to effectively stop coding come April -- my 20 acre hobby keeps me busy. 

[DavidAlfa]

Understood, then I completely agree, for the fun! 
I missinterpreted the reason, its common to see things like "My code uses 20KB please help!" to later see he has 100KB+ free but he still thinks we're in 1980... It's there to be used!

[jpanhalt]

Just a final note.  I have attached alternative code using indirect addressing (FSR0 andFSR1).

Statistics based on a single test number, 56795 (567.95 mm):
Full FSR (this code)
Total Tcy: 215
Math Tcy: 43
Total instructions: 32 + 15 (+ table = 150, i.e., 10x15) = 197

Linear (no FSR)
Total Tcy: 144
Math Tcy: 28
Total instructions:  55+ 28 (+ table = 150) = 233

EDIT:  Delete  the -303 (an out of range message) and the comment about using db rather that dt or dtm.

EDIT2:I just noticed a bit of sloppy code that the assembler fixed.  It is in the section where FSR0 is reading the table.  The current line reads, " addfsr    -10"  The assembler used the default FSR0 register, which happens to be correct.  The correct line should be:  "addfsr    0,-10"   The current attachment has been fixed.