Philip Martin wrote: > For the maths, I know that if I take a distance of say 60 yards and divide > that by 1760 and then multiply it by 1000 it will give me a nice fixed value > of 34 (D). But then I need to take my timing and divide that by 3600 (or 3.6 > thus ignoring the need to then multiply by 1000) to create a value that will > then be divided into the D value. This will give me the resultant average > speed in MPH. > > I've looked at the list FAQ's and Microchips AN's for maths routines but! Is > this 16 or 32 bit maths, and how do I cope with the decimal places? Is this > even possible in a PIC? > > Any help or guidance would be most appreciated as I seem to have gone brain > dead on this one. This may help you understand, or seeing as how I'm not a math wizard, it may confuse you more ;-) 3.6 in decimal = 3 units + 6 tenths of that unit. In hexadecimal, ala PIC world, the units are either bytes/words or larger. 3 fits in a byte nicely, but 0.6 does not. In decimal terms, 0.6 = 6 / 10 In byte terms, 0.6 is saying 6 tenths of a byte Mathematically this would be... 6 X 256 ------- = 153.6 or 99h 10 Thus we can represent 3.6 decimal as 03.99 in hexadecimal. The PIC will not understand 03.99 in hex so the whole value must be made to fit into bytes or words. In this case multiply the entire value by 256. 03.99h X FFh = 0399h High Byte = 03h Low Byte = 99h Now you have a value to work with inside the PIC and you can operate on it any way you like. You also know that the least significant byte of any result is the value after the decimal point. It would be easy to do a BCD conversion on 03h, then a decimal place, then BCD 99h The display would then read 3.15 (ignoring the last digit 153) Ahh, but this is wrong, it should read 3.6 The reason is the value after the decimal place is actually a fraction of a byte value. To convert back to a decimal value, transpose the above formula 99h X 10dec ------------ 256 Or simpler, just do 99h X 10dec and use the high byte of the word result. The result however will be 5, not 6 as we would have liked. The reason is that the 'real' value 153.6 from above was truncated to 153 (99h). Thus there is a small error. The result above is in the low nibble of the high word. You can reduce the error slightly by using a larger conversion number. 99h X 100dec The result in this case will be 3Bh or 60dec in the high word. We know this is a fraction with 1/10ths and 1/100ths so we can display it as such. Now after BCD conversion your display will read 3.60 Also, as you are working with constant values, why not divide them down into simpler terms. Eg 3600 18 ---- = -- 1000 5 Much easier to work with. Try to work out the total math on paper and solve for the final value. Then see if the formula can be simplified, and use that in your code. -- Best regards Tony mICro's http://www.picnpoke.com mailto:sales@picnpoke.com -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics