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).

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!

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!