Shop OBEX P1 Docs P2 Docs Learn Events
SmartPin Mode %10000: Reading 360 Servo Feedback — Parallax Forums

SmartPin Mode %10000: Reading 360 Servo Feedback

tomcrawfordtomcrawford Posts: 1,126
edited 2019-03-18 20:41 in Propeller 2
I was able to reliably recover readings from the Parallax 360 Servo Feedback pin using smarten mode %10000 (Continuous states are counted in clock cycles).

Here is the inside loop:
loop      outh #sync                       'sync at the beginning
          rqpin temp, #servoPin wc         'get PREVIOUS high time or low time
    if_NC waitx #200
    if_NC jmp #loop                        'wait until it returns a "high" value
          wypin #10, #SYellow              'process high
          wrlong temp, HiAdrs
L2        rqpin temp, #ServoPin wc         'now we look for a LOW value
    if_C  waitx #200
    if_C  jmp #L2 
    if_NC wypin #10, #SGreen               'process low 
    if_NC wrlong temp, LoAdrs               
          outl #sync
          waitx ##1000 
          jmp #loop

In mode %10000, the pin is continuously monitored. When an edge is detected, the count is placed in the Z buffer and cleared and the state corresponding to the count is placed in the C-flag buffer. These buffers are maintained until the next edge and can be read at any time.

The program MUST read a high period and then the corresponding LOW period. If it reads a LOW period followed by a HIGH, or if there are intervening states, the results are not valid, particularly if the servo crosses zero. In the method where the program watches for edges (this is what I did on P1), it must wait until it detects a LOW-to-HIGH transition before it starts timing. This can mean as much as nearly two full feedback cycles to acquire timing in the case where the program begins searching during a HIGH period. With the P2, the program can take advantage of the buffers and never spend more than one full feedback cycles to acquire timing.

Here is the code to set the mode
timerMode = %0100_000000000_00_10000_0 'continuous states are counted (schmitt trigger)

  dirl #servoPin
          wrpin MMode, #ServoPin        'set smart pin timer mode
          dirh #ServoPin                   'Remove Reset          

Oddly, I absolutely had to invoke the Schmitt trigger in the smart pin configuration. If not, there were intermittent glitches on the HIGH-to-LOW transitions which would result in spurious readings of 1 or 2. I am unable to explain the glitches; I have never seen them before and do not see them with the Schmitt trigger. Is it remotely possible the smart pin is causing them?

The whole test program in attached.

Comments

  • jmgjmg Posts: 15,140
    I was able to reliably recover readings from the Parallax 360 Servo Feedback pin using smarten mode %10000 (Continuous states are counted in clock cycles).
    ...
    In mode %10000, the pin is continuously monitored. When an edge is detected, the count is placed in the Z buffer and cleared and the state corresponding to the count is placed in the C-flag buffer. These buffers are maintained until the next edge and can be read at any time.
    Nice example.

    Oddly, I absolutely had to invoke the Schmitt trigger in the smart pin configuration. If not, there were intermittent glitches on the HIGH-to-LOW transitions which would result in spurious readings of 1 or 2. I am unable to explain the glitches; I have never seen them before and do not see them with the Schmitt trigger. Is it remotely possible the smart pin is causing them?

    What do you mean by spurious readings of 1 or 2 ? Does that mean measurement LSB variations, or something else ?
    If the servo signal is sufficiently fast, schmitt should make little difference - what is the Servo out rise/fall time ?
    Very slow edges, with some noise present, & no schmitt, could possibly glitch to give a single-sysclk pulse, which could bump the smart-pin state and give large variations.

    With an async signal, some LSB sampling +/-1 effect is expected.


    If you report raw capture values, (SysCLK units) those should drift with the Parallax 360 generating clock, but the ratio should have higher stability.
    If you have more than one Parallax 360 Servo, it would be useful to see the absolute variations from unit to unit, and the (better?) ratio.

    IIRC the output resolves to ~12b, so you should report to better than that, to avoid losing precision inside P2.
  • evanhevanh Posts: 15,091
    Oddly, I absolutely had to invoke the Schmitt trigger in the smart pin configuration. If not, there were intermittent glitches on the HIGH-to-LOW transitions which would result in spurious readings of 1 or 2.
    That's exactly when a Schmitt trigger is needed, keep using it. The cause of the glitches will be the 3v3 switcher noise on the power rail. The LDO regulator will be better but don't count on it being perfect either.
  • evanhevanh Posts: 15,091
    You could enable the input filter too - the %FFF bits. And it has HUBSET config to setup.
  • jmg wrote: »

    What do you mean by spurious readings of 1 or 2 ? Does that mean measurement LSB variations, or something else ?

    IIRC the output resolves to ~12b, so you should report to better than that, to avoid losing precision inside P2.

    By spurious readings of 1 or 2, I meant just that. The P2 was interpreting the noise on the input as valid inputs as short as 1 sysclk.

    For SetPosition and GetPosition, I use degrees; internally I use 1/4096ths. Similarly, for SetVelocity and GetVelocity, I use rpm; internally I use 1/4096ths over 20 millisecs. Usually I call this clicks per tic; on Wednesdays I call it tics per click.

  • jmgjmg Posts: 15,140
    By spurious readings of 1 or 2, I meant just that. The P2 was interpreting the noise on the input as valid inputs as short as 1 sysclk.
    That's ok, it means the slew rate on the Parallax 360 Servo output is slow, relative to the Sysclk. Likely it has a series protection R
    At 180MHz, it has ~ 5.5ns to move some noise level away from the pin threshold.
    evanh's suggestion of enable the filter is a good one, as that widens the noise tolerance for unwanted impulse noise as well.
    Schmitt + filter would be the most robust combination.
    If you wanted to resolve to ~16 bits (to allow for other sensors, and ensure the capture is not losing precision) a tap of 1 and Length of 8, would give just over 16b timing, and ~90ns of filtering window.


  • evanhevanh Posts: 15,091
    The PWM feedback could be treated as an ADC bitstream and processed asynchronously.

    Bitstream processing will add significant lag but, given the control pulse is only 50 Hz, there is something like 19 feedback pulses to play with before even one control pulse is needed.
  • evanhevanh Posts: 15,091
    Did Chip ever get back to sorting out externally clocked bitstreams? I think that might have gone by the wayside. As did external clocked streamer functions.
  • cgraceycgracey Posts: 14,131
    evanh wrote: »
    Did Chip ever get back to sorting out externally clocked bitstreams? I think that might have gone by the wayside. As did external clocked streamer functions.

    I'm not sure what you mean by externally clocked bit streams, but the streamer does not have any externally clocked modes.
  • evanhevanh Posts: 15,091
    edited 2019-03-21 01:58
    cgracey wrote: »
    evanh wrote: »
    Did Chip ever get back to sorting out externally clocked bitstreams? I think that might have gone by the wayside. As did external clocked streamer functions.
    I'm not sure what you mean by externally clocked bit streams ...
    A new smartpin mode for synchronously accumulating the modulated bitstream from an external sigma-delta ADC. It works well asynchronously already but there is probably a small improvement by going fully synchronous. No biggie.

    I had pondered what it would take to do synchronous PWM input with the same but that always needs dual readings. Not something a single smartpin is suited to.

  • evanhevanh Posts: 15,091
    evanh wrote: »
    A new smartpin mode for synchronously accumulating the modulated bitstream from an external sigma-delta ADC. It works well asynchronously already but there is probably a small improvement by going fully synchronous. No biggie.
    Having said that. For every ADC with self-generating clock there is usually a matching model that accepts a synchronous clock input too. So it's still doable to synchronously match the Prop2 with an external bitstream ADC.
Sign In or Register to comment.