Guesstimating Timer Help

Spilly

I measuring angular position via toothed wheel. I am trying to interpolate to give myself more resolution than the toothed wheel allows. By interpolate I mean I am recording the number of clock cycles between the teeth (time period between rising edges) and then multiplying that by the number of teeth and then dividing by 360. This should give the amount of clock ticks to cover one degree, so, I put that value plus CNT into waitcnt and then increment by one degree.

At low speeds it acts as anticipated but at higher speeds it begins to fall on it's face. At the highest operating speeds the time I will need to put into waitcnt will be about 18-19 microseconds (9000rpm with 12 tooth wheel), however, it is running into problems at around 4-500 microseconds.

When I say falling on it's face, I mean that the number of increments are far less than 30 (this is the ideal value) and sometimes as low as zero.

If someone could provide some insight on how I can make this work, I would be extremely thankful. I feel like I have been beating my head against a wall repeatedly.

Here is how I am calculating the time between teeth:

//calculate the period of time between pulsesvoid calcPer()
{
  //set CTRA to increase on every clock cycle
  CTRA = (0b00001<<26);
  FRQA = 1;


  //set CTRB to increase on rising edge of pin 17
  CTRB = (0b01010 <<26) + 17;
  FRQB = 1;


  //counts clock cycles between rising edges
  while(1)
  {
    //wait for rising edge
    while(PHSB == 0)
    {
      //do nothing
    }


    //update global variable with PHSA count (divide this by CLKFREQ to get time in seconds)
    gTime = PHSA;


    //return PHSB and PHSA to zero
    PHSB = 0;
    PHSA = 0;
  } 
}

Here is the function that increments after time for one degree:

void goAdd()
{
  while(1)
  {
  waitcnt(crunchIt + CNT);
  addIt++;
  }
}

Here is the function I am using to create test pulses.

void pulse(){
  int x = 0;
    //for(int x=0; x<=24; x++)
    while(x<=24)    
    {
      //waitcnt(CLKFREQ/50000 + CNT);
      high(0);
      waitcnt(CLKFREQ/10 + CNT);
      low(0);
      if(x==24)
      {
        x = 0;
      }
      x++;
    }


}

JonnyMac

I'm confused... are you measuring angular position or velocity? The latter implies that time is involved.

Spilly

I suppose my guesstimation process is calculating velocity. I am trying to use that information to make the 12 tooth wheel into a 360 tooth wheel. Does that make more sense?

JonnyMac

Does your wheel have a fixed rotational speed? If not, your time-based approach won't work -- without constant recalibration.

I don't know if this will help at all, but I have a friend that makes a Propeller-powered pan/tilt/trolley mechanism for movie cameras. He uses quadrature encoders on all of the motors as that allows him to know exact position and derive speed based on the timing between changes.

Cluso99

You might be running into the problem that spin is quite slow. Therefore the CNT value might be too coarse - overrunning and the counter before you can setup waitcnt. There is a minimum value you can achieve. Assembler would most likely be fast enough, presuming that is your problem. I haven't looked at your code, so this is just a quick assessment.

Often missing waitcnt causes the program to wait an additional ~90 seconds.

Spilly

JonnyMac wrote: »

Does your wheel have a fixed rotational speed? If not, your time-based approach won't work -- without constant recalibration.

I don't know if this will help at all, but I have a friend that makes a Propeller-powered pan/tilt/trolley mechanism for movie cameras. He uses quadrature encoders on all of the motors as that allows him to know exact position and derive speed based on the timing between changes.

Exactly. I would be setting aside a core to constantly measure the time between pulses.

Cluso99 wrote: »

You might be running into the problem that spin is quite slow. Therefore the CNT value might be too coarse - overrunning and the counter before you can setup waitcnt. There is a minimum value you can achieve. Assembler would most likely be fast enough, presuming that is your problem. I haven't looked at your code, so this is just a quick assessment.

Often missing waitcnt causes the program to wait an additional ~90 seconds.

I have ran into the overflow with waitcnt. Took me a while to figure that one out.

Is their a good read/tutorial on assembly language? I only have limited C# programming knowledge.

rjo__

Spilly,

Cluso is exactly correct. PASM is the way to do this. As long as your velocity is changing in an orderly way you should be able to estimate anything you want.
Spin is fine for reporting your results. You are on the right track. Try writing a PASM program that doesn't do anything except change the value of two variables.
Set the variables in Spin... call your PASM routine... Check your values... it really is that simple. I have to leave right now or I would do it for you:)

Good luck

Spilly

rjo__ wrote: »

Spilly,

Cluso is exactly correct. PASM is the way to do this. As long as your velocity is changing in an orderly way you should be able to estimate anything you want.
Spin is fine for reporting your results. You are on the right track. Try writing a PASM program that doesn't do anything except change the value of two variables.
Set the variables in Spin... call your PASM routine... Check your values... it really is that simple. I have to leave right now or I would do it for you:)

Good luck

I'm just going to have to sit down and play with PASM. Is it easier to learn Spin first and then build on top of it?

kwinn

Spilly wrote: »

I'm just going to have to sit down and play with PASM. Is it easier to learn Spin first and then build on top of it?

Knowing spin will help a bit, but assembly language is quite a change. You are working at the bare metal level of the micro as far as the instructions go. Not really all that difficult once you get over the initial hump though.