Quote Originally Posted by Kenjones1935 View Post
cncmachineguy

Five millisec interrupts seems like a good plan. I will do a little more complicated counting and skipping. I think the SONARs should be less often if I am going to calculate velocity.
I'm not sure what needs to be more complicated, but I am prolly not seeing the whol picture. Velocity calc won't take long, I am sure it can still be done in the fourth block You have 5000 cycles to burn up before the next interupt.
I wish I felt more at home with PBP. I'm tempted go to the freebe C, but that means starting all over again. It's been too many years.... Too lazy. sigh...
I don't have any experience with PBP yet (but I will start programming in the next week or so ), all my programming has been in ASM. But from what I can see, there may be a few times when PBP isn't the best choice, but I don't know when that is. All languages have pros and cons. PBP seems to me to be a very good compilier. If I were you, I would just stick with it. I don't think it is where the difficulties are.
How do I get 5millisec interrupts from a FOSC/4 oscillator. I just do not understand section 6.0 of the '887 spec sheet.
Ken
For my part of being lazy, its not going to look at the datasheet for this processor. But the good news is I don't think I need to to answer this. I assume '887 has at least 1 16 bit timer you are not using. So go look at the timer section and figure out how to configure it as a counter. What I find to be the most important part about osc is this, it takes 4 clock cycles to execute an instruction (ASM). So that means if using 4Mhz clock, each instruction takes .000001 seconds, or 1/(osc/4). so for 5 msec, thats 5000 instructions. The timer/counter will increment 1 for every instruction. So heres the math:
16 bit counter = 65535
65535 - 5000 = 60535

so if you preload the timer with 60535, it will take 5000 counts to roll over. thats 5 msec. If timer overflow interupt is enabled, an int will be generated at 5 msec. Then in the handler, reload the timer with 60535 so another int will happen in 5 more msec. and so forth.

1 thing to keep in mind, 60535 assumes there is no lag between rollover and reload. In reality there is, it will take a few cycles to enter the interupt, then another few to reload and start the timer. so your number would adjust up by some small amount. for instance: if it takes 12 cycles to go from overflow to reload, the number you want to load would be 60535 + 12 = 60547. Make sense?

You can determine the exact number with some testing, before you reload the timer, grab the timer low byte and save it. then look at that number. it will be the number of cycles it took to get to the point where you grabbed it. Then replace the code to grab it with code to load it and the timing should be within 1 or 2 cycles.

I will let you chew on this for a while.
BTW, If you find there is not enough time between int for math and such, change the clock to 8Mhz, then you will be able to execute twice as many instructions between interupts.