Execution speed
Hi,
I am switching over from an Atom Pro due to the lack of speed. I'm trying to get my hands around how this thing works. I'm a newbie and an amatuer when it comes to ucontrollers, but my timing and Parallax' timing are pretty good. I have never used assembly, so that is going to be quite a task to learn. Anyway, my point of post.......
I'm curious if you could elaborate upon this a bit. If one were simply using one cog, how fast would code be processing? If I were using an object that required one cog to run, such as:
Could you let me know how fast this will run (less the delay time of 0.1sec) line by line? It is my understanding that it takes two cycles to execute "one line of code". I'm curious what "one line of code" is, and how I can determine how fast the Propeller will effectively run. If it is running at 80MHz, is that 80Mhz per cog, or exactly the 5Mhz (80Mhz/8cogs/2cycles.per.line.of.code), so it is effectively running at 5Mhz, or 5 million lines of code per second?
Now, the same question goes if we add another cog. This cog must be running at the same speed as the first, or 5Mhz, right? Thusly, a propeller can effectively execute 40 million lines of code per second with all 8 cogs???
The reason I ask is that some of your objects seem to be full of code. I am simply curious how it is executed fast enough to do the things it does.
Also, a pin can only have 2 states, on and off, right? I didn't quite get how the A/D object worked...
Eagerly awaiting a new start to microcontrollers, and a new member to the community,
-Parsko
I am switching over from an Atom Pro due to the lack of speed. I'm trying to get my hands around how this thing works. I'm a newbie and an amatuer when it comes to ucontrollers, but my timing and Parallax' timing are pretty good. I have never used assembly, so that is going to be quite a task to learn. Anyway, my point of post.......
Article said...
Another common resource is the system clock; this actually drives all cogs and allows them to be
synchronized, even though they run independently of each other. The system clock also drives a global
register called the System Counter. This 32-bit, read-only counter increments every clock cycle, and can
be read by any cog via the cnt register.
Article said...
That said, Chip has estimated that with a 5 MHz crystal and using the 16x PLL tap
(system clock of 80 MHz), we can run about 80K Spin instructions per second.
I'm curious if you could elaborate upon this a bit. If one were simply using one cog, how fast would code be processing? If I were using an object that required one cog to run, such as:
Example of blinking LED from Article said...
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
Led = 16
VAR
long delayTime
PUB BlinkLED
dira[noparse][[/noparse]Led] := 1
repeat
outa[noparse][[/noparse]Led] := !outa[noparse][[/noparse]Led]
delayTime := cnt + 8_000_000
waitcnt(delayTime)
Could you let me know how fast this will run (less the delay time of 0.1sec) line by line? It is my understanding that it takes two cycles to execute "one line of code". I'm curious what "one line of code" is, and how I can determine how fast the Propeller will effectively run. If it is running at 80MHz, is that 80Mhz per cog, or exactly the 5Mhz (80Mhz/8cogs/2cycles.per.line.of.code), so it is effectively running at 5Mhz, or 5 million lines of code per second?
Now, the same question goes if we add another cog. This cog must be running at the same speed as the first, or 5Mhz, right? Thusly, a propeller can effectively execute 40 million lines of code per second with all 8 cogs???
The reason I ask is that some of your objects seem to be full of code. I am simply curious how it is executed fast enough to do the things it does.
Also, a pin can only have 2 states, on and off, right? I didn't quite get how the A/D object worked...
Eagerly awaiting a new start to microcontrollers, and a new member to the community,
-Parsko
Comments
The ADC example uses two pins and a couple passives to form a Sigma-Delta converter -- Google will give you better explanations than I can provide.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
One thing you have to realize, that 1 instruction execution time is based on Assembler. In Spin it requires 100 - 500 assembler instructions per Spin instruction as it is an interpreted language.
Having said that, this code:
I measure the output at 142KHz roughly. Using the internal counter, if you were looking for a higher frequency pulse, you could attain 80MHz roughly with getting real fancy, and if you use Assembler, you could see from 0 up to 80MHz I believe. Line by line for Spin, it would be tough to tell.
Now, to have 8 seperate processors able to each be doing that while sharing data and I/O.... gets prett wild!
The A/D is using Sigma-Delta, without getting too deep into it, they use an integrator and drive an output with pulses to build to the threshold voltage for the input, and based upon that can calculate the analog voltage.
-Martin
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Martin Hebel
Southern Illinois University Carbondale - Electronic Systems Technologies
Personal Links with plenty of BASIC Stamp info
StampPlot - Graphical Data Acquisition and Control
As Marty said, the Propeller can (currently) run at 16 X 5 Mhz = 80 Mhz divided by 4 cycles per instruction = 20 Mips. So the current (faster later) execution speed is 20 MIPS per cog. Assuming you need high speed, you will need to run your program in assembler because the Spin interpreter is quite awful, perhaps 200X or so in its performance compared to assembler. So in assembler your example to toggle an out put pin is:
Loop move· outa,!outa
······ ·jmp··· #Loop
which takes 2 instructions, and at the stated speed of 20 Mips is 10 MLoops per second, or 100nSec per loop. Not as fast as an SX, but still pretty quick really.
Spin is awesome if you don't need high speed. But if you do, then simply run the high speed requirement in one COG in assembler, and carry on!
This is really great stuff!!
Cheers,
Petrer (pjv)
Thanks for the replies. Now, I get it that Spin is not as fast as assembler. I also get that there are no on-board periperals, such as A/D or PWM or I2C. I know the speed I need to run at (for my current project) is <2000Hz, which on the scale of uontrollers is pretty slow. But, in that 2000Hz, I need to perform 3 A/D, 1 freq check, read in SPI data, possibly log a bunch of data, perform a lookup, and send out a pulse at a specific time. At 142KHz, I think I would have enough to do it. Do you agree? I'm still trying to figure out if one cog would do it, or if multiple cogs will do it???
Now, these things run at 80Mhz in parallel, or 80Mhz serially? Each cog is running at 80Mhz? So, everytime that hub spins, each cog is driven by 8 clock cycles, performing 8 "calculations" per hub revolution, or is capable of only one "calculation" per revolution? Is each cog essentially faster than one BS2?
Can anyone let me know how quick the A/D object runs, for reference?
Lookup tables? I am still trying to figure out how fast they work, and if I can have a 3D (2 inputs => 1 output) lookup table. Can anyone confirm this?
Sorry for so many odd timing questions, but this parallel thing has tossed away my capability to figure out if ucontrollers are fast enough for me. And, I think many green code writers will also want to know.
Thanks,
-Parsko
The HUB rotates at half the clock speed, though, so a COG har 16 clock-cycles between each time it is allowed access to the shared RAM or ROM, but as it can do LWORD(32bit) Read and Writes, that's not going to diminish efficiency much.
(Assembler instructions take from 4 clock-cycles and upwards)
Spin has a certain performance-hit because the interpreter needs to load tokens(the 'compiled' spin code) from the system RAM, but as it on average uses 250 Assembler instructions for each Spin sinstruction, it doesn't need to do those accesses too often.
You mentioned the BasicAtom...
I noticed in a recent Nuts&volts magazine that they brag about 80K instructions / second...
And the Propeller also does 80K, but that's on a single COG.
But that's not what it's all about.
(Even if it multiplies up to something incredible
What REALLY matters is that you can start separate objects(Task/Program/Whatever you like to call it) and let it do its job, without bothering about time-sharing, interrupts or any of that pesky stuff.
Have an AD object running? Set it to measure continuously, and to update a variable in System RAM, that way you always have a fresh value waiting.
Need to do serial output?
Fire it up and point it to a location in System RAM where it finds what it is supposed to send.
Need to have it displayed on a screen?
Add a couple of resistors and run the TV Object...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows
Use the opportunity to learn a language...
Edit: forgot to add
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
"(Assembler instructions take from 4 clock-cycles and upwards)"
So, at 80Mhz, each cog can do 4 assembler instructions (16/4) per hub revolution (assuming ideal conditions, of course)? Or run at 20Mhz.
AND it could do 80,000 (80Mhz / 4 / 250 inst.per.sec) Spin instructions/second PER COG???
So that's 640,000 spin instructions / second (ideally)???· Or 1.5625x10^-6 sec/instruction.
Huh.·
Post Edited (parsko) : 4/3/2006 12:03:03 PM GMT
Don't get too wrapped around the axle on the whole speed thing; I'm sure you'll find it plenty fast and where you need more speed than Spin can provide you are able to add assembly as you desire (note that assembly programs are always launched into their own cog).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
You got it.
Each COG runs 20,000,000 assembler instructions per second........ or 160,000,000 for the whole chip (but not in one program).
Each COG runs 20,000,000 / 200 (approx) = 100,000 Spin instructions per second........ or 800,000 for the whole chip, and this CAN be all in one program.
Alternately some mix of assembler and Spin COGS...... any COG can run assembler OR Spin, not both.
Cheers,
Peter (pjv)