Fastest that you would or could toggle an IO pin?
WBA Consulting
Posts: 2,934
I am getting mixed answers in my searching so I figured I would ask my question directly. Irregardless of what the propeller can do as far as speed of toggling a pin, in most uses of a propeller, what is the fastest you would toggle an IO pin? For example, I know my Honda is spec'd to do 110mph, but I never need to go over 75.
I also need to answer the same question for a BASIC Stamp because my project ties into both.
Update 8/31/12
In SPIN, I was able to obtain 18KHz
In PASM, I was able to obtain 5MHz as a 50% duty cycle with a XOR loop.
With Counters, I was able to obtain 60MHz through my translators which was my goal. I did go to 80, but the translators output was very unstable.
I also need to answer the same question for a BASIC Stamp because my project ties into both.
Update 8/31/12
In SPIN, I was able to obtain 18KHz
In PASM, I was able to obtain 5MHz as a 50% duty cycle with a XOR loop.
With Counters, I was able to obtain 60MHz through my translators which was my goal. I did go to 80, but the translators output was very unstable.
Comments
Using a counter, you can output a ClkFreq/2 square wave (ie 40~50MHz depending on 5~6.25MHz xtal)
Or in single cog Pasm, about 10~12.5 MHz
Your Honda, whats it go to 6000rpm? Thats 100 Hz, or 500,000 times slower
I think what's really being asked is how long it takes for a spin statement to turn on, and then turn off, a single output pin.
rough estimate is that I was just barely able to get 38 KHz IR working with just spin instructions with an 80 MHz clock.
subsequent revisions used a counter, of course, to produce the 38 KHz modulation and then much more slowly stream out the bits using spin.
If PASM, 10Mhz, 1 instruction on, 1 off.
An example test I ran was step through all 4096 values into a 12bit mdac to put out a ramp function. In spin it took multiple seconds to run from 0 to 4096. In PASM, the same ramp would take about 18 mS. So maybe it would make better sense to evaluate whether the chip specs can deliver on the project.
FF
I've toggled a pin at 9000hz, so on for 4444 clk cycles and off for 4444 clk cycles, for my automotive project. (15k rpm) This was in PASM and spin, although with spin I had nothing else in the loop besides the pin toggle code, because it is so much slower. If you can spare a dedicated cog to spin, this will be fine. If you have other stuff going on, PASM is the way to go IMO.
FYI: FUllDUplexSerial will run at 115,200 quite happily - some have run it faster IIRC. That is 115,200 bits per second.
I was at the conclusion that toggling a propeller pin at 80mhz was possible, but why would you need to? A better way to ask my question is probably: If you can't toggle a pin over 30mhz, what can the propeller NOT do that most propeller users would be doing. If I hand you a propeller board that cannot go faster than 30mhz on an IO pin, could you still use it?
Rdl2004: thanks, I was figuring the stamp would be way under my 30mhz breakpoint.
Only for some things - remember the Prop can also resolve any pin edge to 12.5ns, so any Bandwidth limit restricts the corner cases on both generate, and sync.
A better question is, what drives the need to limit a pin BW to 30MHz ?
With a 30 MHz limit you can not do SigmaDelta ADC and DutyPWM output. If Duty not works then for example all the sound object that use DUTY mode for DACs will not work well.
With 30 mhz (=0.03 Hz) you can not do much more than blinking a LED very slow.
Andy
Rather off topic but a BLDC motor at 20,000 rpm the frequency depends on the number of magnet pole pairs, not the number of windings, each winding sees one cycle per pole-pair. I've some brushless BLDCs with 7 pole pairs so the windings would run at 2.33kHz for 20,000rpm, but the time step between each phase switching would be 1/6 of that period, i.e. 71.4us - in the PASM range clearly.
Pet peeve for previous posters: mhz ?? KHz ?? really?? Those mean 0.1 'z' and 1024 hertz respectively (m = milli = x0.001, h = hect = x100, K = x1024 (not SI) hertz is abbreviated Hz not hz)
So there must be some as yet unstated benefit of that chip, and it presumably does not go between ALL Prop Pins, and the real world ?
Dedicated IO functions are fine, provided users still have some choice.
Plenty of designs have RS232 chips, or Darlington Arrays on some of their pins.
-Phil
My apologies, but there are many caveats to the design that are as yet undisclosed purposely, so forgive my attempts to get detailed answers from a non-detailed question. After more thought and an email from someone who has some knowledge of the design, I have been able to confirm that the 30mhz limit will pose minimal issues for my design's main intent. The secondary intent of the design will only have concerns among 10-20% of those users, so overall, less than 5% of my target market will be saddened by the limit.
Can anyone tell me why my PASM code is not faster than that? I am using a modified version of Jonnymac's JM_Blinker code. I still need to dig deeper into counters to try to get to 40Mhz as reported being possible.
'' ================================================================================================= '' '' File....... jm_blinker.spin '' Purpose.... PASM LED blinker '' Author..... Jon "JonnyMac" McPhalen '' E-mail..... jon@jonmcphalen.com '' Started.... '' Updated.... Andrew Wiliams, PASM Toggle Speed '' '' ================================================================================================= CON _clkmode = xtal1+pll16x _clkfreq = 80_000_000 var long blinkpin ' pin used by blinker cog pub start blinkpin := 5 result := cognew(@blinker, @blinkpin) ' start blinker cog dat org 0 blinker mov t1, par ' start of structure rdlong t2, t1 ' read blink pin mov pinmask, #1 ' create mask from pin # shl pinmask, t2 mov dira, pinmask ' make pin an output bloop andn outa, pinmask ' pin off or outa, pinmask ' pin on jmp #bloop ' loop forever ' -------------------------------------------------------------------------------------------------- pinmask res 1 ' mask for blinker pin ontix res 1 ' on timing in system ticks offtix res 1 ' off timing in system ticks timer res 1 t1 res 1 t2 res 1 dat {{ Terms of Use: MIT License Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. }}It depends on semantics - you have a Set/Clr/Jmp, in a 3 op code loop. You have one Pin-cycle per loop (not 50% duty), so 6.6666' MHz is the result.
You can do a XOR+JMP and now the loop runs at 10MHz, but a 10MHz toggle is a 5MHz pin frequency.
Or you can unroll the loop and chain XOR, for a 20MHz toggle burst, or a 10MHz pin frequency burst, for tests.
#11 MASK BEGIN DUP OUTSET DUP OUTCLR AGAIN
#11 MASK DUP OUTSET BEGIN OUTCLK AGAIN
Thanks to all or the help. I am going to change the thread to solved.