The FPGA manufacturers provide excellent tutorials for people learning to use their tools, and there are many excellent books available - the tutorial materials and books are better than those available for the Propeller.
The synthesisable subset of VHDL that is used with FPGAs is relatively small, and using it is no harder than programming in C. Designing hardware requires a different mindset from programming a software application, of course, but all students completing an electrical engineering course these days should have no problems in using FPGAs. Verilog is based on C, and many people find it easier to use than VHDL. I can't get on with Verilog, personally.
Now just hang on one cotton-picking minute! - in one post you have gone from "easier than PASM" to "no harder than C".
And at the same time you now restrict yourself to "students completing an electrical engineering course".
Okay - so I can agree that students completing an electrical engineering course should have no more difficulty programming a simple hardware interface in VHDL than they would in C.
As Phil said (or was it Mike), although not verbatim, Spin is good for getting something to work in a hurry. However, it is not the fastest.
Okay so where is the happy medium?
Personally I like the programming IDE of Visual Studio C++, and I spent a fair amount of money in obtaining this software. Is there any way to write programs in this software for the Propeller?
Now just hang on one cotton-picking minute! - in one post you have gone from "easier than PASM" to "no harder than C".
The two statements are not mutually exclusive.
You suggested that VHDL, being based on Ada, is a very difficult language to learn and use. I was comparing it to a widely used programming language, C.
And at the same time you now restrict yourself to "students completing an electrical engineering course".
If they can use FPGAs effectively, I fail to see why the average hobbyist using PASM on the Propeller should not be able to do the same.
Personally I like the programming IDE of Visual Studio C++, and I spent a fair amount of money in obtaining this software. Is there any way to write programs in this software for the Propeller?
Bruce
Bruce,
Of course! It only takes two easy steps:
1. Compile Catalina using Visual Studio. I've not actually tried this, but assuming Visual Studio is ANSI compliant, this should be easy.
2. Discard Visual Studio and compile your programs using Catalina.
Personally I like the programming IDE of Visual Studio C++, and I spent a fair amount of money in obtaining this software. Is there any way to write programs in this software for the Propeller?
As Phil said (or was it Mike), although not verbatim, Spin is good for getting something to work in a hurry. However, it is not the fastest.
Okay so where is the happy medium?
Personally I like the programming IDE of Visual Studio C++, and I spent a fair amount of money in obtaining this software. Is there any way to write programs in this software for the Propeller?
Bruce
You should be able to use the Visual C++ text editor to create your Spin, C and assembler files for the Propeller.
One of the things that it seems we all do is to try to make the prop "behave" line any other conventional processor.
While it is typical to try to look at something in terms we already understand as a way of trying to "get" the new thing (the Prop), it sometimes gets in the way of seeing the importance of what makes it different.
What I'm saying is we need to play on the strengths of what makes the prop different, not stress out trying to make it the same.
It would be feasible to develop a C++ compiler for the Propeller, but I don't think that it would be all that popular. C++ isn't used very much for embedded systems - they tried it on a big project where I once worked and had horrendous problems with it.
One of the things that it seems we all do is to try to make the prop "behave" line any other conventional processor.
While it is typical to try to look at something in terms we already understand as a way of trying to "get" the new thing (the Prop), it sometimes gets in the way of seeing the importance of what makes it different.
What I'm saying is we need to play on the strengths of what makes the prop different, not stress out trying to make it the same.
C.W.
I think this may be the most intelligent comment yet posted in this thread (excluding mine, of course).
It worked for XMOS! They don't even call their devices processors or MCUs, but refer to them as "programmable chips". Adopting a strategy that has obviously worked successfully for another manufacturer would be a good start.
It worked for XMOS! They don't even call their devices processors or MCUs, but refer to them as "programmable chips". Adopting a strategy that has obviously worked successfully for another manufacturer would be a good start.
I have concluded from this discussion, the future of the Propeller in the commercial and industrial markets is highly dependant upon the knowledge of being able to write and read assembly code. A novice could reasonably assume, that this prerequisite of programming knowledge would be a common standard within the commercial and industrial markets. Therefore any electrical engineer seriously considering the use of the Propeller within an industrial or commercial application should have access to a programming staff that has such knowledge, providing they want to obtain the highest potential of the Propeller chip.
After reading the available biographies for Parallax employees, I see that Parallax has a tendancy to hire exceptionally goodlooking women. I can't remember if I have ever seen a photograph of you, but I believe that you are probably just as beautiful as the rest of them. So I am sure lipstick and rouge would not be required.
>>> I have concluded from this discussion, the future of the Propeller in the commercial and industrial markets is highly dependant upon the knowledge of being able to write and read assembly code.
Although it hasn't been mentioned in this thread, the current "best choice" is probably Bean's PropBasic, since it can compile to either PASM or LMM code. If I'm not mistaken, it's currently the _only_ high level language compiler that compiles to PASM.
Peter, thanks very much for that! I've saved it, and will be porting a small project over to the Prop in the next month or so most likely. I will specifically use that.!!!
Mike Green, I absolutely understand what you are saying, and agree that new ideas take time to settle out and propogate.
I am somewhat thrown by Leon's assertion that the cores are just disposable soft block resources. If so, then where exactly is the actual uC in charge of everything? That was actually rhetorical in nature, but perhaps more professionals actually ask themselves that question and end up being a little confused?
While this might just be Leon's view of the Prop, it strikes me a bit odd that there isn't one large MCP-type Master core that has more significantly more memory as the one ring which binds them all....... I understand the attempt at symmetry, however the limited cog memory is in my limited experience, rather pitiful. Isn't it about the same as in some of the smaller PIC/AVR's? But then, if all the cores are as Leon says, just expected to be simple-medium soft peripherals, that might be ok. One thing that strikes me is, how or is, Parallax looking at its vision of symmetry and gauging whether or not that is still the right call?
I don't know, but I expect someone must have suggested before the possibility of having Prop II bring some asymmetry to the party and have a Host core with triple or quadruple the cog memory to act as more of a Master controller a la the Cell processor. If that were done, I think that in itself would be a very significant milestone in understanding and acceptance by current industry professionals. The coolest trick is that the Host-slave idea is so innate in engineers, so well known that it then makes the concept of all the 'smaller' cores use as free wheeling co-processor/peripherals much more comfie and 'normal'. Whats neat is that while this would undoubtedly be reassuringly familiar to many, it could also make the interrupt-less nature of the system more acceptable and paletable to a sceptic.
I doubt my comments are new in breaking ground in much here, nor will they have much impact on the Prop II.
I just fail to see where upping core count, or even memory or GPIO is going to address many of these foundational concerns. I think updating or creating a new website, evangelizing interrupt-less or customized peripherals is going to have limited impact on the whole, if at all. Product focus groups are hell on developers/designers/engineers who've shed blood sweat and tears on their baby. Suggesting changes almost invariable meets with disagreement, and the charge that the focus groupees just 'don't get it', as it concerns this or that function, or design philosphy.
And, thats a valid charge to make. But if you've had a product too market for 4-5 years, and seen minimal uptake outside of the enthusiast market despite capital investments, then one has to at some point realize that either the approach to explaining the product is failing, or the product itself is simply not addressing certain needs. It could quite possibly be that the design philosophy is just a non-starter for those outside of the design group (and their close followers). Most likely Prop is great for a niche, its just going to be difficult to get traction when you can get a 50Mhz ARM M3 now for ~$2-3 which happens to be bog standard interrupt driven that everyone was schooled on and is intimately familiar with.
It sounds like Parallax is ramping up the future Prop II with the idea that the issue is evangelizing and not feature satisfaction. From almost every forum I've come across, when Prop is mentioned its usually regarded as a cool idea, but seems to come across as just too alien/different to wrap one's head around to be worthwhile for the price.
Its always good to have a Plan B. For the Prop II, is there any chance that a Prop II-x with some of the most oft complained about roadblocks addressed?
There are limits to Parallax' budget no doubt though, and I expect it would be time consuming to embark upon such a back-up that Chip and others just don't have too spare.
OK, I'm sure I've more than enough personal opinion for the thread.
Just a simple query. You are an engineer at a company, and you are looking at an entirely new (not really) type of uC. In addition to the new environment and associated learning curve, do you think many will really -want- to have to spend their time designing their own peripherals? I know there is an OBEX, and talk of a Gold Standard, but too my mind, high-lighting the ability to design your own peripherals is probably something that is more of an initial turn-off than a selling feature.
Has anyone asked the question of whether or not the average engineer even feels comfortable with software programmed peripherals in the first place? Let me point out again, I am an semi-ignorant hobbiest, so this may be a moot point.
However if it isn't, and hopefully Parallax has some sort of data on this, then is it possible that the vast majority of engineers are too uncomfortable with the concept itself to even consider going further?
-IF- that is true, then some sort of intervention is needed here to stem the masses from simply dismissing the Prop and leaving it as a curiosity,
Somehow Parallax has to get over this hump regarding the lack of peripherals on the Prop. I think trying to sell a soft peripheral is hard enough as it is, and then dropping the bomb that they can write their own is on par with taking your average developer, and telling them blithely that they can write their own drivers. Assuming we are not talking to a device driver group here but average programmers.
Parallax must supply some sort of Official/Approved Gold Standard, kick-butt objects for all of the main peripherals an engineer would normally expect to find available at the outset, and consider where and how to go about discussing a primary feature that may really be a turn-off for most engineers. I really don't think the average professional wants to be told that a peripheral he needs is available in the OBEX, and its written by someone in a Parallax' forum. Are you really going to trust a piece of software that doesn't come from the Parallax, or a known vendor for a production product? Now you have to consider how much test time you will need before you have a level of confidence, and if you have done enough testing, or almost enough where an outlier condition causes a failure -after- you've gone into production!
I can't help but think that these are questions that would cross any common sense professional who values his position. Knowing that the questions might exist and be true only help Parallax address them in furtherance of the Prop's success.
Someone tune me up with the clue bat if Parallax already includes these and I'm just showing my ignorance again. I promise to go back to lurk-mode now
Heater, you are correct! The Prop is similar to an FPGA/CPLD in many ways, and Parallax should definately put a major spin on the Prop (heh) as having many of the same properties/usefulness of same.
I'd say consider marketing it as some sort of Fusion of uC and FPGA, but AMD has the Fusion moniker locked up.
Is something I and others have been thinking about for a long while. As it stands if you stumble across the Prop you might immediately move on as it is not made obvious that whilst it has no built in peripherals it is very easy to make them in software or easier still to just snag existing ones. I know this to be true because I did it myself.
Hurdle #1 is getting the engineer to know the prop exists. So many of us on this formu found it by accident.
Hurdle #2 is getting the engineer to understand the concept of soft peripherals. They are not rocket science. In fact, with say the FullDuplexSerial object, it is easier than programming a UART, period! There are now so many peripherals in these "other" chips and they have predetermined pins although we are seeing some more flexibility here, it is a nightmare to see if you can actually configure what you want on the chip.
I am going to ignore Leon's Verilog and VHDL FPGA comments - they are too stupid to get a response from me.
The symmetry is deliberate. All cogs are equal (theoretically and, for most purposes, practically). COGNEW starts up a hunk a code in a new cog ... whichever cog is available.
There are some special cases where, due to wiring path lengths on the chip, there is some slight difference in signal propagation times and coupling between signal lines. EFX-TEKs .wav player uses a specific cog for each audio channel to reduce analog noise. At high volume levels, you can apparently hear a difference in sound quality compared to using arbitrary cogs.
There have been some design changes in the Prop II to eliminate these cog to cog variations further. The idea is that you will be able to assign functions to cogs without regard to which cogs or even how many cogs implement the function. If you want two TV outputs, you can have them. I've done this with the Prop I so I can have the program's normal output plus a separate debug display. There's a text-only TV driver available that keeps its display buffer in the cog's memory so the only hub memory needed is a long for a communications link.
Do remember in comparing the Prop to an ARM or equivalent: The Prop is a microcontroller. Its main function is controlling other devices, usually I/O and usually low level I/O. The ARM is a general purpose computer. It works as a microcontroller, but not well. The Prop works as a general purpose computer, but not well. Because of the limited cog memory, it functions like a microcoded interpreter often using external memory. That causes a speed hit, but the underlying processor is very fast and the net throughput is often reasonable. Remember that most of the IBM 360 series mainframes were done this way. If you take an ARM core and surround it with I/O functional blocks, you'll find that they're not as flexible as you may want. You may find that you have to write very complex and probably unreliable code for the ARM to do some of the I/O that doesn't quite fit the functional blocks that you're given and do it using interrupt processing. If you do the same thing with a Propeller, you may find that a little bit of assembly plus some Spin will get you your custom I/O block in a fraction of the time and effort.
As others have mentioned, the Propeller shines in low to moderate product volumes where time to market and other development time is important. It's probably not the best choice for high volume products, particularly where a relatively long lead time is available. It shines where software reliability and flexibility might be important.
Regarding fluency in assembly language. A reading fluency is necessary and some ability to make small changes in existing code or to write small straightforward routines. One of the advantages of the Object Exchange is that there's a library of existing objects, most of which involve some assembly language with Spin for glue and complex logic. Most of the time, the assembly portion of an object can be taken as is and any changes for customization can be done to the Spin portion of the object. It's very rare for significant changes to be needed in the assembly portion of an object.
If the ARM didn't work well as a microcontroller, companies like NXP wouldn't be selling millions of them for use in embedded systems. NXP even makes a tiny 2 mm x 2 mm Cortex-M0 device with 16 balls, containing 32k of flash and 8k RAM, and several peripherals like timers, an ADC, a UART, and SPI. I wouldn't call that a general-purpose computer. Companies like NXP are even touting the Cortex-M0 as a replacement for 8-bit MCUs like PICs and AVRs, they cost about the same in large quantities.
What evidence do you have that interrupt-driven applications are unreliable? Your mobile phone almost certainly uses an ARM chip, and the software is interrupt-driven - when did that last crash on you?
Getting engineers to understand soft peripherals isn't all that hard considering the success Cypress has had with it's PSOC series and it's introduction of the PSOC3 and 5. Good documentation and examples along with a decent development environment can do wonders in this area. And the PSOC5 looks like a real thunder stealer for the PropII, forget about the "other chip that must not be named".
That said, a set of gold standard objects would probably be a must when the PropII rolls out along with a PSOC like developers environment if Parallax wants to market the PropII in this direction.
On interrupts, it's no black art despite what many here have alluded to, programmers and engineers have been using them for decades, trying to scare them about the evils of them won't work well.
I wouldn't say that the PSOC has been much of a success, have you ever used one? The latest versions have probably improved, but I found using one for even a simple application was rather painful. They don't have "soft" peripherals in the same sense as the Propeller, they are actually the same sort of blocks of logic that you get in any MCU.
Leon,
Almost anything is called an embedded system these days. I have an oldish PC in a little desktop enclosure complete with everything that any other PC has including WiFi, Bluetooth, a nice graphics controller, etc. and the processor board with most of the peripherals on it was sold for embedded system use. Linux runs on ARMs packaged for embedded use. There's nothing wrong with that, but it's a different market with different development needs. You're clearly convinced that the Propeller is not good for very much compared to almost anything else. I'm kind of an old-fashioned idealist with a lot of experience in a lot of different computer architectures. I've programmed most of them in their instruction sets as well as a variety of programming languages. The Propeller seems clean to me ... mostly straightforward. I know that counts for little these days, but I think that what gives it its power and utility.
On the contrary, I think the Propeller is an ideal device for hobbyists and certain niche professional applications. I just don't think it compares favourably with many of the other solutions that are available, as a general purpose MCU for use in large-quantity production.
Most ARM devices sold into the embedded market won't even run Linux, they don't have an MMU or nearly enough RAM. They are conventional embedded controllers.
I've been programming microcomputers and microcontrollers on and off over the years, since 1975. I got my own MC6800 system as soon as they became affordable, and had to hand-assemble my code as an assembler wasn't available.
Comments
Now just hang on one cotton-picking minute! - in one post you have gone from "easier than PASM" to "no harder than C".
And at the same time you now restrict yourself to "students completing an electrical engineering course".
Okay - so I can agree that students completing an electrical engineering course should have no more difficulty programming a simple hardware interface in VHDL than they would in C.
Now can we get back to the Propeller?
Ross.
As Phil said (or was it Mike), although not verbatim, Spin is good for getting something to work in a hurry. However, it is not the fastest.
Okay so where is the happy medium?
Personally I like the programming IDE of Visual Studio C++, and I spent a fair amount of money in obtaining this software. Is there any way to write programs in this software for the Propeller?
Bruce
The two statements are not mutually exclusive.
You suggested that VHDL, being based on Ada, is a very difficult language to learn and use. I was comparing it to a widely used programming language, C.
If they can use FPGAs effectively, I fail to see why the average hobbyist using PASM on the Propeller should not be able to do the same.
Bruce,
Of course! It only takes two easy steps:
1. Compile Catalina using Visual Studio. I've not actually tried this, but assuming Visual Studio is ANSI compliant, this should be easy.
2. Discard Visual Studio and compile your programs using Catalina.
Ross.
Bruce,
Here is a thread that was started on the subject:
http://forums.parallax.com/showthread.php?127210-Spin-and-PASM-in-Visual-Studio&highlight=visual+studio
C.W.
You should be able to use the Visual C++ text editor to create your Spin, C and assembler files for the Propeller.
Thanks for that link.
Bruce
Yes, I already know that, but I was thinking more along the lines of writing object oriented code and compiling it with the native compiler.
Bruce
Yes, I was referring to C++.
Bruce
While it is typical to try to look at something in terms we already understand as a way of trying to "get" the new thing (the Prop), it sometimes gets in the way of seeing the importance of what makes it different.
What I'm saying is we need to play on the strengths of what makes the prop different, not stress out trying to make it the same.
C.W.
I think this may be the most intelligent comment yet posted in this thread (excluding mine, of course).
Ross.
C.W.
Thin ice, Leon.
http://forums.parallax.com/showthread.php?124851-Theory-on-why-the-Propeller-is-not-used-in-the-comsumer-market&p=931996&highlight=XMOS#post931996
I have concluded from this discussion, the future of the Propeller in the commercial and industrial markets is highly dependant upon the knowledge of being able to write and read assembly code. A novice could reasonably assume, that this prerequisite of programming knowledge would be a common standard within the commercial and industrial markets. Therefore any electrical engineer seriously considering the use of the Propeller within an industrial or commercial application should have access to a programming staff that has such knowledge, providing they want to obtain the highest potential of the Propeller chip.
Bruce
Thanks, and BTW I find that a bit of lipstick, blush, lash blast and liner always
pays off well for me :-)
After reading the available biographies for Parallax employees, I see that Parallax has a tendancy to hire exceptionally goodlooking women. I can't remember if I have ever seen a photograph of you, but I believe that you are probably just as beautiful as the rest of them. So I am sure lipstick and rouge would not be required.
Bruce
Although it hasn't been mentioned in this thread, the current "best choice" is probably Bean's PropBasic, since it can compile to either PASM or LMM code. If I'm not mistaken, it's currently the _only_ high level language compiler that compiles to PASM.
Mike Green, I absolutely understand what you are saying, and agree that new ideas take time to settle out and propogate.
I am somewhat thrown by Leon's assertion that the cores are just disposable soft block resources. If so, then where exactly is the actual uC in charge of everything? That was actually rhetorical in nature, but perhaps more professionals actually ask themselves that question and end up being a little confused?
While this might just be Leon's view of the Prop, it strikes me a bit odd that there isn't one large MCP-type Master core that has more significantly more memory as the one ring which binds them all....... I understand the attempt at symmetry, however the limited cog memory is in my limited experience, rather pitiful. Isn't it about the same as in some of the smaller PIC/AVR's? But then, if all the cores are as Leon says, just expected to be simple-medium soft peripherals, that might be ok. One thing that strikes me is, how or is, Parallax looking at its vision of symmetry and gauging whether or not that is still the right call?
I don't know, but I expect someone must have suggested before the possibility of having Prop II bring some asymmetry to the party and have a Host core with triple or quadruple the cog memory to act as more of a Master controller a la the Cell processor. If that were done, I think that in itself would be a very significant milestone in understanding and acceptance by current industry professionals. The coolest trick is that the Host-slave idea is so innate in engineers, so well known that it then makes the concept of all the 'smaller' cores use as free wheeling co-processor/peripherals much more comfie and 'normal'. Whats neat is that while this would undoubtedly be reassuringly familiar to many, it could also make the interrupt-less nature of the system more acceptable and paletable to a sceptic.
I doubt my comments are new in breaking ground in much here, nor will they have much impact on the Prop II.
I just fail to see where upping core count, or even memory or GPIO is going to address many of these foundational concerns. I think updating or creating a new website, evangelizing interrupt-less or customized peripherals is going to have limited impact on the whole, if at all. Product focus groups are hell on developers/designers/engineers who've shed blood sweat and tears on their baby. Suggesting changes almost invariable meets with disagreement, and the charge that the focus groupees just 'don't get it', as it concerns this or that function, or design philosphy.
And, thats a valid charge to make. But if you've had a product too market for 4-5 years, and seen minimal uptake outside of the enthusiast market despite capital investments, then one has to at some point realize that either the approach to explaining the product is failing, or the product itself is simply not addressing certain needs. It could quite possibly be that the design philosophy is just a non-starter for those outside of the design group (and their close followers). Most likely Prop is great for a niche, its just going to be difficult to get traction when you can get a 50Mhz ARM M3 now for ~$2-3 which happens to be bog standard interrupt driven that everyone was schooled on and is intimately familiar with.
It sounds like Parallax is ramping up the future Prop II with the idea that the issue is evangelizing and not feature satisfaction. From almost every forum I've come across, when Prop is mentioned its usually regarded as a cool idea, but seems to come across as just too alien/different to wrap one's head around to be worthwhile for the price.
Its always good to have a Plan B. For the Prop II, is there any chance that a Prop II-x with some of the most oft complained about roadblocks addressed?
There are limits to Parallax' budget no doubt though, and I expect it would be time consuming to embark upon such a back-up that Chip and others just don't have too spare.
OK, I'm sure I've more than enough personal opinion for the thread.
Just a simple query. You are an engineer at a company, and you are looking at an entirely new (not really) type of uC. In addition to the new environment and associated learning curve, do you think many will really -want- to have to spend their time designing their own peripherals? I know there is an OBEX, and talk of a Gold Standard, but too my mind, high-lighting the ability to design your own peripherals is probably something that is more of an initial turn-off than a selling feature.
Has anyone asked the question of whether or not the average engineer even feels comfortable with software programmed peripherals in the first place? Let me point out again, I am an semi-ignorant hobbiest, so this may be a moot point.
However if it isn't, and hopefully Parallax has some sort of data on this, then is it possible that the vast majority of engineers are too uncomfortable with the concept itself to even consider going further?
-IF- that is true, then some sort of intervention is needed here to stem the masses from simply dismissing the Prop and leaving it as a curiosity,
Somehow Parallax has to get over this hump regarding the lack of peripherals on the Prop. I think trying to sell a soft peripheral is hard enough as it is, and then dropping the bomb that they can write their own is on par with taking your average developer, and telling them blithely that they can write their own drivers. Assuming we are not talking to a device driver group here but average programmers.
Parallax must supply some sort of Official/Approved Gold Standard, kick-butt objects for all of the main peripherals an engineer would normally expect to find available at the outset, and consider where and how to go about discussing a primary feature that may really be a turn-off for most engineers. I really don't think the average professional wants to be told that a peripheral he needs is available in the OBEX, and its written by someone in a Parallax' forum. Are you really going to trust a piece of software that doesn't come from the Parallax, or a known vendor for a production product? Now you have to consider how much test time you will need before you have a level of confidence, and if you have done enough testing, or almost enough where an outlier condition causes a failure -after- you've gone into production!
I can't help but think that these are questions that would cross any common sense professional who values his position. Knowing that the questions might exist and be true only help Parallax address them in furtherance of the Prop's success.
Someone tune me up with the clue bat if Parallax already includes these and I'm just showing my ignorance again. I promise to go back to lurk-mode now
Heater, you are correct! The Prop is similar to an FPGA/CPLD in many ways, and Parallax should definately put a major spin on the Prop (heh) as having many of the same properties/usefulness of same.
I'd say consider marketing it as some sort of Fusion of uC and FPGA, but AMD has the Fusion moniker locked up.
Whoops, just saw the threads after yours.
Hurdle #2 is getting the engineer to understand the concept of soft peripherals. They are not rocket science. In fact, with say the FullDuplexSerial object, it is easier than programming a UART, period! There are now so many peripherals in these "other" chips and they have predetermined pins although we are seeing some more flexibility here, it is a nightmare to see if you can actually configure what you want on the chip.
I am going to ignore Leon's Verilog and VHDL FPGA comments - they are too stupid to get a response from me.
There are some special cases where, due to wiring path lengths on the chip, there is some slight difference in signal propagation times and coupling between signal lines. EFX-TEKs .wav player uses a specific cog for each audio channel to reduce analog noise. At high volume levels, you can apparently hear a difference in sound quality compared to using arbitrary cogs.
There have been some design changes in the Prop II to eliminate these cog to cog variations further. The idea is that you will be able to assign functions to cogs without regard to which cogs or even how many cogs implement the function. If you want two TV outputs, you can have them. I've done this with the Prop I so I can have the program's normal output plus a separate debug display. There's a text-only TV driver available that keeps its display buffer in the cog's memory so the only hub memory needed is a long for a communications link.
Do remember in comparing the Prop to an ARM or equivalent: The Prop is a microcontroller. Its main function is controlling other devices, usually I/O and usually low level I/O. The ARM is a general purpose computer. It works as a microcontroller, but not well. The Prop works as a general purpose computer, but not well. Because of the limited cog memory, it functions like a microcoded interpreter often using external memory. That causes a speed hit, but the underlying processor is very fast and the net throughput is often reasonable. Remember that most of the IBM 360 series mainframes were done this way. If you take an ARM core and surround it with I/O functional blocks, you'll find that they're not as flexible as you may want. You may find that you have to write very complex and probably unreliable code for the ARM to do some of the I/O that doesn't quite fit the functional blocks that you're given and do it using interrupt processing. If you do the same thing with a Propeller, you may find that a little bit of assembly plus some Spin will get you your custom I/O block in a fraction of the time and effort.
As others have mentioned, the Propeller shines in low to moderate product volumes where time to market and other development time is important. It's probably not the best choice for high volume products, particularly where a relatively long lead time is available. It shines where software reliability and flexibility might be important.
Regarding fluency in assembly language. A reading fluency is necessary and some ability to make small changes in existing code or to write small straightforward routines. One of the advantages of the Object Exchange is that there's a library of existing objects, most of which involve some assembly language with Spin for glue and complex logic. Most of the time, the assembly portion of an object can be taken as is and any changes for customization can be done to the Spin portion of the object. It's very rare for significant changes to be needed in the assembly portion of an object.
If the ARM didn't work well as a microcontroller, companies like NXP wouldn't be selling millions of them for use in embedded systems. NXP even makes a tiny 2 mm x 2 mm Cortex-M0 device with 16 balls, containing 32k of flash and 8k RAM, and several peripherals like timers, an ADC, a UART, and SPI. I wouldn't call that a general-purpose computer. Companies like NXP are even touting the Cortex-M0 as a replacement for 8-bit MCUs like PICs and AVRs, they cost about the same in large quantities.
What evidence do you have that interrupt-driven applications are unreliable? Your mobile phone almost certainly uses an ARM chip, and the software is interrupt-driven - when did that last crash on you?
That said, a set of gold standard objects would probably be a must when the PropII rolls out along with a PSOC like developers environment if Parallax wants to market the PropII in this direction.
On interrupts, it's no black art despite what many here have alluded to, programmers and engineers have been using them for decades, trying to scare them about the evils of them won't work well.
Almost anything is called an embedded system these days. I have an oldish PC in a little desktop enclosure complete with everything that any other PC has including WiFi, Bluetooth, a nice graphics controller, etc. and the processor board with most of the peripherals on it was sold for embedded system use. Linux runs on ARMs packaged for embedded use. There's nothing wrong with that, but it's a different market with different development needs. You're clearly convinced that the Propeller is not good for very much compared to almost anything else. I'm kind of an old-fashioned idealist with a lot of experience in a lot of different computer architectures. I've programmed most of them in their instruction sets as well as a variety of programming languages. The Propeller seems clean to me ... mostly straightforward. I know that counts for little these days, but I think that what gives it its power and utility.
Most ARM devices sold into the embedded market won't even run Linux, they don't have an MMU or nearly enough RAM. They are conventional embedded controllers.
I've been programming microcomputers and microcontrollers on and off over the years, since 1975. I got my own MC6800 system as soon as they became affordable, and had to hand-assemble my code as an assembler wasn't available.