Anyone done any real benchmark comparisons between propeller and say a small AR
webmasterpdx
Posts: 39
Problem I have is this. I would love to find a multiprocessor embedded chip at the price of the propeller, but I'm not convinced it's that great an architecture.
I have a strong background in supercomputers (so I'm used to working with parallel processors) and in embedded systems development (BSEE but most of my work has been in software).
First, the Cogs don't really run in parallel as the program memory is only accessible by one Cog at a time. It does have the advantage that no context switch is necessary as each Cog holds it's state until it gets the hub again. However, you could achieve the same thing by using one processor and having the state stored in a windowed based system that increments for each hub access (like the spark processor architecture except instead of registers, you are storing the context). Would have saved duplicating the processor core 8 times with the same results.
If I ran 8 PICs in parallel they'd kick *** on the propellor. I'd just need to sync them up with the same external clock and maybe use a line or two to act as semaphores between chips. Could use SPI between chips or a parallel interface to a bus and some bus protocol. Sure you can avoid that in the propellor as it's all built in, so getting data from one processor to another is easy, but I'm pointing out that PICs could transfer data back and forth as needed. Or you could use some common memory or something. Sure it could only be accessed by one processor at a time too, but it wouldn't have that code bottleneck. The only bottleneck would be accessing the same data.
It'd be easier to program since it's well known and can be programmed in C too. In fact, if you wanted, you could set up a hypercube of PIC processors using SPI interfaces between them. There are many classes of problems that this architecture could solve.
Bottom line, the ideal "propeller" chip would have been one that had 8 processors that could have accessed memory all at the same time. That would have been one hell of a design. By removing that, you are only helping avoid context switching, which if done preemptively wouldn't slow things down appreciatively. I'd estimate a very fast arm processor for $8 could outperform a propeller.
Has anyone got any hard data showing any advantages.
Note that I do acknowledge that the propeller has advantages when it comes to video for TV applications like a genlock titling program or TV games like the Hydra games board.
However, I don't see it for a general purpose computing engine for embedded systems....
Thx
-D
I have a strong background in supercomputers (so I'm used to working with parallel processors) and in embedded systems development (BSEE but most of my work has been in software).
First, the Cogs don't really run in parallel as the program memory is only accessible by one Cog at a time. It does have the advantage that no context switch is necessary as each Cog holds it's state until it gets the hub again. However, you could achieve the same thing by using one processor and having the state stored in a windowed based system that increments for each hub access (like the spark processor architecture except instead of registers, you are storing the context). Would have saved duplicating the processor core 8 times with the same results.
If I ran 8 PICs in parallel they'd kick *** on the propellor. I'd just need to sync them up with the same external clock and maybe use a line or two to act as semaphores between chips. Could use SPI between chips or a parallel interface to a bus and some bus protocol. Sure you can avoid that in the propellor as it's all built in, so getting data from one processor to another is easy, but I'm pointing out that PICs could transfer data back and forth as needed. Or you could use some common memory or something. Sure it could only be accessed by one processor at a time too, but it wouldn't have that code bottleneck. The only bottleneck would be accessing the same data.
It'd be easier to program since it's well known and can be programmed in C too. In fact, if you wanted, you could set up a hypercube of PIC processors using SPI interfaces between them. There are many classes of problems that this architecture could solve.
Bottom line, the ideal "propeller" chip would have been one that had 8 processors that could have accessed memory all at the same time. That would have been one hell of a design. By removing that, you are only helping avoid context switching, which if done preemptively wouldn't slow things down appreciatively. I'd estimate a very fast arm processor for $8 could outperform a propeller.
Has anyone got any hard data showing any advantages.
Note that I do acknowledge that the propeller has advantages when it comes to video for TV applications like a genlock titling program or TV games like the Hydra games board.
However, I don't see it for a general purpose computing engine for embedded systems....
Thx
-D
Comments
Here is where the wheels fall off your argument. Each cog has its own program memory and they run completely independently. The hub is simply a very large pool of shared memory.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Computers are microcontrolled.
Robots are microcontrolled.
I am microcontrolled.
But you·can·call me micro.
If it's not Parallax then don't even bother.
I have changed my avatar so that I will no longer be confused with others who use generic avatars (and I'm more of a Prop head then a BS2 nut, anyway)
1) GOGs DO REALLY run in parallel. As long as they are working within their COG space. All those device drivers, especially video would not work otherwise.
2) "If I ran 8 PICs in parallel they'd kick *** on the propellor." No they would not.
Eight PICs trying to share some common RAM would be a night mare to implement and no doubt end up slower.
Keepin the Props deterministic timing would no doubt be a pain if possible at all.
SPI between chips would be much slower. A parallel bus would still be much slower not to mention eating all your valuable pins.
3) The Prop is extremely easy to program in Spin or PASM as it is. There are also 2 different C compilers available.
4) A Hyper cube of PICs could no doubt be done. It would be an order of magnitude more pointless than my Z80 emulation for the Prop running CP/M [noparse]:)[/noparse] The hypercube architecture may be a good fit for many problems but there are a million better ways to do it.
5) The ideal propeller chip would NOT have 8 processors that could have accessed memory all at the same time.
Why, because inevitably two (or more) COGs will want to update access a location simultaneously. One has to go first.
At that point there goes your deterministic timing.
Besides an 8 port RAM is probably not in anyway practical.
6) "only helping avoid context switching, which if done preemptively wouldn't slow things down appreciatively"
No, no, preemptive switching again blows away the deterministic timing of the COG. You could never be sure that your piece of code on your COG is not being preempted by some other COG that may well be running code that you did not write yourself (a driver say).
7)"I'd estimate a very fast arm processor for $8 could outperform a propeller."
Perhaps in terms of RAW compute speed an ARM would win. BUT there are a whole class of real-time embedded applications where it would not stand a chance. Try driving 16 PWM servos at the same time whilst also generating video.
The value of the Propellers deterministic timing and the ease of mixing and matching objects from OBEX or else where which comes from the separateness of the COGs should not be underestimated.
Bottom line is that the Prop is not a general purpose computing engine it's a micro-controller for real-time embedded systems where fast deterministic timing is paramount.
There is not much point in comparing the Prop to other processors with benchmarks. One should choose ones chips to suit the problem at hand. It's hard to think of a general purpose computing benchmark that by itself would point you toward the right selection.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
First, welcome to the Propeller Forum; quite fascinating to say the least; some wonderfully bright and clever people here. Ok, let's gather some information related to your post:
1. Whos "SuperComputer(s)" have you background(s) with?
2. What benchmark (and uC) would you like to use to compare a Propeller with? (Do you have the benchmark code available?)
3. How are you going to run 8 ARM CPU's in parallel on the same wafer?
WRT to Q3; The Propeller is a single chip implementation of 8 independent CPU's (called COG's by their Designer); each COG has its own (private) 2KB program space and each COG shares access to a common pool of 32KB on-chip RAM. Each COG can run either independently from all other COG's or in some form of co-operative way between itself and any other (number of) COG(s) on the same wafer. If you want to tie a common clock between multiple Propeller chips then you can multiply 8 COG's per chip connected to the "common clock" and also wire access to "common storage or I/O" - and maintain synchronicity betwixt the lot - concurrently - yes, in one sense a clock-synchronised Super-Computer with 8 X N elements; but; remember this silicon was designed as a uController - not as a general purpose computer. Browse this Forum and you might think otherwise
Access to the common RAM (called HUB RAM) is controlled by an on-chip bus mechanism called the HUB. The HUB provides a rotating window of time-slice access to the common RAM - in a worst case scenario (assuming a COG wants/needs access to HUB RAM), the latency is 22 (but typically less) clock cycles. There is no other interrupt, arbitration or otherwise enforced access to HUB RAM. There is also no interrupt handling or other hierarchical access mechanisms other than thoses deemed necessary by an application programmer. It seems there are true atomic "test and set" facilities in-built into the access mechanisms however, I am not clear on how this is done albiet to say the SPIN default language has these facilities. Interestingly, condition code flags can be set and tested selectively by a Programmer and used some time later when it may be more efficient to deal with them. This is truely a clever design and implementation lending itself extremely well for a multi-stage pipeline architecture embedded within a multi-CPU on-chip design. Consider instruction restart or unroll without interrupts - Programmer defined and clock countable!
Considering any COG can access any I/O pin (user defined as to use) and an arbitrary "[noparse][[/noparse]external] device" can be connected to any (set of) pin(s) [noparse][[/noparse]as either I or O assignments] all COG's have equal "bus speed" access to any I/O pins - without need for (specific) arbitration, hardware interrupt or other overheads as would be required in traditional designs. All clock cycle predictable.
There are also no other overheads involved in doing all this - of course the Programmer is responsible for making sure they don't trash their own code (as always).
Finally, no specific CPU to CPU communications are required; things like inter-processor interrupt or cache-invaldate cycles (be these internal to the CPU [noparse][[/noparse]module or bus architecture] or not); all can be done using simple HUB RAM locations or even pin assignments if you want to get really clever
Well, that's a start; so in answer to the above, what say you?
Cheers,
HarryE.
I need to have three rotary encoders (256 step and 32 step concentric) and seven push buttons where their functions change based on the value of variables. They control four 1024 position SPI digital potentiometers, eleven SPST analog switches, and six DPDT analog switches. some of which are through an I2C I/O expander. It also has to send serial commands to an OLED display. Heck, the three different communication protocols are going to hurt enough, but trying to do that with interrupts would melt my brain into a big puddle of failure. Using the prop gives me plenty of head room to be sloppy the first couple times around.
The second reason that I chose the prop over anouther solution is that this forum is amazing. It is like having a big bag of experience to grab what I need from when I get stuck. I investigated using a pic, but it took a ton of googling to find any answers, and they were scattered about in different places. This place has everything, It has answers, schematics, hardware, code examples, drivers, debates, books, it even has parallax staff on the boards, and all without much drama. If I had found a faster solution I wouldn't have choose it.
I know that it wouldn't really apply to someone with a lot of experience already, but they are valid reasons for someone like me.
Oh yea it also has an easy way to scale power consumption. That is a huge plus, it makes it flexible.
If you want to breadboard up a project, it's possible to give the prop a serious go for less than $30.
Give the thing one man day of effort. I think you will find it to be a unique, fun and very capable design where a minimum of external components are required to accomplish many things.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Instead of a single chip CP/M, perhaps a single chip Linux. That will be into ARM territary.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Just wanted to correct this. Each cog has 512 -Longs- of ram. That's more than 4 times 500 bytes. [noparse];)[/noparse]
I was asked what supercomputers I've worked with. First, I worked at a now defunct company that was called Floating Point Systems (FPS) during the 80's and they made array processors (at the time they were what today are known as DSPs inside a big box as they had to be implemented discretely as VLSI was only just appearing on the scene). We had multiple boards each with it's own "DSP" and a mix of different boards. Then, later we had hypercube architectures running with NMOS transputers and a board at every node and we had systems as big as 10000 nodes.
Then I worked for a company called Aptec that made an I/O supercomputer mostly for military applications and it also had a vector processing board (again like a super DSP).
Then I worked for Cray Research and worked on various architectures.
I also worked for what today is the high end Sun superservers that basically consists of 64 suns in a single system with a fully coherent cache.
I also worked on a high end tester that had multiple boards in parallel and special "paths" to each pin on the chip tester. I was in charge of calibration so I had to do TDR's in software to get timing to each pin with a resolution of 2 picoseconds.
I think that was the last highly parallel system I worked with.
As for deterministic behavior, every real time system (and I've worked on a few dozen in my life) has hard deterministic requirements. It's never been a problem using a decent RTOS. Essential IO happens with interrupts as someone correctly said with a discrete processor. The COGs are not 100% deterministic unless they can run SPIN code without waiting for the HUB.
Also I have read the specs of the propeller (so I don't need a lecture on how it works), and I have not read anything about each Cog being able to run it's own program memory. Can you point me to the section and page number in the documentation? It did say that it can run certain instructions, but I'm assuming thats things like keeping it's I/O going in parallel. Can it run SPIN code on it's own COG?....or does it require the HUB to do that (because thats what I thought). I couldn't find much on how to get the Cog to do anything except run HUB code. Is there a special document (maybe with examples) that I can read????
I agree, it doesn't matter what language. If the architecture is good enough, I can use whatever is there. It needs to be significantly good enough though.
For the example with 8 PWM servos. I could easily implement 32 PWM servos on a PIC by just having a 10uS timer and determining based on the PWM timing whether I needed to turn on or off that pin. I just need enough pins and enough memory. a 40 pin PIC would probably do it. Now, what IS difficult is doing video at the same time. I did say that the propeller is good at video. I typically am not interested in video applications. Why on earth would you want to control 8 servos AND video at the same time???? Not exactly a real world application anyways.
I'm aware it's not a general purpose embedded processor, but what I'm saying is it's applications are very limited unless I can figure out how to run code in all cog's simultaneously.
So, by all means correct me.....show me where it says that you can run program code from a COGs internal RAM?????
(BTW, I wish the internal ROM was a programmable flash, as if you aren't doing video, you don't need that space wasted on fonts, and there are fast ways to implement logs and sines without such big tables.....however, I do have the 32K of RAM).
I really want to use this chip eventually, as I am interested in creating a powerful virtual sound synthesizer, and an 8 processor with frequency synthesis in each COG would be great. I just need to be convinced that it can be done faster on a propeller than on something like an ARM.
Oh, someone said you couldn't do benchmarks.....thats not true. Choose a few different apps (some without video please) and implement the same thing on an 80MHz arm and an 80MHz propeller chip.
Someone mentioned a medical monitor. Apart from the FDA requirements thats actually a very good example of an app that the propeller might be good at. You typically are reading several ECG waveforms from the heart and you have to "treat" the signals received, and maybe SPO2 and NIBP (blood pressure) all at the same time and then forward the data in a data stream format to a wireless network hub to the central nurses station and display the waveforms on an LCD display simultaneously. (I've worked on a medical monitor too.....the welch-allyn micropaq ambulatory monitor which communicates using wireless back to the main Acuity workstation on the network which the nurses monitor multiple patients on). Thats actually an app that a propellor might actually be able to do. However, you typically need to store more data and you can get an arm with more built-in RAM, but it could be done using a propeller. I'd prefer to use an ARM as there are less unknowns though.....which is my whole point.
Anyways, anyone point me to where it shows how to run SPIN or assembler code on any cog?
Thanks
-Donald
Propeller Datasheet V1.2 (page 16 of 37):
Cheers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
SPIN can't run within a COG. The SPIN interpreter runs on (and fits into) a single COG. The SPIN code itself is in HUB-RAM. You can let run ASM in a sinle COG. See command "newcog" etc. The code space within a COG is limited. A bit below 500 Words for data AND code.
Edit:
Of course you can have up to 8 cogs that each run some different ASM.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
OK, so SPIN runs on COG 0 and you can spawn off assembler code to run in each of the other cogs, and thus, they all run in parallel.
Is there something better than the chip spec. Is there like a User Guide or an intro to programming manual or something like that that has both simple and complex examples in it...../??????
Thanks
-Donald
Spin is an interpreter that comes in the Propeller's masked ROM, written in the native cog instruction set. It is loaded by the hardware into cog 0's RAM during the reset process where it's passed information by the hardware to start by interpreting the Spin byte codes in masked ROM for the bootloader. The bootloader eventually executes a COGINIT instruction which restarts the same cog, reloading the Spin interpreter from ROM, this time interpreting the newly loaded Spin byte codes in the hub address space. The 32K masked ROM is in the hub address space, the same as the 32K hub RAM.
The COGINIT instruction (as described in the Propeller Manual) loads a block of 512 long words (2K bytes) from hub RAM to a cog's local RAM, initializes the cog, then starts it executing from location 0 of its local RAM. The cog then executes its code, one instruction per 4 clock cycles, independent of any other cogs. The shared 32K of RAM and 32K of ROM is available using special instructions on a round-robin basis with the other cogs. Although there is a variable latency for this access since the cogs are not normally synchronized with their assigned time slot, the programmer can synchronize the cog to the hub and to other cogs producing a deterministic relationship between the cogs and between the assigned time slot and the cog. This has been done for several I/O drivers.
Added: The OBEX has lots of example code: obex.parallax.com
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
- Propalyzer: Propeller PC Logic Analyzer
- BMA: An on-chip PASM Debugger
- SPUD: Spin Source Level Debugger
Post Edited (jazzed) : 8/30/2009 3:52:47 PM GMTThere are "sticky" threads at the top of the thread list for this forum including a "Getting Started" thread. There are several tutorials there for both Spin and assembly language. There's also a bimonthly column in Nuts and Volts magazine that's now focused on the Propeller. The index can be found on the main Parallax website under the Resources tab.
Spin is started by default on cog 0 and that Spin code can replace the Spin interpreter running in cog 0 with an assembly program or it can spawn off either other Spin interpreters or other assembly programs in the other cogs.
It wasn't a medical monitor we designed using an LPC2148 ARM, but an "ektacytometer" for measuring red blood cell deformation, which occurs in certain rare diseases. This is the machine:
www.esiee.fr/~research/documents/Index/Projets/Ektacytometre.html
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Post Edited (Leon) : 8/30/2009 4:11:53 PM GMT
I have a lot to read here. This'll keep me busy for a while. Since it's sunday here in Oregon, I won't have much time except here and there during the week, so I'll get back to y'all in a couple of weeks. I'm starting to come around
Thx
-Donald
I'm sorry but I think you do need a lecture on how it works. That sounds a bit harsh but l don't mean to be.
Cogs are 100% deterministic. They can only get HUB RAM access when the HUB says so which is on a round robin cycle. This access "window" is happening on a regular period sync'ed with the COG clock cycles. So once the COG has made its first HUB access it is known exactly how many ops it can perform before it has access again.
This fact has been made use of in order to synchronize COGS for video, for high speed communication, for high speed access to external RAM, data grabbing etc.
The only thing that can upset this determinism is if another COG changes the clock frequency, messes with your I/O pins or calls COGSTOP on you.
A COG can easily run a program in its own memory. Yes it's will be quite a small program and will probably be written in PASM. Although it could be compiled from say Bean's PropBASIC or other language.
PASM is easy to write anyway compared to many other assembly languages.
Do check the Propeller manual again, a third of it or so is dedicated to PASM and how to get a program into COG.
There are some subtleties about the Propeller that may not be immediately obvious from a read or two of the spec sheet and manual. They are to do with how easy it is to bolt a bunch of functionality together, including functions one may not have written ones self, all of which could have strict timing requirements and you don't have to make changes to any of them or worry about hooking into interrupts or assigning priorites etc etc.
As you said, given a fast enough CPU, some interrupts and possibly an RTOS in may well be possible to meet all real-time requirements. But when a new requirement needs adding it can't just be dropped in without reviewing its effect on all the other code that is clamouring for time.
OK that's enough for the lecture [noparse]:)[/noparse] lets have a productive and fun time with the Prop (where it fits, of course).
As for your proposed sound project, the Prop may not be a good fit. When I think about sound I think DSP and fast-multiplies. The Prop I has no MUL. Maybe pushing things a bit. But I found that whenever I think that someone goes and makes it work anyway [noparse]:)[/noparse]
Edit: Did I forget to say "Welcome"? Welcome to the forum, have fun.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
There are more examples but that one is quite simple to understand. If the COGS where not deterministic there would not be a way of synchronized them without losing sync at every event. If you see the code is exactly the same in terms of instructions used, number of.
Have fun.
(Note: Maybe the xmos chip is better suited for your purposes)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
but seriously..... really? I'm not even sure there's a limit to how many situations that would be good for. How many industrial machines have an video interface? Whether the machine sorts Smile, or moves some physical axes, or just about any 'real world' application... an interface is pretty handy. Some things get around with leds or some small lcd displays, but a vga display is very very usefull. (Even if only hooked up for diagnostics or something.) Industrial control is one of the most important places for deterministic control, and just about everything has a display. Especially if something is programmable, imagine writing a program with an lcd screen... ehhh
I worked on an indexing drive for the turret on Mazak CNC lathe Thursday, and boy do I wish it had an actual display. To read/write parameters, or diagnostics, you have to buy a small keypad with some 7-segment leds on it and hook it up to the drive. It can only display the name OR value of anything at once, and if it is more than 4 digits, then the low portion is displayed/edited, then the high portion. Being 7 segment, you get some pretty funky looking parameter names to boot.
.... Just.... Seriously? That sentence boggles my mind.
Not for me, not for you. But maybe for others.
The Propeller is quite different to other µCs. Some here use it for whatever comes into their minds. No, they don't use it, they abuse it! The Propeller is excellent for scenarios like this:
One master-program that keeps track of the general tasks and ties the ropes together. And 7 busy helpers that do small(er) tasks at a high speed. You get the best performance when you do have a steady flow of data coming in that needs processing in several steps (the COGs have to do that) and the final result has to go to the outside somehow.
An example is an ignition system I made. One COG runs SPIN-code that looks for over revs, and other not-so-really-time-critical tasks. One COG reads the position sensor, one does make pre-calcs to get positions to within 0,1° of crank, one COG adjusts the timing (advance the ignition point based on a table, doing bi-linear interpolation), one COG cares for firing the ignition coils and switches them off after an exact time (too long in the on-state, they would simply burn), and one COG handles the serial connection that displays real-time data (like RPM and advance). The result: 60000 RPM with 24 cylinders and accurate to 0,1° crank.
Now do that with any other µC...
An other example is my Modbus interface:
One COG runs the C-program that does most of the logic. That is decode commands, map register/coil-numbers to memory etc. One COG receives the serial data. Up to 4 COGs are shifting the data that was received or has to be sent in and out to some extender cards. They do run all the time, so the data is most up to date, even when not requested. To make things even faster, I could use an extra COG that does calculate the CRC while the data is received.
If you can't use the parallel processing power of the Propeller, there are better choices.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
There are things I can do with a 500mhz ARM that the propeller can't...the reverse is also true.
There are things the 500mhz ARM is too slow to do...so we resort to using a mobo/ssd with a quad core cpu
on it running Linux....I can have a prop, ARM, AVR wake it up and tell it what to do, then get the data
and shut it back down.
At first glance I though the propeller was a toy, nope, I was wrong.
The 500 instructions space each cog has seems a bit small...but you can fit a lot of asm code in there.
And if you can program in asm for any other processor then you won't have problems using pasm.
It's far far easier to use than asm on a pc.....it's childishly simple in comparison.
Self altering code and multiple processors takes getting used to though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Some mornings I wake up cranky.....but usually I just let him sleep -
Post Edited (HollyMinkowski) : 8/30/2009 8:07:00 PM GMT
Take 4 or 5 functions the prop does well, duplicate the function on the other microcontrollers, and compare the results.
Take 4 or 5 functions the other microcontrollers do well, duplicate the function on the prop, and compare the results.
I would bet the prop wins hands down on any functions that required high speed and/or deterministic I/O timing.
The propeller is just outstanding for precision timing chores.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Some mornings I wake up cranky.....but usually I just let him sleep -
The Arm could take care of a lot of regular memory eating application code, networking etc. Would be running Linux.
The Prop(s) handle the I/Os, tricky real-time stuff and provide a display for free.
From experience it's a lot easier to knock up real-time code for a Prop than to have to create the same functionality as a device driver in Linux.
Of course the ARM could then host the development environment for the Props, bstc say.
By the way Webmasterpdx, if you are interested in the sound processing capabilities of the Propeller check out this amazing project: www.openstomp.com/
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
1986 Chevy EL Camino·· No prop yet
1984 Suzukie GS1100GK No prop yet
Those are the same I know.
There are 20,000 rpm motors (F1 for example) but they are 8 cylinders. And some pressurized-air motors at some 30,000 rpm... I read bigger motors are always lower in revolutions. We want to know what kind of motors are you talking about !?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU