Just a reminder that CANONICAL Spin2 (that is, compiled by PNut/Propeller Tool/Spin Tools) can do assembly testing without invoking a separate cog. I've never used ALTS but think it will be useful in an upcoming project so I took Andy's suggestion and wrapped it into an inline test. It works as intended. Thanks, Andy!
pub demo_alts()
org
mov pr0, #0
.loop alts pr0, #Fib0
mov pr1, 0-0
debug("Index: ", udec_(pr0), " Fibo:", udec_(pr1))
waitx ##(CLK_FREQ >> 2)
incmod pr0, #9 wc
if_nc jmp #.loop
ret
Fib0 long 0
Fib1 long 1
Fib2 long 1
Fib3 long 2
Fib4 long 3
Fib5 long 5
Fib6 long 8
Fib7 long 13
Fib8 long 21
Fib9 long 34
end
@JonnyMac said:
Just a reminder that CANONICAL Spin2 (that is, compiled by PNut/Propeller Tool/Spin Tools) can do assembly testing without invoking a separate cog.
Inline ASM works in flexspin, too, no need to stress out. Recently a new mode has been added that's even more compatible with PNut (Put {++opt(!fast-inline-asm)} between PUB/PRI and the method name to enable - other compilers treat this as a regular comment)
Lol, that might be a little overkill. Jon was just saying he hasn't tested using Flexspin so can't speak for it. His example assembly will compile in just fine without special controls.
The main reason Eric added that full assembler compatibility switch was to provide compile-time cogRAM allocation warnings for two of my chunky Pasm2 Fcache'd routines that use big RES directives. The default assembler can't do the calculation to give a warning.
Coming out with the next question: the smartpin modes are very nice, as I suppose ;-) and now I have to use the ADC the way I'm used the P1: read the ADC counter at any time and determine the number of counts form successive reads at certain times by subtraction. If for example I read the counter 3 times 100 µs apart, the wait for 1 ms to read another three values, I can see, if the signal changes a little.
I have to figure out, if this is possible...
Is it as simple as using "RQPin" ?
I think there is no "free running" mode that behaves exactly like the P1 did. But there are a lot of possible tricks. If you need to sync the ADC sampling window to a PWM you could probably use the Goertzel mode and "abuse" the weighting table to generate seperate sampling windows for the high and low phases.
Or you can use one of the SINC filtering modes with a low sampling period and add a number of samples together.
@ManAtWork said:
I think there is no "free running" mode that behaves exactly like the P1 did.
Mind that the ADC low-level pin mode and the ADC smart mode are independent of each other. The former generates a bitstream that's integrated and sampled by the latter. You could select the ADC pin mode with one of the counting smart modes to get a P1-style thing. I think, anyways, haven't tried it to see if there's a gotcha.
Certainly can, Sinc1 filtering is the Count-Highs mode: pinstart(<pin number>, P_ADC_1X | P_COUNT_HIGHS, <sample period>, 0)
For totalising counter mode just set the sample period = 0, so then it's up to the software to diff.
PS: Silicon Manual has it named as %01111 AND !Y[0] = Count A-input highs
@evanh, that shows good results when I run a first test. Now I have to do is in ASM and it looks, the smart pins are smarter than me ;-)
OK, I have the first conversion running! The signal is way better, than what I'm used to know from the P1! Thanks to all that took part in the development of this great chip!
All to do: set up the ADC and later read and calculate the difference!
' setup ADC Pin 43 Shun
fltl pinAdcSh 'set pin to ADC mode
wrpin adc_modes, pinAdcSh
wxpin #0, pinAdcSh '#0 is 1-clock
drvl pinAdcSh 'start pin
rdpin Sh_Val0, pinAdcSh ' Read ADC
sub Sh_Val0, oldValu ' determine increase of counter
add oldvalu, Sh_Val0 ' update to current counter value
That's it.
And you will have very nice signals from a 50 kHz source!
Comments
Forget the first MOV, and ALTS's D operand is meant to be the index.
'Update pattern here alts PatIdx_, #PWMPatt00 ' PatternIdx added mov PattCurr, 0-0As long as the pattern table is in the cogram (of the same cog that executes the code), the ALTS approach should work. I would write it like that:
alts PatIdx_, #PWMPatt0 ' PatternIdx added to pattern table addr mov PattCurr, 0-0Andy
OK, I was close, just not close enough! Now it works as expected. Nothing like the Prop around !
Just a reminder that CANONICAL Spin2 (that is, compiled by PNut/Propeller Tool/Spin Tools) can do assembly testing without invoking a separate cog. I've never used ALTS but think it will be useful in an upcoming project so I took Andy's suggestion and wrapped it into an inline test. It works as intended. Thanks, Andy!
pub demo_alts() org mov pr0, #0 .loop alts pr0, #Fib0 mov pr1, 0-0 debug("Index: ", udec_(pr0), " Fibo:", udec_(pr1)) waitx ##(CLK_FREQ >> 2) incmod pr0, #9 wc if_nc jmp #.loop ret Fib0 long 0 Fib1 long 1 Fib2 long 1 Fib3 long 2 Fib4 long 3 Fib5 long 5 Fib6 long 8 Fib7 long 13 Fib8 long 21 Fib9 long 34 endInline ASM works in flexspin, too, no need to stress out. Recently a new mode has been added that's even more compatible with PNut (Put
{++opt(!fast-inline-asm)}between PUB/PRI and the method name to enable - other compilers treat this as a regular comment)Lol, that might be a little overkill. Jon was just saying he hasn't tested using Flexspin so can't speak for it. His example assembly will compile in just fine without special controls.
The main reason Eric added that full assembler compatibility switch was to provide compile-time cogRAM allocation warnings for two of my chunky Pasm2 Fcache'd routines that use big RES directives. The default assembler can't do the calculation to give a warning.
Coming out with the next question: the smartpin modes are very nice, as I suppose ;-) and now I have to use the ADC the way I'm used the P1: read the ADC counter at any time and determine the number of counts form successive reads at certain times by subtraction. If for example I read the counter 3 times 100 µs apart, the wait for 1 ms to read another three values, I can see, if the signal changes a little.
I have to figure out, if this is possible...
Is it as simple as using "RQPin" ?
I think there is no "free running" mode that behaves exactly like the P1 did. But there are a lot of possible tricks. If you need to sync the ADC sampling window to a PWM you could probably use the Goertzel mode and "abuse" the weighting table to generate seperate sampling windows for the high and low phases.
Or you can use one of the SINC filtering modes with a low sampling period and add a number of samples together.
Mind that the ADC low-level pin mode and the ADC smart mode are independent of each other. The former generates a bitstream that's integrated and sampled by the latter. You could select the ADC pin mode with one of the counting smart modes to get a P1-style thing. I think, anyways, haven't tried it to see if there's a gotcha.
Certainly can, Sinc1 filtering is the Count-Highs mode:
pinstart(<pin number>, P_ADC_1X | P_COUNT_HIGHS, <sample period>, 0)For totalising counter mode just set the sample period = 0, so then it's up to the software to diff.
PS: Silicon Manual has it named as %01111 AND !Y[0] = Count A-input highs
@evanh, that shows good results when I run a first test. Now I have to do is in ASM and it looks, the smart pins are smarter than me ;-)
OK, I have the first conversion running! The signal is way better, than what I'm used to know from the P1! Thanks to all that took part in the development of this great chip!
All to do: set up the ADC and later read and calculate the difference!
' setup ADC Pin 43 Shun
fltl pinAdcSh 'set pin to ADC mode wrpin adc_modes, pinAdcSh wxpin #0, pinAdcSh '#0 is 1-clock drvl pinAdcSh 'start pinrdpin Sh_Val0, pinAdcSh ' Read ADC sub Sh_Val0, oldValu ' determine increase of counter add oldvalu, Sh_Val0 ' update to current counter valueThat's it.
And you will have very nice signals from a 50 kHz source!