Brian:
Are you actually in the need to handle the whole range of the input parameter over the 24 bits? At .000001 meter/LSB across 24 bits corresponds to a length of 660.5203 inches. If this is the case then you will not directly be able to use the umul16 routine I mentioned to you before in my earlier post to this thread. Conceptually you can still use the concept of:

     SenRead * 100
     -------------
          254

to compute a value that has 4 implied decimal digits like I described before. The trick however will be to get the 24-bit sensor reading multiplied by 100 into a 32-bit value that you can put as one input to the udiv32 routine. Here is my suggestion to solve that problem, (rather than having to write a new multiply routine).

Rewrite the above to:

     SenRead * 100 * 2.56
     ---------------------
            254 * 2.56

This simplifies to:

     SenRead * 256
     -------------
          650.24

Now you can just take the 24-bit sensor reading and left align it into the upper 3 bytes of a 32-bit value and set the low byte to zero (this is equivalent to multiplying by 256). Then as before this 32 bit value can be passed directly to udiv32 with a divisor of 650. The resulting quotent will be your display value, albeit still in binary that you can convert with the chain of divides as I indicated before.

I am going to have to leave it to you to decide if dropping the 0.24 off the divisor leads to too much error in the calculation. The 0.24 of the divisor being left off has the effect of making the converted result being slightly larger than it should be. With a full count from the sensor at all 1's (24-bits of 1's) for a max reading, when it is converted with this modified process it leads to a reading of 660.7641 inches instead of 660.5203 with the original formula. This is an error of 0.0369% which is greater than the 0.01% or less I am sure that you would like your readout with 4 decimal places to represent.

Another technique you could try that allows you to still use the first *100 /254 formula would be to convert the 24-bit reading into a *100 value as follows.

  - Copy reading to 32-bit variable "sensor"
  - Copy sensor to 32-bit variable "temp"
  - Shift sensor left 1 bit  (*2 value)
  - Shift sensor left 1 bit  (*4 value)
  - Add temp to sensor       (*5 value)
  - Shift sensor left 1 bit  (*10 value)
  - Copy *10 sensor to temp variable
  - Shift sensor left 1 bit  (*20 value)
  - Shift sensor left 1 bit  (*40 value)
  - Add temp to sensor       (*50 value)
  - Shift sensor left 1 bit  (*100 value)

This leaves you with the 32-bit sensor*100 value which you can now pass to the udiv32 routine as the dividend. This permits the divisor to be 254 again and you won't introduce the small error as the "easier" approach above causes.

Hope this can make your life a little easier.
Mike Karas