Shop OBEX P1 Docs P2 Docs Learn Events
Questions about the P2 instrution set for anyone but Chip - Page 3 — Parallax Forums

Questions about the P2 instrution set for anyone but Chip

13

Comments

  • Dave HeinDave Hein Posts: 6,347
    edited 2016-04-25 19:53
    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.
  • jmgjmg Posts: 15,140
    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*
  • rjo__rjo__ Posts: 2,114
    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,363
    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,363
    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: 15,140
    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


  • rjo__rjo__ Posts: 2,114
    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


  • jmgjmg Posts: 15,140
    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.
  • rjo__rjo__ Posts: 2,114
    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.
  • jmgjmg Posts: 15,140
    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: 15,091
    edited 2017-12-06 11:11
    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.
  • rjo__rjo__ Posts: 2,114
    sounds good.

    thanks
  • rjo__rjo__ Posts: 2,114
    edited 2017-12-08 16:15
    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
    
  • rjo__rjo__ Posts: 2,114
    @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.


  • jmgjmg Posts: 15,140
    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.
  • evanhevanh Posts: 15,091
    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. :)
  • cgraceycgracey Posts: 14,131
    edited 2017-12-09 01:17
    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.
  • rjo__rjo__ Posts: 2,114
    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


  • rjo__rjo__ Posts: 2,114
    OK...so I have the 360 servo with feedback using a smart pin for the feedback. I went with %0000_0000_000_0000000000000_00_10000_0 'time A high states.
    I was stymied by the TT setting. I looked at my serial code and TT for rx was set to _01_... which I used until I figured out that TT was the issue and set it to _00_ as above.

    I didn't set the B pin to the inverse, because it seems to me that I would have no idea whether that measurement preceded my
    high state or followed my high state... which means it has no value.

    So... what I am thinking is that I need to set up the B pin, but toggle it to 'on' only when I am sure that the A pin is already high, but not yet in transition and not yet reported.

    Is this possible?


    I haven't fully studied the issue but it seems that at any particular load, voltage and PWM drive setting, the variance in the feedback period seems just incredibly small... so I can probably get away with just watching the high state of the feedback signal. According to the rules, I need the whole period, but... maybe not if I am careful (periodic re-calibration).
  • jmgjmg Posts: 15,140
    rjo__ wrote: »
    ...
    I haven't fully studied the issue but it seems that at any particular load, voltage and PWM drive setting, the variance in the feedback period seems just incredibly small... so I can probably get away with just watching the high state of the feedback signal. According to the rules, I need the whole period, but... maybe not if I am careful (periodic re-calibration).

    What actually generates the PWM, and what is the granularity & jitter on that ? (the 5% frequency variance seems quite poor)
    Seems you only need to measure better than the source ?

  • rjo__rjo__ Posts: 2,114
    jmg...


    Every time I think I have it solid... all I have to do is wait 5 minutes.

    This morning I think I have it!!!

    I take the actual input signal out to two physical pins, A and C... not A/B pairs but just two different pins... then use the smart pin as above except include and invert B. I then read A/B and sample the other real pin for present state.

    This should tell me whether A or B was last read...

    I won't be able to test this for a while. Holidays have me humping.

    Thanks.

    Merry Christmas
  • jmgjmg Posts: 15,140
    rjo__ wrote: »
    I take the actual input signal out to two physical pins, A and C... not A/B pairs but just two different pins... then use the smart pin as above except include and invert B. I then read A/B and sample the other real pin for present state.

    This should tell me whether A or B was last read...
    In the P2, the A,B can be the same pin, or two separate (close by) pins.
    If you need a true Time-interval A-B, like my Frequency Counter has, you need 2 pins.
    If you want to capture pulse width and period, two smart pin cells are needed, but they can map onto a single physical pin.

    You might generally choose to discard the very first measurement, but I think Chip has this true-edge-triggered, so (eg) a pin enabled part-way thru a period, waits for a following full period, before it captures.

    More testing of smart pins would be great to see...
  • rjo__rjo__ Posts: 2,114
    About the issue of jitter...

    This is a Parallax product personally approved by Ken Gracey. There is no jitter:)

    Thanks a bunch

    Rich
  • Happy new year!
    Short question concerning the mathematical instruction set:

    Is there a combined MultiplyAdd - instruction available in P2?

    (Perhaps I simply missed it in the documentation)
  • cgraceycgracey Posts: 14,131
    ikemschn wrote: »
    Happy new year!
    Short question concerning the mathematical instruction set:

    Is there a combined MultiplyAdd - instruction available in P2?

    (Perhaps I simply missed it in the documentation)

    There are the SCLU/SCL instructions which multiply two 16-bit numbers and then put the 32-bit result into the next instruction's S value, which an ADD instruction could use. So, that's two 2-clock instructions to achieve a multuply and add.

    SCLU/SCL are getting renamed to SCA/SCAS in v31.
  • Ok, thank you.
  • rjo__rjo__ Posts: 2,114
    I'm using a P123-A9 (vers. 19a and 31)

    I hook an LED to a pin(" lzrping1") and also tie that pin low using a 10K resister. This code:
    
                    outh #lzrping1
                    dirh #lzrping1
    
                    waitx ##100
                  
                    outl #lzrping1
                    dirl #lzrping1
    
    
    

    causes the LED to light up and stay lit. The brightness is a function of the period of the waitx... the longer waitx, the brighter the LED.
    ?
  • rjo__ wrote: »

    causes the LED to light up and stay lit. The brightness is a function of the period of the waitx... the longer waitx, the brighter the LED.
    ?

    btw - you can use drvx instead of the combo outx/dirx. Are you saying those 5 lines of code are all that there are? Where's the end? Maybe it is cycling through all "nops" until the program counter starts running your code again???
Sign In or Register to comment.