Questions about the P2 instrution set for anyone but Chip

13»

Comments

  • Dave HeinDave Hein Posts: 5,309
    edited April 2016 Vote Up0Vote Down
    Yes, I wrote a P2 assembler called qasm that is part of the Taz C compiler tool set. It's contained in the qasm directory in the zip file attached to the first post in the thread. It hasn't been updated since December so it won't contain the latest Smart Pin codes that have been added since then.

    Edit: There is a taz002.zip file posted in the 7th post of the thread, which would be better to use than the zip file in the first post.
  • Dave Hein wrote: »
    Yes, I wrote a P2 assembler called qasm that is part of the Taz C compiler tool set. It's contained in the qasm directory in the zip file attached to the first post in the thread. It hasn't been updated since December so it won't contain the latest Smart Pin codes that have been added since then.

    Does this support Macros ? Users could patch in their own opcode updates, in the short term ?

  • No, it doesn't support macros. The opcodes are defined in qasmsym.h. You can look at qasmsym.txt for the values of the opcode type. Originally, I defined the opcodes in qasmsym.txt, and qasm would read that file at runtime. I converted it to an array of strings in qasmsym.h so that the program would be self-contained in one file.

    I have a utility that converts qasmsym.txt to qasmsym.h, but I would suggest just modifying qasmsym.h directly.
  • rjo__ wrote: »
    I want you working not talking to me!!!!!

    *cracks whip*
  • m00tykins ...

    Occasionally I just want to find cheap gas... and occasionally I want to understand refineries. When I'm looking for cheap gas I use this thread.

    In that spirit... ALL I want is PNUT in some kind of fancy wrapper so I can create menu equivalents from the command line... how hard could it be?

  • AleAle Posts: 2,303
    I was wondering if there is a P2 instruction simulator. I thought of doing some testing I we (I) 're going to get a CV A2 version :) That Oberon thread we had a while ago got me thinking again what a nice complete system that would be for the P2... but at the time I didn't find a way to bootstrap development. I eneded installing several Oberon compilers and was unable to make any progress... cross-compiling was the problem.
  • AleAle Posts: 2,303
    Of course there is spinsim by Dave Hein, It was in the back of head that there was already something... I'll have to check how up to date it is, and ask him :)
  • jmgjmg Posts: 10,635
    Ale wrote: »
    I was wondering if there is a P2 instruction simulator. I thought of doing some testing I we (I) 're going to get a CV A2 version :) That Oberon thread we had a while ago got me thinking again what a nice complete system that would be for the P2... but at the time I didn't find a way to bootstrap development. I eneded installing several Oberon compilers and was unable to make any progress... cross-compiling was the problem.

    Did you look at either this, for Spin..

    http://forums.parallax.com/discussion/164187/fastspin-compiler-for-p2/p1

    or maybe this, for Oberon to C, for initial bootstrap ?

    http://www.excelsior-usa.com/xdsc.html


  • Here is an easy one.

    I am looking at using Smart Pins to generate 50Hz PWM to drive Parallax's feedback 360 servo. A 50Hz cycle requires a period of 160_000 clocks, but the parameters in the smart pin are limited to 16 bits. In the Chip's documentation, it says that a prescaler is available for pwm modes but I can't see how to use it... I assume that the prescaler allows one to skip clocks and make everything fit into 16 bits. I could be wrong:)

    I am also interested in using Smart Pin to measure the PWM feedback coming back... Not sure what mode to use.

    Thanks


  • rjo__ wrote: »

    I am looking at using Smart Pins to generate 50Hz PWM to drive Parallax's feedback 360 servo. A 50Hz cycle requires a period of 160_000 clocks, but the parameters in the smart pin are limited to 16 bits. In the Chip's documentation, it says that a prescaler is available for pwm modes but I can't see how to use it... I assume that the prescaler allows one to skip clocks and make everything fit into 16 bits. I could be wrong:)

    Docs say
    "Triangle/sawtooth/SMPS PWM output, 16-bit frame with 16-bit prescaler"

    So you should be able to /24 to get
    80M/24/2^16 = 50.8626Hz
    rjo__ wrote: »
    I am also interested in using Smart Pin to measure the PWM feedback coming back... Not sure what mode to use.
    That depends on how stable the Servo is....

    The Servo Docs say
    "Feedback Signal
    The servo sends a feedback output signal to your microcontroller via the yellow wire connection.
    This signal, labeled tCycle in the diagrams and equations below, has a period of 1/910 Hz (approx. 1.1 ms), +/- 5%.
    Within each tCycle iteration, tHigh is the duration in microseconds of a 3.3 V high pulse. The duration of
    tHigh varies with the output of a Hall-effect sensor inside of the servo.
    The duty cycle of this signal, tHigh / tCycle, ranges from 2.9% at the origin to 97.1% approaching one clockwise revolution. "

    That 5% is not great, so you need to either

    a) measure both Period, and Hi-Time, for the same cycle. The ratio Th/Tp
    This needs 2 smart pins, but has the highest precision, and updates every 1.1ms, and does not care if you miss one pair.
    or
    b) Measure Edge-Edge for all edges, with nimble SW. The MIN times are ~ 31.9us, so this uses one smart pin, but must be read within 31.9us - Maybe Interrupt code ?

    As for which modes ?
    The Smart Pins DOCs are somewhat hard to decode, as they lack connections and actions.

    eg I think
    %10000 = Time A-input states
    will capture a time from every edge. I do not see clear-on-capture mentioned, but I think that is done ?


    If you want to read at a lower rate than 1.1ms, then maybe this mode

    %10010 = Time X A-input highs
    I think that can be set to measure eg 46 periods, for a ~50Hz read rate.

    and for a user-defined-gate time, ( > 1.1ms) these modes can capture Period/Hi-Time pairs, using 2 smart pins.

    %10101 = For periods in X+ clock cycles, count time
    %10110 = For periods in X+ clock cycles, count states
    %10111 = For periods in X+ clock cycles, count periods

    X[31:0] establishes the minimum number of clock cycles to track periods for. Periods are A-input rise/edge to B-input rise/edge.
    ...
    Note: The B-input can be set to the same pin as the A-input for single-pin cycle measurement.

    The first mode accumulates time within each period, for an oversampled period measurement.
    The second mode accumulates A-input trigger states within each period, for an oversampled duty measurement.
  • Thank you. I think that gets me close to where I need to be.

    But... where do I use the prescaler? I don't see it documented except in that one line that you quote.
  • rjo__ wrote: »
    Thank you. I think that gets me close to where I need to be.

    But... where do I use the prescaler? I don't see it documented except in that one line that you quote.

    My reading for %01001 = PWM sawtooth is
    fP = PWM Clock = SysCLK / X[15:0]
    pM = PWM reload (Max Count) = X[31:16]
    Cv = PWM Compare = Y[15:0]

    If you wanted full 16b range, pM = 0xFFFF, fP = /24 or /25
    Or, if you wanted precisely 50.00Hz for some reason, you might choose
    fP = /25, pM = 64000-1, Cv is 0..64000-1
  • evanhevanh Posts: 4,428
    edited December 6 Vote Up0Vote Down
    X[15:0] is the pre-scalar period in sysclocks

    X[31:16] is the PWM period in pre-scalar periods

    Y[15:0]​ is the PWM duty level (working rang is zero to PWM period). Zero is always 0%, and equal to PWM period is 100%. Anything value above PWM period is same as 100% level.

    Other things of importance in configuration is always do a DIRL #smartpin at start of config. And when setting a smartpin output override mode the TT component of the mode needs to be %01, Eg: For setting the PWM sawtooth mode use: WRPIN #%01_01001_0, #smartpin

    Then set the X and Y parameters, then enable the mode with a DIRH #smartpin

    That should get you going. After it's enabled you can continue to change X and Y. Obviously, Y is the level you want to output.
    The Prisoner's Dilemma, in english - "Selfishness beats altruism within groups. Altruistic groups beat selfish groups." - Quoted part from 2007, D.S Wilson/E.O Wilson.
  • sounds good.

    thanks
  • rjo__rjo__ Posts: 1,855
    edited December 8 Vote Up0Vote Down
    Ok... for the PWM this is what I am looking at. The only think I don't understand is why for a 1 Hz signal the frame*prescaler = 40_000_000. Seems like we should need 80_000_000.
    dat		org
    
    		clkset	#$FF		'set clock to 80MHz
    
    		mov	x,#0            'x is smart pin
    		wrpin	pm,x		'set triangle pwm mode in smart pin #0
    		wxpin	fr,x		'set frame count and prescaler
    	        wypin	pwm,x           'set pwm (as a fraction of frame)
                    dirh    x               'start smart pin
    
    		.loop
    
    		jmp	#.loop		'loop
    
    
    pm		long	%1_01000_0	        'triangle pwm mode
    fr		long	40000<<16 + 1000	'frame is 40000 counts, prescaler is 1000 = 1Hz  
            '**************
             '      long    40000<<16 + 20         'frame is 40000 counts, prescaler is 20 = 50Hz (20ms)
                                                   'this gives pwm resolution of 0.02/40000= 0.0000005s =0.5us (per unit of pwm).
            ''''''''''''''*
                                         
    pwm             long  100                     'on for 100/40000 of total pwm period
    x		res	1
    
  • @jmg

    Smart Pin pwm is fabulous... almost set and forget. I can't imagine lower overhead.

    But given the math that has to be done on the feedback signal coming from the servo, it just doesn't make much sense to handle the signal using smart pin features.
    I'll need a loop to do the math anyway... not using smarts only costs about 8 lines of code.


  • rjo__ wrote: »
    Ok... for the PWM this is what I am looking at. The only think I don't understand is why for a 1 Hz signal the frame*prescaler = 40_000_000. Seems like we should need 80_000_000.
    I think that is because it is a triangle PWM in this case. Counts Up, then Counts down so period doubles.
    Triangle is mostly used when you have many channels, and want dead-bands on each edge.
    rjo__ wrote: »
    ..
    But given the math that has to be done on the feedback signal coming from the servo, it just doesn't make much sense to handle the signal using smart pin features.
    I'll need a loop to do the math anyway... not using smarts only costs about 8 lines of code.
    I'm not following ? - you still need hardware to do PWM, otherwise the software has to be bit-bang fast.
    Or do you mean capture ?

    With capture, the smart pins allow precise same-cycle or many-cycles capture of 2 values - HI time and Period, to extract an exact % Duty.
    Where the source clock is not stable, if you do not do this, you have lower precision Duty Cycle readings.
  • I think RJO is talking about the Cog running the servo loops has nothing else to do so can just as easily bit-bash the PWM as set a PWM level in a Smartpin.

    The luxury of the Propeller. :)
    The Prisoner's Dilemma, in english - "Selfishness beats altruism within groups. Altruistic groups beat selfish groups." - Quoted part from 2007, D.S Wilson/E.O Wilson.
  • cgraceycgracey Posts: 8,343
    edited December 9 Vote Up0Vote Down
    It's still nice to use the smart pins for PWM, even if you have time to do it manually because:

    1) You can start them all up at the same time and they'll forever remained synchronized.
    2) WXPIN sets up both the empirical time unit and the frame size.
    3) WYPIN writes a double-buffered value that updates on the start of each frame.
    4) The double-buffering allows you a whole frame time to update all your PWM values.
    5) There are no gotcha's on concurrent changes that are difficult or impossible (at highest speed) to do in software.
  • Sorry,

    Heavily into childcare today and didn't have time to correct my post.

    I love smarts for PWM... for all of the reasons that Chip mentions.

    Where I was wrong was about using smarts for analyzing the feedback loop of the new 360 feedback servo_s.

    What was wrong with my thinking is that I wasn't factoring in the time a P2asm loop would spend waiting for the feedback signal to complete one cycle. That overhead disappears when you use smart pins.

    With smarts, you can let the pin wait for the signal and simply poll it at a convenient time.

    So, with one cog both actuation and feedback can be handled synchronously for multiple servos... and have time left over to do all kinds of things.

    I haven't had time to play with this yet, but it is next up ... probably next week:)

    Sorry for the confusion.

    Rich


Sign In or Register to comment.