Thread: PIC math help

well, here's my problem.


I've been revising/reworking an old project (might recognize it as the PIC Chronograph from another post)

it is now built with a larger microcontroller, and has a more sensitive 2 gate system.

in the programming, after the first photogate has been broken, the microcontroller will begin increasing a counter/storing #'s in a set of 3 registers.

these three registers will store the # in a decimal format. the first register for the 1ns place, the second for the 10ns place and the third for the 100ns place. (meaning it can only store a number at or below 999)

when the second photogate is broken, the counter will stop increasing this #.


the # stored in these three registers will be the amount of time there is between the breaking of the two gates.

the distance between the two gates is 1ft. it has been set up like this to help make the programming a little bit easier.

I need to somehow divide 1 by that # stored in the three registers so that I can have the device display the speed of whatever broke the two gates, but I have no idea how to do that using the PIC's instruction set.


I am programming in PICassembly using MLAB IDE

any ideas?

attached is the circuit diagram

(sorry, the image was invalid on the first message, so here it is again)

Originally Posted by ericgibbs

Use PORTB.0 as the start/stop Interrupt control for a an internal reg counter.

Or use a 16-bit hardware capture for better accuracy & less overhead.

Originally Posted by ericgibbs

To simplify even further use a 3.768Mhz xtal [ or multiple] in place of the 4Mhz xtal.

He's dealing with metric time measures, so 4MHz is good (gives 1 us resolution)... I think there is a mistake in his above post; he must be measuring us, not ns.

Originally Posted by ericgibbs

Its a basic elasped time measurement.

Yes, followed by a basic conversion to speed through scaled reciprocation.

Originally Posted by ericgibbs

Do you follow OK.?

No, I don't.

Originally Posted by ericgibbs

Im puzzled why you are unable to follow my simple explanation.

I'm also puzzled. The way I read his post, he's after a speed, not time measurement.

Originally Posted by ericgibbs

My reply was intended for the OP's benefit, not so that you could go off in a childish Rant!.

Maybe. Well, at least my rant was concise.

Originally Posted by ericgibbs

The method I outlined is a well used way of doing exactly what the OP wants.

Again, I thought he was after a speed measurement.

Last night, my partner for this project came up with an algorithm that will take care of what we need.

Say x represents the number stored in the register.
In the program we then have x added to itself a Q number of times until the result =y, or a number that is equal to/slightly greater than one. At the moment that x added Q # if times together is greater than one, your speed is given as Q.

It is only accurate in very high velocities and doesn't give decimal numbers (Q is a whole number) but we just make a second loop that goes into the tenth place or hundreth place. I'm not quite sure how to explain it here, but i've tried it through my partners explanationm and it works.


Thankyou guys for your help, but I can't modify the circuitry any more as I already have a PCB ready and waiting for the components to arrive in the mail.

If anyone else has any suggestions I'd be glad to take them, but unless there is something that will work much better than our algorithm posted here, the programming will use what my partner came up with.

For dougy83 and ericgibbs:

I appreciate the help, but niether of the ways posted here I will be able to use as the circuit above here is final.

Also, before this thread becomes an argument over which way is better, please reconsider the reasoning on why you are posting. Such as: is it really necessary to argue with someone I've never met before over the internet?
Please don't take offence to this, I'm just saying what needs to be said before stones are hurled at each other.

Originally Posted by ericgibbs

If he chooses the time 'int' correctly for his internal timers, he can finish up with a count proportional/equal to speed.

I have no idea what you mean. I'm sure it's obvious to you, nevertheless.

Originally Posted by ericgibbs

But I dont need lessons in how to suck eggs.

I would never propose to provide tutition on such things, it's certainly not my area of expertise.

Originally Posted by electronicsfreak

I'm just saying what needs to be said before stones are hurled at each other.

Hardly. Sorry if I upset you two.

Originally Posted by electronicsfreak

Last night, my partner for this project came up with an algorithm that will take care of what we need.

Say x represents the number stored in the register.
In the program we then have x added to itself a Q number of times until the result =y, or a number that is equal to/slightly greater than one. At the moment that x added Q # if times together is greater than one, your speed is given as Q.
...

Yep "inversion by addition" is how I would have done it. By simply choosing the correct value for Y (the destination) you scale the result, so you can use different values of Y to give a result in FPS or m/s etc.

Once you have the first decimal digit you get the remainder, multiply the remainder by 10 and just do it again to get the second decimal digit. Etc for more digits.

It's not that fast as a calculation but it is pretty "bulletproof" hehe get the pun?

Originally Posted by ericgibbs

If he chooses the time 'int' correctly for his internal timers, he can finish up with a count proportional/equal to speed.

Could you please explain how this is done. Thanks.

Originally Posted by dougy83

Could you please explain how this is done. Thanks.

Ok, let's say the detectors are 1 foot apart, the bullet goes through and you get an elapsed time period of 253uS. To convert from a period to a speed (like feet per second) you add X to itself until you reach Y (which is 1 second or 1000000uS).

So;
Add X to Accumulator until it reaches 1000000;
(it is added 3952 times, reaches 999856)
the remainder = 144
so feet per second = 3952 and (144/253)

Now if you need the result in metres per second, you just use a different Y value, so instead of Y=1000000 you use a new Y=304878.
(feet/metres = 1/0.304878)

So use the same hardware, and same calc code but just with the new destination Y value;
Add X to Accumulator until it reaches 304878;
(it is added 1205 times, reaches 304865)
the remainder = 13
so metres per second = 1205 and (13/253)

Obviously the remainder can be processed with a similar "addition division" to the main calc.

I hope that answered your question? You see that the same hardware and excactly the same code can give the answer in FPS or M/S, and the code is very compact and brutally simple, just a loop and addition, although it is slow time-wise (which doesn't matter at all for this app).