It will definitely involve 16-bit numbers, even 32-bit numbers. The real problem then is the DIVISION of 32-bit and 16-bit numbers by 16-bit numbers.

If you are using a cross-compiler and writing in C, there won't be a problem since everything will be handled internally....but if u do it in assembly, you will have to write algorithms for multi-byte division.

There is sample code available for that, but if you like the challenge, you can try and write it yourself :))

the trick is to divide and conquer. Here's how I did it:
->wrote a subroutine for 16/8 bit divide using 8/8 bit divide iteratively [ express the 16-bit number as:
hi-byte*(255 + 1) + lo-byte
= hi-byte* 255 + hi-byte + lo-byte
dividing by 8-bit divisor:
hi-byte*(255/divisor)+(hi-byte/divisor)+ (lo-byte/divisor)
Add all quoients and remainders, substitute (recursively)16-bit quotient into dividend and execute again until quotient becomes 0.]

->used 16/8 bit subroutine iteratively for 16/16 bit divide

->used 16/16 bit divide iteratively for 32/16 bit divide

I think it's called bootstrapping. It's actually much more complicated than that... :D

Another alternative is to use the timer to provide a timebase of 40 msec or higher,so that the final count you get is in a manageable 8-bit form and then use a look-up table (e.g. 0.1Hz @ 40 msec pulses = 250 counts)but accuracy is very limited, quite non-linear and 0 Hz can only be detected after an overflow. You could use look-up tables for 16-bit numbers too, but, as fast as that is,it could be highly tedious and memory-consuming. If you want, you can write a C program that automatically generates an asm file containing the look-up table (I've done it once).

The optimum solution will depend on what you requirements are in terms of accuracy and resolution...Without clearly defining those, you cannot even decide what frequency crystal to use

Kundi