Hi,
The timer, since it is 16 bits wide, consits of two 8 bit registers, TMR1H and TMR1L (check the datasheet). You read the registers as you read any other register in the PIC, for example TickCount = TMR1H * 256 + TMR1L. Since it's a hardware timer it'll keep running in the background without any impact to the rest of your software - as long as you don't want to use it for something else of course. Just remember that it's "only" 16 bits wide so it'll overflow "frequenctly".OK. So I am starting the clock ticker... How would I pull the current values from it? And then, since I only really need it when the machine is "lost", after my homing process, would it be to my advantage to disable it once finished, or just leave it running?
Well, yes, the math might not be very complicated from a human perspective but none of the devices you list as possible targets for your code does multiplication OR division (no 10, 12, 16 or 18 series PICs does division) in hardware so even though the actual equation/formula in it self (multiply by a thousand, divide by delta time) isn't "complicated" it's going to take the poor little PIC a lot of instruction cycles to get to a result (which MAY or may not matter). What I'm saying is that if you instead see to it that you get a new position update every x ms then all you need is a subtraction (current position - previous position) to get your velocity (in encoder counts per x ms).And I'm not sure what you mean about getting V without doing a lot of math. The math is simple enough...
If it's not possible to get a consistent interval between position updates then you ARE doing the right thing by calculating velocity based on delta time AND distance.
/Henrik.
Bookmarks