Why would you choose a Propeller instead of...
Alex.Stanfield
Posts: 198
I have some hard time "selling the Propeller" to friends and DIYers.
There are many options out there today that have lots of attractive features like UARTs, I2C, SPI, ADC, PWM, etc and are even of lower or similar cost compared to the Propeller. Add all the hype around them like the Arduino family, Raspberry, etc
So, the question is:
Why do you choose the propeller?
I'm interested in both a DIY and/or professional perspective.
[disclaimer]
I'm not saying you shouldn't choose a Propeller, I do like it. I just want to know which reasons you people out there have to favor it.
[/disclaimer]
Alex
There are many options out there today that have lots of attractive features like UARTs, I2C, SPI, ADC, PWM, etc and are even of lower or similar cost compared to the Propeller. Add all the hype around them like the Arduino family, Raspberry, etc
So, the question is:
Why do you choose the propeller?
I'm interested in both a DIY and/or professional perspective.
[disclaimer]
I'm not saying you shouldn't choose a Propeller, I do like it. I just want to know which reasons you people out there have to favor it.
[/disclaimer]
Alex
Comments
The second strong point of the Propeller for me is the multi-core aspect. In my product, we have to process data as fast as possible through a pipeline from a bunch of sources to a single destination. Once I got this pipeline up and working then I can forget about it: any changes that I make to the other cores (such as adding a complex and slow command processing state machine) won't affect the speed of the pipeline core. This strong orthogonality makes the Propeller programming easier. You do not need to understand the whole system to make changes.
That being said, some people that I have talked to have commented that Parallax is a bit quirky, and that this difference from the norm (for a semiconductor company) is a problem. It makes it hard for them to take the Propeller seriously, and it's something that I hope Parallax Semiconductor can fix (if it ever seems to be anything but a shell).
Professionally: Development time. In my most recent case, it only took me about 20 minutes to create a program for a functional test fixture that feeds a VGA test pattern and stereo audio through a breakout board for an ARM processor board. The test setup was originally using an ARM based board running Linux which meant a total test time of about 6 minutes (boot time, etc). With the Propeller, it's running the audio and video in about 6 seconds.
- OBEX has pretty much everything they need
- prototyping with Propeller is very quick (time to market)
- support from Parallax (FAEs) and from these forums is very good
- capability, ease of program design with multicore removes headaches
- PCB layout is easy with software peripherals - route it the way you want to, not the way the chip demands
- debugging ability with composite video is useful
- quick adaptability from one project to the next
The production use is typically 100-5,000 units. Propeller does very well in lower-volume production projects.
From a production standpoint, the Propeller has won at finding its way into new technologies in these areas: CNC/3D printing; renewable energy; medical; robotics (UAVs, educational, etc.); biofeedback; point of sale terminals; etc. Sometimes we do the customer's entire project (PCB, firmware) and other times our FAEs just provide basic input on layout, coding practices, etc.
Ken Gracey
The Propeller has all those as soft peripherals -- and more. Unlike chips with dedicated hard peripherals, you can assign any peripheral to any pin. 'Need five UARTs? The Prop can handle that with ease. Could you do that with a PIC? And how many cheap micros can do all that AND display video at the same time -- or speak? That's just one 32-bit chip you need to learn about, and you have your choice among several languages and dev tools. Oh, and did I mention no messy interrupts to worry about?
I've programmed many other micros. None of them come close to the Propeller for ease of use and rapid application development. When performance and productivity count. the Prop nearly always comes out ahead of the pack.
-Phil
I like the ability to start with a Propeller and just allow the project to expand and grow without too many worries of maxing it out before I'm done. Case in point: one of my first projects with a Propeller drove 4 digital pots, a VGA output, a mouse, recorded data to an SD card, provided a link to some digital thermometers, sported an SD card swap-out switch, a Real Time Clock, EEPROM, plus 3 pins were inputs coming from photomultiplier tubes (one pin for coincidence counting) counting photons. I'm not an electronics guy by training but I found the Propeller to be so easy to work with, I just kept adding on things as I went along. My code writing skills were (and still are) very bad, but the Propeller still managed to swallow all the junk I fed into it.
The only reason I even think of using other chips these days is because I have to please other people sometimes, the ignorant unwashed masses of humanity who know nothing about Propellers.
If your tasks are simple, then a Prop will not compete with the lowest-level uC ( eg 44 pin AT89LP52 at 65c/100),
but a Prop can 'be in 8 places at once', has very flexible pins, and 16 counters, and it can resolve to 12.5ns, in many cases.
Those timers are also 32 bit, with 32 bit atomic access.
A Prop is very good for keeping tasks from 'getting tangled', especially as a project adds more real-time IO.
Some designs use a small uC and a Prop.
(sorry about the "just", Skip
The only real limitation is memory.
There are several documented ways to expand that when such is called for.
But for many projects the Prop can do it - without any support hardware at all.
Speed, power, flexibility (, and the OBEX).
It's cheap enough to compete with a Pic based board,
but won't come up short of capability half way through the design cycle.
I generally agree with every comment, however i still have a "but" feeling on several matters:
- SW peripherals. Sure you can do it, so what? How does using one brain (cog) to do a trivial task (uart, etc) benefit the programmer? Instead of assigning one from a pool of commodity functions you have to waste one of your "silver bullets" for that.
- pin flexibility. Sure that's good, and expected i guess; even though some micros will have that restricted.
Some stuff on the propeller is sophisticate and beyond the common and some trivial stuff i wish it were more simple.
I hope the propeller 3 will include the best of both worlds.
Alex
Good point.
Real world example, before the propeller, I was using picaxe chips. If you wanted to wait for a serial input, the entire chip would hang until a byte came in. And if no byte came, the chip appeared dead!
Take a microcontroller and ask it to listen to 4 serial ports, an I2C bus, a keyboard, talk to an SD card and drive a display all at the same time. Most micros can do a few of these things, and most can do all these things, but they struggle doing all these things all at the same time.
I think this is where the propeller really shines.
As to the "so what?", suppose you need a UART that works with Baudot (5-bit) code using shift-in and shift-out, or how about a USART that understands SDLC or HDLC? Maybe you need Manchester coding instead of NRZ. The point is that hardware peripherals tie your hands with finite feature sets, probably determined by a committee who think they know what's best for you. By contrast, soft peripherals give you complete freedom to define your own features.
-Phil
I soon learned to think of it the other way around. Let me explain by example:
Let's say you have a normal MCU and make use of a UART. At some point a character will come in and an interrupt will fire off causing your processor to stop doing what it was doing and run the interrupt routine which will read the character and buffer it or whatever. BOOM at that point in time you have not just wasted one of your silver bullets but you have wasted your one and only bullet. You absolutely cannot be doing anything else at that moment.
Now, you might say that does not matter, the interrupt returns and things continue. But if the thing that was interrupted was time critical you are sunk.
The major advantage of the "silver bullets" is that it makes it very easy to mix and match drivers and other code. You can add a UART object from here and an I2C from there, throw in some PWM or whatever. Never do you have to worry about hooking interrupt routines up to devices. You don't have to worry that some new feature will disturb the timing of your existing program. No fuss with juggling interrupt or task priorities.
As all thse silver bullets are totally independent timing wise you can expand your program with out worrying about breaking anything. (As long as objects keep off each others pins and you have memory of course).
Now it is true that using a whole 32bit CPU for just a UART seems wasteful, but don't forget that UART can be a bit cleverer than a regular UART. It can support some odd serial protocols, as noted above, it can do some work on higher levels of the line protocol if you like. And of course it can support more than one port. I believe four ports are supported by at least one object in OBEX.
What about PWM drives. You may have a couple on a regular MCU. The Propeller if can drive many PWM channels from a single COG, up to 32 in fact.
Bottom line is that the flexibility afforded by te "silver-bullets" together with the fact that any COG can use any pin for any function makes real-time software development so much easier and many things possible that would otherwise not be.
P.S. I'm not sure why the Rasperry Pi is up for comparison here. It is not an MCU, it is a totally different animal suited to totally different applications. Yes it has some GPIO but that's not really in the same league.
However, the Pi and a Propeller combined into a system has some interesting possibilities. Each doing what it is best at.
Every question I have ever asked has been answered openly, promptly, courteously, and completely... right here:)
Regardless of your personal experience (whether amateur or professional), Parallax seems to have a development path to optimize your progress.
You just have to look around a little and ask a few questions.
There are guys here on the forum who really needed only a 10 page description, and they were off to the races.
For others there are all kinds of materials directed at all levels of experience and competence.
Why choose the Propeller?
... you will never regret your choice, you will get more done in less time, and you will smile more.
Rich
1) It is available in a stonking great 40 pin dip package that I can see and connect to easily. Breadboarding is easy.
2) You don't need any special hardware to program it.
3) Because it has multiple CPUs and no dedicated peripherals it is an experimenters dream. It can have any of the opening posts peripherals if I like. In any quantity or combination that fits or none.
4) Because it does not have interrupts it is a breeze to mix and match drivers and other software as required. From OBEX or wherever.
5) The support from Parallax and this forum is about the best I have ever seen.
6) I had a pile of "dead" AVRs on my bench that somehow got their fuses set wrongly and I had no way to unset them. Grabbing a Prop was the easist cheapest way to continue.
7) Spin and the PropTool or BST or Simple IDE are drop dead easy to use.
8) When you need the speed PASM is about the easiest assembly language I have ever used...
9) ...and that is because the COG instruction set is so simple, elegant and orthogonal.
10) You can use any pin for any function connected to any processor. This makes PCB layout or just knocking up a bread board circuit so easy.
11) Pins have a decent current drive for LEDs and such.
12) If you have a bunch of Propellers in you inventory you can quickly knock up a prototype. No scouring the catalogs of available AVRs or whatever trying to find the one that has the right combination of peripherals for the task at hand, no ordering that, no waiting for it to arrive. Just do it. No having to swap to a new part and redesign everything around it when you find your requirements have changed.
There. That should be enough for now.
I saw the PASM code and SPIN for the little graphics demo that Chip did and just had to have one. The whole package was just kind of beautiful, and that sucked me in. I stayed with it because of the people surrounding it, and I could make a portable setup to use when I travel to far away, boring places. Makes the day go quick. Blast through whatever it is, then play.
Didn't hurt that one can be doing fun stuff in SPIN + PASM in a day, which is precisely what happened with me.
One just can't find multiple processor like this anywhere, at least not for this cost. Of course, one probably should have a need vor multiple processors, and an understanding of how to use them, or at least a diesire to learn.
Software peripherals. Thisis the most powerful concept. No need for expensivce special hardware, this is THE most flexible method to start experiementing and development. The prop might be too much for you final applications, but it is rarae to find a microcontroller application where it is not enough. A sinngle tool can answer all my development needs, this is a prize indeed.
If you don't care about multiple processors, and don't care about software peripheral and the flexibility it provides, you probably already have something else in mind, use that. You don't need a car if your horse is doing fine.
Let's say you are browsing catalogs or the net trying to find an interesting MCU for some project or perhaps just to see what's around.
One the one hand you come to "normal" MCUs sporting various useful features, UARTs, I2C, SPI, ADC, PWM etc. "Oh goody" you think "I can use that, it fits my task fine".
On the other hand you come to the Propeller with, well, nothing. Oh sure multiple cores is nice but that kind of programming is for rocket scientists and anyway they only have 512 memory slots each, what use is that? I need those peripherals to get my project off the ground.
Quickly you turn the page in the catalog and see what else is available.
You see what I mean here? All that wonderful flexibility and ease of use software peripherals is not obvious. You don't really get the idea and till you have played with it.
Sometimes I think Parallax should sell the Propeller under a dozen or so different part numbers. Each part number would be listed in catalogs and such as having different combinations of UARTs, I2C, SPI, ADC, PWM etc etc. That way potential users would immediately see the chip they want for heir job.
Of course all the different part numbers would be the same Propeller but when you select that device in the Prop Tool it automatically and silently pulls in the software objects required for the peripherals that part is said to have.
P.S. I thought I'd back up the above thesis by showing how ELFA describes the Propeller chip in it's catalog. Well it's even worse than I thought. They don't even list Propeller chips under "microcontrollers". So anyone looking at AVRs, PICs and ARMs would never find Propellers. No, they are listed under "education/kits/breadboards/propeller" in the ELFA scheme of things.
https://www.elfa.se/elfa3~eu_en/elfa/init.do?toc=20966&name=AVR+Microcontrollers
Sorry but I have to disagree with Ken on this..........Support from the forums and FAEs is not "very good", it's EXCELLENT!!!!!
I've learnt and still am learning a great deal from asking questions here, you couldn't ask for a nicer more helpful bunch of guys and gals.
Thanks Heater, you read my mind.
I believe the SW peripheral concept is great for those strange interfaces you need, but using them for anything standard is just a shame. All that geat silicon wasted on a trivial std interface instead of being available for your value added creations doesn't look efficient to me.
Furthermore, getting some std stuff done isn't that straightforward when you are begining (think of set and forget pwm, i2c in your pasm code, etc) Your learning ramp isn't that fast, althoug the power unleashed afterwards is great.
Finally, I don't think this should be a either/or religious thing. Adding std peripherals to the current Propeller architecture would have been above great from every perspective IMHO.
I just finished a project which uses all 8 cogs, however only 5 are used for original creations, 1 is uart to an XBee, 1 SPI (SD) driver, 1 uart for a serial console that i had to interwine an I2C reader to read an RTC
Sometimes great products are ahead of their time, but because they lack some wanted std features they are not valued as they should. And this lessens their chance of rising the bar for the whole industry.
I chose the Propeller because I wanted to dive into parallel programming, I certainly overlooked lots of stuff in the spec sheet (gladly) otherwise I probably would have kept looking around for other alternatives.
Alex
It would be nice if there was an easy way to add a standard peripheral with a drag-n-drop. I've been trying to make time for that in SimpleIDE, but the Education program is the highest priority right now.
Let's say we add a UART hard ware to the Prop I. Well:
1)
The Prop is a clean canvas that has few of those goodies "as standard", instead of getting the run of the mill UARTs etc there were the video/VGA generators and even those could sprout from all sorts of pin variations. that was the thing that got me over from AVRs (and 8051s... sorry).
But then, I often think of something to do, and then think that it would be a shame to use a Prop "just for that", and struggle to think on how to use an AVR instead. I am old and my brain needs interrupts too.
That's an interesting point we didn't mention before, SW peripherals consume hub ram, much more than standard HW peripherals. I know you have workarounds like loading overlaps but that rises difficulty. If you had a huge amount of ram no problem but then you have 32K, not small indeed but you pile up fast with SW peripherals.
Alex
Another good point. And one that has come up here many times. The issue of all that HUB RAM wasted on code that is loaded to COG once and never needed in HUB again.
It occurred to me that it would have been cool if the Prop I used an EEPROM that was twice as big and loaded all it's COGs up from some area of that prior to loading the rest of the code to HUB. That would give us the option have having our COG peripherals up and running by the time the main app is loaded and save a lot of space in HUB. That migh require some tweaks to how the Spin language works though.
I believe with the Prop II loader this is more likely to be possible.
That is the opposite of what I was suggesting. To me the value of Propeller is the freedom to make it behave like any hardware device on pins of my choosing, and provide as many copies of the device as required in one chip rather than having to buy N of those other chips to do the same thing in a larger PCB real-estate foot-print. The customized foot-print cost extends to opportunity lost and inventory as well.
I'd agree here, you need to just get things slow enough that SW can take over, and you do not want the usable silicon-speed constrained by software.
So a a general purpose serializer/deserializer covers that, that can read and or write to pins, at a full clock rate.
The Prop 2 has added threading, which is a nifty way to soften COG usage steps.
In Prop 1, you may have a real time task, using a tiny section of valuable COG RAM, simply because it cannot be interleaved with any other task.
Threading allows you to better fill-up that COG ram, in all but the most speed paranoid applications.
What is a logic element? As far as I can tell it is a RAM based look up table that can become any sequential logic function, AND, OR, XOR etc. Plus a flip flop or two to give it state. By programming that LUT RAM and the interconnections between logic elements you can get pretty much any logic you like.
What happens in larger, more complex, designs in FPGA? Seems that because all that logic is a pain to deal with people put an implimention of a CPU in the FPGA and surround it by some custom peripherals. Of course the CPU and those peripherals are all just configuration of the same logic elements. Turns out that solving the bulk of your problem as a program for a CPU is much easier than designing it into those logic elements.
Hmmm... so the ideal FPGA would probably not be a bunch of logic elements, a LUT and a flip flop is to stupid, what you want is an array of CPU's.
In theory, given fast enough processors and enough of them, you don't need UARTS and PWMs etc. You only need software.
The Propeller is a first small step along that road. Devices from XMOS are another.
If that works for you in practice is another matter. But what we see,in Propeller or XMOS, is that is is hard or impossible to follow the "universal programmable device" road and the "dedicated hardware peripheral" road at the same time.
Here are my additions...
Intelligent Peripherals
1. Take the simple UART - we have a quad port UART in the OBEX that I runs efficiently in 1 cog. But, the UART(s) are not standard uarts because they actually take the characters from a hub buffer (cyclic fifo style buffers of any size) and transmit them, and receive characters and place them into a hub buffer. There are no traditional uart registers that need setting up - just pass the parameters on a start call, including which pins are to be used. You do not need to understand how the object works. It is far simpler than programming a traditional uart!
2. Now, if you decide you want to do some further pre-processing (in a soft peropheral) you can actually dive into the object and add you own code there. Effectively this is what is done with the PS2 Keyboard Driver - it's really an I2C style driver with inbuilt key processing.
* So these objects become extremely powerful and intelligent peripherals. And they don't even interrupt your main processing routines.
Program Memory
3. Both hub and cog program memory is RAM, not Flash or EEPROM as used in other micros. This therefore has the ability to be softoaded, and can be changed on the fly. What this means, is that the micro can set about doing its normal thing. But by some setting/button or whatever, code can be reloaded (fully or partially) to implement some obscure special processing event that only occurs occasionally. For instance, uploading new code, or downloading stored datalogging results.
4. The hub waste for holding the code loaded into cogs can be quite simply overcome. While this has not been done by many of us, it has been tried and proven by some. Of course you don't really know what some of the commercial users are actually doing.
Debugging
5. Debugging is different on the prop. But what chip can have everything running and can then use 1 pin and a serial 100R..1K to display some intermediate code results on a tv monitor? With an extra pin and 100R and 2x 10K you can add a PS2 keyboard for input. And because your code is simpler and in blocks/objects, there are fewer errors. Tried and proven routines can be copied often without fear of failing due to timing constraints.
OS on the Prop
6. We have a number of prop OS versions where you can run code from an SD card (usually microSD).
All with the one Prop chip
* And all of these things can be done with the one prop chip, particularly because the program memory is RAM instead of Flash or Eeprom.
Pricing
7. While the prop is certainly more expensive than a lot of simpler micros, there is a huge cost in inventory savings, in development costs, and reusable code (objects). But once you take what a single prop can do and then compare it with other micros, the other comparible micros costs are dearer than the prop.
Everyone seems to like to compare the simple AVRs, PICs, etc, with the prop - but this is not a fair comparison!
Once you realise how many pins and peripherals you really need for a lot of projects, your "other" micros cost is no longer a simple micro, but a complex micro costing at least as much as a prop.
*** As a final comment...
IMHO the prop datasheet has at least one major and critical flaw... It needs a block diagram(s) depicting all the known intelligent peripherals that can be handled (internally) by the prop.
As an example, find me a chip that can have 4x UARTs, 2x I2C, 2x SPI (one SD), VGA, PS2 Keyboard, and some pins left over? Tomorrow I want 8 uarts, composite video, keyboard and stereo out. Day later I want 6 SPI, LCD and key matrix. All of these can be done using the same chip. No need to search a family of chips with the right peripheral choice, including ensuring the peripherals don't share the same pins!