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.
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.
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.
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
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.
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.
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
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.
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
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.
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
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.
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.
..
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.
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.
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:)
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).
...
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 ?
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.
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...
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.
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???
Comments
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.
Does this support Macros ? Users could patch in their own opcode updates, in the short term ?
I have a utility that converts qasmsym.txt to qasmsym.h, but I would suggest just modifying qasmsym.h directly.
*cracks whip*
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?
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
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
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
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.
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
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.
thanks
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 1Smart 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.
Triangle is mostly used when you have many channels, and want dead-bands on each edge.
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.
The luxury of the Propeller.
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.
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
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).
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 ?
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
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...
This is a Parallax product personally approved by Ken Gracey. There is no jitter:)
Thanks a bunch
Rich
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.
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 #lzrping1causes 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???