...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
Yes. That is exactly what I was trying to say earlier. I hope somone in Parallax is listening.
It is quite a bit different, yes you can map UARTS etc to HUB space. But if there is only one then if my object uses it yours cannot, no matter what we do with handles. OK you could throw a whole bucket of UARTS in there and check them out as we do locks. And also a whole bucket of PWM and I2C and ... and...etc. All of a sudden you have a whole pile of silcon providing multiple instances of many peripherals which most of the time will not be used in any single app. Starts to sound as wastefull as using a 32 bit CPU for a UART.
I was thinking of say 8 to 16 configurable peripherals uart/i2c/spi/pwm with std commodity functions. If your particular app requires more than that, you go with SW peripherals for the remaining
We do have 16 configurable "counters" already...
Sticking with the SW peripherals notion ... the Prop-1 ROM could have had code for some basic peripherals instead of transcendental tables and instead of the ROM font. Those occupy a lot of ROM space. If there were a version of FullDuplexSerial and maybe an I2C/SPI driver ... an improved version of the one in FemtoBasic. Wow! ... Oh, wait a moment. The FullDuplexSerial driver has no handshaking and a small buffer and has been improved multiple times since. Wait!! FemtoBasic wasn't developed for some time after the Prop-1 was released and its combined I2C/SPI low level driver really needs some work ... and we're talking about a masked ROM ... it's not possible to have an EEPROM or even a OTP PROM on the Prop-1.
"I just think it would be unbeatable with a small amount of std goodies" ... You are entitled to your opinion. Given the facts ... tradeoffs of chip area mostly ... and issues around how to share a fixed set of peripherals among a set of essentially identical parallel processors, it's not anywhere as simple as you've suggested. Chip, as the sole chip architect and mostly sole designer, had to make some hard decisions early in the process and, as far as I can tell, doesn't feel that he made mistakes sticking to a pure SW peripheral model. He's essentially doing it over again with the Prop-II and there won't be HW peripherals. I'm sure there are / will be people who won't use the Propeller because of that, but I'm also sure that there will be people who will use the Propeller (for commercial products) because of the unique advantages brought about partly because of the use of SW peripherals.
There's a huge difference between the cog counters and HW peripherals like a UART / I2C / SPI / PWM in terms of complexity and chip area. They're hard to debug ... often have serious bugs well into the product's revision history. Check out nearly any PIC with HW peripherals.
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.
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.
!
Absolutely! And make it a simple drag and drop from the editor to add these std stuff. That would be a good and elegant workaround.
I am really proud to be the one who, after Chip had done all the hard work putting task switching in, casualy suggested that automatic multi-threading should be doable. ...
You caught Chip in a more receptive frame of mind than I did four years prior to that.
1. everything else that everyone here has said.
2. tools are free. okay maybe that is not so unusual. and *they work* without muss and fuss. okay maybe that is not so unusual.
3. the fact that we can have a dialog with the designers of the device from time to time and the company actually LISTENS to our needs as a bunch of (well at least for me) small fries. now THAT is unusual.
For me, the main selling point was the ability to do VGA or TV output with only passive external components.
Not sure if it's still true, but when I started, no other microcontroller did that.
So, my choice was FPGA or Propeller.
If I had infinite time, maybe FPGA could be better, but the Prop let me get something working very quickly...
Support from and by Parallax is indeed the best in the industry... any industry for that matter. I have dealt with many providers, vendors, contractors, etc. in the geology, engineering, industrial electronics and other arenas over the years and by far Parallax has stood by the customer and strived to provide support for everything they have produced, better than anyone. I have a couple of the Propeller Activity Boards and am rapidly learning how to program in C/C++ with the great Propeller C Learning System they have provided online. Should I need to revisit the BS2 that I started out with, Parallax maintains those devices and the folks at Parallax and at these discussion forums are priceless resources. The Propeller is a very capable device that I am learning more about on a daily basis. So far I have found the Propeller to be as powerful and configurable and easier to work with than the Texas Instruments MSP430 and the ARM Cortex M3 mbed devices, and I really like them, too. I have worked with the Propeller only for a very short time, but I am certain I will find the long-term support to be just as all of us Parallaxians expect... wonderful as usual.
One additional advantage of the Propeller (that I think wasn't mentioned before in this thread) is determinism. Since there are no interrupts you can even calculate what your code's speed will be. That's also hard to or even impossible to do in other MCUs
You caught Chip in a more receptive frame of mind than I did four years prior to that
Wow, yes, looks like I did. I can imagine Chip was busy enough thinking about everything else on the PII at the time. Even Chip's brain must have a capacity limit somewhere.
Seems that when Chip had done all the heavy lifting on task switching the automatic threading could just fall into place.
It has been fascinating to see how that and many other ideas have evolved in the Prop II over the years with all the discussion between Chip and the forum members. I can't think of any other processor or MCU that has been designed so openly with so much customer feed back. Might be a world first.
...determinism. Since there are no interrupts you can even calculate what your code's speed will be
Yes, exactly. How did I forget, its a key feature and should have been on my list. Although it is implied by other things I said there.
There are those of a more software oriented frame of mind who say that having critical timing be determined by the number of instructions in your code is a bad idea that "instruction counting" is bad practice. They would say it makes the code complex and unmaintainable and if you are using a compiler you cannot rely on it always generating the same code in future versions, bla bla bla.
To that end guys like XMOS have added all kinds of timer features to their devices so that code can always synchronize to real hardware time and other events. Given that, your code will always work even if your chips clock rate gets upgraded or the compiler optimization gets improved etc etc. They use events rather than interrupts so it works out quite simply.
As a practical matter theXMOS approach adds a whole lot more complexity to the processor architecture and then requires that is programmed in a language that can use those timers and the evented model. You have to use XC rather than C. Meanwhile with PASM being so simple and regular the good old instruction counting approach has worked just fine.
The Parallax point of view.
What is that? You don't need to buy the 'right processor' with all the features in silicon. You can develop one generalized very fast processor with a minimum of features and have the software/firmware adapt it to whatever you need to deploy.
Why do that?
You learn more and become a better engineer.
It is all about becoming 'above average' in a world that only the 'above average' people prosper.
The Propeller has won at finding its way into new technologies in these areas: CNC/3D printing
Ken Gracey
Hello,
Are there any examples of the propeller being used in a commercial or hobby 3D printer? I personally have not knowingly seen one , but I would like to.
Pardon me if I am a bit late to the game, but a couple of observations.
You can write code to do soft peripherals, or write code to handle external hardware, either way you code to perform or manage the function. Just comes down to the code size to do what you want and the time to realize the function.
Then again if I can go soft periph, I get the benefits and limitations already listed here, what I don't get may be the added cost of all the external silicon. Total cost of implementation will not exceed the cost of the prop chip and development time of the function. For hard peripherals, that needs to account for the mcu +/- cost difference , the glue logic, the peripheral device and the cost of the board space all of that will eat up. As always, cost vs benefits.
I don't have as much time as I would like for playing at night, but the prop gives me the best return for my efforts at the moment. Someday I may get to play with one of the ARM dev kits I have already on hand, but that is another day's post.
FF
Recalling some of my S/V history late '70s, I seem to recall that the Zilog dual uart slipped so badly that they ended up modifying (hard coding) a Z80 cpu to be a DUART. Maybe just rumor, but heard it from a couple different sources.
Not exactly. You could add std hw peripherals mapped into hub ram. We have 32bit addressing but only 32k+the rom tables, there's plenty of room to map everything you might need.
Regarding the sharing of these peripherals I see it no different from reserving a lock or launching a cog, let the HW decide and return you a handle, then you use it wisely without stepping over other resources.
Additionally you would have freed RAM which would be used for your non-std peripherals or anything original, not for the re-invention of the wheel.
Don't get me wrong, I do like the propeller a lot. I just think it would be unbeatable with a small amount of std goodies.
For me it was the determinism and lack of interrupts that drew me to the Prop. I started with PIC chips, trying to build a quad-rotor. I come from the video game world, so I'm no stranger to multi-threaded programming or interrupts, but being interrupted in the middle of trying to read your remote control inputs or send out your servo lines causes lots of problems.
PWM on the other chips I've used is useless for servo outputs or inputs, because the precision for the required cycle time isn't high enough. The Prop, not having fixed hardware, doesn't have that limitation.
My current Prop code has:
- 1us precision on 6 PWM inputs
- 1us precision on 8 PWM outputs at 250 Hz (plans for significantly higher than that - IE 100 ns or better precision with up to 500 Hz output)
- 3 x I2C devices (gyro, accel, mag) being read and post-processed on a single hardware thread - angles computed, etc.
- Full duplex serial output for debugging, status, and configuration
- Logging to an SD card
- Flight control running at 250 Hz, uninterrupted
That's not all of it, but doing all of that on a single-threaded MCU of any other kind would be *very* hard. I know people are doing it, but they're often "cheating". For example, the remote control input is usually done with a PWM to serial converter, using an ATTiny or something like it. On the Prop, I could do either one and just make it configurable.
The Prop isn't the perfect choice for everything. There are some applications where you need a monolithic, single-threaded program, or a very tiny, single-threaded program. The ATTiny is a good choice for the latter case, and there are a number of good choices for the former. If you need one chip to do half a dozen or more things at the *same time* without going insane, the Prop is a fantastic choice. Especially if those things are industrial protocols that are old or non-standard, or just slightly outside the norm, or someone inserted an extra bit somewhere, or ... you get the idea. Fixed hardware generally chokes on those things. With the Prop, you can just alter the "fixed hardware", because it's actually software that's shipped with it, as source.
This forum! I follow and use Microchip, AVR/Arduino, Raspberry PI and a slew of others in the past. Nowwhere to you have such an avid, expert and helpful bunch in one place.
VGA and TV support out of the box (with minimal external components) or ready to go like the Demo boards.
Same for keyboard, mouse and all the aforementioned peripherals.
Edit - Also: Unparalleled support of legacy products. You can confidently design with Parallax products and be assured of availability in 10 years. Older products from other vendors are dropped like a hot potato if they can't sell 10 million units/year.
Every time I use one of the platforms that have some features in hardware, I initially think "awesome, this will make it easier" then I start banging into the limitations. Want another I2C bus? Tough, you don't have one. Bit bang it on the main CPU or do without. Want another SPI? Sure, but that cripples your audio. Need a timer, you can use this one but that means that the UART is broken, or your pauses don't work right anymore. Oh yeah, the I2C hardware doesn't handle repeated start correctly, tough luck there.
I used to bristle at the notion of using a cog for some mundane task but over time I have really come to appreciate the fact that the Propeller can do a great many things and the same chip can be used to drive 16 PWMs in one project or handle 4 I2C buses in another the only change is the program running on it. The only thing I end up wishing for most times now is more RAM for C/C++ work.
The Prop isn't the perfect choice for everything. ...
Correct. For many things, clearly it is overkill; for others, it's not enough.
In my case, I'll just echo what others here have proffered as the Propeller's advantages: computing power w/o unwarranted complexity, reduced development time, flexibility, support/community/forums.
That said, I too have problems getting clients and others to consider the Propeller as a viable option. Not infrequently I'm met with a queer look when I mention it. When I press them, their objections generally mirror those easily found in this thread and elsewhere (http://compgroups.net/comp.arch.embedded/parallax-propeller-3/1957243).
Merely from a practical design standpoint, I'd say the Propeller's biggest weakness right now is that it's somewhat memory constrained. (Likewise, but not as critical, IMO, a little more oomph would be nice, so that you didn't have to drop out of Spin quite as often.)
Had a quick look (again) - it's not very fast and it's not very cheap (compared with a CortexM4 clocked at 150MHz or more). Then there is all the pain of programming and synching multiple cores which is (I think) worse than the pain of managing DMA on a typical M4 based micro-controller.... suffers from a less than first rank supplier which would worry
most of my customers.
When you see that you know you are not going to make any progress. Obviously the poster has not looked very hard and has no intention of doing so. These guys need their interrupts and cannot imagine a world without them.
When you see that you know you are not going to make any progress. Obviously the poster has not looked very hard and has no intention of doing so. These guys need their interrupts and cannot imagine a world without them.
First, I would point out there's much more to that thread. Second, that thread simply repeats (nicely in one place) the gripes you most often hear/read about the Propeller. Lastly, if Parallax are truly serious about expanding Propeller's adoption in commercial/industrial designs, they would do well to find a way to make progress here.
I agree that the interrupt thing is (mostly) a bogus stumbling block, but many of these other "issues" aren't so easily dismissed. Regardless, that rhetoric is coming from the very markets I assume Parallax would like to penetrate. Best not to simply ignore it.
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).
No need to be "sorry." The 8051 is still alive and kicking. I'll use one myself from time to time.
I actually read that entire "elsewhere" thread a while back. As far as I remember the post I quoted sums up most of it.
Lets's look at that "150MIPS for cheaper with an M4" statement. That might be true, but if you want to bit bang some weird serial protocol or perform some other fast logic on pins you might look at a custom logic circuit or an FPGA to do it. On the other hand there is a whole class of such jobs for which a single Prop COG is sufficient. You will not look at a 150MIPS M4 as you will eat all it's power doing that little task, as soon as you have an interrupt or some other processing arrive it fails.
Conclusion: Comparing MIPS in such an off hand way is not the right way to look at it.
Next up " there is all the pain of programming and synching multiple cores which is (I think) worse than the pain of managing DMA": Really, Many of us here, even relative newbies are throwing multiple COG programs around with ever suffering such management problems. Most of the time it's not something you have to thing about much, just use an object that does it for you. When you do need to communicate COG to COG in your own code it's not exactly rocket science.
Conclusion: The guy making that post had not looked into the Prop much.
Next up: "suffers from a less than first rank supplier which would worry most of my customers."
Ah, got me there. This is a non-technical comparison about which I cannot say much. Except that given the huge rate of churn in the chip industry I would not guess my design was in better hands with another manufacturer.
Conclusion: Stick with 8051's and other archaic designs if you want a reliable supply. But hasn't the Prop been around longer already than some devices that have come and gone in recent years?
I actually read that entire "elsewhere" thread a while back. As far as I remember the post I quoted sums up most of it. ...Conclusion: The guy making that post had not looked into the Prop much.
How about this guy ...
And I'd imagine it is similarly "easy" to work with - some things /will/
be easy, but other things will be a lot harder in practice. In
particular, 8 cores/threads sounds great when you start, and you can
write very elegant UARTs, flashing lights, etc. But in the real
application you need more than 8 cores, and you start having to combine
tasks within a single core/thread and the elegance, clarity, and ease of
development go out the window. The other big problem is the small
memories - you start off thinking how cool these devices are that are so
fast you can make USB or Ethernet peripherals in software cores, using
ready-made "software components" from the company's website. But then
you discover that to actually /use/ them for something more than a
flashing lights demo takes more ram than the chips have.
So it's a nice idea for some types of problem - but it is not unique,
and it is only really good for a small number of applications.
... I have no doubt that you can do lots of fun things with a Parallax - and I have no doubt that you can do commercial projects with it. But I also have no doubt that 8 cores/threads is far too few to be able to dedicate a core to each task in non-trivial real world applications. And when you have to multiplex tasks within each core/thread, you have lost much of the elegance that you had by using the multi-core system.
To my mind, these seem tolerably well thought-out criticisms not entirely lacking in substance.
Conclusion: Stick with 8051's and other archaic designs if you want a reliable supply.
(Of course, 8051 isn't really the Prop's main competition. Those would likely be (X)Mega AVR, PIC32, ARM, FPGA/CPLDs, Cypress PSoC, ...)
But hasn't the Prop been around longer already than some devices that have come and gone in recent years?
Probably so. (I'm not sure that ARMs aren't coming and going too fast myself.) But, rightly or wrongly, Parallax as chip supplier is an issue in the minds of a few people.
Anyway, all this stuff is out there - I know that I hear it - and shouldn't be ignored or dismissed out of hand. Preaching to/getting feedback from only the choir (of which I consider myself one) won't get Parallax the new business they seemingly need/desire.
At the end of the day we have a huge range of devices to choose from in a space between the SN7400 and the high end FPGAs, between the tiny Atmegas to the multi-core Intels and AMDs.
All of those devices have a space of applicability, many of them overlapping.
Question is what is the space of applicability of the Propeller? What applications are there where the Prop is the way to go over any other device?
What is frustrating is seeing the Prop, or any other device, dismissed out of hand because of naive numbers comparisons of MIPs or KBs. Or because it's just to different to show up on the radar of whoever is looking.
An example of this I have seen a few times is comparisons of the Prop to the Raspberry Pi. What? Who ever is asking such questions clearly has a very poor understanding of what is in front of them or a poor understanding of the Problem they want to solve.
Question is what is the space of applicability of the Propeller? What applications are there where the Prop is the way to go over any other device?
What is frustrating is seeing the Prop, or any other device, dismissed out of hand because of naive numbers comparisons of MIPs or KBs. Or because it's just to different to show up on the radar of whoever is looking.
I agree 100% and make this same point all the time. Prop is well-suited for some applications, unit price and all. Prop is also very easy to work with (especially when compared with other options you might be considering for said applications). But it's not a good fit for everything; then again, neither is, say, ARM.
An example of this I have seen a few times is comparisons of the Prop to the Raspberry Pi. What? Who ever is asking such questions clearly has a very poor understanding of what is in front of them or a poor understanding of the Problem they want to solve.
Some of the reasons given for not choosing a Propeller are not things that Parallax can fix. For example, the "less than first rank supplier" objection Parallax can't control. They're not a Microchip or TI or Dallas/Maxim. It's sort of what happened in the mainframe computer era when people chose IBM simply because of their size and market penetration.
The absence of interrupts is something that won't be fixed because the downside of adding an interrupt feature is much much worse than the small amount of sales that would be generated by being able to say that they exist in the chip. There are all sorts of technical reasons why interrupts would fundamentally change the internal design of the chip and the feature would cost in terms of chip area even if never used.
As far as numbers of cogs and memory per cog ... How much is it worth? The cogs and their memory take a lot of chip area. How many cogs are needed for the application? How much memory is needed? You can complain about what the chip doesn't have, but would anyone "put their money where their mouth is"? Parallax has thoughtfully chosen one set of parameters based on tradeoffs between what the chip can do and what people would likely want to pay for it. You can disagree with them, but it's easy to do so when you're not putting any money on the line.
Some of the reasons given for not choosing a Propeller are not things that Parallax can fix. For example, the "less than first rank supplier" objection Parallax can't control. They're not a Microchip or TI or Dallas/Maxim. It's sort of what happened in the mainframe computer era when people chose IBM simply because of their size and market penetration.
Meh, I'm not so sure about that. I think many of these people view Parallax as, primarily, a hobbyist/educational outfit and Propeller as more a novelty. Surely there are things that can be done (marketing, etc.) to dispel those perceptions to some degree.
The absence of interrupts is something that won't be fixed because the downside of adding an interrupt feature is much much worse than the small amount of sales that would be generated by being able to say that they exist in the chip. There are all sorts of technical reasons why interrupts would fundamentally change the internal design of the chip and the feature would cost in terms of chip area even if never used.
The person who does not think it possible to program a microcontroller without interrupts likely will never be sold on the Propeller concept. On the other hand, those for whom lack of interrupts ties in with other concerns about Prop, such as memory and performance constraints, probably can be won over *without* adding interrupts.
As far as numbers of cogs and memory per cog ... How much is it worth? The cogs and their memory take a lot of chip area. How many cogs are needed for the application? How much memory is needed? You can complain about what the chip doesn't have, but would anyone "put their money where their mouth is"?
Why should anyone. on those forums, much less here, put up money for anything? That is for Parallax to do. It's their chip, their concept, their business.
Parallax has thoughtfully chosen one set of parameters based on tradeoffs between what the chip can do and what people would likely want to pay for it. You can disagree with them, but it's easy to do so when you're not putting any money on the line.
Again, why would anyone "put money on the line" in this context other than Parallax? That's a very odd way to view this, if you ask me. In fine, either the chip does what folks want, for the price they want, or it doesn't. Apparently, for many the answer is in the negative. Certainly Parallax can ignore them altogether, dismiss them as fools unable to see the light. That is for Parallax to decide. Period. However, one can wonder, and aloud, whether it's a good business strategy.
Comments
Threading is going to be great. I am really proud to be the one who, after Chip had done all the hard work putting task switching in, casualy suggested that automatic multi-threading should be doable. http://forums.parallax.com/showthread.php/141706-Propeller-II?p=1117188&viewfull=1#post1117188
Chip, being a genius, had it implimented a few days later http://forums.parallax.com/showthread.php/141706-Propeller-II?p=1122235&viewfull=1#post1122235.
It's possible that that casual suggestion is my greatest contribution to humanity:)
Yes. That is exactly what I was trying to say earlier. I hope somone in Parallax is listening.
I was thinking of say 8 to 16 configurable peripherals uart/i2c/spi/pwm with std commodity functions. If your particular app requires more than that, you go with SW peripherals for the remaining
We do have 16 configurable "counters" already...
Alex
"I just think it would be unbeatable with a small amount of std goodies" ... You are entitled to your opinion. Given the facts ... tradeoffs of chip area mostly ... and issues around how to share a fixed set of peripherals among a set of essentially identical parallel processors, it's not anywhere as simple as you've suggested. Chip, as the sole chip architect and mostly sole designer, had to make some hard decisions early in the process and, as far as I can tell, doesn't feel that he made mistakes sticking to a pure SW peripheral model. He's essentially doing it over again with the Prop-II and there won't be HW peripherals. I'm sure there are / will be people who won't use the Propeller because of that, but I'm also sure that there will be people who will use the Propeller (for commercial products) because of the unique advantages brought about partly because of the use of SW peripherals.
There's a huge difference between the cog counters and HW peripherals like a UART / I2C / SPI / PWM in terms of complexity and chip area. They're hard to debug ... often have serious bugs well into the product's revision history. Check out nearly any PIC with HW peripherals.
I agree, I was just wearing the devils hat
Absolutely! And make it a simple drag and drop from the editor to add these std stuff. That would be a good and elegant workaround.
Alex
-Phil
1. everything else that everyone here has said.
2. tools are free. okay maybe that is not so unusual. and *they work* without muss and fuss. okay maybe that is not so unusual.
3. the fact that we can have a dialog with the designers of the device from time to time and the company actually LISTENS to our needs as a bunch of (well at least for me) small fries. now THAT is unusual.
Not sure if it's still true, but when I started, no other microcontroller did that.
So, my choice was FPGA or Propeller.
If I had infinite time, maybe FPGA could be better, but the Prop let me get something working very quickly...
Alex
Funnily enough, in that same thread I was against hyper threading (or whatever it is really called), I said "I worry about these cache and hyper-threading ideas, seems they could lead to all kinds of gotchas.http://forums.parallax.com/showthread.php/106059-Should-the-next-Propeller-be-code-compatible?p=747009&viewfull=1#post747009. And later Chip agreed: "Yes, I feel much better about simplicity, too".
Seems that when Chip had done all the heavy lifting on task switching the automatic threading could just fall into place.
It has been fascinating to see how that and many other ideas have evolved in the Prop II over the years with all the discussion between Chip and the forum members. I can't think of any other processor or MCU that has been designed so openly with so much customer feed back. Might be a world first.
There are those of a more software oriented frame of mind who say that having critical timing be determined by the number of instructions in your code is a bad idea that "instruction counting" is bad practice. They would say it makes the code complex and unmaintainable and if you are using a compiler you cannot rely on it always generating the same code in future versions, bla bla bla.
To that end guys like XMOS have added all kinds of timer features to their devices so that code can always synchronize to real hardware time and other events. Given that, your code will always work even if your chips clock rate gets upgraded or the compiler optimization gets improved etc etc. They use events rather than interrupts so it works out quite simply.
As a practical matter theXMOS approach adds a whole lot more complexity to the processor architecture and then requires that is programmed in a language that can use those timers and the evented model. You have to use XC rather than C. Meanwhile with PASM being so simple and regular the good old instruction counting approach has worked just fine.
The Parallax point of view.
What is that? You don't need to buy the 'right processor' with all the features in silicon. You can develop one generalized very fast processor with a minimum of features and have the software/firmware adapt it to whatever you need to deploy.
Why do that?
You learn more and become a better engineer.
It is all about becoming 'above average' in a world that only the 'above average' people prosper.
Hello,
Are there any examples of the propeller being used in a commercial or hobby 3D printer? I personally have not knowingly seen one , but I would like to.
-Cameron
You can write code to do soft peripherals, or write code to handle external hardware, either way you code to perform or manage the function. Just comes down to the code size to do what you want and the time to realize the function.
Then again if I can go soft periph, I get the benefits and limitations already listed here, what I don't get may be the added cost of all the external silicon. Total cost of implementation will not exceed the cost of the prop chip and development time of the function. For hard peripherals, that needs to account for the mcu +/- cost difference , the glue logic, the peripheral device and the cost of the board space all of that will eat up. As always, cost vs benefits.
I don't have as much time as I would like for playing at night, but the prop gives me the best return for my efforts at the moment. Someday I may get to play with one of the ARM dev kits I have already on hand, but that is another day's post.
FF
Recalling some of my S/V history late '70s, I seem to recall that the Zilog dual uart slipped so badly that they ended up modifying (hard coding) a Z80 cpu to be a DUART. Maybe just rumor, but heard it from a couple different sources.
PWM on the other chips I've used is useless for servo outputs or inputs, because the precision for the required cycle time isn't high enough. The Prop, not having fixed hardware, doesn't have that limitation.
My current Prop code has:
- 1us precision on 6 PWM inputs
- 1us precision on 8 PWM outputs at 250 Hz (plans for significantly higher than that - IE 100 ns or better precision with up to 500 Hz output)
- 3 x I2C devices (gyro, accel, mag) being read and post-processed on a single hardware thread - angles computed, etc.
- Full duplex serial output for debugging, status, and configuration
- Logging to an SD card
- Flight control running at 250 Hz, uninterrupted
That's not all of it, but doing all of that on a single-threaded MCU of any other kind would be *very* hard. I know people are doing it, but they're often "cheating". For example, the remote control input is usually done with a PWM to serial converter, using an ATTiny or something like it. On the Prop, I could do either one and just make it configurable.
The Prop isn't the perfect choice for everything. There are some applications where you need a monolithic, single-threaded program, or a very tiny, single-threaded program. The ATTiny is a good choice for the latter case, and there are a number of good choices for the former. If you need one chip to do half a dozen or more things at the *same time* without going insane, the Prop is a fantastic choice. Especially if those things are industrial protocols that are old or non-standard, or just slightly outside the norm, or someone inserted an extra bit somewhere, or ... you get the idea. Fixed hardware generally chokes on those things. With the Prop, you can just alter the "fixed hardware", because it's actually software that's shipped with it, as source.
Jason
This forum! I follow and use Microchip, AVR/Arduino, Raspberry PI and a slew of others in the past. Nowwhere to you have such an avid, expert and helpful bunch in one place.
VGA and TV support out of the box (with minimal external components) or ready to go like the Demo boards.
Same for keyboard, mouse and all the aforementioned peripherals.
Edit - Also: Unparalleled support of legacy products. You can confidently design with Parallax products and be assured of availability in 10 years. Older products from other vendors are dropped like a hot potato if they can't sell 10 million units/year.
RickInTexas
I used to bristle at the notion of using a cog for some mundane task but over time I have really come to appreciate the fact that the Propeller can do a great many things and the same chip can be used to drive 16 PWMs in one project or handle 4 I2C buses in another the only change is the program running on it. The only thing I end up wishing for most times now is more RAM for C/C++ work.
In my case, I'll just echo what others here have proffered as the Propeller's advantages: computing power w/o unwarranted complexity, reduced development time, flexibility, support/community/forums.
That said, I too have problems getting clients and others to consider the Propeller as a viable option. Not infrequently I'm met with a queer look when I mention it. When I press them, their objections generally mirror those easily found in this thread and elsewhere (http://compgroups.net/comp.arch.embedded/parallax-propeller-3/1957243).
Merely from a practical design standpoint, I'd say the Propeller's biggest weakness right now is that it's somewhat memory constrained. (Likewise, but not as critical, IMO, a little more oomph would be nice, so that you didn't have to drop out of Spin quite as often.)
I agree that the interrupt thing is (mostly) a bogus stumbling block, but many of these other "issues" aren't so easily dismissed. Regardless, that rhetoric is coming from the very markets I assume Parallax would like to penetrate. Best not to simply ignore it.
Lets's look at that "150MIPS for cheaper with an M4" statement. That might be true, but if you want to bit bang some weird serial protocol or perform some other fast logic on pins you might look at a custom logic circuit or an FPGA to do it. On the other hand there is a whole class of such jobs for which a single Prop COG is sufficient. You will not look at a 150MIPS M4 as you will eat all it's power doing that little task, as soon as you have an interrupt or some other processing arrive it fails.
Conclusion: Comparing MIPS in such an off hand way is not the right way to look at it.
Next up " there is all the pain of programming and synching multiple cores which is (I think) worse than the pain of managing DMA": Really, Many of us here, even relative newbies are throwing multiple COG programs around with ever suffering such management problems. Most of the time it's not something you have to thing about much, just use an object that does it for you. When you do need to communicate COG to COG in your own code it's not exactly rocket science.
Conclusion: The guy making that post had not looked into the Prop much.
Next up: "suffers from a less than first rank supplier which would worry most of my customers."
Ah, got me there. This is a non-technical comparison about which I cannot say much. Except that given the huge rate of churn in the chip industry I would not guess my design was in better hands with another manufacturer.
Conclusion: Stick with 8051's and other archaic designs if you want a reliable supply. But hasn't the Prop been around longer already than some devices that have come and gone in recent years?
And I'd imagine it is similarly "easy" to work with - some things /will/
be easy, but other things will be a lot harder in practice. In
particular, 8 cores/threads sounds great when you start, and you can
write very elegant UARTs, flashing lights, etc. But in the real
application you need more than 8 cores, and you start having to combine
tasks within a single core/thread and the elegance, clarity, and ease of
development go out the window. The other big problem is the small
memories - you start off thinking how cool these devices are that are so
fast you can make USB or Ethernet peripherals in software cores, using
ready-made "software components" from the company's website. But then
you discover that to actually /use/ them for something more than a
flashing lights demo takes more ram than the chips have.
So it's a nice idea for some types of problem - but it is not unique,
and it is only really good for a small number of applications.
...
I have no doubt that you can do lots of fun things with a Parallax - and I have no doubt that you can do commercial projects with it. But I also have no doubt that 8 cores/threads is far too few to be able to dedicate a core to each task in non-trivial real world applications. And when you have to multiplex tasks within each core/thread, you have lost much of the elegance that you had by using the multi-core system.
To my mind, these seem tolerably well thought-out criticisms not entirely lacking in substance.
8051s are not as archaic as you might think (http://www.silabs.com/products/mcu/Pages/8-Bit-Microcontrollers.aspx); they work dandy for some applications - and are quite cost-effective too.
(Of course, 8051 isn't really the Prop's main competition. Those would likely be (X)Mega AVR, PIC32, ARM, FPGA/CPLDs, Cypress PSoC, ...)
Probably so. (I'm not sure that ARMs aren't coming and going too fast myself.) But, rightly or wrongly, Parallax as chip supplier is an issue in the minds of a few people.
Anyway, all this stuff is out there - I know that I hear it - and shouldn't be ignored or dismissed out of hand. Preaching to/getting feedback from only the choir (of which I consider myself one) won't get Parallax the new business they seemingly need/desire.
All of those devices have a space of applicability, many of them overlapping.
Question is what is the space of applicability of the Propeller? What applications are there where the Prop is the way to go over any other device?
What is frustrating is seeing the Prop, or any other device, dismissed out of hand because of naive numbers comparisons of MIPs or KBs. Or because it's just to different to show up on the radar of whoever is looking.
An example of this I have seen a few times is comparisons of the Prop to the Raspberry Pi. What? Who ever is asking such questions clearly has a very poor understanding of what is in front of them or a poor understanding of the Problem they want to solve.
Yeah, really makes you wonder.
The absence of interrupts is something that won't be fixed because the downside of adding an interrupt feature is much much worse than the small amount of sales that would be generated by being able to say that they exist in the chip. There are all sorts of technical reasons why interrupts would fundamentally change the internal design of the chip and the feature would cost in terms of chip area even if never used.
As far as numbers of cogs and memory per cog ... How much is it worth? The cogs and their memory take a lot of chip area. How many cogs are needed for the application? How much memory is needed? You can complain about what the chip doesn't have, but would anyone "put their money where their mouth is"? Parallax has thoughtfully chosen one set of parameters based on tradeoffs between what the chip can do and what people would likely want to pay for it. You can disagree with them, but it's easy to do so when you're not putting any money on the line.
The person who does not think it possible to program a microcontroller without interrupts likely will never be sold on the Propeller concept. On the other hand, those for whom lack of interrupts ties in with other concerns about Prop, such as memory and performance constraints, probably can be won over *without* adding interrupts.
Why should anyone. on those forums, much less here, put up money for anything? That is for Parallax to do. It's their chip, their concept, their business.
Again, why would anyone "put money on the line" in this context other than Parallax? That's a very odd way to view this, if you ask me. In fine, either the chip does what folks want, for the price they want, or it doesn't. Apparently, for many the answer is in the negative. Certainly Parallax can ignore them altogether, dismiss them as fools unable to see the light. That is for Parallax to decide. Period. However, one can wonder, and aloud, whether it's a good business strategy.