Your opinion about Propeller's future
damagedcells
Posts: 12
Just an idle thought here:
I am a complete newbie when it comes to the prop (i'm still waiting for my 1st board to arrive); but in my research it is obvious that the prop is unique.
I was wondering what thoughts people have concerning the propeller chip's future in industrial and commercial applications.
I am a complete newbie when it comes to the prop (i'm still waiting for my 1st board to arrive); but in my research it is obvious that the prop is unique.
I was wondering what thoughts people have concerning the propeller chip's future in industrial and commercial applications.
Comments
However, when upper management (where fear reigns over logic) interferes with the design process, the Prop's uniqueness can be a hurdle that requires a strong sales pitch to overcome. But I know that Parallax is up to that task and that we will see even more effort along those lines in the months to come.
-Phil
1) Ken has mentioned Parallax Semiconductor. Parallax is putting together a team of experts to specifically get the Propeller into commercial markets, providing more than simply sales, but also assistance with product design as well. I'm sure we'll see this move forward in the coming months. The Propeller looks good in a suit and tie.
2) Parallax has committed (publicly) not to forget it's roots in hobby and education. The Propeller has historically done well with us "eggheads" who have flexed our minds around it's unique multi-core design. A push is already on both in Parallax and committed players to drive the barriers of entry even lower, making the chip attractive to artists, and hobbyists of all kinds and experience with better documentation and access to high-level objects. The Propeller looks great in jeans and a t-shirt.
The Propeller's outlook looks pretty good from here..
OBC
But this is about Propeller.
I am not sure Parallax will appreciate critical evaluation of their hardware on their site. But here it goes.
1. The Propeller multitasking architecture, similar to SX, must be a challenge to program and keep error free.
2. The proprietary SPIN „language“ dictated by the architecture could be a major obstacle to a person who used Basic Stamp Basic. (It's sometime called “repeat business”)
3. „Advertizing“ assembly language ability in 2011 is ignoring the commonalty of high level languages we have today. Does that mean that SPIN is not efficient? I hope not.
4. On chip memory is insufficient for today's graphic heavy applications. And I would love to see how someone implemented “video” capability of Propeller.
(Moot point , since Murphy points out that any program will be too big for available memory anyway)
5. Unless I missed it – there are no specialized hardware I/O (USB, I2C, SPI, etc), only universal I/O pins.
As I said, I judge only by what I can gather from Parallax documentation and from forum discussions. As any processor it really depends on what is the application. However, from what I said about the Propeller, I think it is a time for a new Parallax hardware. And I would include the aging and as some will say expensive (in comparison with other processors ) Basic Stamp..
'
SPIN a new code; Not good
'
SPIN a slow code; Not good
'
Why look at the Propeller over other chips that use a familiar code.
'
Not everyone has weeks or months to make something happen
'
'
EDIT by WMc
'
I'm NOT being negative toward the propeller at all. I was referring to the mind set in Industry.
Sorry I didn't say this to start with.
'
I hope all is well.
Good Point!
However, I truly believe there is a lot going on behind the scenes at Parallax that we are unaware of. We might all be pleasantly surprised in the near future. I sure hope so. If not, I will stand behind the Propeller anyway, because I will have this Spin programming down pretty good here in the future and it is a nice chip.
Bruce
I don't think Parallax minds criticism as long as it is constructive and reasonable. But I think you need to do more reading about the Propeller. To respond to some of your points:
Ross.
Didn't make Parallax look like a serious player at all. Then Parallax avoided the conferences such as ESC.
Personally I think to the biggest impediment to the Prop II being adopted by embeddedl world is SPIN, It's a nice language for hobbyists but considering the nasty performance hit you take ought to not be emphasized if they want to market to anyone but them. C needs to emphasized for pros.
And get GNU C working for the Prop II and not via emulating another architecture either. That is not a selling point. It's saying to the customer the architecture is deficient and a software workaround had to be found for C to be viable.
And why are macros needed for 512 instructions in the COG? With out understanding how C actually would work, SPIN + PASM makes perfect sense, and is not difficult to develop on. The release tools could have used conditionals and such for SPIN, but the PASM programs being small really didn't warrant much beyond what was supplied, IMHO.
Seems to me, discovery of the LMM way of executing code opened the door for that. Prop II will have changes designed to streamline that, and when those happen, C will operate much better, and macros will make sense too. And SPIN can always be used, and frankly used concurrently, with C, if somebody wants to. That's all down to the concurrency and multi-processing nature of the chip. I think that's pretty tough to do on a shared memory device. The prop has a shared data memory, and completely separate execute memories. That's a big difference from a lot of what is out there.
The model will then be a kernel / supervisor set of code, that could be equated to microcode, in that it runs directly in the CPU memory space. "Assembly language programs" then are executed under that supervisor, with the option of firing up a intrepeter for SPIN, where it's useful to do so. The "flexible silicon" then becomes a compliment to a C program, not the direct focus of it, as those parts of the program can be built however people want to build them, packaged, and binary loaded. We've learned now how that all tends to work, and I think going that direction will significantly improve what languages other than SPIN+PASM will look like.
BTW: The existing tools can build those driver components nicely. Once the binary product is developed, just fetch it, stuff it into the COG, and suddenly, you've got a "device" that is seen like hardware is. I personally find that compelling over time, and particularly as the chip design scales upwards with Prop II.
We've also got what is essentially "execute in place", where that same supervisor / kernel / microcode like thing, can fetch program data from either the fast shared HUB, or some external device.
There are lots of trade-offs possible there, and that's a good thing now, not well understood when the chip was released, and again, at that time it was, and remains, new in some ways that are not matched by other devices out there. That takes time to develop for, building up the enabling tools that then bring rather ordinary tools to bear on the chip.
Look at the Cell, or advanced graphics hardware for the PC. The very same things had to happen on those so that "the pro" wanting to "just use C" had the interfaces needed to make that happen. We didn't even grok LMM until Bill thought it through. Without that, there is no C to be had at release time. Again, I don't know if that's deficient, just really new.
Edit: Some pretty darn sharp people have put their brains on the design, and we are seeing some really great things now. Would Parallax have been able to make that investment before release? Not sure they would have, given some of the innovations were not seen for quite some time after release. That's just a artifact of being new, not some deficiency, IMHO. Just thought I would put that detail out there, often forgotten.
Re: Future.
I suspect Prop II will settle in to some niches that play well to it's strengths, both chips will see some smaller scale or niche industry work, and will continue to enjoy growing hobby type project success. As long as Parallax sees the sales it needs to continue doing business, and invest some in positioning and selling the chip, it will be available, and working in some niches very well, not even a consideration in others. There are a lot of niches, and ways to compete. Some of those will align well with the chip, and life will be good.
For the Hobby person, it's a great chip to learn. Powerful, and flexible, and Prop I is very friendly. Easy to use.
For the person who gets to select enabling tech, and is the source of solutions to problems, it's also a good chip to learn, for the same reasons.
For mainstream professionals, it's a niche device, and I think it's going to remain that way. IMHO, some specialized uses and specialists will probably benefit from the Prop II over time, building out some share that's needed to get the bigger sales moving.
Hey guys!
Bruce brought up some good points about documentation and a library of objects. I'd like to say that these two points are being addressed, though I am a bit nervous about giving myself more work to do
Rod1963 also brought up some really good points about C and the Propeller/Propeller II. I'm not too sure of the direction that will be taken with that (its not my area of expertise) but C is definitely on Parallax's brain.
One big problem is that engineers seem to look at block diagrams and so do not see any peripherals. That is the beauty of the prop - you code what you require and don't have to sift through families of chips to find one that has the correct mix of peripherals.
The next problem, is that engineers do not appreciate that interrupts are not required when using the prop. It is a hurdle that has to be overcome and the simplicity of it is completely missed because engineers inherrently look for hidden complexities, and there are none to do with the lack of interrupts.
High level languages such as C are used for the main program. By removing the timing complexity, often the slowdown by C or spin will not be noticed. Just because some of the cores (cogs) will use pasm is not a deterrent. In fact, these programs are so minimal that a good engineer should be able to cope very quickly, should he/she require to use pasm.
The only problem I see with spin is that the language does not use standard C like calls such as the vere easy to understand "void" statment or "switch" statement <grin>. I mean, here we are in 2011 and void and switch is used in preference to Pub, Pri and case - really is this a step forward - I think not! The other thing I see with spin is it's enforced indentation. This is great for beginners to implant this methodology but for those others it is a bit cumbersome. This is however, an easy fix, and there is nothing wrong with having a different parser for spin.
Coding the prop is extremely simple. There is not a massive bunch of registers (now often hundreds) to program just to get the chip to function. A half a dozen instructions can get a prop up and running. Try that on almost any other chip!
Now let me say, I am using the Prop in commercial projects. None are huge quantities, at least not now. However, I have no reason to doubt it's continued availability. In fact, I think there is more chance of a PIC, AVR or ARM based chip to disappear than the prop. You may say there will be another pic/avr/arm to replace it - while that is probably true, you will still have to do a redesign of the pcb and some code adjustments. It is far easier to see a single chip being around than a whole family.
The Prop II will address a lot of issues and of course is so much more powerful and has a lot (but still not enought!) memory. It will co-exist with the Prop I.
The biggest problem I see is that there is not enough publicity about the propeller. We can all help with that
For the record, I have been commercially programming and designing with micros since 1976 (the release of the Motorola MC6800) and my products have been sold world-wide, including under other names such as Apple.
The idea of a "Parallax Gold Standard" for objects in the OBEX is excellent. The Prop tool should come with all such objects ready to use and/or a clickety click way to download/update them from OBEX. Of course such automation should apply to all OBEX objects.
On thing I would like to see is that all such "Gold Standard" objects that are predominately PASM with a Spin wrapper be easily usable from other languages or operating systems without the need for any Spin.
1) It should be possible to extract the assembled PASM part into a binary blob using tools such as BSTC, ignoring any Spin code.
2) The resulting binary blob should be usable just by loading it to a COG with parameters via PAR and then interacting with it through an in-HUB "mailbox".
3) There should not be any sneaky "POKING" of config/setup values into the DAT section from Spin prior to starting the PASM in COG.
Restriction 3) is required as a language such as BASIC or C has no "linkage" to the locations in the PASM part like Spin does.
Lonesock's floating point object F32 is a good example of an object whose PASM part is usable from C or other language without any Spin wrapper.
With these rules in mind objects become easy to use with BASIC, Catalina, ZOg and whatever else comes along including any future C implementations from Parallax.
Durability seems to be very robust on the Prop 1. I have not been so kind to my chips and they have help their ground good. I don't know if that is communicated well enough in the datasheet.
Availability, there was a shortage last year but I suspect that if a company is planning on using the chip for a product, they would be in close contact with Parallax to manage the supply chain.
Price is probably the most critical attribute regarding industrial/commercial use and application. If a $1.50 Atmel micro can do the job, there is no need to even consider using a prop. The Prop has its advantages - multitasking and for those applications I suspect it is the best value out there. There are certainly some applications for multi-tasking, but there are many more applications that don't require it.
Time to market is a big factor with any new product development. The longer the development cycle, the greater the cost and the greater the likelyhood that someone else will get a similar product on the market first. Oddly enough this is a potential "big" problem for the Prop. The most common "Pro" language is some form of C. From my point of view, a profesional programmer should be able to program in more than just C and shouldn't consider the Prop difficult to program at all. The spin language is slow but easy to program whereas PASM is very fast but easy to learn (when compared to ASM on other micros).
So to respond to the OPs request for comment I think it will boil down to the application. There is nothing wrong at all using the Prop for any application be it industrial or commercial. If the requirements for the micro can justify the cost then it is a good chip for the application. Being that the Prop is a unique chip, with unique features, its application would be to fill unique requirements. So if you want to use a prop for your next commercial project and it fits within the budget, go for it.
Chris
XMOS is a similar company to Parallax in some ways, they are both about the same size (50 or so people) with products that have many similarities. However, their business models are very different, as are their marketing strategies. Unlike Parallax, which seems to have developed a hobbyist product that they are now attempting to market to commercial users, XMOS has always seen themselves primarily as a supplier to the commercial market. That doesn't necessarily mean they are only interested in large companies - someone there once said that they would rather supply 1,000 chips to 100 customers than 100,000 to one company. Compare the two web sites and see which company you would prefer working with if you were a designer developing a new product from scratch. Parallax needs to take a leaf out of XMOS's book and adopt a similar strategy, if they are to become a player in the industrial and commercial sector.
Some of the things they need to do are:
Donate free hardware to staff at universities on request.
Get frequent coverage in the trade journals.
Attend professional conferences and exhibitions.
Provide free samples.
Sell through a worldwide distributor like Digi-Key.
Provide professional tools and documentation.
Sort of true. Do you mean multi-tasking or parallel processing? Pretty much all embedded systems I have worked on used multi-tasking either as actual tasks defined in some operating system or just as interrupt handlers firing of at regular intervals or on demand.
If you were meaning "parallel processing" I think that is somewhat missing the point. The Prop is not actually designed as a high speed parallel processor.
Rather what all those parallel running COG gives you is the flexibility to have enormous choice in the combinations of peripherals you can use for any particular job. Because those peripherals are defined by the software loaded into COGs rather than actual silicon hardware it becomes possible to support all kinds of hardware configurations whilst only having to think about, purchase, stock a single device.
This I think is a great benefit when prototyping different embedded systems or manufacturing low quantities of many different products. One does not have to worry that that particular AVR or PIC with the features you need for a particular product is going go out of production and trigger a product redesign.
I am no expert in these matters, but from my research, I have found no other chip available like the Propeller. It is in a league all by itself. As with any product, you must evaluate the task at hand, the cost of the product, and the time it takes to implement the product to complete the desired task. For me, the key factor in choosing the Propeller over other microcontrollers was the fact that it had 8 individual cogs(multi-tasking capabilities) and 32 IO pins. This is actually very impressive when compared to the competitors.
When Prop II arrives, which should be soon, it will have a lot more IO pins (I have not read much about it yet). In addition to being able to multi-task, the number of available IO pins should be of the utmost importance to any developer. Running out of IO pins is a BAD thing!
Besides the problems that I previously mentioned, there needs to be good documentation and a good object for interconnecting Propeller devices. I truly believe this is also a key to the Propellers success. Because in my opinion, 10 Propeller chips that can communicate with each other is much better than 1 propeller with 32 IO pins. However, this is achieveable, as people are already doing this. But there definitely needs to be much better documentation pertaining to this subject. With 10 Propellers, each having 8 cogs and 32 IO pins, you sure can do an awful lot of multi-tasking with a lot of input/output, for a very low price.
I think the Propeller is here to stay for hobby, commercial, and industrial applications, however, they will have to provide inter-communication documentation. In my own personal opinion, this will be the ultimate key to the longevity and success of the Propeller. By doing so, I think they will attract and keep a lot more potential customers. And if they don't, perhaps they will lose this clientele that seek these possibilities. I futher believe daisy chaining possibilities should be mentioned in the datasheet to make the product more attractive.
Bruce
All good ideas. Only one nit-pick. Re: Digikey
A lot of peripheral blocks are available in the obex. It is true that some are better than others, so the "Gold" idea sounds great. Certainly we require they be, as far as possible, calling code agnostic (i.e. same object for C, basic, spin, etc). However, that said, most of the code for each object is a pasm cog.
It would be nice to understand the counters/video better (i.e. better documented) because I am sure we can use the video section & counters to make some better peripherals, if only we knew how it worked (the finer details). I know it is possible to use the VGA section to output a serial stream.
And sorry Bruce... It is easy to get props communicating, and even downloading code to the sub-ordinates. The hard part is to understand what you require and then put that into code. Some things you just have to do yourself. I have a stack of pcb designs that have been almost finished for quite some time. They are prop based and will plug into each other, just like RamBlade. Someone even has 55 props working together - see humanoido's list.
Price was mentioned. The prop is high price for some things, so certainly a cheaper avr or pic would do. However, with the prop, I only have 1 device on the shelf. I do not have to look at hundreds of pics or avrs to find a suitable one, then ensure that it is actually readily available, work out how to initialise all those peripherals. For example, we don't initialise a UART in the prop - we just give the FDX object the pin numbers and baud rate and invert/noninvert and we are done. It even has spin support routines to output strings, convert to hex, decimal, binary, AND the capability to simply extend this to do other more complex processing if required (e.g. edit a value of 1234567 into say $12,345.67 or 12-345-67 or anything else we desire). When we use the keyboard object, we don't worry about the protocol, nor the keypresses and releases - we just get the keycodes into the buffer, completely decoded for us - and we can change anything we want quite simply.
Companies often specialise in interfacing specific peripherals. So all that is required is for the programmer to build an intelligent peripheral once and then use it as an object. You may say that you can do this in other micros and C, but that is not what I am saying here - it is simpler and easier, and there are no interrupts to worry about. It is a completely different way of thinking and it is a hell of a lot easier once you overcome the mental block !!!
One way to get people like myself who have problems trying to make the jump from stamps to the prop would be to have some sort of pbasic emulator, and better documentation on how to make the transition.
I wouldn't mind taking a performance hit if could run my pbasic code with little no changes
Or emulating 2 or three stamps at the same time. At least I'd be programing my S2
I think that would be one way to get more people using the prop..
-dan
This won't be a problem for too much longer. Parallax will be selling
Propeller chips through a commercial arm, Parallax Semiconductor.
However, Parallax Semiconductor won't be a simple commercial sales
desk, but will include services geared toward commercial clients.
Other distribution sites like Digikey will also continue to offer the
Propeller as well.
OBC
Hmmmm..... I am also sorry. If I remember correctly, you have a vast amount of knowledge in serial communication from previous work experience. You should not assume that everyone has the same experience. Regardless of what I have been told, there is very little documentation that really demonstrates the hook up, the protocol, etc... Sure there are several objects that allow fast communication, but where is the documentation for hook-up, use, etc... Sure I know how to do it now, but only after in depth research and with the help of numerous people.
And like I said, it isn't even mentioned in the datasheet, and it is a key selling point.
As far as price goes, I think it is well worth the money spent, considering the possibilities it can give you. Sure it is not perfect for every situation and there may be cheaper solutions, but if you need the cogs and the IO pins, then it is well worth every penny. Of course that is just my opinion
Bruce
A lot of focus in the forums seems to be on how to make it act like a more general purpose microprocessor. While those exercises are no doubt intellectually appealing, they are unlikely to result in commercial use.
I have seen mention of pairing up a prop with a more general purpose processor where the prop provides I/O services and the other processor would run the larger application. This would be an example of where the prop would fit nicely.
C.W.
My 2 cents.
I think that all Parallax Products should be compatible on all OS's. Without much effort from the user, I think in the next 5 to 10 years there will be more and more people using other than Windows as their OS. Why create something that not everyone can use.
-Ron
Kind of a students perspective but, I really think it should be in every engineers toolbox for those that are not EE's or experts in this field. So much potential to be useful in past projects, if only ive known about the prop earlier. The 32bit math, super fast speed, and objects make the prop far to easy and worthwhile. Literally takes minutes not hours, and fills the void as daq's etc are expensive and not everything is programmable. If there was large integration in things like matlab/labview etc would be perfect.
Perhaps within industry the experts in micro's can have alternatives, and maybe not much room for the prop. For people that arent micro experts and are doing design/research/projects/prototyping etc i dont know if there is any replacement quiet as good where seemingly simple things would be worthwhile.
I agree !!
here is how I see it ..
when apple used PPC very few users used Windows on a mac .. It was not native .
now that apple is runing X86 It is no different form a dell or HP hardware "compatibility " wise ( price aside for now )
there is a drift from windows to other OSes .
so now Lots of users I know are doing multy boot with WIN or GNU/Linux and other fancy things . apple Is no longer "waste of time " to develop for ...
as for linux ..
Linux is a geeks dream . its super tinkerable and is free d so If I had a choice for a lab computer for work on bench to so electronics "stiuff" would use P4 with a XP box or a Tux box
why Casue you don't need a Win7 or a mac to do pBASIC or most other hobby stuff.
XP according to MS is old news and it glory days are over .
I LOVE the BS2 mac version . its clean and it Just works Every time I need it .
PeterD