I'm sure you are right Mike, as I said we are only day dreaming. Well except it's two o'clock in the morning here:)
Though I am hoping that Chip has some surprises up his sleeve for us that will help with this issue of high bandwidth Prop- to-Prop and Prop-to-other CPU communications.
bigfoot: What do you mean about fast serial drivers for 6.25MHz? I use 115200 FDX with a 6.5MHz xtal (104MHz) without problems.
Phil & heater: I have already asked for the hub access to be granted to 1 cog if the others were not utilising it. Similar for giving 1 cog priority, such as every 2nd access and the other cogs getting 1 in 16, etc. I don't think any of those options were treated seriously.
As for you hub ram access, from what I gather about the info published, I would be extremely surprised if the mechanisms to fire counters and pulses etc cannot be used in many other ways, including helping what you propose. We discovered that the vga counters can only clock out and it would have beeb good to be able clock in. I dare say anything that goes 1 way is likely to go the other. There seems to be an aweful lot of silicon in there for the new counter logic. I cannot wait to find out what Chips thinks it can do and what we all will end up making it do. The only sure thing I can say with confidence, we are ALL going to be really and pleasantly surprised!!!
Most microcontrollers these days do not have data/address busses. We are attempting to get one in the prop because we are using the prop in ways not intended (which BTW doesn't make us wrong). Therefore, we are stuck with only 32 I/Os. I bet we would be complaining about not enough cogs today if we had the 64 I/O Prop 1B - or maybe more cogs and 80 I/Os so we could do 32bit SRAM/DRAM access.! There is still a lot of steam left in this Prop 1 and the tools are getting better all the time. Where a prop cannot cut the ice for the main processor, use another processor such as the arm or avr together with the prop(s).
Most microcontrollers these days do not have data/address busses.
True.
Where a prop cannot cut the ice for the main processor, use another processor such as the arm or avr together with the prop(s).
Exactly.
That's why I daydream about a Prop with a bus driven by an external CPU. The Prop becomes a super intelligent 8055 PIO chip if you like. With a much higher bandwidth connection to the "main" CPU. Ah well.
I have a couple of comments, as an admitted novice. And yes, I'm THAT guy who always has to point out the elephant in the room...
1. Parallax has an established reputation as an educational/enthusiast niche. Attempting to move from that persona to a commercial one is going to be difficult to say the least.
As has been mentioned, most professionals who've previously heard of Parallax will know them primarily from the Basic Stamp products. Perhaps some will know of the Propeller, however the Stamp will have set expectations that will somehow need to be placed into context as the 'old' Parallax. Parallax is, or should in my view be focused on transcending that history and showing that it is now the equal of, and exceeds in many cases the current 'standard' of the industry. Much more could be said, however as long as memory or a quick google of Parallax comes up with Basic Stamp, or the Hydra, I think it will be difficult for the average professional to give Parallax the time of day. I think this is where you need a real Business Development expert to give insight.
2. The Propeller is quite possibly too advanced, on too many fronts.
Stop and imagine if Atmel or Microchip were to announce an 8-core uC today. While there would be much screaming and cheering, I honestly thing the folks on AVR freaks and Microchips forums would be somewhat stunned. I'm sure someone would be able to come up with applications, however the sheer magnitude of having 8 cores would be welcomed for the power, and inspire at least some trepidation at the unknown interprocess communications required to make it all work.
Now, take just those 2 issues and throw in non-industry standard interrupt-less operations, lack of an industry respected C language (sorry, telling someone that there are 3 possible versions of C available is possibly more trepidatious than not), requirement of either a new langage Spin, or dropping to PASM, and lastly no 'real' peripherals.
I find the ability to have soft-peripherals unique, possibly brilliant. And suspect that many professionals consider it to be too unique, outside their comfort level (Left-brained likely), and simply un-proven.
Other honorable mentions are sole-supplier is a small company = risk, and considering all the above, and the learning curve required, not exactly enough positives to check off on a benefit analysis. And lets not forget that for someone to seriously push adoption of this new, unknown technology, a smart person would likely look at potential risk to themselves, their career/standing at their company.
For the average professional looking at the Prop on the website, I agree with another poster that it is very murky figuring out what the Prop really is. While microcontroller is mentioned, I just tried to re-read the areas I think a new site visitor would scan, and the Prop really seems to come across as more of a cpu than a controller.
I think there was a definite desire to highlight the Prop's power as more comparable to a cpu than a controller. And that may have been good at the time. However, there is very little detail on anything that an engineer interested in a controller might want to see, until one starts digging further in. And I'm pretty convinced in my mind that engineers are like most other people, if I can't find detailed information relatively quickly I'll move on to something else.
I also have to add that not stating right up front the specifics of how peripherals are done, with a list of the expected hardware one normally finds on a uC that can be implemented on the Prop is a big FAIL.
A pro coming to the site to look at the Prop is going to want to know several key things: speed, power, and peripherals. Speed and power are easily found, peripherals, hmm.
Once you start digging deeper, you find out that there is no UART, no I2C or SPI, no ADC....
But, you can add on. But there goes one of your cores. So, you need a UART, thats one core. You want I2C or SPI? OK, scratch another core. I know this is true for at least one engineer, a friend who humored me when I was talking up the Prop to him last year.
I think his final comment was along the lines of, "OK, once I've gotten this Prop to a state of usefulness with the minimum of peripherals I expect any uC to have, I'm down to 2-3 "Cores", and I still need another component for ADC. For me to even start to do anything useful with this chip, I have to expend at least 50% or more just to get basic resources, and an EEPROM, ADC, and who knows what else. Too much additional work, additional BOM when they could have added them to the uC and then left me with maybe 4 cores."
In the end, his opinion was that this felt sort of like a bait and switch. I know I'll probably get heat for this, but this is from a real engineer, with 15+ years in wireless/rf design, and generally open to new stuff.
So, this is a sample of (1), and thus not statistically valid. But that doesn't mean that it is automatically incorrect. I think the single best thing Parallax could do if they are serious about getting into the commercial arena, would be to make an investment in some product/customer focus reviews. I forget the actual term, however I've been on several years ago when the remuneration was worth the time/hassle.
I think many of these 'reasons' mentioned above are part and parcel for anyone trying to break into a market, and only more important and potentially killers when you have a product that is so radically different than the current status quo.
Like all of us, I expect the Professional Engineer has deadlines, is overworked, and wants to focus on getting stuff down, his task list checked off to allow for the new ones constantly coming in. Expecting him/her to willingly jump on the Prop wagon and drop interrupt programming which he/she has become comfy with, AND get in the groove of using soft peripherals, etc, etc at the same time is doubtful. Unless it can be proven to him that the solution can be designed faster, cheaper, made more reliable, or even just get him out of the office earlier to get home.
I've got the flame retard-ant suit on, just be aware that I like the Prop, and my comments are rooted in what I consider common sense, and 15 years in the IT field where I've seen lot of critical hardware reviewed in-house. I've seen fantastic hardware loose out to more mediocre simply based upon tools availability or being too far outside the mainstream. I'm not hatin' on the Prop.
You've made some good points and I think all of them have been encountered and mentioned at one time or another. Ken Gracey has mentioned several times that Parallax is in the process of creating a subsidiary whose purpose is to provide support for commercial / industrial use of the Propeller including the creation of presentations / documentation of the sort you and others have suggested. There's still the difficulty of the Propeller being something different from what a lot of potential customers are used to dealing with. That will take time to address and, to some extent, Parallax is limited in what it can do. Clearly, there's no benefit in changing what the Propeller is to make it more like what the Microchips, Atmels, NXPs, TIs, and others are making. Parallax is simply unable to compete there with the margins on the products being as low as they are. The Prop II will not be a "Parallax saver". It will be larger, more complex, more expensive, hungrier for power, faster than the Prop I. The Prop II will allow many more functions to be performed by a Propeller and the idea of a multi-core microcontroller with software peripherals. It will make easier some of the things that can already be done by a Prop I.
Now, take just those 2 issues and throw in non-industry standard interrupt-less operations, lack of an industry respected C language (sorry, telling someone that there are 3 possible versions of C available is possibly more trepidatious than not), requirement of either a new langage Spin, or dropping to PASM, and lastly no 'real' peripherals.
"Trepidatious"! Nice word! Precisely describes the uncomfortable feeling any professional engineer thinking about adopting the Prop would experience upon discovering that there is no C compiler supported by Parallax.
The interrupt thing I'm not so worried about - I beleive this can be made a positive selling point for Parallax - "You need to use interrupts to achieve that? how quaint!".
The remainder of your points I agree with wholeheartedly. Parallax urgently needs to implement the "gold standard" OBEX (or whatever they are contemplating), containing PASM implementations of the various commonly required peripherals, in a form that can easily be used from SPIN, C, BASIC or any other language.
That's why I like this forum. Saying things that are perhaps not popular rarely seem to cause a knee jerk reaction.
I would say that supporting GNU in someway such that Propeller could be added as an officially supported target would be a good step forward, or one of the other 'main' industry standard vendors perhaps? Not that I don't find the 100(?) languages currently available in the forum interesting, but not sure that would necessarily reassure a professional.
I would argue that incorporating some of the basic features/peripherals would be a sound investment bridge worth the silicon expense in the attempt to re-brand the Prop in a more commercial vein. How many gates would it detract from the Prop II to actually put in a UART ADC/DAC, I2C, etc? The problem is that on the one hand Parallax is trying to 'sell' the Prop as an 8 core controller to an engineer. But as soon as he looks at needing basic comms with a UART, he realizes he's now down to 7. Adding another feature, and down to 6, 5, etc.
So in reality, you don't actually have 8 cores but 8 programmable feature blocks.
If you happen to only need several, then you have 4-5 potential threads with now possibly n-fewer GPIO depending upon what you used the several cores for.
I don't know how much silicon space is required for the duplication of a video generator for each core, but it seems like an idea that overshot the mark a bit. I would think some of that space could be repurposed for something that will be actually useful for the other 99% of potential applications.
I would hope for some measure of success in the Prop II commercialization push. It just seems as though some of the design decisions made when this was a a blue-sky, "let's go for it" type of project at the outset are real handicaps to adoption today and even more so in the future.
Aren't the cogs intended for implementing peripherals? They are not really suitable for parallel processing, so it doesn't matter if they are used up for UARTs, SPI, etc.
However, the main obstacle to its wider adoption is simply the price - it's far too expensive. It can't possibly compete on price with PICs, AVRs and ARMs, except in a few niche markets, and no one has yet determined what they are. Perhaps Parallax has some ideas and they will be mentioned on the Parallax Semiconductor web site, when it materialises. They do seem to be taking an inordinate amount of time getting the new venture off the ground!
Even though noone respects my opinion anymore, I think Parallax should strive to be a big competor in the process control and automation market, with the Propeller chip. Compared to the high cost of an equipment controller, I believe the Propeller is very reasonable in price. Some very good controllers could be built around the Propeller.
koehler,
Although the cogs are usually used one per functional block for I/O, that's not the way they have to be used. There are multi-serial port drivers (4 per cog). There's a combined SPI / I2C driver and a few others. There's some "work in progress" on general purpose multi-threading and other schemes to use the excess throughput available in a cog for multiple I/O functions.
You might ask "why is this functionality not more highly developed?" or "where was all this at the beginning?". It all comes back to the notion of the Propeller being a new concept for embedded microcontrollers and Parallax being a small company with limited resources. It takes time for this all to be developed, matured, and packaged for easy use.
Even though none respects my opinion anymore, I think Parallax should strive to be a big competitor in the process control and automation market, with the Propeller chip. Compared to the high cost of an equipment controller, I believe the Propeller is very reasonable in price. Some very good controllers could be built around the Propeller.
Bruce
'
Hello Bruce:
'
I respect your opinions and I agree with about the Propeller and PLC's (process logic controllers)
'
If Parallax would make the propeller bi-lingual it would really help it's sales $$$$
'
Ladder-Logic is the norm for Industry, I hate it my self but its what I have to work with.
'
Spin is killing the prop and PASM is to much to write.
'
(I could just be lazy and I don't like to type as much as you other guys do)
*Off the cuff here* (why should this post be any different?)
Sometimes I think the Propeller competes on a level too low. We've proved that many times it can do jobs performed by a small computer system. I could see the Propeller in place in industrial applications where an older PC has been doing the job. We have a local foundry which uses a lot of really old hardware to do many of the jobs because the initial investments are always extremely high (development costs, not hardware). The Propeller is suited to take these jobs, places where other micros couldn't begin to compete.
In most applications, an ARM can do everything the Propeller can. It is cheaper, faster, has on-chip debugging, and has lots more memory, besides being programmable in C without taking a performance hit. There are some things the Propeller can do that the ARM can't do, of course, but whether those are attractive outside the hobbyist market remains to be seen.
If it wasn't for the capabilities of the Propeller, my investment in my machinery would have been MUCH MORE significant. Just for the record, I am not a hobbiest.
$WMc%,
You or someone else could write a ladder-logic to Spin translator, sell it, and make oodles of money. If it's as large a potential market as you think, it could be a great investment. If you don't have the expertise to do it, you could hire someone who does.
Parallax is in the business of making subassemblies and (now) chips along with their educational market robots. They did sell an industrial controller, but it was still a Stamp inside and mostly they provided the interface circuitry. I don't know how well it sold, but they seem to be out of that business now.
I don't believe they are that big, and that does mean multiple displays, or multiple uses for them. Sound could be done, for example. Finally, one of the core design principles of the Propeller is symmetry. A cog is just a cog, which means they all need counters, and they all need the generator.
I think your comments are very well formulated, but I would like to offer up a common - almost universal- misconception. By introducing a small (60 instruction) assembler based Sheduler Kernel into a Cog, one can now very easily have that Cog run multiple Soft Peripherals concurrently and independently, In other words, the UART, I2C, DAC/ADC (plus more if desired) do not each need their own Cog, leaving yet 7 more Cogs to do with as one wishes.
Most folks appear to be unaware or uninterested in that capability, and I suspect it is because the implementation of this concept is geared to an "assembler only" implementation, and that approach is certainly not the flavor of the day. For the person who is trying to squeeze a lot of performance out of a Prop and is willing to put in the effort, a staggering amount of functionality can be effected by a single Cog, let alone 8 of them.
For me, the prop is great, but like Cluso, I wish that a bit more thought had gone into the video section and made its high speed shift register a bit more general purpose, such as allowing shift-ins.
Perhaps if an "engine" object were created that used the Scheduler Kernel concept and incorporated the common, or a configurable, selection of proven (Gold ?) Soft Peripherals, then the Prop might find a wider audience as they would then be able to drastically increase its functionality while not (neccesarily) giving up their favorite high level programming language.
The ability to do mult-threading in a single Cog does not jump out at you when reading the Prop specifications, and perhaps Parallax should address that capabitity more specifically.
That looks and sounds like some very impressive work! However, I see it is pretty much all written in assembly. Can multi-threading within one cog be accomplished in Spin?
Spin is killing the Prop and PASM is to much to write.
This may be true if the only language a person knows (or is willing to learn) is C. But to me, Spin is the glue language that makes rapid application development possible. It's easy and quick to write, with a minimum of syntactical gingerbread, and it is high-enough-level to express complex algorithms efficiently.
As to PASM, it's faithful to the underlying architecture, which is elegant and regular. The Prop is one of the easiest micros to program at this level of any I've experienced.
My main quibble with Spin and PASM (which I've stated elsewhere ad nauseum) is the lack of professional-level programming features, such as macros, conditional compiling, etc. These missing features represent the "big boy pants" that the Prop's dev tools have to grow into before it will be taken seriously in the commercial/industrial arena.
I personally love SPIN. It's lean, clean, and not very difficult. The many little short cut operators can get a bit cryptic though. Minor nit at best.
Agreed on conditionals, that's kind of the bare minimum. I understand how macros would benefit, but I personally like the fact that they are not currently a part of SPIN. Parsing code written by others is lean too, and that adds to the utility of the objects to date. On the next rev, where Prop goes up in scale, both are necessary though. Bring it on! Agreed, but I'm enjoying the simple nature of it right now.
That looks and sounds like some very impressive work! However, I see it is pretty much all written in assembly. Can multi-threading within one cog be accomplished in Spin?
Bruce
I don't know SPIN, but I suspect not with the Scheduler I have created.
I fear that Spin's high-level implemented loops and delays will make the interaction with an assembler Cog very complicated and not workable. Remember that assembler and Spin must reside in different Cogs by design. Perhaps if someone created a Spin based multi-tasker, but then in Spin the performance would be utrocious and not usable for any reasonable speed peripherals.
But perhaps an assembler Kernel combined with a (re)loadable complement of "standard" peripherals that can be instanced in the assembler Cog at run time could be of significant benefit. I have done some successful preliminary work on that, and should really give it a bunch more attention.
P.S. the reference Leon posted was for an early version, which has been superceded my a much more capable, faster, finer-grained, albeit somewhat larger --60 longs vs 25 longs -- Beta version.
Multithreading in a single cog in Spin may reflect a misunderstanding of what Spin is and how it works.
Spin is compiled into byte codes, a "machine language" for a stack-based virtual CPU designed around a 64K memory space. This virtual CPU is emulated by a program written in the Propeller's instruction set, stored in the Propeller's ROM, and loaded into cogs for execution. This emulator occupies essentially all of any cog used to execute it.
The Spin interpreter is designed to allow efficient access from the Spin language to essentially all of the features of the Propeller's hardware except the cogs themselves (since these are fully occupied by the interpreter). As is usual with interpreters, the Spin byte codes are executed at about 1/20th the speed of the equivalent machine instructions. On the other hand, Spin programs occupy much less memory than the equivalent machine instructions and the byte codes are much more powerful in what they do. For example, there's no hardware multiplication or division, there's nothing like an index register, but Spin has a wide variety of arithmetic operations as primitives and has single dimensional arrays and some simple string / byte array operations.
When programming in everyday Spin there is no way to do multi-threading. I'm sure Mike explanation shows why.
However we have come to learn that nothing is impossible on the Prop:)
I suspect one could put together some very hacky code that would do some self-modification to the byte codes as it runs that would implement a context switch and make it possible to perform cooperative multi tasking. In principal doable but I'm sure it would be ugly and slow.
Alternatively there seem to be a few alternative Spin interpreters around. Look for "big Spin" for example. One could modify such an interpreter to provide a contect switch mechanism. Again messy and slow.
Mike,
Spin as 1/20the the speed of PASM seems a little optimistic.
I've no idea what the normally expected ratio between Spin and PASM speed is when performing the same task but my Fast Fourier Transform exists in Spin and in PASM. The former being the model for the latter. So same functionality done in the same way. The PASM code is nearly 80 times faster!
Yeah, the 1/20th speed is optimistic, probably idealistic based on simple operations. On the other hand, 80 times faster is unfair as well. I'm sure the PASM version is pretty well optimized for the architecture ... it's not hard to do for the Propeller's instruction set with an algorithm like FFT. I doubt you did much if any optimization of the Spin code with attention to actual execution speed of the compiled code.
My main quibble with Spin and PASM ... is the lack of professional-level programming features,
I might be inclined to agree with you. However that statements leads to a paradox in my mind:
0) Spin is elegant, uncluttered, easy to learn, simple to use.
1) Our "professional" programmer wants all the grown up features of languages like C
2) Said professional programmer does not want take time out to learn Spin.(especially since it lack those features anyway)
Adding a lot of professional features to Spin has the following effect:
0) Blows it's ease of use and makes the learning effort greater for beginners/casual programmers
1) Well , now it looks like C so "why not just give me C?" says the professional programmer.
2) Said professional programmer has an even bigger reason to not take time out and learn Spin having made it as hard as C why not have C?
Conclusion, whilst adding a bunch of "professional" grade features to Spin may appeal to you and me it complicates things for the casual programmer and offers nothing to the professional.
Comments
Though I am hoping that Chip has some surprises up his sleeve for us that will help with this issue of high bandwidth Prop- to-Prop and Prop-to-other CPU communications.
-Phil
Phil & heater: I have already asked for the hub access to be granted to 1 cog if the others were not utilising it. Similar for giving 1 cog priority, such as every 2nd access and the other cogs getting 1 in 16, etc. I don't think any of those options were treated seriously.
As for you hub ram access, from what I gather about the info published, I would be extremely surprised if the mechanisms to fire counters and pulses etc cannot be used in many other ways, including helping what you propose. We discovered that the vga counters can only clock out and it would have beeb good to be able clock in. I dare say anything that goes 1 way is likely to go the other. There seems to be an aweful lot of silicon in there for the new counter logic. I cannot wait to find out what Chips thinks it can do and what we all will end up making it do. The only sure thing I can say with confidence, we are ALL going to be really and pleasantly surprised!!!
Most microcontrollers these days do not have data/address busses. We are attempting to get one in the prop because we are using the prop in ways not intended (which BTW doesn't make us wrong). Therefore, we are stuck with only 32 I/Os. I bet we would be complaining about not enough cogs today if we had the 64 I/O Prop 1B - or maybe more cogs and 80 I/Os so we could do 32bit SRAM/DRAM access.! There is still a lot of steam left in this Prop 1 and the tools are getting better all the time. Where a prop cannot cut the ice for the main processor, use another processor such as the arm or avr together with the prop(s).
True.
Exactly.
That's why I daydream about a Prop with a bus driven by an external CPU. The Prop becomes a super intelligent 8055 PIO chip if you like. With a much higher bandwidth connection to the "main" CPU. Ah well.
1. Parallax has an established reputation as an educational/enthusiast niche. Attempting to move from that persona to a commercial one is going to be difficult to say the least.
As has been mentioned, most professionals who've previously heard of Parallax will know them primarily from the Basic Stamp products. Perhaps some will know of the Propeller, however the Stamp will have set expectations that will somehow need to be placed into context as the 'old' Parallax. Parallax is, or should in my view be focused on transcending that history and showing that it is now the equal of, and exceeds in many cases the current 'standard' of the industry. Much more could be said, however as long as memory or a quick google of Parallax comes up with Basic Stamp, or the Hydra, I think it will be difficult for the average professional to give Parallax the time of day. I think this is where you need a real Business Development expert to give insight.
2. The Propeller is quite possibly too advanced, on too many fronts.
Stop and imagine if Atmel or Microchip were to announce an 8-core uC today. While there would be much screaming and cheering, I honestly thing the folks on AVR freaks and Microchips forums would be somewhat stunned. I'm sure someone would be able to come up with applications, however the sheer magnitude of having 8 cores would be welcomed for the power, and inspire at least some trepidation at the unknown interprocess communications required to make it all work.
Now, take just those 2 issues and throw in non-industry standard interrupt-less operations, lack of an industry respected C language (sorry, telling someone that there are 3 possible versions of C available is possibly more trepidatious than not), requirement of either a new langage Spin, or dropping to PASM, and lastly no 'real' peripherals.
I find the ability to have soft-peripherals unique, possibly brilliant. And suspect that many professionals consider it to be too unique, outside their comfort level (Left-brained likely), and simply un-proven.
Other honorable mentions are sole-supplier is a small company = risk, and considering all the above, and the learning curve required, not exactly enough positives to check off on a benefit analysis. And lets not forget that for someone to seriously push adoption of this new, unknown technology, a smart person would likely look at potential risk to themselves, their career/standing at their company.
For the average professional looking at the Prop on the website, I agree with another poster that it is very murky figuring out what the Prop really is. While microcontroller is mentioned, I just tried to re-read the areas I think a new site visitor would scan, and the Prop really seems to come across as more of a cpu than a controller.
I think there was a definite desire to highlight the Prop's power as more comparable to a cpu than a controller. And that may have been good at the time. However, there is very little detail on anything that an engineer interested in a controller might want to see, until one starts digging further in. And I'm pretty convinced in my mind that engineers are like most other people, if I can't find detailed information relatively quickly I'll move on to something else.
I also have to add that not stating right up front the specifics of how peripherals are done, with a list of the expected hardware one normally finds on a uC that can be implemented on the Prop is a big FAIL.
A pro coming to the site to look at the Prop is going to want to know several key things: speed, power, and peripherals. Speed and power are easily found, peripherals, hmm.
Once you start digging deeper, you find out that there is no UART, no I2C or SPI, no ADC....
But, you can add on. But there goes one of your cores. So, you need a UART, thats one core. You want I2C or SPI? OK, scratch another core. I know this is true for at least one engineer, a friend who humored me when I was talking up the Prop to him last year.
I think his final comment was along the lines of, "OK, once I've gotten this Prop to a state of usefulness with the minimum of peripherals I expect any uC to have, I'm down to 2-3 "Cores", and I still need another component for ADC. For me to even start to do anything useful with this chip, I have to expend at least 50% or more just to get basic resources, and an EEPROM, ADC, and who knows what else. Too much additional work, additional BOM when they could have added them to the uC and then left me with maybe 4 cores."
In the end, his opinion was that this felt sort of like a bait and switch. I know I'll probably get heat for this, but this is from a real engineer, with 15+ years in wireless/rf design, and generally open to new stuff.
So, this is a sample of (1), and thus not statistically valid. But that doesn't mean that it is automatically incorrect. I think the single best thing Parallax could do if they are serious about getting into the commercial arena, would be to make an investment in some product/customer focus reviews. I forget the actual term, however I've been on several years ago when the remuneration was worth the time/hassle.
I think many of these 'reasons' mentioned above are part and parcel for anyone trying to break into a market, and only more important and potentially killers when you have a product that is so radically different than the current status quo.
Like all of us, I expect the Professional Engineer has deadlines, is overworked, and wants to focus on getting stuff down, his task list checked off to allow for the new ones constantly coming in. Expecting him/her to willingly jump on the Prop wagon and drop interrupt programming which he/she has become comfy with, AND get in the groove of using soft peripherals, etc, etc at the same time is doubtful. Unless it can be proven to him that the solution can be designed faster, cheaper, made more reliable, or even just get him out of the office earlier to get home.
I've got the flame retard-ant suit on, just be aware that I like the Prop, and my comments are rooted in what I consider common sense, and 15 years in the IT field where I've seen lot of critical hardware reviewed in-house. I've seen fantastic hardware loose out to more mediocre simply based upon tools availability or being too far outside the mainstream. I'm not hatin' on the Prop.
Just a minute while I re-load my elephant gun
"Trepidatious"! Nice word! Precisely describes the uncomfortable feeling any professional engineer thinking about adopting the Prop would experience upon discovering that there is no C compiler supported by Parallax.
The interrupt thing I'm not so worried about - I beleive this can be made a positive selling point for Parallax - "You need to use interrupts to achieve that? how quaint!".
The remainder of your points I agree with wholeheartedly. Parallax urgently needs to implement the "gold standard" OBEX (or whatever they are contemplating), containing PASM implementations of the various commonly required peripherals, in a form that can easily be used from SPIN, C, BASIC or any other language.
Ross.
I would say that supporting GNU in someway such that Propeller could be added as an officially supported target would be a good step forward, or one of the other 'main' industry standard vendors perhaps? Not that I don't find the 100(?) languages currently available in the forum interesting, but not sure that would necessarily reassure a professional.
I would argue that incorporating some of the basic features/peripherals would be a sound investment bridge worth the silicon expense in the attempt to re-brand the Prop in a more commercial vein. How many gates would it detract from the Prop II to actually put in a UART ADC/DAC, I2C, etc? The problem is that on the one hand Parallax is trying to 'sell' the Prop as an 8 core controller to an engineer. But as soon as he looks at needing basic comms with a UART, he realizes he's now down to 7. Adding another feature, and down to 6, 5, etc.
So in reality, you don't actually have 8 cores but 8 programmable feature blocks.
If you happen to only need several, then you have 4-5 potential threads with now possibly n-fewer GPIO depending upon what you used the several cores for.
I don't know how much silicon space is required for the duplication of a video generator for each core, but it seems like an idea that overshot the mark a bit. I would think some of that space could be repurposed for something that will be actually useful for the other 99% of potential applications.
I would hope for some measure of success in the Prop II commercialization push. It just seems as though some of the design decisions made when this was a a blue-sky, "let's go for it" type of project at the outset are real handicaps to adoption today and even more so in the future.
However, the main obstacle to its wider adoption is simply the price - it's far too expensive. It can't possibly compete on price with PICs, AVRs and ARMs, except in a few niche markets, and no one has yet determined what they are. Perhaps Parallax has some ideas and they will be mentioned on the Parallax Semiconductor web site, when it materialises. They do seem to be taking an inordinate amount of time getting the new venture off the ground!
Bruce
Although the cogs are usually used one per functional block for I/O, that's not the way they have to be used. There are multi-serial port drivers (4 per cog). There's a combined SPI / I2C driver and a few others. There's some "work in progress" on general purpose multi-threading and other schemes to use the excess throughput available in a cog for multiple I/O functions.
You might ask "why is this functionality not more highly developed?" or "where was all this at the beginning?". It all comes back to the notion of the Propeller being a new concept for embedded microcontrollers and Parallax being a small company with limited resources. It takes time for this all to be developed, matured, and packaged for easy use.
Hello Bruce:
'
I respect your opinions and I agree with about the Propeller and PLC's (process logic controllers)
'
If Parallax would make the propeller bi-lingual it would really help it's sales $$$$
'
Ladder-Logic is the norm for Industry, I hate it my self but its what I have to work with.
'
Spin is killing the prop and PASM is to much to write.
'
(I could just be lazy and I don't like to type as much as you other guys do)
Sometimes I think the Propeller competes on a level too low. We've proved that many times it can do jobs performed by a small computer system. I could see the Propeller in place in industrial applications where an older PC has been doing the job. We have a local foundry which uses a lot of really old hardware to do many of the jobs because the initial investments are always extremely high (development costs, not hardware). The Propeller is suited to take these jobs, places where other micros couldn't begin to compete.
OBC
Bruce
You or someone else could write a ladder-logic to Spin translator, sell it, and make oodles of money. If it's as large a potential market as you think, it could be a great investment. If you don't have the expertise to do it, you could hire someone who does.
Parallax is in the business of making subassemblies and (now) chips along with their educational market robots. They did sell an industrial controller, but it was still a Stamp inside and mostly they provided the interface circuitry. I don't know how well it sold, but they seem to be out of that business now.
I don't believe they are that big, and that does mean multiple displays, or multiple uses for them. Sound could be done, for example. Finally, one of the core design principles of the Propeller is symmetry. A cog is just a cog, which means they all need counters, and they all need the generator.
I think your comments are very well formulated, but I would like to offer up a common - almost universal- misconception. By introducing a small (60 instruction) assembler based Sheduler Kernel into a Cog, one can now very easily have that Cog run multiple Soft Peripherals concurrently and independently, In other words, the UART, I2C, DAC/ADC (plus more if desired) do not each need their own Cog, leaving yet 7 more Cogs to do with as one wishes.
Most folks appear to be unaware or uninterested in that capability, and I suspect it is because the implementation of this concept is geared to an "assembler only" implementation, and that approach is certainly not the flavor of the day. For the person who is trying to squeeze a lot of performance out of a Prop and is willing to put in the effort, a staggering amount of functionality can be effected by a single Cog, let alone 8 of them.
For me, the prop is great, but like Cluso, I wish that a bit more thought had gone into the video section and made its high speed shift register a bit more general purpose, such as allowing shift-ins.
Perhaps if an "engine" object were created that used the Scheduler Kernel concept and incorporated the common, or a configurable, selection of proven (Gold ?) Soft Peripherals, then the Prop might find a wider audience as they would then be able to drastically increase its functionality while not (neccesarily) giving up their favorite high level programming language.
The ability to do mult-threading in a single Cog does not jump out at you when reading the Prop specifications, and perhaps Parallax should address that capabitity more specifically.
Anyhow, my two bits' worth.
Cheers,
Peter (pjv)
I barely understood a word of that Peter, however you really caught my interest with the following comment:
If you started a thread on this subject, that would be a wonderful thing for many people.
Bruce
http://www.parallax.com/PropRTOS/tabid/852/Default.aspx
That looks and sounds like some very impressive work! However, I see it is pretty much all written in assembly. Can multi-threading within one cog be accomplished in Spin?
Bruce
As to PASM, it's faithful to the underlying architecture, which is elegant and regular. The Prop is one of the easiest micros to program at this level of any I've experienced.
My main quibble with Spin and PASM (which I've stated elsewhere ad nauseum) is the lack of professional-level programming features, such as macros, conditional compiling, etc. These missing features represent the "big boy pants" that the Prop's dev tools have to grow into before it will be taken seriously in the commercial/industrial arena.
-Phil
Agreed on conditionals, that's kind of the bare minimum. I understand how macros would benefit, but I personally like the fact that they are not currently a part of SPIN. Parsing code written by others is lean too, and that adds to the utility of the objects to date. On the next rev, where Prop goes up in scale, both are necessary though. Bring it on! Agreed, but I'm enjoying the simple nature of it right now.
I don't know SPIN, but I suspect not with the Scheduler I have created.
I fear that Spin's high-level implemented loops and delays will make the interaction with an assembler Cog very complicated and not workable. Remember that assembler and Spin must reside in different Cogs by design. Perhaps if someone created a Spin based multi-tasker, but then in Spin the performance would be utrocious and not usable for any reasonable speed peripherals.
But perhaps an assembler Kernel combined with a (re)loadable complement of "standard" peripherals that can be instanced in the assembler Cog at run time could be of significant benefit. I have done some successful preliminary work on that, and should really give it a bunch more attention.
P.S. the reference Leon posted was for an early version, which has been superceded my a much more capable, faster, finer-grained, albeit somewhat larger --60 longs vs 25 longs -- Beta version.
Cheers,
Peter (pjv)
Spin is compiled into byte codes, a "machine language" for a stack-based virtual CPU designed around a 64K memory space. This virtual CPU is emulated by a program written in the Propeller's instruction set, stored in the Propeller's ROM, and loaded into cogs for execution. This emulator occupies essentially all of any cog used to execute it.
The Spin interpreter is designed to allow efficient access from the Spin language to essentially all of the features of the Propeller's hardware except the cogs themselves (since these are fully occupied by the interpreter). As is usual with interpreters, the Spin byte codes are executed at about 1/20th the speed of the equivalent machine instructions. On the other hand, Spin programs occupy much less memory than the equivalent machine instructions and the byte codes are much more powerful in what they do. For example, there's no hardware multiplication or division, there's nothing like an index register, but Spin has a wide variety of arithmetic operations as primitives and has single dimensional arrays and some simple string / byte array operations.
When programming in everyday Spin there is no way to do multi-threading. I'm sure Mike explanation shows why.
However we have come to learn that nothing is impossible on the Prop:)
I suspect one could put together some very hacky code that would do some self-modification to the byte codes as it runs that would implement a context switch and make it possible to perform cooperative multi tasking. In principal doable but I'm sure it would be ugly and slow.
Alternatively there seem to be a few alternative Spin interpreters around. Look for "big Spin" for example. One could modify such an interpreter to provide a contect switch mechanism. Again messy and slow.
Mike,
Spin as 1/20the the speed of PASM seems a little optimistic.
I've no idea what the normally expected ratio between Spin and PASM speed is when performing the same task but my Fast Fourier Transform exists in Spin and in PASM. The former being the model for the latter. So same functionality done in the same way. The PASM code is nearly 80 times faster!
I might be inclined to agree with you. However that statements leads to a paradox in my mind:
0) Spin is elegant, uncluttered, easy to learn, simple to use.
1) Our "professional" programmer wants all the grown up features of languages like C
2) Said professional programmer does not want take time out to learn Spin.(especially since it lack those features anyway)
Adding a lot of professional features to Spin has the following effect:
0) Blows it's ease of use and makes the learning effort greater for beginners/casual programmers
1) Well , now it looks like C so "why not just give me C?" says the professional programmer.
2) Said professional programmer has an even bigger reason to not take time out and learn Spin having made it as hard as C why not have C?
Conclusion, whilst adding a bunch of "professional" grade features to Spin may appeal to you and me it complicates things for the casual programmer and offers nothing to the professional.