Parallax Propeller, why is it so overlooked?

The Propeller chip is unpopular for so may reasons: it is very limited compared with ARM Cortex and far from cheap.

The 8 processor model is difficult to design with and this puts people off but there are worse features to come - each processor has a very limited amount of memory (512 words is tiny) and access to a bigger common memory (still only a tiny 8k words) is time sliced and so very slow. The next big issue is that the chip has effectively no on-chip peripherals. A typical cheap ARM Cortex will have SPI, I2C, UARTS, timers, USB etc etc.

Several companies have attempted to dump peripherals and code them all in software - it's never popular because it's hard work and difficult to support in practice and always gives worse performance than dedicated peripheral functions. XMOS are currently plowing this furrow and have found a few niche applications but aren't breaking into the mainstream (they've inherited too much attitude from Inmos so I don't think they ever will make the big time.)

So while the Propeller is interesting, and can give good performance if you get a job that is a really good fit, it isn't  a patch on general purpose micros for general purpose jobs - and they make up most of the market. For niche stuff DSPs are much better at DSP, FPGAs are much better at massively // and can be clocked so much faster etc etc.

So right now I can buy an ARM Cortex with a 180MHz clock 1Mbyte Flash, >192kBytes RAM, on chip USB, Ethernet, Encryption/Decryption etc etc for about the same price - the Propeller just doesn't offer anything expect less stuff and more hassle.

MK

So right now I can buy an ARM Cortex with a 180MHz clock 1Mbyte Flash, >192kBytes RAM, on chip USB, Ethernet, Encryption/Decryption etc etc for about the same price - the Propeller just doesn't offer anything expect less stuff and more hassle.

.. and run a propeller emulation on it with 1:1 speed (probably - I am guessing here)

Several companies have attempted to dump peripherals and code them all in software - it's never popular because it's hard work and difficult to support in practice and always gives worse performance than dedicated peripheral functions.

Performance should not be an issue, at least not for statdard perpiphals (SPI, PWM, UART, I2C ...) those are all simple protocols. Indeed simple enough to implement them whith a few gates in hardware... that's how they were designed.

I'm not quite sure what you are getting at re. peripherals - are you saying that SPI, UART etc are better off in hardware or software ?

MK

IMHO there should not be any difference, SPI et al are slow compared to the processor speed and not very time critical. So a software implementation is not harmful to the performance. I doubt that this is the reason for software peripheral not being adopted widely.

A chip manufacturer probably asks: "What do I gain by dropping the hardware implementation of serial peripheral?" Because they already have implemented them in hardware the answer would probably be "Not much!"

I. E. it does not free significant chip surface. That's why I think they simply stick with hardware implementations. But if you design a completely new chip, you may think about it - as xmos did. Maybe that saved them the whole IO remapping / multiplexing and made the whole design simpler. (but I am again guessing here, I am not a chip designer).

IMHO there should not be any difference, SPI et al are slow compared to the processor speed and not very time critical. So a software implementation is not harmful to the performance. I doubt that this is the reason for software peripheral not being adopted widely.

A chip manufacturer probably asks: "What do I gain by dropping the hardware implementation of serial peripheral?" Because they already have implemented them in hardware the answer would probably be "Not much!"

I. E. it does not free significant chip surface. That's why I think they simply stick with hardware implementations. But if you design a completely new chip, you may think about it - as xmos did. Maybe that saved them the whole IO remapping / multiplexing and made the whole design simpler. (but I am again guessing here, I am not a chip designer).

Doing bit bang SPI in software absolutely cripples processor performance - especially when operating as a slave. You need to be watching for clock edges all the time which you can do with an edge detector peripheral and interrupts or by sitting in a loop. One way the processor gets loads of interrupts (at least one for every SPI clock edge) and the other it's 100% dedicated to the task. XMOS get round these issues by having multiple cores and some special support logic. A normal single core processor could not handle SPI at anything like the half or quarter of core clock speed offered by many SPI peripherals.

Modern processors often go one step further than just an SPI peripheral and use DMA as well so not only does the uP core not need to know about clock edges but it need not know or care about exactly when each byte is transferred.

(I've said SPI but applies to other interfaces as well.)

MK

Anything in hardware is going to be 1000 times faster than in software.  However if implemented in software you can fix bugs, update standards etc...

One locked into hardware its written in stone.

The Pic32 has a bug in the I2C that cannot be fixed.

Hmmm. I have to admit that I have not bitbanged a SPI signal but a WS2812. Timing tolerances are normally high enough to simplify the code. In case of the SPI slave I'd asume the masters and slaves clock to be accurate enough to not drift significantly. Then it's enough to have a interupt every SPI clock cycle to sample the input since it is not important to detect the edges only a "hig" or a "low" bit. Or do I overlook something here?

Thanks for your patience!

Anything in hardware is going to be 1000 times faster than in software.

True. But I2C standard speed of 100 kHz vs. 180 MHz uC? I guess software is good enough. Not all uC are used for "demanding" applications. Most are sleeping all the time wating for a key press from the user. (coffee machine, electric tooth brush...). But I wolud not use a 16 MHz M0 to drive the motors of a segway...

Don't forget if it is implemented in software, it can conflict with resources since it will usually use one or more of the built in timers, ISRs etc..

The propeller can bitbang spi @ 10mhz+ and the Uart is 2Mbaud... It doesn't have USB and a lot of other cool peripherals but theHALre coming in the prop 2. I personally think using a dedicated chip works just as well. I think ARM has taken off, it has the Arduino IDE on some chips and EMBed.. I think it would be more popular if the chips were easier across to port HAL layers across vendors and cortex 0/1/2/3/4 architectures. I have plenty of ARM boards which wont run Embed.

I guess I think of the propeller as having 8 little arduinos in one chip with internal lines to talk to each other. There is no need for interupts on the propeller architecture, but if you must have them they have been implemented in software. The propeller also has 16 hardware based counters which are fairly useful, Ive been reading a piece of software that uses 3 counters to receive RF and mix the IQ signals and output audio. This is all done with just an inductor antenna and a few other passives to make the props sigma delta A to D work. Which btw is very scale able up to 16 bits (most likely higher if proper care is taken during layout), its a resolution vs speed trade off.

The chip is very capable It is niche but it's niche works very well for hobby robotics and automation. Its also much easier to program without interrupts the deterministic nature is great... you can count on things getting done in a certain amount of time without interrupts disturbing them. Im not trying to sound like a fan boy, I guess the real reason I wonder why the arduino took off over the propeller is because Parallax already had the hobby market with the basic stamp, so why did hobbyist pick a 16mhz single core mcu over an 80mhz 8 core mcu? I personally think the PSOC chips are great and wish they actually had the arduino market they are easy to use and the digital fabric allows you to get your feet wet with an HDL when your ready, on top of being an ARM core.

No problem with fan boys 

I decided to go mainsteam (ARM) instead of niche (Xmos) despite I like the solutions in the niche products. PSoC and Xmos are very intresting (have dev boards lying aroud but no time to give them a closer look)

In the past I had an Inmos Transputer board which got me into programming but turned out to be not relevant on the market. Same with parallel programming, tile based rendering and many other technologies I had great hopes for. For hobby it is ok to look besides the mainstream, but if you have to make your living it's hard.

For my work stuff I use mainly ARM based micros with FPGAs for the hardware gymnastics (when required).

I rather like the idea of all the esoteric chips but they've never looked convincing enough to actually use (Propellor, Parelella, XMOS, GreenArrays GA144 etc)

re. Joey's comment on I2C - I do often bit bang I2C on micros because I've had so much trouble with the built in stuff in the past. But it does mean that the micro is busy all the time it's I2C-ing.

MK

Yep, that's what I meant when I said earlier that the XMOS has "special support logic" - it (and some other processors) are much better at bit banging than your normal micro.

Unfortunately the price that is paid for that (in the widest sense) has (so far) kept such processors out of the mainstream.

There's been a thread on E14 recently talking about the Snickerdoodle (I wish they had thought of  a less silly name) which is an even cheaper way of getting a Zynq (but no array processor).

MK