I have to say I'm in the frustrated camp. The propeller is a great simple engine for doing some IO intensive stuff at moderate speed, but also at relatively high cost.
So while I think it's fine for the hobbyist community, and the very low volume product world (like <100 units), it's not commercially competitive with other microprocessors.
The Propeller and 2-
- require an external boot ROM
- have severe memory limits, and paged memory is very slow
- having to deal with page memory (which to most people implies your CPU is not truly 32 bits)
- do not have 5V tolerant pins
- (prop 1) requires an external crystal
- (prop 2) requires multiple supplies
- not enough memory to do true VGA
- proprietary architecture means poor tool support
The competition at around $2 in single volume-
You get an ARM with 5V tolerant pins, only needing a single supply, built in Flash memory (total memory around double the prop 1), internal oscillators, a variety of hard peripherals, which can equate to COGs that would be dedicated to something else
Performance -- 110K Dhrystones/sec vs prop 1 at 6K -- PS because COGs would have to share an external memory, the multiple CPUs doesn't buy you much if any performance increase
Will the Prop 2 fair much better?
I kind of doubt it, in the commercial world. It still has severe memory limitations and at $10 you're comparing to 200 MHz ARMs with multiple cores, many built in peripherals, including external memory controllers that have very high throughput to external memories, and built in LCD controllers capable of VGA and SVGA at full 24 bits/pixel. Or in the $20 range (in low volume) there are the ARM9/11 cores that are running 600/800 MHz and linux/android capable which are being used in the Rasberry Pi /BeagleBone.
I'm afraid if Parallax keeps its eggs in the Propeller basket, it will get left behind, I love their support community and the users, but technology moves on.
brucee,
Parallax will keep its eggs in the Propeller basket. Although an ARM can do some things more cheaply than a Prop1, there are a number of things that the Prop1 can do that an ARM cannot. The hard peripherals of the ARM are fixed in function while the cogs of the Prop are completely software controlled. That's both a blessing and a curse depending on how well the particular set of hard peripherals of a particular ARM (or PIC or ATMega or whatever) chip match your needs. The Prop2 will do particularly well in unusual signal processing situations, some video applications, some communications applications, and the hobby and education markets. It will work particularly well in situations where there's a limited run of devices and prototype development is important.
Neither the Prop1 nor the Prop2 is a general purpose microprocessor like the ARMs. It's never been marketed that way and it's absolutely not competitive. It's a microcontroller. The Prop2 is looking to be a very very sophisticated microcontroller that will still be able to do many things that no other microcontroller will do as well. Whether that will provide a large enough market for Parallax is yet to be seen. Their philosophy allows them to take the time that few others can afford to do to build their markets.
I am trying to get this prop chip to run wondoze so that I can replace my PC. It is just not up to the job and no-one want to help me. Guess I will just have to use one of those expensive Intel or AMD chips after all!
PostEdit: I should have explained further. I have no idea how to do this. Why isn't there a fully documented object in OBEX that I can just use, together with the fully explained circuit diagram, Bill of Materials, and all under MIT so I can make some money without any hard work. Why doesn't Parallax just provide a decent App Note to do this.
BTW, don't point me to a thread where this is discussed. That's just too hard.
I am trying to get this prop chip to run wondoze (....).
We all will be trying to run windoze with Propeller 2 I think Prop2 will be capable to emulate an advanced dos box (and then run win 3.1)
For me what is most frustrating with the Propeller is its unavailability here. We need cheap money transfer (=PayPal) and cheap shipping so I can tell my friend - Look, the Propeller is cool, go, buy it and try. Now I cannot. Parallax store shows 50$ shipping cost if you try to buy something there.
Parallax... do something with this 50$ shipping in your store....
Someone, who wants to start learning microcontrollers stuff here will start with the Arduino and Atmega88/168. They are cheap here and ready available in every shop with electronic parts.
Parallax... do something with this 50$ shipping in your store....
Seconded! It is quite possible to send goods from the US far cheaper than $50. I was fortunate in that someone helped me out by sending a box of parts to me but Parallax ought to be doing it themselves.
I agree the Prop can be frustrating due to memory/speed limitations as I have mentioned here previously. Frustrating because often I found that it almost has everything I need but not quite.
However there are a few of your remarks I have to respond to:
..it's not commercially competitive with other microprocessors.
Depends what you are trying to do. Note that the Prop is a micro-controller not a microprocessor. I.E. self contained solution that is not competing with microprocessors.
...require an external boot ROM
Not really an issue. Note that FPGAs require an external configuration device as do the micro-controllers from XMOS.
..have severe memory limits, and paged memory is very slow
As do many micro-controllers. The Prop does not have paged memory, or do you mean the slow down caused by 8 cores sharing the HUB RAM? That is a shame but is the price you pay for the simplicity and determinism of interrupt free programming.
..having to deal with page memory (which to most people implies your CPU is not truly 32 bits)
As above. The Prop is for sure 32 bit.
do not have 5V tolerant pins
That's the way chips are going. It does not seem to be much of an issue looking at all the projects that pass by the forum.
...requires an external crystal
The Prop will run happily with no crystal. For accuracy use a crystal or external clock source. Perhaps I have not been paying attention but which other microcontrollers do not need a crystal?
..(prop2)requires multiple supplies
That is a shame. I note than many other devices also have the requirement, especially when push for high performance for example the devices from XMOS.
not enough memory to do true VGA
Perhaps, how many other MCUs can do VGA at all whilst still being able to easily implement other real time functions?
..proprietary architecture means poor tool support
Not sure which nuance of "proprietary" you mean.
Enough of the workings of the Prop are published that anyone can build one if they want to. Perhaps they would have write their own Spin byte code interpreter though.
Poor tool support seems to be a thing of the past now that Parallax has embraced GCC and other opensource goodness. Anyway the available tools have always been sufficient I believe.
The competition at around $2 in single volume...You get an ARM...
True. The world is awash with ARMs. And AVRs, and PICs etc etc.
That is not to say there aren't niches where the Prop works and they don't. How many of them can do this: http://forums.parallax.com/showthread.php?140777-Audio-Signal-Processing-on-the-Propeller-Demo-Board or drive up to 32 servos. etc These may seem like artificial cases but they do indicate where the Prop shines and other devices would be struggling.
I'm afraid if Parallax keeps its eggs in the Propeller basket, it will get left behind, I love their support community and the users, but technology moves on.
Indeed technology moves on. Hence the Prop II.
But are you saying that Parallax should drop the whole Prop architecture idea and build dirt cheap ARMs or some such instead?
I don't think they are in a position to compete in that arena, and I'm sure they don't want to.
Better to have a unique selling point and a niche market. Others agree, for example XMOS is on a similar path.
Finally, those cheap ARMs as used in the Rasperry Pi and such are totally unusable by hobbyists or small shops unless they come in a working board like the Pi. You are unlikely to want to get the raw chip, design a board for it, target an OS at it etc etc. Better to buy Pi like boards and mate them with Props for the I/O and real time stuff. Propeller Pi anyone?
there are a number of things that the Prop1 can do that an ARM cannot
I'm still looking for that application, with 900 vendors of ARMs out there you can usually find some version of ARM with the peripheral you need. From ones with LCD controllers and SDRAM support so you can do true SVGA in 16 bits of color, not just 16 colors per line, to small ARMs with 16 PWM channels
Many ARM vendors have internal regulators and trimmed internal oscillators, so do provide a 1 chip solution.
If you accept a multiple chip solution, seems to me a small ARM and a small FPGA scales much better to do the signal processing and can run at much faster rates.
Yes COG memory and LMM are not really paged, though I'm not sure what to call it, and that's the closest thing I can think of. But having to partition your program to fit in 2K, then taking a huge performance hit to go beyond that is frustrating.
So my expertise is in the engineering side, as for marketing my amateur opinion is that Parallax should have adopted another CPU long ago, as the success of the Arduino has show there was a huge niche waiting to be filled, unfortunately by an inferior AVR part. Parallax could still have done a Propeller, but they should have moved off the dying Scenix platform long ago. Again my amateur marketing opinion.
with 900 vendors of ARMs out there you can usually find some version of ARM with the peripheral you need.
And that is exactly the Problem the Prop solves for many of it's users. Unless you are building a large quantity of some widget you really don't want to have expend the time and effort to trawl through the offerings of 900 vendors searching for the device that fits. Never mind getting into all those 1000 page data sheets and becoming familiar with umpteen development environments. Also you have great flexibility in being able to change the make up of the project in hand as requirements change.
If you have a stock of Props it's flexibility allows you to tackle a wide range of problems without having to order up and become familiar with a new device for each project. May be a bit more expensive but for hobbyists, small shops, prototypers and such it is a god send.
A small ARM and FPGA will get you a lot of bang for the buck. It will also require a great deal of study to design and get going.
I agree the 2K cog limit can be frustrating. It's pretty much welded into the architecture though. I'm not sure the performance hit of sharing HUB is as bad as it seems at first. On a regular mcu you might have 8 interrupts firing off all the time. Effectively sharing the RAM among 8 processes, with the extra performance hit of sharing registers as well, not to mention messing up timing.
I have no idea about what Parallax was up to before the Prop. They must have been doing something right in order to have gotten to the Prop and now Prop II.
I love this aspect of the Propeller. It's difficult to invest so much energy in just product selection. Well, maybe not difficult, just not a value add. If I've got a Prop, that time is spent on doing stuff with it, and not having to worry about sourcing this and that, because software is nearly always an option.
The 2K limit was a bother at first, just because I was used to building larger programs in assembly. Truth is, a lot of cases can be broken into discrete, reusable chunks. No worries on those.
Because the COG is really just all registers, I see PASM more as microcode than I do anything else. A COG can be programmed to run in various ways, one of which is simply a CPU that does stuff with the common RAM. And there are 8 of them!
On P1, this is at issue because of the scale people tend to want to work at. It's overall speed is right in the zone where doing things like LMM, SPIN, etc... tend to make things a little challenging, where pure assembly would deliver easily. (Difficulty perception surrounding ASM aside) The slower access to shared memory is a great trade off for consistency as well. Frankly, it's not that slow, once all things are considered and optimized.
On P2, most of those things go away, with scale reaching up past many things people want to do. Of course, people will be there at the edge doing stuff, with similar frustrations. Always happens, but the "it works well" space will be considerably improved.
At that speed and scale, larger shared memory and external memory functions improved, the COG as microcode approach is going to make an awful lot of sense. Can't wait to see that all play out.
Parallax stuck with the dying Scenix platform partly because they (and others) could get performance out of it that they could not get from other microcontrollers available at the time. Part of this performance was the ability to do fast, deterministic programming and soft peripherals. Some of the design choices in the Propeller came directly from Chip's experience with the Scenix processors.
Partitioning a program to fit in multiple cogs or to have to use overlays is perhaps an indication that the Propeller may not be the best choice as a microcontroller for your project. That may be a good solution when other parts of the code are really ideally solved by the use of a cog and its limited memory. That kind of decision making is part of engineering. Considering that any program consists of a small portion that's performance limited plus a much larger portion that's not executed enough to make a significant different in performance, Spin + native instructions or LMM / XMM + native instructions is an excellent mix.
Both an internal 1.8V regulator and a trimmed internal oscillator would be nice additions to the Propeller. A 1.8V regulator would occupy a large amount of chip real estate and the Prop 2 design is already very large. 1.8V regulators are cheap and readily available and that's a fair tradeoff against loss of features or on-chip memory size. I don't know what it would cost to do the necessary chip by chip calibration of the internal oscillators. There would also need to be a chip temperature sensor since that's a large part of the frequency drift. A good crystal is cheap. Both features (built-in regulator and trimmed internal oscillator) may not be doable with the process being used for manufacture even if the chip area were available. I don't know the reasons behind the choice of foundry and processes used. There may also be patent licensing issues.
Parallax decided years ago to develop their own microcontroller with some unique features and design decisions. They control and own the intellectual property. They have a history of maintaining their products for years and years which is very different from most of the industry. Someone who designs a product with the Propeller 1 will still be able to buy parts 5 or 10 years from now if they want. Technology marches on, but it's not always necessary to redesign products to match. Sometimes there are advantages to do so, but not always.
Some open questions to all the the entrpeneurial wizards, chip designers, captains of small businesses and business consultants out there that are so frustrated by Parallax and the Propeller.
Can you provide me with your web sites so I can review your company, interact with your forums and examine the designs of your chips?
Can you arrange for me to sit and talk with yoru CTO and principal chip architect at your next regional user conference?
Can you hook me up with your President and let me discuss documentation plans for your new compiler launch?
Can you allow me to interact with yoru developers?
Can you show me the 20 year history of you succesful privately held company?
Can you openly discuss the design of your next micro-C with your customer base?
Can you provide information about your educational programs to by 4H group?
Can you show me the 40+ people YOU employ?
Please post information, we are all open minded about micr-controllers and would be interested in trying YOUR products.
I find the tone of this thread very much like going to Friend A's home, asking for a meal, and then in the middle of that meal declaring, "Friend B is a better cook than you!"
I find the tone of this thread very much like going to Friend A's home, asking for a meal, and then in the middle of that meal declaring, "Friend B is a better cook than you!"
...and then asking if you can stay over since you drank a bit too much!
So , if in C or Pascal indentation is optional and start/stop blok keywords are mandatory ( {, } in C, begin,end in Pascal).... let reverse this... Optinal start/stop keywords...
pub something | i
{begin}
repeat i from 0 to 100
{begin}
'some code here
{end}
{end}
This is vaild in current version of Spin and everyone can use it now
I find the tone of this thread very much like going to Friend A's home, asking for a meal, and then in the middle of that meal declaring, "Friend B is a better cook than you!"
I agree that it's taken a nasty turn. My problem with the propeller isn't with the propeller itself but since I don't have my own company, many employees, interactive forum, CTO, etc, etc, etc, etc I can't say what they are.
Tools, documentation, and marketing aside... (things that Parallax was not able to provide as adequately as companies much larger)...
The propeller chip's concept of architecture (maybe not the current architecture, but the concept) has the ability to simplify the real time operating system (RTOS) world. Which has a huge market. You can program all the things you want with your ARM or Atmel chip and use all the hardware features and do amazing things. Sure, the chips are cheap, sure, they are powerful. But, here's the kicker:
As an engineer you have to deliver a product that works. Preferably, you'll sleep better at night if you can mathematically prove that your product will work. The flaw in interrupt based systems that runs RTOS is that you have to preform many different tasks with different schedules on time, every time. Careful attention must be put into writing a RTOS, which means most companies license them from another manufacturer in order to just buy an RTOS that is professionally certified to work. When human life is on the life business gets serious. Additionally, you can't even use all the processor's power using an RTOS, you have to keep CPU utilization down to make sure that you don't ever have any interrupt caused failure situation.
Add locking and processes with different priorities to this mix and you have yourself a nightmare.
Now, what if I told your there was an idea where you could put all your processes in separate cores? Now it's easier to prove your system works. But wait... this means I can finish the product quicker. Oh, and what more, I can play with one process's code all I want without the whole system failing.
The above idea is in general what people enjoy on a PC. Except on a PC, you don't have to deal with the real time part of anything (in general - it's better if stuff is fast, but, the PC environment is not a hard real time system like your car's braking system). On a PC you never program for interrupts. The OS does that for you. Instead, you make "threads" that spin in loops waiting for an event. When that event happens the threads do something. Then they go back to waiting or exit.
On a PC you never write code for hardware either, you write code for device drivers which allow flexibility and abstraction away from the hardware.
This is why the idea of having multiple cores, like the propeller chip has, is so powerful
---
Now, the current propeller chip is just a start on this idea. The propeller 2 will get closer. I agree that there are limits to the propeller chip. It was designed and envisioned back in the early 2000's. The propeller chip right now shines at doing a bunch of stuff at medium speed at once. Yes, you have to make sure your program code is small. But, if you meet that limitation it works.
4x5n, my snippy comment wasn't directed at you or any of the forum members with legitimate concerns about what the propeller lacks and reasonable thoughts on how to improve things. Some of the frustrations are getting a bit ridiculous. Yes, it would be nice if the Propeller was a 3GHz, 16 cog, 128 pin microprocessor with 2meg of cog memory and a 4gb hub that boots wirelessly but to say it should be that and Parallax is behind if it isn't and is going to be in financial ruin if they can't provide that in a month is a bit ridiculous.
If you want the Prop to be an ARM or an Arduino or anything else then go get that anything else you desire and stop being frustrated. If you are frustrated and come up with solutions for your frustration like so many, many forum members do, then that's fantastic! If you are frustrated and trying to point out problems with reasonable and possible solutions to the frustration, by all means use the forums to voice that opinion and concern. I've seen Parallax be pretty darn responsive to the forum suggestions. But if you think there should be a catalog full of Propeller derived micro controllers using 45nm fabrication from a company of 40 some people, well, that's a bit unreasonable.
Best yet, if you see a frustration and you're able, contribute a solution like so many forum members have.
And by all means if you have all the answers on how to make a successful company with an admirable business model better, then you most likely have a successful company we'd all be happy to do business with, so please share that with us.
I find the tone of this thread very much like going to Friend A's home, asking for a meal, and then in the middle of that meal declaring, "Friend B is a better cook than you!"
What I find frustrating is that, even with all my frustrations with the Prop and its toolset/documentation, I just can't move on and use a different chip.
Once up and running there is nothing left in Hub RAM that is needed any more; the 8 blocks of 512 longs needed by the COG code having been loaded to the COGs so I should, on paper, have 32k bytes of memory to use for data storage.
Finding out how to use that memory though is a struggle. I've so far spent several hours searching the forum with a variety of search terms with not much luck. I've come to the conclusion that my best bet is to forget trying to get any help from the tools and just work out a memory map on paper and hard code the address of all my variable into the COG code.
Sounds like I've been given permission to "vent my frustration" at the propeller!!!! :-) I promise to keep the list short.
I should start out by saying that I am a customer of Parallax and don't have any illusion of thinking I know better then Chip and Ken how to run the company. I also don't think it's possible to make a perfect anything. My issues with the Propeller itself is limited. I wish it had more ram and I'm not crazy about the hub/cog approach with it's limited access window. I do understand the reason and in the long run think that compared to any other solution it's six of one, half a dozen of the other. On the positive side it's mostly transparent to the end programmer in spin and for the most part pasm. My biggest grip has to do with the lack of interrupts. I know that's almost a religious matter here so I'd just like to say that when properly done with a multi-core processor it can be both optional and implemented with a minimal amount of fuss and bother. I'm thinking of adding a spin instruction like "watchpe" and "watchnpe" and a corresponding unwatch. When a pin goes high or low execution of a given cog would stop and the "interrupt" method would start to execute. Not perfect but better then scattering tests throughout the code scanning IO pins. A single cog could be used to do nothing but watch pins but even then it would need to set a flag for methods running in the other cogs. Those cogs would then have to have to poll the flag. In the end that approach simply "wastes" a cog. Like most other spin instructions it would have to be used. Don't like it, don't use it!
Those issues are minor compared to the development tools available for the propeller. While the spin tool is usable I think we can all agree that it leaves a lot to be desired. Even Parallax appear to agree in that they're actively working on a replacement for it. The changes I would like to see to it include but aren't limited to it understanding the concept of a "project" that includes multiple files. The current nature of spin requires that individual object be contained in their own file. This means that it's reasonable to expect that a single application to require multiple file. It would be very nice that when uploading a program to a prop that the build compile the "project" for upload instead of just the file in the current window. If I had a dollar for every time I compiled only a method and uploaded it for testing instead of the entire project. Being able to have my own collection of objects in a directory of my choosing instead of the current directory or main library directory would be nice as well. I know I've seen mention of the desirability of "conditional compilation" mentioned from time to time!!
I'm sure that given time I could think of more things that "frustrate" me about the propeller and associated tools. When all's said and done I do think the pluses far outweigh the negatives and although not perfect I do think the prop is the best I've worked with. Barely beating out the 68hc11! :-)
I love what Kye said. He encapsulate my experience in a nutshell. The countless hours that were wasted by team members trying to debug nested interrupt problems on the last project at work was scandalous. Meanwhile, the test fixture I created using a Propeller worked marvelously and was always part of the solution and not the problem. If someone is complaining about the lack of interrupts on the Propeller, I think it is because their task hasn't been properly fractionated. I've found the Propeller architecture to be exceptionally flexible.
Ditto User Name's comments about interrupts. Chip was smart not to include them. I'm sure that not having them has not only resulted in faster, more reliable application development but has reduced Parallax's tech support load by a significant amount. Let's face it: an interrupt is nothing more than an emulation of multiprocessor capability. Why emulate something that already exists in the Propeller's hardware?
Interesting that of all the things that frustrate me about the propeller and the tools that go with it the only one that gets any comment has to do with interrupts.
While I have learned to hate software interrupts spending ~10 years working on industrial process control systems I've learned to appreciate hardware interrupts. While not perfect they're better then wasting cycles continually polling inputs.
Again if your application doesn't need them don't use them!
Interesting that of all the things that frustrate me about the propeller and the tools that go with it the only one that gets any comment has to do with interrupts.
You just haven't waited long enough. Keep polling this thread for updates.
I think with Steve's demonstrated ability, the SpinIDE tool/personality will be to a working state very shortly. I'm sure it will have your project methodology well supported.
The thing about interrupts in micros is that they typically fall into 2 categories: subsystem and pin. Pin interrupts are generally used for low speed I/O (did they press a button). Subsystem interrupts are generally for peripherals that need to communicate some update to the execution unit, whether it's a character available from the serial port (and you must grab it now or it's lost) or it's a timer interrupt that needs to be processed.
In both of those situations, the Propeller offers some very simple and creative solutions. Waiting for pins, a whole bunch, is just a waitpeq or waitpne, if you want blocking I/O. If you want non-blocking, just poll it during some other process and use up free cycles. Subsystems are all handled by software code, and they can do DMA instead of requiring the execution unit to handle I/O. Furthermore, you can combine additional processing within those peripherals so the "main" unit is only doing the "important" things.
Yes, it's not the conventional architecture, but it's much more flexible and potentially much more powerful. You may be able to do something easily with the propeller, but would need a more expensive micro from another company to get some corner case to work, if you were using "standard" micros.
It would be very nice that when uploading a program to a prop that the build compile the "project" for upload instead of just the file in the current window. If I had a dollar for every time I compiled only a method and uploaded it for testing instead of the entire project. Being able to have my own collection of objects in a directory of my choosing instead of the current directory or main library directory would be nice as well. I know I've seen mention of the desirability of "conditional compilation" mentioned from time to time!!
SimpleIDE is "project" oriented. Files specified by spin will be selected from the current project folder or a library folder of your choice.
Comments
So while I think it's fine for the hobbyist community, and the very low volume product world (like <100 units), it's not commercially competitive with other microprocessors.
The Propeller and 2-
- require an external boot ROM
- have severe memory limits, and paged memory is very slow
- having to deal with page memory (which to most people implies your CPU is not truly 32 bits)
- do not have 5V tolerant pins
- (prop 1) requires an external crystal
- (prop 2) requires multiple supplies
- not enough memory to do true VGA
- proprietary architecture means poor tool support
The competition at around $2 in single volume-
You get an ARM with 5V tolerant pins, only needing a single supply, built in Flash memory (total memory around double the prop 1), internal oscillators, a variety of hard peripherals, which can equate to COGs that would be dedicated to something else
Performance -- 110K Dhrystones/sec vs prop 1 at 6K -- PS because COGs would have to share an external memory, the multiple CPUs doesn't buy you much if any performance increase
Will the Prop 2 fair much better?
I kind of doubt it, in the commercial world. It still has severe memory limitations and at $10 you're comparing to 200 MHz ARMs with multiple cores, many built in peripherals, including external memory controllers that have very high throughput to external memories, and built in LCD controllers capable of VGA and SVGA at full 24 bits/pixel. Or in the $20 range (in low volume) there are the ARM9/11 cores that are running 600/800 MHz and linux/android capable which are being used in the Rasberry Pi /BeagleBone.
I'm afraid if Parallax keeps its eggs in the Propeller basket, it will get left behind, I love their support community and the users, but technology moves on.
Parallax will keep its eggs in the Propeller basket. Although an ARM can do some things more cheaply than a Prop1, there are a number of things that the Prop1 can do that an ARM cannot. The hard peripherals of the ARM are fixed in function while the cogs of the Prop are completely software controlled. That's both a blessing and a curse depending on how well the particular set of hard peripherals of a particular ARM (or PIC or ATMega or whatever) chip match your needs. The Prop2 will do particularly well in unusual signal processing situations, some video applications, some communications applications, and the hobby and education markets. It will work particularly well in situations where there's a limited run of devices and prototype development is important.
Neither the Prop1 nor the Prop2 is a general purpose microprocessor like the ARMs. It's never been marketed that way and it's absolutely not competitive. It's a microcontroller. The Prop2 is looking to be a very very sophisticated microcontroller that will still be able to do many things that no other microcontroller will do as well. Whether that will provide a large enough market for Parallax is yet to be seen. Their philosophy allows them to take the time that few others can afford to do to build their markets.
I am trying to get this prop chip to run wondoze so that I can replace my PC. It is just not up to the job and no-one want to help me. Guess I will just have to use one of those expensive Intel or AMD chips after all!
PostEdit:
I should have explained further. I have no idea how to do this. Why isn't there a fully documented object in OBEX that I can just use, together with the fully explained circuit diagram, Bill of Materials, and all under MIT so I can make some money without any hard work. Why doesn't Parallax just provide a decent App Note to do this.
BTW, don't point me to a thread where this is discussed. That's just too hard.
We all will be trying to run windoze with Propeller 2
For me what is most frustrating with the Propeller is its unavailability here. We need cheap money transfer (=PayPal) and cheap shipping so I can tell my friend - Look, the Propeller is cool, go, buy it and try. Now I cannot. Parallax store shows 50$ shipping cost if you try to buy something there.
Parallax... do something with this 50$ shipping in your store....
Someone, who wants to start learning microcontrollers stuff here will start with the Arduino and Atmega88/168. They are cheap here and ready available in every shop with electronic parts.
Seconded! It is quite possible to send goods from the US far cheaper than $50. I was fortunate in that someone helped me out by sending a box of parts to me but Parallax ought to be doing it themselves.
Cheers
Richard
I agree the Prop can be frustrating due to memory/speed limitations as I have mentioned here previously. Frustrating because often I found that it almost has everything I need but not quite.
However there are a few of your remarks I have to respond to: Depends what you are trying to do. Note that the Prop is a micro-controller not a microprocessor. I.E. self contained solution that is not competing with microprocessors. Not really an issue. Note that FPGAs require an external configuration device as do the micro-controllers from XMOS. As do many micro-controllers. The Prop does not have paged memory, or do you mean the slow down caused by 8 cores sharing the HUB RAM? That is a shame but is the price you pay for the simplicity and determinism of interrupt free programming.
Not entirely true. The larger trend I see, is for chips (especially microcontrollers) to include regulators.
eg The new RX200 series from Renesas, are all Wide Vcc parts, and 1.8-5.5V is common on most smaller Microcontrollers.
Customers are buying smart pins, and wider-supply is a smarter pin.
I'm still looking for that application, with 900 vendors of ARMs out there you can usually find some version of ARM with the peripheral you need. From ones with LCD controllers and SDRAM support so you can do true SVGA in 16 bits of color, not just 16 colors per line, to small ARMs with 16 PWM channels
Many ARM vendors have internal regulators and trimmed internal oscillators, so do provide a 1 chip solution.
If you accept a multiple chip solution, seems to me a small ARM and a small FPGA scales much better to do the signal processing and can run at much faster rates.
Yes COG memory and LMM are not really paged, though I'm not sure what to call it, and that's the closest thing I can think of. But having to partition your program to fit in 2K, then taking a huge performance hit to go beyond that is frustrating.
So my expertise is in the engineering side, as for marketing my amateur opinion is that Parallax should have adopted another CPU long ago, as the success of the Arduino has show there was a huge niche waiting to be filled, unfortunately by an inferior AVR part. Parallax could still have done a Propeller, but they should have moved off the dying Scenix platform long ago. Again my amateur marketing opinion.
And that is exactly the Problem the Prop solves for many of it's users. Unless you are building a large quantity of some widget you really don't want to have expend the time and effort to trawl through the offerings of 900 vendors searching for the device that fits. Never mind getting into all those 1000 page data sheets and becoming familiar with umpteen development environments. Also you have great flexibility in being able to change the make up of the project in hand as requirements change.
If you have a stock of Props it's flexibility allows you to tackle a wide range of problems without having to order up and become familiar with a new device for each project. May be a bit more expensive but for hobbyists, small shops, prototypers and such it is a god send.
A small ARM and FPGA will get you a lot of bang for the buck. It will also require a great deal of study to design and get going.
I agree the 2K cog limit can be frustrating. It's pretty much welded into the architecture though. I'm not sure the performance hit of sharing HUB is as bad as it seems at first. On a regular mcu you might have 8 interrupts firing off all the time. Effectively sharing the RAM among 8 processes, with the extra performance hit of sharing registers as well, not to mention messing up timing.
I have no idea about what Parallax was up to before the Prop. They must have been doing something right in order to have gotten to the Prop and now Prop II.
The 2K limit was a bother at first, just because I was used to building larger programs in assembly. Truth is, a lot of cases can be broken into discrete, reusable chunks. No worries on those.
Because the COG is really just all registers, I see PASM more as microcode than I do anything else. A COG can be programmed to run in various ways, one of which is simply a CPU that does stuff with the common RAM. And there are 8 of them!
On P1, this is at issue because of the scale people tend to want to work at. It's overall speed is right in the zone where doing things like LMM, SPIN, etc... tend to make things a little challenging, where pure assembly would deliver easily. (Difficulty perception surrounding ASM aside) The slower access to shared memory is a great trade off for consistency as well. Frankly, it's not that slow, once all things are considered and optimized.
On P2, most of those things go away, with scale reaching up past many things people want to do. Of course, people will be there at the edge doing stuff, with similar frustrations. Always happens, but the "it works well" space will be considerably improved.
At that speed and scale, larger shared memory and external memory functions improved, the COG as microcode approach is going to make an awful lot of sense. Can't wait to see that all play out.
Partitioning a program to fit in multiple cogs or to have to use overlays is perhaps an indication that the Propeller may not be the best choice as a microcontroller for your project. That may be a good solution when other parts of the code are really ideally solved by the use of a cog and its limited memory. That kind of decision making is part of engineering. Considering that any program consists of a small portion that's performance limited plus a much larger portion that's not executed enough to make a significant different in performance, Spin + native instructions or LMM / XMM + native instructions is an excellent mix.
Both an internal 1.8V regulator and a trimmed internal oscillator would be nice additions to the Propeller. A 1.8V regulator would occupy a large amount of chip real estate and the Prop 2 design is already very large. 1.8V regulators are cheap and readily available and that's a fair tradeoff against loss of features or on-chip memory size. I don't know what it would cost to do the necessary chip by chip calibration of the internal oscillators. There would also need to be a chip temperature sensor since that's a large part of the frequency drift. A good crystal is cheap. Both features (built-in regulator and trimmed internal oscillator) may not be doable with the process being used for manufacture even if the chip area were available. I don't know the reasons behind the choice of foundry and processes used. There may also be patent licensing issues.
Parallax decided years ago to develop their own microcontroller with some unique features and design decisions. They control and own the intellectual property. They have a history of maintaining their products for years and years which is very different from most of the industry. Someone who designs a product with the Propeller 1 will still be able to buy parts 5 or 10 years from now if they want. Technology marches on, but it's not always necessary to redesign products to match. Sometimes there are advantages to do so, but not always.
Can you provide me with your web sites so I can review your company, interact with your forums and examine the designs of your chips?
Can you arrange for me to sit and talk with yoru CTO and principal chip architect at your next regional user conference?
Can you hook me up with your President and let me discuss documentation plans for your new compiler launch?
Can you allow me to interact with yoru developers?
Can you show me the 20 year history of you succesful privately held company?
Can you openly discuss the design of your next micro-C with your customer base?
Can you provide information about your educational programs to by 4H group?
Can you show me the 40+ people YOU employ?
Please post information, we are all open minded about micr-controllers and would be interested in trying YOUR products.
Thanks!!
...and then asking if you can stay over since you drank a bit too much!
The indentation still defines the blocking! :-(
I agree that it's taken a nasty turn. My problem with the propeller isn't with the propeller itself but since I don't have my own company, many employees, interactive forum, CTO, etc, etc, etc, etc I can't say what they are.
The propeller chip's concept of architecture (maybe not the current architecture, but the concept) has the ability to simplify the real time operating system (RTOS) world. Which has a huge market. You can program all the things you want with your ARM or Atmel chip and use all the hardware features and do amazing things. Sure, the chips are cheap, sure, they are powerful. But, here's the kicker:
As an engineer you have to deliver a product that works. Preferably, you'll sleep better at night if you can mathematically prove that your product will work. The flaw in interrupt based systems that runs RTOS is that you have to preform many different tasks with different schedules on time, every time. Careful attention must be put into writing a RTOS, which means most companies license them from another manufacturer in order to just buy an RTOS that is professionally certified to work. When human life is on the life business gets serious. Additionally, you can't even use all the processor's power using an RTOS, you have to keep CPU utilization down to make sure that you don't ever have any interrupt caused failure situation.
Add locking and processes with different priorities to this mix and you have yourself a nightmare.
Now, what if I told your there was an idea where you could put all your processes in separate cores? Now it's easier to prove your system works. But wait... this means I can finish the product quicker. Oh, and what more, I can play with one process's code all I want without the whole system failing.
The above idea is in general what people enjoy on a PC. Except on a PC, you don't have to deal with the real time part of anything (in general - it's better if stuff is fast, but, the PC environment is not a hard real time system like your car's braking system). On a PC you never program for interrupts. The OS does that for you. Instead, you make "threads" that spin in loops waiting for an event. When that event happens the threads do something. Then they go back to waiting or exit.
On a PC you never write code for hardware either, you write code for device drivers which allow flexibility and abstraction away from the hardware.
This is why the idea of having multiple cores, like the propeller chip has, is so powerful
---
Now, the current propeller chip is just a start on this idea. The propeller 2 will get closer. I agree that there are limits to the propeller chip. It was designed and envisioned back in the early 2000's. The propeller chip right now shines at doing a bunch of stuff at medium speed at once. Yes, you have to make sure your program code is small. But, if you meet that limitation it works.
Thanks,
If you want the Prop to be an ARM or an Arduino or anything else then go get that anything else you desire and stop being frustrated. If you are frustrated and come up with solutions for your frustration like so many, many forum members do, then that's fantastic! If you are frustrated and trying to point out problems with reasonable and possible solutions to the frustration, by all means use the forums to voice that opinion and concern. I've seen Parallax be pretty darn responsive to the forum suggestions. But if you think there should be a catalog full of Propeller derived micro controllers using 45nm fabrication from a company of 40 some people, well, that's a bit unreasonable.
Best yet, if you see a frustration and you're able, contribute a solution like so many forum members have.
And by all means if you have all the answers on how to make a successful company with an admirable business model better, then you most likely have a successful company we'd all be happy to do business with, so please share that with us.
I should start out by saying that I am a customer of Parallax and don't have any illusion of thinking I know better then Chip and Ken how to run the company. I also don't think it's possible to make a perfect anything. My issues with the Propeller itself is limited. I wish it had more ram and I'm not crazy about the hub/cog approach with it's limited access window. I do understand the reason and in the long run think that compared to any other solution it's six of one, half a dozen of the other. On the positive side it's mostly transparent to the end programmer in spin and for the most part pasm. My biggest grip has to do with the lack of interrupts. I know that's almost a religious matter here so I'd just like to say that when properly done with a multi-core processor it can be both optional and implemented with a minimal amount of fuss and bother. I'm thinking of adding a spin instruction like "watchpe" and "watchnpe" and a corresponding unwatch. When a pin goes high or low execution of a given cog would stop and the "interrupt" method would start to execute. Not perfect but better then scattering tests throughout the code scanning IO pins. A single cog could be used to do nothing but watch pins but even then it would need to set a flag for methods running in the other cogs. Those cogs would then have to have to poll the flag. In the end that approach simply "wastes" a cog. Like most other spin instructions it would have to be used. Don't like it, don't use it!
Those issues are minor compared to the development tools available for the propeller. While the spin tool is usable I think we can all agree that it leaves a lot to be desired. Even Parallax appear to agree in that they're actively working on a replacement for it. The changes I would like to see to it include but aren't limited to it understanding the concept of a "project" that includes multiple files. The current nature of spin requires that individual object be contained in their own file. This means that it's reasonable to expect that a single application to require multiple file. It would be very nice that when uploading a program to a prop that the build compile the "project" for upload instead of just the file in the current window. If I had a dollar for every time I compiled only a method and uploaded it for testing instead of the entire project. Being able to have my own collection of objects in a directory of my choosing instead of the current directory or main library directory would be nice as well. I know I've seen mention of the desirability of "conditional compilation" mentioned from time to time!!
I'm sure that given time I could think of more things that "frustrate" me about the propeller and associated tools. When all's said and done I do think the pluses far outweigh the negatives and although not perfect I do think the prop is the best I've worked with. Barely beating out the 68hc11! :-)
-Phil
While I have learned to hate software interrupts spending ~10 years working on industrial process control systems I've learned to appreciate hardware interrupts. While not perfect they're better then wasting cycles continually polling inputs.
Again if your application doesn't need them don't use them!
-Phil
Unless I get an interrupt I'll just keep polling this thread!
The thing about interrupts in micros is that they typically fall into 2 categories: subsystem and pin. Pin interrupts are generally used for low speed I/O (did they press a button). Subsystem interrupts are generally for peripherals that need to communicate some update to the execution unit, whether it's a character available from the serial port (and you must grab it now or it's lost) or it's a timer interrupt that needs to be processed.
In both of those situations, the Propeller offers some very simple and creative solutions. Waiting for pins, a whole bunch, is just a waitpeq or waitpne, if you want blocking I/O. If you want non-blocking, just poll it during some other process and use up free cycles. Subsystems are all handled by software code, and they can do DMA instead of requiring the execution unit to handle I/O. Furthermore, you can combine additional processing within those peripherals so the "main" unit is only doing the "important" things.
Yes, it's not the conventional architecture, but it's much more flexible and potentially much more powerful. You may be able to do something easily with the propeller, but would need a more expensive micro from another company to get some corner case to work, if you were using "standard" micros.
SimpleIDE is "project" oriented. Files specified by spin will be selected from the current project folder or a library folder of your choice.
I have never had a problem with interrupts and have designed systems with 20+ of them in use. Really, it's not difficult.