Where are the prop jobs?
dbpage
Posts: 217
When I go to freelance websites such as odesk and freelancer, I see Arduino, PIC and Atmel jobs. I see no jobs for Parallax, Propeller, P8X32A. Same for Monster, Linkedin and Career Builder websites. Why is that? Am I looking in the wrong places?
Comments
Contract programming and what is used in industry runs in trends that lag what is really competitive. Here in Taiwan, I have talked to a lot of programmers in Taiwan industry and their usual reply is that they are using Visual Basic. I thought it was quite odd that Visual Basic is so popular in Taiwan industry, but it seems that Asia just can't keep up with translating all the leading edge alternatives.
Given that the Propeller, at a wild guess, accounts for 0.000000001% of the world wide market for micro-controllers the probability of seeing a job advertised that requires Propeller/Spin skills seems likely to be equally small.
http://www.microchip.com/pagehandler/en-us/family/8bit/
http://www.microchip.com/pagehandler/en-us/family/16bit/
They also cost a lot less.
I think everyone here will agree with you. The Propeller can be used more easily than many other devices for many tasks and indeed do things that they cannot, so how come it does not get selected more often?
Lets see:
1) The chip has amazing capabilities...
For sure it does. It seems that most of the world does not know, or does not care and gets by with something else for their applications.
2)...is reasonably priced...
I suspect not. Seems you can get 32 bit MCU for 10c or so now a days. In the world of consumer products every cent counts and a Propeller may just be too expensive.
I really don't know how to judge this. There is a vast range of MCUs on the market now from that 10c upwards. Where does the Prop fit in?
Personally I find Propellers quite expensive compared to the range of other offerings in the the catalog of my local electronics distributor. I still buy them though.
3)...open source hardware...
Not really. The Prop chip itself is as closed as any other comercial MCU. The Propeller boards that are available may well be open source but in that huge consumer market that does not matter at all.
4)...and software...
That is true now. I really do think this is where Parallax slipped up with the Propeller. At the time it was launched the only way to program a Propeller was with the Propeller Tool which is closed source and Windows only. At that time the Arduino was storming the world. In large part because of it's opensource tool chain, the compiler, the IDE, etc. Had the tools required to program the Propeller been open source from day one perhaps the Propeller would have gained some traction in that open source movement.
Of course even once you have a convincing demonstration, then you have to market it. If you could get Leon to buy it then you might get some PIC users' attention. There will always be someone who has an excuse or desire to minimalize the product though.
My own project for trying to demonstrate the power of propeller compared to some other device(s) is with the Audio Agent (it's still a baby though). What are others with ability and zeal doing?
Virtually all of the projects I've seen that show off the Prop's capabilities have been done in Spin/PASM. The only exception that comes to mind is the automatic parallelizing done by the C compiler for Heater's FFT program. I don't mind saying that that was impressive! Maybe more such examples will emerge as time goes on. Truth be known, the Prop's parallel processors are almost never used for parallel processing but, rather, as soft peripherals. Perhaps C will find its niche among Prop professionals by opening the door to true parallelism.
-Phil
I've only worked on one project for which the Propeller was an ideal solution, and the customer decided to use another processor for some reason and got someone else to develop it. I had all the various functions and interfaces working on a Proto board and they just needed integrating, assigning them to different cores, and the development of a PCB.
Maybe "just one project where it was ideal" is an imagination opportunity issue?
Seriously, I think that the opportunities for propeller is where most MCUs fail. That is, when other MCUs don't have enough timers, or there is not enough instruction execution overhead when there are enough timers. The other place where most MCUs fail is in inventory requirement. That is, you don't need to keep 5 specialized copies of propeller chips to replace those 5 specialized copies of AVR, PIC, or other MCUs. If you only need 3 of each of those 5 specialized MCUs, that's easy, but what happens when you need 3000 each of 5 parts having specializations?
Btw, how many MCUs are available with up to 14 each 3 wire UARTS in one chip? Have you ever seen how ARM and other devices with one or two I2C ports get connected to more I2C devices? They have to use 3 I2C multiplexers in a tree to do more than 8 I2C connections. By contrast the propeller chip can do 15 I2C bus connections with one chip. Odd cases? No, I2C for example is the control plane bus of choice for huge network switch ports ... lots of ports.
Some people mention documentation as an issue. That's a loaded subject. The propeller datasheet has just about all the information you ever need for the hardware, and it is very small (less to remember and easy to find data). Other MCU datasheets are usually so bloated that one needs to be a specialist in one part for months on end to be effective.
Unfortunately SPIN/PASM by itself will not sell propeller chips unless every possible customer is their own boss. It might be nice to think that is possible, but it ain't gonna happen. And since the world hasn't caught that Spinny feeling yet after 8 years, one might consider the other possibilities for evangelizing the propeller story.
They don't care what's in the box, just that the box delivers. JonnyMac has been doing well with his products based on the BS1, BS2 and Propeller.
The great resource of the OBEX has made my time to market incredibly short.
Base on your fountain project. it's looks like you might be leaning to the industrial type field? The Propeller is great for that.
Identify a market and create a product to fill a need in that market. The trick is to come up with products that customers need and will want to pay you for.
Be open with your customers. If you're doing hardware / software development for a specific customer tell them what you're doing and how you're doing it. They don't really care about the cool ADC driver code you wrote in PASM but they do appreciate the fact that you're not hiding anything from them. That way they'll be confident that their product will be truly theirs when it's delivered. Delivery includes all hardware design information and source code. The idea being that they wouldn't be required to come back to me if they wanted modifications later. The product wouldn't truly be theirs if they had to come to me every time they wanted changes. If they do come back, I'm betting they will, then that's a bonus
Parallax identified a market, created excellent products and have been very open with their customers. A fine example to follow. It's why most of us are here.
Sandy
-Phil
I imagine that's true, however that is one of the biggest factors that drew me to the Propeller, as well as the 32 IO pins. In addition to that, as you mentioned, SPIN seemed to be an easy language for fast development.
And oddly enough, those are still the very same reasons that I have stuck with and will continue to stick with the Propeller. However, I am really looking forward to more IO pins, without having to think about expansion.
Interupt-less programming is not for everyone. Unless one needs and understands determininstic execution, the prop would not appear to have many advantages. I think thats the biggie.
Of course I totally agree with your statements about the Props ease of use. The whole package from the PropTool to the Spin and PASM languages to the Prop architecture, to the byte code interpreter, to the loader, is an amazing symbiosis of parts working together in harmony and simplicity. A masterful design unlike anything you will find in the rest of MCU land.
Thanks for the kind words about my FFT efforts. However mentioning that does highlight a problem the Propeller faces...
If a designer actually needs an FFT in in his MCU application the FFT on the Propeller is very slow compared to many other MCU's. Even if you employ multiple COGS to parallelize the work it does not perform anything like as well a, well for example, an STM32. In terms of doing this kind of thing the Propeller does not compete at all. That STM32 will be far cheaper, perform better and generally has enough grunt and peripherals that one would not look at a Propeller.
In short, such parallel processing tricks may get you out of a bind if you are using a Prop already and just need a little bit more oomph. But it does not help performance in any meaningfull way, in general other devices will perform better and be the first choice if you need that level of performance.
The parallel processing on the Propeller is better suited to those soft peripherals where you can mix and match all kind of interfaces into the one chip and create custom interfaces that other device don't have available in hardware and can't do in software because it sucks all the performance of their single CPU.
That demo of a Prop driving 32 PWM servos is an extreme example of where the Prop can shine. Try doing that on an STM32!
I very strongly disagree. In pretty much every non-trivial embedded system application there is a need to do more than one thing at a time.
So what happens? You can write some code that does thing A. You can write some code that does thing B. Now you have to put them together in your application. But how?
Well you can write a top level code that calls on A and then calls on B and do that in a loop. That's fine but if A or B contain an endless or long running loop already they are going to hog the show and hold up the other guy. Fail.
So now you have to rewrite A and B to not do that. Perhaps introducing a state machine structure that ticks around every time the entry point is called. This complicates your nice code.
Or you can write A and B in some kind of event driven style so that your top level calls the appropriate entry points of A and B as different conditions arise. This is a total restructure of your design and requires a more complex top level.
Or you can introduce a real-time operating system scheduler into your system and run A and B as threads. This is nice because it requires almost no change to A and B but such a scheduler takes up space and has a performance hit of it's own.
Or you can...don't get me started on interrupts...
Or you can just, you know, run your code. A and B on different cores. Job done.
Better yet, when you come to add more functionality, say C, you can just run that as well with total confidence is does not effect the running of the original A and B in anyway.
Having multiple cores and not needing interrupts simplifies things no end.
And note, I have not said anything about deterministic timing here.
It certainly seems wrong in many ways. But when you are a small business without the means to go public to create a huge pile of capital to expand market share..... the buzz and publications produced by deep pockets can delay the obvious.
Over time, the Propeller may just prove its worth regardless, but it doesn't happen quickly.
When the Prop was released there was no C compiler, no debugger. Just a proprietary interpreter for a odd ball language and a assembler. Right off the bat that told industry look somewhere else. Look, they'd wonder why there wasn't the typical C tool set that every other 32 bit micro had. That's not a marketing enhancement but the equivalent of putting a warning sign on your product.
Worse, use SPIN and take very big and nasty performance hit. If you need computational power you had to use PASM.
By the time GCC was available, Parallax has been forced to play catchup. Arduino's and their offspring have taken the hobbyist market, while in the commercial sector the Prop ends up competing against the M3 and M4 ARM's. 16 and 32bit PIC's, which it cannot do in terms of raw performance or price.
-Phil
In my 30-year career at a defense company, I used a variety of MCUs chosen based on the availability of boards, interfaces and software for the target application (primarily test equipment, supervisory control and data acquisition).
For my fountain project, I chose the prop after the BS2 and Atom MCUs ran out of memory and I/O capability. I can't think of another MCU that has the ability to control 21 servos, 7 solenoids valves, 200 individually addressable RGB LEDs, a 16x2 LCD display, and play music/read commands from a microSD card on a single Propeller Activity Board with virtually no external components. On the other hand, I can't think of a consumer or commercial application with similar requirements.
Can it be that the prop's unique advantages solve problems that companies and entrepreneurs rarely have?
Could be .... Alternatively no one has seriously tried to identify these areas (because of wasting time on other distractions) much less tried to sell into them?
Many technology products are engineering driven more than market driven even if the products started out as ideas to fill a need.
I thought we had plenty of examples, but apparently with minimal widespread use.
Maybe it is still an opportunity for Parallax, as there are no simple constructs to handle the multiple CPUs in a higher level language. ARM tools are pretty lack luster here as well, even though multiple cores are becoming common in the around $5 ARM embedded products.
SPIN is not really a solution as the Prop is pretty slow already, that adding the overhead of an interpreter doesn't help; not to mention the lack of widespread acceptance. It is a hard sell to say hey, let's try this chip, and oh by the way you have to use a language no one else uses.
So, Andy's approach is not simple enough?
But then it was only published 8 years after the chip came out and is still somewhat buried in in tutorials for Stamps, BOEbots and the like.
Would it be possible to create a development environment and language that would be very familiar to experienced ARM users but would make the choice of target processor transparent? Something that could be used to program an ARM processor or a Prop / Prop II and take advantage of the Prop features when that was the target processor. I know that would be a 'nontrivial' task but quite cool if you could pull it off. Give the customer what he or she thinks they want ( otherwise known as 'anything for a buck' ). [edit] If the ARM is chosen as the target then the experience should be no more than 'they' are used to now.. When the Prop is the target then the experience should be nothing short of fantastic. Use the development environment to sell the Prop. Indirectly, that's what the ARM guys are doing. [/edit]
I know nothing about ARM programming but there must be code that implements an interrupt and that would trigger a coginit when a Prop was the target processor.
The speed limitations of spin could be eliminated with a good compiler. That's right isn't it?
Sandy