I want to calculate T=1/f.

But how can I devide 1/f?

This will be very small numbers when f gets greater.

Difficult?

:roll:

Author

Message

I want to calculate T=1/f.

But how can I devide 1/f?

This will be very small numbers when f gets greater.

Difficult?

:roll:

-Will

But how can I devide 1/f?

This will be very small numbers when f gets greater.

Difficult?:roll:

I bet you would have a better chance of getting a response if you included even the slightest detail of the problem you are trying to solve.

I use a calculator to figure out 1 / anything. It's not difficult at all.

I want to enter a frequency and have this frequency at a pin, so I though to calculate T (period time), because when I have T, well better to have T/2, I can simply switch the pin every half period time to get f at it.

RoBSki!,Divide 1000000000 by your frequency to get the period in nanoseconds.

Or, 1000000 by your frequency to get the microseconds. Or 1000 for the milliseconds...

1.000.000.000 / 4.000 = 250.000 nsec. :P

Yes Girogos_K, good idea, but one billion takes 30bits of data, thus four registers.

Well ok, lets try this.

Thanks.

8)

Last Edited: Mon. Dec 5, 2005 - 07:33 PM

Quote:Yes Girogos_K, good idea, but one billion takes 30bits of data, thus four registers.Yes RoBSki!, you are correct. So, there is also a need for an unsigned 32-by-32 bit division, that costs about 550 clock cycles only.

The alternative, a floating point division -or even a fixed point one-, needs lots of more CPU power and time, and some serious skills to implement.What is your choice?

550ck? It's ok, at 20MHz it takes 27.5usec.

I try 32-by-32 bit division.

8)

Hello,

Do you really need the time in S? If you are putting the frequency out, you don't need T. You will probably be using a timer or something, which you will be calculating a timer load value.

Do all the constant multiplication beforehand you probably won't need any sort of floating point.

-Colin

Do you really need the time in S? If you are putting the frequency out, you don't need T. You will probably be using a timer or something, which you will be calculating a timer load value.

Do all the constant multiplication beforehand you probably won't need any sort of floating point.

-Colin

Problem is a 10-bit, or even a 16-bit (lots of freq. steps, more accurate.) table is huge, but not impossible, yes a table and a timer will be much easier and faster.

I also have to prescale the timer when the T/2 is so wide that the value will be greater then 65355.

Example.

Xtal = 20MHz -> ck = 50 nsec.

When running a timer at ck, this will take 65536 * 50 nsec = 3.2768 msec.

So this is the largest T/2 possible, after that I have to do ck/8 and so on?

This is perhaps an easier way.

:roll:

you do not necesarily need a 32 bit divide routine...

Tell us what range of frequencis are we looking at?/

It may be possible tooptimise maths given a clearer EXPLANATION of application.

Quote:

Problem is a 10-bit, or even a 16-bit (lots of freq. steps, more accurate.) table is huge, but not impossible, yes a table and a timer will be much easier and faster.

What I mean is that when setting up the timer there is a register you load. The formula will involve a lot of constants that you can rearrange and do beforehand probably, so there is only one or two multiplicitons to do. It's still somewhat slow, but I can't imagine that you need to change the frequency that often.

-Colin

How many digits are you going to allow the user to enter? And, what error are you going to allow between the entered value and the generated frequency?

One thing you CAN do is an abbreviated table using linear interpolation between the points. You ought to be able to reduce the table to 10% of its fully-populated size, and and reasonable computation with no division. Its a standard numerical math process.

Jim