It's funny, but I don't think the number of fanboys on this forum is really all that large - not if you mean people who put down all other options. There are many fans here, but only a few who really like to claim the prop (or stamp for that matter) is better than everything else.
AVRfreaks, on the other hand, can really get kind of scary. It's been a while since I frequented the forum but I always found the amount of noise and antagonism to be pretty high. It was also not particularly beginner friendly. Maybe it's changed since I stopped paying much attention to it.
It's just the same as it's always been. I enjoy it there.
In my experience, fear of interrupts is inversely proportional to the experience of the programmer.
Perhaps. But it does not change the fact that an interrupt handling an event for one thread mucks up the performance and deterministic timing of all other threads. No amount of experience will fix that issue and it will be a problem when you need the speed/determinism.
On an MCU loaded up with peripheral hardware for UARTS, SPI , etc etc this is mitigated some what as those hardware blocks are handling the fastest events, the arrival of bits on a serial line say. Swapping those peripheral blocks for multiple processors gains you flexibility in your designs and removes the need for interrupts, a win win.
* There is an big 'X factor' in the possible combination of cogs - they can be used individually or combined for throughput. So with some clever programming we can achieve 1600*1200 using 6 cogs, or a USB host using 3/4 cogs.
* The sheer number of useful counters - 16 + the system counter is very high relative to others. The counters have unique modes - I use XOR mode a lot.
* Similar for soft perhipherals. I haven't tried but it should be possible to get say 28 serial ports concurrently using quad serial ports
* As discussed in Rayman's security thread now, the non-flash code space is relatively unique and may be an advantage for some applications. If nothing else its a differentiator
Perhaps. But it does not change the fact that an interrupt handling an event for one thread mucks up the performance and deterministic timing of all other threads. No amount of experience will fix that issue and it will be a problem when you need the speed/determinism.
On an MCU loaded up with peripheral hardware for UARTS, SPI , etc etc this is mitigated some what as those hardware blocks are handling the fastest events, the arrival of bits on a serial line say. Swapping those peripheral blocks for multiple processors gains you flexibility in your designs and removes the need for interrupts, a win win.
Indeed, a powerful advantage, but perhaps the best part is that you have all the flexibility of software control rather than having to learn and work-around the vaguaries and complexities of a chip's specific hardware modules - in otherwords the hardware is more adaptable and multi-purpose and all identical across the cogs - more flexible than other microcontrollers.
A microcontroller's whole purpose is bringing between hardware and software (its never an ideal fit), but the prop does some of this bridging in a cleverer and more orthogonal way than most.
Perhaps. But it does not change the fact that an interrupt handling an event for one thread mucks up the performance and deterministic timing of all other threads. No amount of experience will fix that issue and it will be a problem when you need the speed/determinism.
True, but it's rare that embedded applications require absolute determinism. The majority of applications do not require this and can (and have) gotten along just fine with traditional MCUs. Many hardware interfaces do not have strict timing requirements. For example, SPI in master mode. The master controls the clock and the vast majority of slave devices have no problem with irregular clocks caused by other activities happening on the MCU generating the clock. I've bit banged SPI on many traditional MCUs and have yet to find a slave device that has a problem with this. Of course, there are interfaces that do have more strict timing requirements. The 1-wire interface is one that comes to mind, and it's much easier to implement this on the prop or "X" chip because of the deterministic timing.
On an MCU loaded up with peripheral hardware for UARTS, SPI , etc etc this is mitigated some what as those hardware blocks are handling the fastest events, the arrival of bits on a serial line say. Swapping those peripheral blocks for multiple processors gains you flexibility in your designs and removes the need for interrupts, a win win.
Again, true to a certain degree, although running an 80MHz processor at full speed 100% of the time to handle these is wasteful power-wise and unnecessary in many other architectures. (I've seen a surprising number of prop drivers that don't even bother with waitpeq/waitpne when waiting for a transition on a port.)
True, but it's rare that embedded applications require absolute determinism.
Disagree - its quite common for functional changes to excede timing constraints after very few changes, even on very simple designs.
I've seen experienced engineers unafraid of interrupts miss the time window target. The equipment was capabilty of performing within the required specification. But changes during development and production caused the wrong component to zig when they should have zagged. Most designs i've seen start out with surplus capability, but this is quickly exceded by rev 2 if not during bug fixes on rev 1.
While a processor that that eliminates the need for interrupts would address this issue, the root cause is poor control of requirements and inattention to design technical limitations by management. Most outfits are not equipped to address the root cause.
I've seen experienced engineers unafraid of interrupts miss the time window target.
This is what timing analysis tools are for and any company that refuses to buy them for their engineers is being penny wise and pound foolish. Even worse is the case where the engineers have the tools, but don't use them.
Except that in general timing analysis of complete programs is impossible.
For example: You may be able to analyse a loop and figure out the worst case execution time of each iteration but the number of iterations may depend on some variable that the tool cannot know the value of. Compound this with interrupts which may or may not occur during the loop and may themselves be complicated enough to not be amenable to timing analysis.
A full timing analysis, as you say, is impossible, but it's rarely necessary to go to that extent. Just knowing the worst case is often all that's needed. The majority of embedded applications don't have timing issues that would require a full analysis, as evidenced by literally thousands, perhaps millions, of embedded applications out there running on billions of traditional (with interrupts) MCUs.
In the rare case where complete determinism and strict timing are required, then one should use a processor that does support it, such as the propeller or the "X" chip. That's why I use the propeller as an I/O processor in my designs. I still maintain, however, that it is lacking as an application processor (for which I use the ARM Cortex-M3).
Just knowing the worst case is often all that's needed.
But that is the point. Timing analysis cannot know the worst case in general.
The majority of embedded applications don't have timing issues that would require a full analysis, as evidenced by literally thousands, perhaps millions, of embedded applications out there running on billions of traditional (with interrupts) MCUs.
True enough. They are mostly not working "on the edge" and have enough slop to get by with.
In the rare case where complete determinism and strict timing are required, then one should use a processor that does support it,
Seems I have spent a large part of my career working on those rare cases. All processors support determinism, they are just logical devices after all. Those aircraft flight computers, engine controllers and actuator controllers did not have the luxury of Propeller or XMOS chips. But with careful software design you can know exactly where you are in time all the time.
For example:
Engine controllers and flight controls at Lucas Aerospace were written in a language that did not support loops. (Would you believe?). Every module of code was executed every 10 or 100ms seconds. The compiler would work out the worst case execution time of each module (Which it could do easily as there were no loops) After compilation it would print out the execution time of each module and the total system. So you always knew how much of your time slot you had consumed.
Later they started using Ada for flight controls. They were shocked when I told them their code was taking from 70 to 95 percent of the available CPU capacity (seemingly at random) when the project was mostly written. They had no way to analyze that code and see that they were heading into trouble without running it on the target. Even then they could not give me a guarantee that the 95% would not jump over 100% in some unforeseen situation.
Another good example of this is the Saturn V instrument unit and Apollo guidance computer. It's amazing what those guys accomplished with primitive 50s and 60s technology.All of this is documented on the Internet, including source code and schematics, and it's worth looking at by anyone interested in real-time control systems.
I find the debate on interrupts versus independent processors a waste of time, so I normally don't comment on it. It's obvious that some things require very tight deterministic timing and interrupts don't work with applications like that. A video driver on the prop is one example. Of course, it's possible to provide a hardware FIFO so that tight timing is not required, and in that case a processor with interrupts could drive video.
Other things, such as serial drivers do not require tight deterministic time, and a processor with interrupts works fine. That's why we can implement multiple serial ports in a single cog. In general, most things that can be done on a Prop with independent cogs can be done on a processor with interrupts. The Prop has 8 cogs at 20 MIPs each. In most cases a large percentage of the 160 MIPs is wasted. A single 160-MIP processor with interrupts would more efficiently use the processing cycles.
With that said, it is easier to build a chip with 8 20-MIP processors without interrupts than it is to build one with a single 160-MIP processor with interrupts. The Prop 2 will have 8 160-MIP processors, which should make it a very nice chip. At this speed it makes a lot of sense to use multiple processors. It would be very difficult to build a single processor that runs at 1,280 MIPs with interrupts.
Yes, my Dell Streak Android tablet crashes every 5 minutes, like all those iPhones and iPads out there. I can't think why I'm still using it several times a day after over a year.
What about all those iPhones, iPpads and Android phones and tablets? They use 1 or 1.5 GHz ARM devices with interrupts going on all over the place.
Leon, you have a valid point. So, I would assume in your view Chip and his crew are wasting their time designing the Prop 2. Why shouldn't we all just use a 1.5 GHz ARM device for all our projects? Leon, why are you even wasting your time with the Prop? Why does Parallax even allow you on the forum if your only purpose is to evangelize competative devices? Is there anything positive that you can say about the Prop? Is there anything the Prop can do that a 1.5 GHz ARM couldn't do better?
It doesn't seem all that suitable for many embedded applications, despite forthcoming devices being available in quad-core and running at 2.5 GHz per core.
The Propeller is fine for some applications, but is a niche market device. For the vast majority of applications there are far better solutions that are cheaper, smaller, and use less power.
The way I see it, this interrupt vs no-interrupt discussion is a lot like structured vs non-structured programming discussions.
Structured languages more or less force a programmer to think through their use case, where unstructured ones do not, allowing for incremental construction via the goto keyword.
A prop does the same thing. The lack of a interrupt turns many things into timing and sequencing problems, where having the interrupt available means being able to not do that in the same way.
I may be expressing that poorly. Likely actually, as I'm here sick, probably not thinking as well as I should. (Sick means prop time today though, so what can I say?)
And I like interrupts. Let's get that clear. There are times when I feel constrained on the prop, for lack of one. When I think through those cases, I realize that it is possible to do it with out one, after having worked through the possible paths involved in whatever it is that needs to get done. Had there been a interrupt, I may well have just piled on the bits needed with that, trading determinism. Interestingly then, I would not know all the possible outcomes of the code, as noted above, but would be running that code anyway, and that's the difference right there.
Leon, you have a valid point. So, I would assume in your view Chip and his crew are wasting their time designing the Prop 2. Why shouldn't we all just use a 1.5 GHz ARM device for all our projects?
Get real here... No one's wasting their time with the Prop 2. It'll fill a valid niche in the market that is not well served by other chips. Sure, it'll never be used in very high volume apps, like kid's shoes with blinking LEDs, which are served by 8-pin PICs, or even 4-bit MCUs, nor will it ever be used in something like an iPad, which requires a high-end applications processor with memory management, etc.
Why does Parallax even allow you on the forum if your only purpose is to evangelize competative devices?
Perhaps because Parallax management has an open mind and realizes that open discussion is more beneficial than censorship?
Imagine a case where the only micro a group of programmers has ever programmed is the Prop or some other interruptless multi-processor device. After becoming a competent with it, they are then introduced to a more conventional, single-processor micro with interrupts. I think you would see this same discussion, but in reverse, with most comments being critical of the "new" architecture. The point is that one's initial inclination is to compare the new unfavorably with the familiar. Out-of -the-box thinking for one person is, more often than not, well within the comfort zone of another.
Comments
Sal: If you are going to misquote me and change the meaning of my post, please do not do it within QUOTE /QUOTE ! The wink does not fix that.
It's just the same as it's always been. I enjoy it there.
Perhaps. But it does not change the fact that an interrupt handling an event for one thread mucks up the performance and deterministic timing of all other threads. No amount of experience will fix that issue and it will be a problem when you need the speed/determinism.
On an MCU loaded up with peripheral hardware for UARTS, SPI , etc etc this is mitigated some what as those hardware blocks are handling the fastest events, the arrival of bits on a serial line say. Swapping those peripheral blocks for multiple processors gains you flexibility in your designs and removes the need for interrupts, a win win.
Sorry to respond late to this, but...
* There is an big 'X factor' in the possible combination of cogs - they can be used individually or combined for throughput. So with some clever programming we can achieve 1600*1200 using 6 cogs, or a USB host using 3/4 cogs.
* The sheer number of useful counters - 16 + the system counter is very high relative to others. The counters have unique modes - I use XOR mode a lot.
* Similar for soft perhipherals. I haven't tried but it should be possible to get say 28 serial ports concurrently using quad serial ports
* As discussed in Rayman's security thread now, the non-flash code space is relatively unique and may be an advantage for some applications. If nothing else its a differentiator
Ok, you sold me.
Indeed, a powerful advantage, but perhaps the best part is that you have all the flexibility of software control rather than having to learn and work-around the vaguaries and complexities of a chip's specific hardware modules - in otherwords the hardware is more adaptable and multi-purpose and all identical across the cogs - more flexible than other microcontrollers.
A microcontroller's whole purpose is bringing between hardware and software (its never an ideal fit), but the prop does some of this bridging in a cleverer and more orthogonal way than most.
True, but it's rare that embedded applications require absolute determinism. The majority of applications do not require this and can (and have) gotten along just fine with traditional MCUs. Many hardware interfaces do not have strict timing requirements. For example, SPI in master mode. The master controls the clock and the vast majority of slave devices have no problem with irregular clocks caused by other activities happening on the MCU generating the clock. I've bit banged SPI on many traditional MCUs and have yet to find a slave device that has a problem with this. Of course, there are interfaces that do have more strict timing requirements. The 1-wire interface is one that comes to mind, and it's much easier to implement this on the prop or "X" chip because of the deterministic timing.
Again, true to a certain degree, although running an 80MHz processor at full speed 100% of the time to handle these is wasteful power-wise and unnecessary in many other architectures. (I've seen a surprising number of prop drivers that don't even bother with waitpeq/waitpne when waiting for a transition on a port.)
Disagree - its quite common for functional changes to excede timing constraints after very few changes, even on very simple designs.
I've seen experienced engineers unafraid of interrupts miss the time window target. The equipment was capabilty of performing within the required specification. But changes during development and production caused the wrong component to zig when they should have zagged. Most designs i've seen start out with surplus capability, but this is quickly exceded by rev 2 if not during bug fixes on rev 1.
While a processor that that eliminates the need for interrupts would address this issue, the root cause is poor control of requirements and inattention to design technical limitations by management. Most outfits are not equipped to address the root cause.
This is what timing analysis tools are for and any company that refuses to buy them for their engineers is being penny wise and pound foolish. Even worse is the case where the engineers have the tools, but don't use them.
For example: You may be able to analyse a loop and figure out the worst case execution time of each iteration but the number of iterations may depend on some variable that the tool cannot know the value of. Compound this with interrupts which may or may not occur during the loop and may themselves be complicated enough to not be amenable to timing analysis.
In the rare case where complete determinism and strict timing are required, then one should use a processor that does support it, such as the propeller or the "X" chip. That's why I use the propeller as an I/O processor in my designs. I still maintain, however, that it is lacking as an application processor (for which I use the ARM Cortex-M3).
But that is the point. Timing analysis cannot know the worst case in general.
True enough. They are mostly not working "on the edge" and have enough slop to get by with.
Seems I have spent a large part of my career working on those rare cases. All processors support determinism, they are just logical devices after all. Those aircraft flight computers, engine controllers and actuator controllers did not have the luxury of Propeller or XMOS chips. But with careful software design you can know exactly where you are in time all the time.
For example:
Engine controllers and flight controls at Lucas Aerospace were written in a language that did not support loops. (Would you believe?). Every module of code was executed every 10 or 100ms seconds. The compiler would work out the worst case execution time of each module (Which it could do easily as there were no loops) After compilation it would print out the execution time of each module and the total system. So you always knew how much of your time slot you had consumed.
Later they started using Ada for flight controls. They were shocked when I told them their code was taking from 70 to 95 percent of the available CPU capacity (seemingly at random) when the project was mostly written. They had no way to analyze that code and see that they were heading into trouble without running it on the target. Even then they could not give me a guarantee that the 95% would not jump over 100% in some unforeseen situation.
Another good example of this is the Saturn V instrument unit and Apollo guidance computer. It's amazing what those guys accomplished with primitive 50s and 60s technology.All of this is documented on the Internet, including source code and schematics, and it's worth looking at by anyone interested in real-time control systems.
Other things, such as serial drivers do not require tight deterministic time, and a processor with interrupts works fine. That's why we can implement multiple serial ports in a single cog. In general, most things that can be done on a Prop with independent cogs can be done on a processor with interrupts. The Prop has 8 cogs at 20 MIPs each. In most cases a large percentage of the 160 MIPs is wasted. A single 160-MIP processor with interrupts would more efficiently use the processing cycles.
With that said, it is easier to build a chip with 8 20-MIP processors without interrupts than it is to build one with a single 160-MIP processor with interrupts. The Prop 2 will have 8 160-MIP processors, which should make it a very nice chip. At this speed it makes a lot of sense to use multiple processors. It would be very difficult to build a single processor that runs at 1,280 MIPs with interrupts.
Well, Leon, with all the interrupts going on on those devices, they're just disasters waiting to happen! Like a phaser on overload.
C.W.
http://www.qualcomm.com/snapdragon/specs
It doesn't seem all that suitable for many embedded applications, despite forthcoming devices being available in quad-core and running at 2.5 GHz per core.
The Propeller is fine for some applications, but is a niche market device. For the vast majority of applications there are far better solutions that are cheaper, smaller, and use less power.
Structured languages more or less force a programmer to think through their use case, where unstructured ones do not, allowing for incremental construction via the goto keyword.
A prop does the same thing. The lack of a interrupt turns many things into timing and sequencing problems, where having the interrupt available means being able to not do that in the same way.
I may be expressing that poorly. Likely actually, as I'm here sick, probably not thinking as well as I should.
And I like interrupts. Let's get that clear. There are times when I feel constrained on the prop, for lack of one. When I think through those cases, I realize that it is possible to do it with out one, after having worked through the possible paths involved in whatever it is that needs to get done. Had there been a interrupt, I may well have just piled on the bits needed with that, trading determinism. Interestingly then, I would not know all the possible outcomes of the code, as noted above, but would be running that code anyway, and that's the difference right there.
Get real here... No one's wasting their time with the Prop 2. It'll fill a valid niche in the market that is not well served by other chips. Sure, it'll never be used in very high volume apps, like kid's shoes with blinking LEDs, which are served by 8-pin PICs, or even 4-bit MCUs, nor will it ever be used in something like an iPad, which requires a high-end applications processor with memory management, etc.
Perhaps because Parallax management has an open mind and realizes that open discussion is more beneficial than censorship?
-Phil