POLL- Suggest (5) objects the Prop needs to be seen as a viable alternative to
koehler
Posts: 598
the professional engineer in the industrial markets mentioned here: http://www.parallaxsemiconductor.com/corporate/aboutus
Note- This is a small attempt to get the Gold Standard Library going again. At this point we just want to get a count on objects.
1.
2.
3.
4.
5.
Note- This is a small attempt to get the Gold Standard Library going again. At this point we just want to get a count on objects.
1.
2.
3.
4.
5.
Comments
1. FSRW
2. FFDS1
3. "All purpose I2C driver"
4. The Wiznet Drivers
5. 24 channel MCP3208 driver
1. template and example for a general serial driver
2. template and example for a general I2C driver
3. template and example for a general ADC driver
4. template and example for a general DAC driver
5. template and example for a general PWM driver
These would include
The idea being that armed with this information, most folks would be able to recognize and use the power of software programmable peripherals.
All essential but they do fail to show just what the Prop is capable of.
Anyone doing a side-by-side comparison of a Prop to A.N.Other uProc will struggle to a see why they should take a gamble on the Prop. As a comparison, for the same money and board area as a Prop, I can have a uP that has...
3 x SPI
5 x I2C
6 x USART
2 x CAN
5 x PWM
16 x 10-bit ADC
5 x 16-bit timers
2 x 32-bit timers
1 x JTAG debug port
plus loads more memory
Having just 'single device per COG' Gold Standard peripherals will not show the Prop in a good light.
Question is, what is a Gold Standard intended to provide? Is is reliable software that can be use for a particular purpose, or another sales pitch?
I think the former is what is needed (hnce the request for the Gold Standard), and the later exists in abundance or can be created custom for a specific audience.
1. Universal and multiple Serial interface with API handling for XBee
2. FSRW (ideally with clock reading from the RTC embedded in the PASM driver for speed)
3. Universal I2C/SPI driver
4. The Wiznet Drivers
5. Universal ADC/DAC/PWM
Some more to consider
- Stepper Pulse Generator with ramping
- Module and App Note on implementing speed control (with feedback) with the Pololu drivers
- Skeleton and App Note on creating a Finite State Machine using multiple cogs. I believe the Propeller shines here given it's unique capability of true parallel processing of events.
Alex
All Gold Standard objects must be written in C and/or PASM.
And I also said elsewhere, let's not call them objects. Call them "modules" or "libraries". The word "object" has connotations of object oriented programming.
They might have experience with 10 out of the 700++ objects in the OBEX.
Those objects may not be
* The best of its kind
* Well written
* Using the the "full" potential of the Propeller
* General enough
* Etc
We need to have a better way of deciding which objects really are Gold standard. We need to filter out the most obvious garbage first!
IMHO, in most cases pure spin objects goes directly in the garbage. Especially if performance is important.
But of course there are exceptions where a pure spin object may be an advantage, e.g, when you don't want to "waste" a cog or when a small footprint is more important than performance.
This is definitely not an easy task and I'm afraid that the real gold might be hard to find.
Because of the reasons given above, I will not say my personal list of Gold Standard objects. (Yes I do have one)
/Johannes
So, some kind of table:
Jonathan
Thanks for the input so far.
As far as the comment that this is Parallax' responsibility, that is correct though short sighted.
Parallax has obviously limited resources, and anything we can do can only help them when the final decision is made.
Choosing not to help is your right, however not really of much help.
Again as the subject was headed, this is a 'think outside the box' sort of question for many here, who are not professional engineers or developers.
"Suggest (5) objects the Prop needs to be seen as a viable alternative to the professional engineer in the industrial markets mentioned here: http://www.parallaxsemiconductor.com/corporate/aboutus "
Obviously the Prop has significant unique capabilities that are rather outside the norm, however it is the 'norm' that many are going to look to first to see if they want to expend any time to begin with.
As an aside, Brian's comment on what he can do with one prop is a great primary demonstration head-turner that should be explored. Would be best if it actually used Gold Standard code.
I agree and have mentioned before, the term objects is a poor choice and does infer something akin to OOP, which is not what I think many engineers want to even consider.
That aside, what processing power would actually be available in Brian's demo unit once all those cores are used up running objects, modules, programmable hardware, etc?
If there isn't much horsepower left, then it actually hurts more than it helps.
So Thanks to the 3 people who took the time to post some suggestions, here are the results.
Unfortunately, such a small sample does not yield 5 candidates.
1. All purpose I2C driver
2. FSRW
3. Template and example for a general serial driver
4. Universal ADC/DAC/PWM
It doesn't appear as though the 'community' is really interested in doing much beyond either arguing about documentation or dissmissing any effort as Parallax's responsibility.
So aside from you 3, and several other folks working on documentation, etc, I'm not sure what will come of this is anything.
I'll PM Ken just so he can see whats been suggested, and maybe get a more sober view of how much support he can realistically expect to get.
http://www.parallaxsemiconductor.com/support/goldstandard/commission
ps to anybody reading this: I don't think the $50 credit is still available...
Jonathan
However, would appear as though it is an older page and PS doesn't even have 1 GSL yet?
lone sock, understood.
It was just rather annoying that with all the talk, and >250 views, only about 1% felt it worth input.
Hopefully P-S has something planned for release time, as if not I think initial impression that will propagate for P2 is going to be 'faster Propeller, same lack of soft peripherals they are trying to sell on as before'.
That seemed to be the general consensus of most of the professional types I heard after P1 had been out for a couple of years. Was hoping that can be avoided this time around.
My concern is that the enthusiest niche has been Pic and AVR for a while now, with the Arduino the dominant force and growing. With the Arduino now getting into ARM, a lot of the straight horsepower advantage the P1 had is rapidly diminishing.
I only can see the ARduino growing in popularity, even by people who have disdained it as a watered down platform. The power it will have with ARM is going to make it a seriously nontrivial competitor.
For that reason, the P2 has to come out of the gate swinging, in both HW and SW/IP Blocks.
I really hope Parallax has a plan.
Additional memory is one thing that is clearly needed (you'll see this mentioned over and over on forums where the Prop is being compared to other options). In terms of horsepower, it has enough for many applications but I see no overwhelming advantage there - yet. Having an extensive, ready-made library of modules/objects in place would certainly help Parallax market the Prop. Start with the basics (eg, serial interfaces) and go from there. Of course, nowadays file systems, networking, and so on fall more and more often into the "basics" category. Another thing the Prop has going for it is programming languages. It still compares favorably when you look at the number of programming languages that can be used on it. If I were Parallax, I would continue to encourage and explore different language options. More languages increases the market of potential Prop users, whether it be educators, hobbyists, or professionals.
I probably didn't answer the question specifically enough, but I hope the two cents I've added here help.
Also, spin string handling needs to be much improved.
Thirds, a standard sd driver and filesystem would be great.
What is most important isn't having a lot of new objects, but having objects that are easy to use, nicely documented and work well.
Don't worry, many off us are making efforts to cover this for you.
You actually getting a fast response. My project thread has over 12,000 views, 400 comments, and 350 downloads (closer to 1000 downloads if you count previous version) and after almost 3 years we only have 10 team members.
Some folks must lead, over folks must always follow. Some are shy, most are simply busy with other projects that have a higher priority.
The power of soft peripherals is that we can do anything that we want. The "other edge of the blade" is that we must know something about what we want. The prop is just a little bit higher on the technology curve than most (hobbyist) folks think they can handle.
Pic and AVR started as 8 bit, single thread, low MHz parts, that were simple to use. They are over powered for 90% of the "popular" apps that people use them for. Now they are getting bigger, so people can use them even less efficiently. We see a similar pattern as Windows PC. Now consider the prop is more than 10 times more powerful. People don't know what to think. Most folks can barely use 1 core.
Prop and RPi are tools for completely different uses. RPi cannot handle realtime down to 12.5ns on multiple threads, Prop cannot handle processing large chunks of data or HD video. But if we let the prop handle the realtime, and the RPi handle the processing the large chunks of data (in a single thread) things work really nicely.
Proper tool for the proper job. We can use a hammer on screws (the guys called using a hammer to drive drywall screws "Russian nails"), but its harder to use a screwdriver with nails.
The biggest issue is there is a very broad and conflicting set of definitions for "nicely documented". And how to measure "nicely documented". On one extreme is the opinion that documentation should be measured in terms of requirements-tests-results; the other extreme says that is too excessive and they would prefer to take it on faith that a given code set "just works", and complain when things don't work out. On this point, the first step of defining what we mean is the most difficult.
Yes, its all very well having all that stuff, but most projects only use a subset of that capability.
But much more importantly: What makes the Prop worth the effort is the architecture, and even more so, what that architecture means to software development.
It is so much faster to write an application that works rock solidly on a Prop (assuming the app will fit) than it is on the "other" chip because you can put something (and often that "something" is something from the Object Exchange) in a cog, and once its debugged and works, it just works. You dont need to service peripherals in main code or interrupts, and thats where much of the effort occurs in getting projects to work on the "other" processor. The time savings are enormous, and I'd suggest the reliability improvements are also important.
The other problem with the Prop is Parallax. They make great stuff, but then either cut a corner, or wont hold faith waiting for folks to discover they have the perfect solution. For example, cancelling the spin stamp. And now I have another one. The GPS/Prop combo board is canned. Just when I thought I had found the perfect application for it. Or it would be an application if the 1 PPS pulse was available to the on-board Prop. But it seems it isn't. And on the surviving GPS module, the 1 PPS output from the chip also appears to be unavailable. Who would design a GPS solution, and then be so blinkered to think that no-one will ever need that useless 1 PPS output? Take gun, aim at foot, pull trigger.
Some of it may just be a matter of marketing. But it helps to know exactly where/what your market is, and once you do know, to make certain your product is ready for it.
You can't just say, "real-time or no". If you need to do a bunch of real time stuff then a Prop might do it but an ARM, especially in a Raspi or Arduino will not. If you like to quickly build a real-time program incorporating work that others have done you can do it with Spin objects and COGs (or even in C now a days) not so easy on an ARM having to hook into interrupts and check how the timing of one part will effect the others.
Conversely of course if you want a serious networking stack and other large scale things then an ARM is probably the way to go.
It's is a big bonus to have a stock of Propellers, with no dedicated hardware peripherals, that can be adapted to different tasks as and when required over having to find a different version of AVR, ARM whatever with the right mix of peripherals for each job
That's why I fascinated by the idea of pairing a Propeller with a Raspberry Pi, on a stackable board of the same form factor. They compliment each other rather than compete.
From an educational perspective, what could be better than the elegant simplicity of the Propeller for learning assembler for example. It's about the simplest most regular, easy to use instruction set I have ever seen. Much more approachable than ARM.
FPGA's are great, but up against Raspi, Arduino, Propeller they are a lot more expensive and much harder to use.
(1) full duplex serial, with support for hardware flow control (CTS/RTS), in-band flow control (XON/XOFF - not what level escaping/deescaping would be handled), automatic baud rate matching (e.g. sync to 0x80 or perhaps a character such as @), and baud rates up to 3 Mbit (perhaps 1 MBit would be sufficient).
(2) I2C master at 400 kHz. Pretty plain vanilla but would be nice to make 10-bit slaves trivial to support. Perhaps the I2C master could respond to a device interrupt, although this might be handled at a different level.
The characteristics of these interfaces would have to be well understood. e.g. how much jitter does the UART generate/tolerate, and does the I2C master meet the NXP specs.
And supporting these from C would have been a big plus since that's how most development is done. It's too late for this project because they went with an Atmel processor, but I think that the Prop would have worked out nicely. The application is somewhat like a sensor hub.
One concern would be Parallax Semiconductor's ability to respond to inquiries from the QA departments at large companies. Hopefully for this market it wouldn't be an issue.
Myself, I usually think of things like Arduino or RPi as educational tools, hobbyist toys, and platforms that are sometimes used to do prototypes for proof-of-concept. They may also end up from time to time in higher-end, low-volume equipment or designs strictly for in-house use.
I can also do it with the many many libraries available, open-source and those provided by manufacturers. Never mind, too, that some of these things may be incorporated in onboard peripherals. So, yes, it can be done easily enough - and in fact is all the time.
Agreed. Nonetheless, moving from one device to another in the same family can keep things fairly simple. So, for example, if your shop uses AVRs, there are plenty to choose from for most any job, and the tools stay the same and much of your in-house code ports seemlessly.
I'd also be curious to see how that works out.
Again, I don't disagree. But you'll have to sell them on it and, like it or not, competition in that space is fierce right now.
It just depends on the application, right tool for the right job and all that.
Except the part about the "..many libraries available...". It matters not what libraries are available, if you have a single CPU the use of some functionality from some library will impact the speed and timing of functionality from another library. There is no way around that. If you want to mix and match these things in your app you always have to take time into account. With the Prop it's not just that it's very easy to use Spin objects but that having 8 cores available to run them on you know that they are not going to have bad timing interactions. They will just work.
I hate to mention it but as far as I know XMOS is the only other MCU vendor that has taken this approach, for the same reasons. However multi-cores have become all the rage recently.
A Prop for your Raspberry Pi makes a very nice I/O expander if nothing else. Also it would be neat to make a VGA text terminal for the Pi. Besides we can now use the Pi to develop Prop code on using propgcc and SimpleIDE. No more PC required.
The only way around that physical reality is to off load functionality into more hardware that can operate in parallel. That can be hardware peripheral devices or the "more cores and do it in software" approach of Parallax and XMOS. Hardware peripherals are fine and cheap for standard functionality like UARTS, I2C etc etc but ridged, inflexible. The "soft peripherals" are fine for that not so standard stuff and for flexibility.
Here is my list for machine control:
1) Multiple serial interface
2) SD (FSRW)
3) SPI/I2C/One Wire
4) Floating point
5) Frequency synthesis (for a variety of PWM/stepper/inverter situations)
6) VGA/KBD
Just because the poll seemed meager is no reason to end the survey.
Regards,
sm
Perhaps, dare I say, the Prop I was only the prototype. It has the philosophy and architecture but perhaps enough limitations, memory, speed, to make it not quite viable in a broad range of industrial applications.
We might hope the Prop II has enough chops to encompass more of that landscape.
Anyway, there would certainly be no point in Parallax having built a more "normal" AVR, ARM, whatever style device, The world is swimming in those already.