I have been reading this thread on and off for a while now. I think about it often while I take my lunch break walk and have a few things to say:
After managing engineers and skilled workers for a number of years now I amazed at how emotionally attached we can become to Ideas, Designs, Software and Hardware. Allegiance directed towards the tools of the trade will impair even the most skilled when it's time to be objective. And this thread to me is a prime example of this lack of objectivity....of course the Propeller is better...just kidding! Come on, it was a joke! The fact that this dialog has gone on with salient points on both sides is evidence of the success of both platforms. The fact that Parallax has not squashed the thread early on bears tribute the brass ones they have and the confidence in their product line.
I am a mechanical guy who, through the use of the Parallax educational resources, became a pretty savvy electronic guy...after burning my share of I/O's on the first few Stamps. As I progressed in my skills I became frustrated with limitations I perceived to be the limitations of the hardware or software of the Parallax products I took a look around at what else was out there. Soon I found something else and swore I'd never use another Stamp again. Guess what...I still use Stamps, can't remember the name of the other one I swore off Parallax for and I am weekly impressed with the power and versatility of the Propeller.
At the same time I look at all the cools stuff people are doing with the Arduino and other products out there. In the end it is more a testament to the innovative minds that cook up the ideas than to the products they use to do whatever it is they are doing. Everyone has their favorites. That is the way it was, is now and always will be. No one is going to change that. Let's be proud of what we can do...it's pretty cool!
AND KEN....remember what Henry Ford said of consumer requests...."If I listened to my customers, I would've given them a faster horse"
I'm enough of an outsider here to appreciate both sides of the debate. There are some assumptions I made about the Propeller, at the outset, that were wrong. And I see others suffering the same misapprehensions.
Decades spent in the PIC and AVR world did not prepare me for the flexibility of the Prop. Remapping pins has never before been 1/100 as easy as it is with the Prop. Every app from OBEX I've used has been completely flexible as to how I wanted to wire things. The Arduino NEEDS the "standards" Fernand keeps talking about because it would be intractable any other way...and that is because of the fundamental limits of the AVR chip itself.
On the subject of timing...if you have an AVR generating NTSC or PAL, all the timers in the world aren't going to save you from having to delicately and carefully shoehorn in other uP activity during blanking and retrace intervals. It will never be 1/100 as easy as the Prop. I can (and do, all the time) have a video generator in one cog and something entirely different and ultra-demanding running on the cog next door, and yet it is utter child's play to have them operate full tilt in the same chip.
But in defense of Fernand...I can TOTALLY relate to the documentation frustration. Phil's Tricks 'n Traps were a great help, as were Graham Stabler's tutorials. de Silva's PASM tutorial was absolutely invaluable. But it would be great if all of these disparate resources were condensed and formalized by Parallax into an official document of not very many pages.
Historical Example: My intro to computer programming was 6502 assembly. Only years later did I write my first line of HLL code. And that HLL was BASIC on the Color Computer. I wasn't even sure my CoCo had BASIC, or what abilities BASIC had...it was just a word I'd heard tossed about. But I had a thermodynamics assignment to complete (several hundred iterations of the air-standard Brayton cycle) and didn't want to wait in line for a VAX terminal. So I pulled out the CoCo's manuals (that I'd carefully preserved against the day that I might want to look at them). I was horribly dismayed to realize how stupid and verbose they were. I was a college student and didn't have 26 consecutive nights to digest their nitwit content! Then I discovered a little red and white pamphlet I'd saved with the books, that contained a summary of every BASIC command and every OS command.
Long story short, the thermodynamics assignment was done in a flash and I'd gained a vast new appreciation for my silly little computer (which, until then, was just a vehicle for 6809 assembly).
From the get-go, I was looking for such a pamphlet for the Prop. The Propeller Chip Quick Reference was too little, and said absolutely nothing about the particular points that were troubling me so much. Meanwhile, the Propeller Manual was far too big and much too diffuse. I *still* didn't have 26 consecutive nights to digest a computer manual. (And I found out much later that the manual never really does address head-on the questions that puzzled me so greatly.)
This forum would have been a great place to ask all the questions I had, but I was too private and too proud. I just wanted the 'right' document in my hot little hands, and I expected Parallax to provide it.
One final point I'd like to make: Someone earlier in this thread criticized the Prop for not having JTAG. I was put off by this same 'glaring omission' at first. Later I had the opportunity to use a JTAG-equipped uC at work, and found JTAG to be woefully lacking. It is really just a post-mortem tool. It is far too slow to capture real-time diagnostics. I can capture far more data, and in real-time, on a Prop just by using a spare cog. JTAG is just about the most overrated feature I've ever encountered.
I'm firmly in JonnyMac's camp regarding the Prop: It is the most productive and flexible embedded controller I've ever used. The more simultaneous tasks you have, the more critical their timing is, and the quicker it all has to be finished, the more the Prop shines.
And as heater pointed out, a couple decoupling caps and a prop plug is all it takes to make the Prop come alive.
Someday I'd like to own a BOE, P3, PDB, ViewPort, etc. But I'm doing perfectly well with perf board and the PropTool.
UserName: Thankyou. You make some extremely well-presented observations.
I have the Prop Instruction summary at hand, and I refer to the Prop Manual from time to time using pdf search - ouch!. I agree that a little more detailed summary would hit the mark.
The prop shines once you have more than one time critical process to handle. We can use VGA or TV (or a PC for that matter) by just changing the object. No need to tune the interrupt routines because they don't exist. ANd we don't need to fight over pins. I have my little modules that I can make anything from quite simply. I don't have to go an order that particular PIC/AVR etc because my version doesn't have I2C and SPI or whatever.
I have used 12blocks with a group of kids last year.
Nice for programmers and Hanno is very helpful.I like it.
But if you buy it and a demoboard i think it is rather expensive for teatchers.
And i am not quite sure that it is specific for young kids. A bit hard and complex sometimes .
If you have a look at what is used with Arduino you find more tools and much more applications for kids than for the Propeller .
Last week i tested Minibloq on an Arduino Duemilanove.
After ten minutes it works.
I started a new business last year and have been using the propeller with great success. I just signed my biggest contract(160K) to date and it was the ease of learning and capabilities that led me to use the Prop. I still am a newbie and have a lot to learn but I find the Propeller has met all my needs even with the terrible code I write at the moment. Lol...The Object Exchange has been a great help and i have not had to ask for much help as there is plenty between the forums and docs. The easiest way for me to learn at the moment has been to just go through the educational manuals. In a year or two, I'll be rocking along on coding hopefully. I am currently trying to learn communications. RF, Serial, WIFI,, etc... Lots to learn but I'm enjoying it. Thanks Parallax for the opportunity to build my dreams! You guys rock!
I know the thread was long ago but in case someone is searching. As usual, I try to break the idea down to several simple statements.
Soon their projects will require doing several things at once: sense environment, control servos, process, read/write to EEPROM. They can see that.
Then I observe that many of these things need exact action at exact times (servos as crude example). If they have to get all of those timings on tpo of each other exactly right they will be overwhelmed. That is new knowledge but easy to understand
Prop has eight microcontrollers that can co-ordinate so you can just assign one task to each cog and never have a problem. Completely logical.
That explanation has basically always worked because they can picture it. So they accept a higher $ to start knowing they will be better off later.
Not sure exactly what the explanation is, but a latecomer, the raspberry pi platform,
has supposedly sold in the MILLIONS. Yes, I know it's not a raw MC, but it's small
and cheap and people are bitbanging away on that I/O.
If volume and $$ matter, whatever they did right is worth looking into.
Oh boy. The Raspberry Pi is of course a totally different animal.
It's a 700MHz "proper computer" with 512MB memory, networking, USB, a GPU, running a full up Linux deistribution. Lot's of people just buy it to use as a video player. For it's intended educational purposes it can be programmed in a multitude of high level languages.
The GPIO is iceing on the cake. Not any anything in the league of the Propeller but useful for many thinhgs.
The Raspi is designed by a charity with no need to make a profit or even feed the people who work on it.
The fact that the Raspi became available for 30 odd dollars is quite franky stunning.
I suspect the Props can never compete with all that. And nither should they. They are totally different devices.
That's not to say that there can't be found a huge market for the Prop II doing what it does best.
Anyway having two million Pi in the world is a good thing. When the Pi users hit the limits of what it can do in terms of real world interfacing many of them will be looking for something to solve their problems and the Props will be there.
I haven't gone back and re-read all the posts, however there is a disconnect here.
At the university level and on up, I think the interrupt-less mantra that is seen by so many as -the- key selling point, is actually, possibly, a fatal check against its inclusion or uptake at that level. Most teachers, instructors, professors are obviously going to be 'biased', and want to use what they are most familiar with. Which is obviously some sort of interrupt driven uC.
While they may see some benefits of running multiple cores independently and sans interrupts, one has to wonder if -they think- that is going to be beneficial to their students out in the real world.
Versus getting to understand industry standard interrupt driven architecture and programming, which is almost guaranteed what they will be doing.
I believe that many in the education field do want to help out the people they are teaching. Assuming that, taking limited instruction intervals to teach about a non-mainstream niche product that goes against several industry standard conventions probably doesn't look like it would benefit the average student considering how little time they have to ramp them up to speed, even across 4 years.
I'm currently working on a small project that is very low power, and I took the opportunity to give the MSP430 a look-see as it is supposed to be very low power. At least it was a couple of years ago.
Once I'm done, I'm going to repeat it with a Prop board I've got, and see how much time I save by avoiding interrupts. I expect it to be quite a bit.
However, while there is a small but consistent market for my device, even at a $50-75 unit cost, the BOM costs of $1 vs $7-8 for the Prop makes it a non-starter.
Not sure where the break-even point is with respect to unit price/volume that the Prop would become viable, though I hear that there are some volume buyers of the Prop.
OK, I'll shut-up now.
*EDIT- OK, just thought I'd add that I'm seriously not trying to troll here. I think some of the reading I've been doing over in the P2 forum has got me a bit bugged. I'm hoping I'm wrong and the echo chamber that is the Parallax Prop world isn't going to end up the same as the P4 (Netburst) did.
I'm not sure what can be done about that. An innovative design has been achieved, that by its definition precludes it being just like the 99% of other products you'll likely work on. If the academic world won't spend time on that it's understandable but that's just the way things are. Universities used to like to teach computing courses on mainframes and COBOL programming was the only thing a business computing degree needed to focus on. Things change out there before curriculum does. My school offered nothing on OOP programming other than one Java course even though that little idea was taking off around that time. Even the Java professor was only half-interested in teaching it.
The core design principle for the Propeller is that for the work each cog does I know what time it will take and that lets me design soft-modules to do the work of hardware modules without needing an interrupt. I can monitor up to 7 other time critical signals without the need to interrupt the main process on the P1. Why would it make sense to put in interrupts just so it looks like 99% of the other products? Any time I go to work on a project that requires me to fuss with ISR's I immediately remember why I never liked them.
There is no doubt that this chip has seen a few hind-sight missteps in marketing to a wider audience. It's also clear that the price is tough for commercial designs were a $1 part will do the job. There are jobs the $1 part will not do well though and some jobs where the Propeller really shines. I came to the Propeller and nearly dismissed it as well. "So I have to code everything?". When I picked it up and wrapped my head around how to use the cores to get things done in parallel I was hooked. My only real gripe has been the lack of floating point math that makes a lot of chores harder than they ought to be. That's where the echo chamber comes from though, it's tough to get people to step in and take a look but a great many will stay once they do. So the question is how do you get them to walk in that door?
When i point to the success of Arduino and Rasppi, I'm talking not about the devices, but the conceptual "marketing".
These success stories tell us what we need to do better to better "place" the prop. Parallax has at last recently taken an interest in promoting the prop with some simple and clear tutorials, and ventured into C, FWIW. Up to now the Prop code was typical engineer coding: efficient and obtuse, in other words code that solves the problem today well, but is weak on legibility, maintainability, and as teaching materials. And teaching doesn't refer to children, it's for everyone who isn't familiar with the very specialized Prop lingo and approach.
Koehler's points on mainstream and interrupts are correct, but teachers don't have to only use one MCU in classes, if there is a lot of good sample code, and the hardware is inexpensive. I don't quite understand why Parallax has to make the same profit ratio on every item. A little prop board analogous to an Arduino Mini (that would use an external FDDI compatible Prop Plug) could be made cheaply in China and sold cheaply to "seed the channel". And of course the USB interface boardlett should be 100% compatible with the FDDI boardletts that are out there by the millions, and not a unique "prop plug". That's my main grief. That Parallax doesn't think in those terms, they seem to think the mountain must come to them.
As to the RaspPi, the Prop is a perfect I/O handler that could be sold to RaspPi developers if it came on a boardlett that was plug-compatible and had all the drivers ready to go, something to schlepp data DMA style right into the RaspPi memory space. It could likewise be sold to Linux developers who need smart I/O. Again, it's a matter of conscious targeting and marketing. It can't be just another MCU chip!
The limited direct memory space of the Prop makes it IMHO all but unsuitable for general programming, exceptional and heroic cases of shoe-horning notwithstanding. So perhaps make it dominate the area it CAN dominate, namely I/O handling?
I'm very happy to see Parallax's new tutorials. It's a great start. The quickstarts are great but priced too high, and they're bulky. Some $10 tiny Arduino-like boards that plug into a protoboard, or can be flying-wired, would be great. The crystal socket can even be optionally empty, and until the Prop2 comes out, the board could be laid out with say 4 channels of super cheap bit-banging Analog inputs, or a cheap mux'ed A/D.
Not sure exactly what the explanation is, but a latecomer, the raspberry pi platform,
... whatever they did right is worth looking into.
The guys started by designing for a particular goal, using a set of parts that the knew had specs to fit that goal. Right tools for the right job is all they did.
Remember, from day 1 there were folks that claimed the RPi was not feasible, not possible, would never succeed, and could not be useful. Even now there are folks that denounce it as some sort of scam or such.
I haven't gone back and re-read all the posts, however there is a disconnect here.
.... the interrupt-less mantra that is seen by so many as -the- key selling point, is actually, possibly, a fatal check against its inclusion or uptake at that level.
Again right tool for the right job. If somebody selects a different tool for whatever reason, that is their choice. There's more then one way to skin a cat.
took the opportunity to give the MSP430 a look-see as it is supposed to be very low power.....Once I'm done, I'm going to repeat it with a Prop board I've got, and see how much time I save by avoiding interrupts.
We usually do it the opposite way. Do development first on the prop, because is got tons of power, and we are familliar with it. Once we are completely familliar with the final application and ciruitry, we pare it down and try to stuff is onto the cheapest, smallest device that can scrape by. "Appropriate sizing" they call it. So it doesn't really matter how much the favorite development rig is, the final product will always be cheapest possible, whether its prop or something else will be determined by the applications itself.
When this is done backwards, working based on the cost of the parts first, rather than what the application needs, it tends to turn out poorly.
When i point to the success of Arduino and Rasppi, I'm talking not about the devices, but the conceptual "marketing".
Again this is about "percevied" right tool for the right job.
For example, my favorite tool, FORTH, tends to be popular among electrical engineers that need to write simple programs on embedded microcontrollers, but don't want the burden of a full CS degree before they can get the job done. Compare this to software engineers, that always tend to use the most powerful, workstation based tools, even on the tiniest microcontroller. Both approaches make perfect sense in the context of the background of each user. Both are right tool for the right job in the proper context.
Teachers, like everybody else, take the path of least resistance. Their goal is to produce "coders" not engineers. That is, the measure of success is whether or not the student successfully wrote a functioning program. Coding is much different than engineering. Engineering is orders of magnitude more difficult. And when kid can type in (or cut and paste) a successful program and meet the measure, the "engineering" need not be addressed any further.
So the only disconnect is the definition of success. If the goal is a functioning program, with a single action, or even several very slow, infrequent actions, and cost is the first consideration, we get what we got in the general case. If the goal is engineering, and many many very quick, time critical actions, we get what we got in the specialized cases. As always, it all about the right set of tools for the job.
When i point to the success of Arduino and Rasppi, I'm talking not about the devices, but the conceptual "marketing".
These success stories tell us what we need to do better to better "place" the prop. Parallax has at last recently taken an interest in promoting the prop with some simple and clear tutorials, and ventured into C, FWIW. Up to now the Prop code was typical engineer coding: efficient and obtuse, in other words code that solves the problem today well, but is weak on legibility, maintainability, and as teaching materials. And teaching doesn't refer to children, it's for everyone who isn't familiar with the very specialized Prop lingo and approach.
I think most here are in agreement on that. I think Parallax is in agreement as well as they do seem to be working on marketing the chip beyond the hobbyist warrior. I especially like the concept of marketing it as having up to 8 I2C, 8 SPI, or 16 UARTS and having ready-to-go code that implements those and up-front information on how to quickly start using them. I know I almost passed over it because I didn't want to code everything from the ground up not realizing at first what all was in the Object Exchange of the day.
As to the RaspPi, the Prop is a perfect I/O handler that could be sold to RaspPi developers if it came on a boardlett that was plug-compatible and had all the drivers ready to go, something to schlepp data DMA style right into the RaspPi memory space. It could likewise be sold to Linux developers who need smart I/O. Again, it's a matter of conscious targeting and marketing. It can't be just another MCU chip!
Agree. Making this into an easy-to-use real-time I/O handler ought to be a prefect fit for these platforms where they have GPIO but can't do serious time-sensitive work because.... well, Linux is interrupted constantly. Where I keep struggling there is how to interface for programming it in a simple and beginner-friendly way that doesn't take up one of the precious USB ports on the RaspPi or the ONLY USB on the BeagleBone. I'm working on an I/O co-processor now for my Beagle Bone Black for my own project but have not mounted those challenges yet.
The limited direct memory space of the Prop makes it IMHO all but unsuitable for general programming, exceptional and heroic cases of shoe-horning notwithstanding. So perhaps make it dominate the area it CAN dominate, namely I/O handling?
The RAM available was fine when you used PASM and SPIN to code it and so I certainly see where that seemed completely reasonable when P1 was developed. When you switched to C/C++ then it got very cramped in a big hurry. Things there are improving greatly though. CMM code can be smaller than SPIN and run at double to triple the speed. Optimize CMM for speed and you can get 10 to 15 times or more SPIN's speed at right at 1.5 times the code size. Problem is that C is just big. Add a few familiar libraries and boom you are running into the limits. We need more libraries similar to Arduino where they do 80% of the work of the big boy libraries but at 30% of the size so people can develop co-processor jobs that warrant the 8 cores. Used to need to printf() to do most debug and watch the code size balloon by 12 or 18K and that all but ended you on anything to terribly complex. Now I can get that debug output from Simple Libraries for a far reduced code-size hit. I program for the ChipKit Uno32 and while it has 128K of flash program memory I can still chew that up fast for anything that uses a lot of library code but I spend a lot less time worried about code size there. The P2 should feel about as roomy I would think so they are trying to address this issue too.
Until there is a nice manual or book that covers these in detail though it's all buried in forum posts, wikis, blogs, and bits and pieces all over. Lots of pages need to be dedicated to using multiple cores in various ways. That has got to get better to bring in more people, and I see effort going into that. I hope that will not get too back-burner though. I think there is too much reliance on people being forum junkies in the way things are now. Lots of things you won't know about or get clear examples on if you don't live around here and know where to start digging.
The Arduino, especially, is for people who have no idea of 90% of what people are talking about in this thread. RAM, Flash, assembler, and all that are terms they hear, but don't understand. Or care to understand.
What they care about is that there's an example sketch that does what they want. They may not (and usually aren't) aware the sketch may use an interrupt or two, or does some tricky things with internal timers.
Robotics, especially, is a good example of where the Propeller can shine. But until recently, there hasn't been a lot of examples. I've showed a couple of Prop-based bots in some SERVO articles, but the real push took Parallax themselves to develop a core robotics platform around the Prop, the ActivityBot. I know they had plans for a long time, and there have been robotics-based examples here and there, but this platform codifies all of it. I think it will make a big difference.
The Prop2 will reintroduce the concepts around the Propeller, making it newsworthy again. Hopefully that will spur more project articles that will in turn showcase the chip, that will in turn bring in more projects, and so on.
I've always felt the best way to truly compare the Propeller and Arduino is to do the same project with both, then review how easy or hard it was. About a year ago, I did a MIDI-based project (an as-yet-to-be-published article for Make) that was sheer interrupt and timer hell using the Arduino. Extremely frustrating to work around all the hardware limitations of the Uno. It took a full four times longer to write and debug the sketch than I anticipated because it pushed the Arduino to its limits. The same project using a Prop would be a cakewalk.
The Prop will always "lose" when comparing gut features like RAM. It can only really be compared in a real-world situation, like a small robot. So when asked to compare the Prop against an Arduino, just *show* them what it can do. How it does it -- hardware underpinnings and all -- is not nearly as important .
I tend to agree with Gordon McComb... no depth of understanding to the average Arduino user... just wanting to play with templated designs
Nonetheless I have recently purchased an Arduino Uno as it was actually being sold over the counter here in Kaohsiung, and cheaply. But my whole plan is to simply load AVR Forth into it and never deal with Arduino code. The Propeller should NOT be compared to the Arduino, but the underlying AVR chip.... after all a chip for chip comparison would be a lot more concise. Have both run in Forth. Then, the pros and cons would be much more obvious.
As for the RPI, it is SOC or 'system on a chip' ... a whole computer system in a one chip package.... you use it like you would use a PC. If you don't know much about programing a whole PC system, well the RPI has about the same learning curve -- it is a lot more complex that the average learner needs for an introduction. I have never thought it was appropriate for young children.. too many topics to introduce and too many layers of abstraction. Just because it has more 'stuff' in a $35 package doesn't make it ' the right stuff'.
How do you use RPi? It's a nice board, but I haven't found the right use for it yet.
1) Buy it for $35, and give it to a kid to play with. If it gets broken, no biggie. Much cheaper than risking the laptop.
2) Load Raspbmc and make a media player. Works much better than the software in a disc play. Particularly handy for me since I rarely handle disks any more.
3) put it on a bot, and have it aggregate the sensor from the prop. Send high level control commands back to the prop. Prop does the real time stuff, which the RPi doesn't do so well, RPi does the crunching stuff, that the prop doesn't do so well.
I also tried using RPi as a headless node to run a Reprep. It sort of worked, but had a bunch of stalls during print, which tended to ruin things. I don't know if this was from VNC causing too much load, or if it just too much to send the Gcode from pronterface. I needed a print right away, so I switched back to the desktop pc and never got around to sorting out the RPi.
At the university level and on up, I think the interrupt-less mantra that is seen by so many as -the- key selling point, is actually, possibly, a fatal check against its inclusion or uptake at that level. Most teachers, instructors, professors are obviously going to be 'biased',
I think I have to dispute that statement. In recent months I have watched hundreds of hours of videos on youtube of undergraduate lectures in computer science and computer architecture from places like Berkeley. I was curious to see what the kids are up to now a days. Not a mention of interrupts anywhere.
Further, it seems to me that 99.9% of the worlds programmers never have to deal with interrupts. The ones that do are building drivers for things like Linux or whish they did not have that hassle and complication whilst trying to get their embedded applications off the ground.
Quite the reverse. The worlds GUI developers work in an "event driven" world. They hang code off of mouse and keyboard events etc. Similarly the worlds Web developers work in an entirely "even driven" way. There is no other choice with JavaScript in the browser.
In recent times XMOS MCU's are multi-core and have hardware scheduled threads. You work with them in an event driven way. You never have to get into interrupts unless you want to do something really exotic.
That is where the Prop is. An multi-core and now , with the P2 multi-threaded, event driven machine.
It's not our fault if a few old accademics hang on to teaching old ways.
I've showed a couple of Prop-based bots in some SERVO articles, but the real push took Parallax themselves to develop a core robotics platform around the Prop, the ActivityBot. I know they had plans for a long time, and there have been robotics-based examples here and there, but this platform codifies all of it. I think it will make a big difference.
Thank you for the lead-in and introduction, Mr. McComb.
1) Buy it for $35, and give it to a kid to play with. If it gets broken, no biggie. Much cheaper than risking the laptop.
2) Load Raspbmc and make a media player. Works much better than the software in a disc play. Particularly handy for me since I rarely handle disks any more.
3) put it on a bot, and have it aggregate the sensor from the prop. Send high level control commands back to the prop. Prop does the real time stuff, which the RPi doesn't do so well, RPi does the crunching stuff, that the prop doesn't do so well.
I also tried using RPi as a headless node to run a Reprep. It sort of worked, but had a bunch of stalls during print, which tended to ruin things. I don't know if this was from VNC causing too much load, or if it just too much to send the Gcode from pronterface. I needed a print right away, so I switched back to the desktop pc and never got around to sorting out the RPi.
That's exactly my reason to use the BeagleBoneBlack (Similar but way more GPIO). The Propeller was just a giant pain trying to do math needed for stuff like gyro/accel/magno IMU and fusing the readings and it had little space for lookup tables and so forth to do acceleration for the stepper motors. The BBB can do that math without breaking a sweat and has gobs of space for any data structures I may need. It can read simple 1|0 switches and sensors but it can't properly time a SONAR pulse from a ping sensor or count the pulses from a VCO sensor like a Propeller can without breaking a sweat. Certainly not without making a complicated mess out of it. They fit together like legos though. A serial port and some code and let each handle the parts it excels at.
I'm on it Ken! My son's middle school lost the teacher that spearheaded the robotics club a couple of years ago so I've been talking to the GT Science teacher about helping get it going again. She seems very enthusiastic about it and hopefully I can have some input on platform decisions (-- I've been keeping her dog healthy for 14 years if she's reading this).
I also tried using RPi as a headless node to run a Reprep. It sort of worked, but had a bunch of stalls during print, which tended to ruin things. I don't know if this was from VNC causing too much load, or if it just too much to send the Gcode from pronterface. I needed a print right away, so I switched back to the desktop pc and never got around to sorting out the RPi.
A headless computer running VNC is a lot like a computer with keyboard, mouse, and video.
I tried something similar thinking I could use RPi for web browsing on my TV. What a disaster.
An RPi without a window manager might have enough bandwidth to do some useful things.
That kind of thing is what the X window system was created for...
VNC is a real HOG in that it has to scrape the screescreen all the time. A computer running X can handle the graphics in their entirety, leaving much more resources on the Pi to get things done.
Alas... way too many folks kind of tuned out of multi-user networked GUI capability and here we are with browsers, VNC and other kinds of things.
I don't have a Pi, but perhaps the applications people run on it are still X capable. If so, setting a display host might make running headless more effective. You just need an X server on your "head" machine. There are a few of those out there for the Windows PC, Linux has it just an install away, and Apple either ships it, or in recent releases, refers people to the open X server for OS X.
You may even get the Pi to present a login screen over X, in which case it then becomes trivial to do multiple things on a Pi, with efficient use of its RAM.
It isn't the window manager that is at issue. Typically, it is the graphics server. If desired, a Pi can still do window management for another computer running X to serve up graphics. I used to have an SGI do that for my Linux machines back in the day of more crappy window managers.
Either way, getting the graphics off the Pi could really improve it's overall performance.
As far as VNC goes, you might have luck running it in 8. Bit color to cut down on the massive data transfer requirements.
A headless computer running VNC is a lot like a computer with keyboard, mouse, and video.
I tried something similar thinking I could use RPi for web browsing on my TV. What a disaster.
An RPi without a window manager might have enough bandwidth to do some useful things.
I came to the same conclusion. Except for the media player, I just ssh in to the RPi's with teraterm or minicom.
Poor old Raspberry Pi gets a lot of battering for not doing many things very well.
The idea of a "headless VNC" is nonsense. VNC requires that graphics is rendered on the server machine and then sent as some kind of compressed bit maps to the client. "Headless" would be more like an X application having it's GUI rendered on your local machine.
Let's face it, the Pi has the power of a PC running Linux back in 2000 or so. Nobody would have expected VNC to work well then.
However, the Pi has a GPU, it plays video very well. way in excess of that year 2000 PC.
Oh, and by the way the Pi can run propgcc and Simple IDE effortlessly. Want a self contained embedded system in some robot or other gizmo , a Pi and a Prop does that.
X was effective at 30Mhz (Mips + IRIX) and 10-T networking. Just a data point. With reasonably written applications (and those are increasingly rare), X just didn't need much.
Honestly, a Pi running as an X server makes great sense! That way the GPU actually contributes nicely. (I know, ducking down now to let the veggies flying my way find an alternative landing...) Not sure what I would do with that, but I may do it one day, just for grins. Maybe get a CAD screen shot or something on a Pi desktop just to mess with people.
Re: Video. I had DVD resolution video in 2000. Matrox made a great set of cards, and one of them was the G400, and it offered up VGA or TV with the right cable. A 300Mhz Intel something or other with 128Mb RAM would blast full frame video perfectly all day long. That card could probably do 720p in the same way, on not much more given a source... I never tried it then. I used this: http://en.wikipedia.org/wiki/Ogle_DVD_Player and that was '02, but the machine was older, 2000 era e-machine something or other given to me to "tinker" with.
IMHO, just getting video done isn't that big of a deal. We've had it for quite some time. What that older PC could not do was higher level 3D graphics, lights, shaders, polys, textures and such. I could put Quake 3 Arena on it and play a reasonable game in 640x480, but anything more intense was just lost on it. A Pi, from what I can tell, does a whole lot more in that department...
VNC was reasonable in that time period, if you had 100-T networking, just FYI. I did it a lot around the 2000's, using an SGI for the VNC client. At one point, I had every machine in the place setup with VNC and the SGI scripted to display any one of them with a couple clicks on an icon. Spent a few weeks getting that all tuned in, but once it was done, doing IT / application support was cake. Seriously lean environment.
Comments
After managing engineers and skilled workers for a number of years now I amazed at how emotionally attached we can become to Ideas, Designs, Software and Hardware. Allegiance directed towards the tools of the trade will impair even the most skilled when it's time to be objective. And this thread to me is a prime example of this lack of objectivity....of course the Propeller is better...just kidding! Come on, it was a joke! The fact that this dialog has gone on with salient points on both sides is evidence of the success of both platforms. The fact that Parallax has not squashed the thread early on bears tribute the brass ones they have and the confidence in their product line.
I am a mechanical guy who, through the use of the Parallax educational resources, became a pretty savvy electronic guy...after burning my share of I/O's on the first few Stamps. As I progressed in my skills I became frustrated with limitations I perceived to be the limitations of the hardware or software of the Parallax products I took a look around at what else was out there. Soon I found something else and swore I'd never use another Stamp again. Guess what...I still use Stamps, can't remember the name of the other one I swore off Parallax for and I am weekly impressed with the power and versatility of the Propeller.
At the same time I look at all the cools stuff people are doing with the Arduino and other products out there. In the end it is more a testament to the innovative minds that cook up the ideas than to the products they use to do whatever it is they are doing. Everyone has their favorites. That is the way it was, is now and always will be. No one is going to change that. Let's be proud of what we can do...it's pretty cool!
AND KEN....remember what Henry Ford said of consumer requests...."If I listened to my customers, I would've given them a faster horse"
That comment was made before genetic engineering came of age
Decades spent in the PIC and AVR world did not prepare me for the flexibility of the Prop. Remapping pins has never before been 1/100 as easy as it is with the Prop. Every app from OBEX I've used has been completely flexible as to how I wanted to wire things. The Arduino NEEDS the "standards" Fernand keeps talking about because it would be intractable any other way...and that is because of the fundamental limits of the AVR chip itself.
On the subject of timing...if you have an AVR generating NTSC or PAL, all the timers in the world aren't going to save you from having to delicately and carefully shoehorn in other uP activity during blanking and retrace intervals. It will never be 1/100 as easy as the Prop. I can (and do, all the time) have a video generator in one cog and something entirely different and ultra-demanding running on the cog next door, and yet it is utter child's play to have them operate full tilt in the same chip.
But in defense of Fernand...I can TOTALLY relate to the documentation frustration. Phil's Tricks 'n Traps were a great help, as were Graham Stabler's tutorials. de Silva's PASM tutorial was absolutely invaluable. But it would be great if all of these disparate resources were condensed and formalized by Parallax into an official document of not very many pages.
Historical Example: My intro to computer programming was 6502 assembly. Only years later did I write my first line of HLL code. And that HLL was BASIC on the Color Computer. I wasn't even sure my CoCo had BASIC, or what abilities BASIC had...it was just a word I'd heard tossed about. But I had a thermodynamics assignment to complete (several hundred iterations of the air-standard Brayton cycle) and didn't want to wait in line for a VAX terminal. So I pulled out the CoCo's manuals (that I'd carefully preserved against the day that I might want to look at them). I was horribly dismayed to realize how stupid and verbose they were. I was a college student and didn't have 26 consecutive nights to digest their nitwit content! Then I discovered a little red and white pamphlet I'd saved with the books, that contained a summary of every BASIC command and every OS command.
Long story short, the thermodynamics assignment was done in a flash and I'd gained a vast new appreciation for my silly little computer (which, until then, was just a vehicle for 6809 assembly).
From the get-go, I was looking for such a pamphlet for the Prop. The Propeller Chip Quick Reference was too little, and said absolutely nothing about the particular points that were troubling me so much. Meanwhile, the Propeller Manual was far too big and much too diffuse. I *still* didn't have 26 consecutive nights to digest a computer manual. (And I found out much later that the manual never really does address head-on the questions that puzzled me so greatly.)
This forum would have been a great place to ask all the questions I had, but I was too private and too proud. I just wanted the 'right' document in my hot little hands, and I expected Parallax to provide it.
One final point I'd like to make: Someone earlier in this thread criticized the Prop for not having JTAG. I was put off by this same 'glaring omission' at first. Later I had the opportunity to use a JTAG-equipped uC at work, and found JTAG to be woefully lacking. It is really just a post-mortem tool. It is far too slow to capture real-time diagnostics. I can capture far more data, and in real-time, on a Prop just by using a spare cog. JTAG is just about the most overrated feature I've ever encountered.
I'm firmly in JonnyMac's camp regarding the Prop: It is the most productive and flexible embedded controller I've ever used. The more simultaneous tasks you have, the more critical their timing is, and the quicker it all has to be finished, the more the Prop shines.
And as heater pointed out, a couple decoupling caps and a prop plug is all it takes to make the Prop come alive.
Someday I'd like to own a BOE, P3, PDB, ViewPort, etc. But I'm doing perfectly well with perf board and the PropTool.
I have the Prop Instruction summary at hand, and I refer to the Prop Manual from time to time using pdf search - ouch!. I agree that a little more detailed summary would hit the mark.
The prop shines once you have more than one time critical process to handle. We can use VGA or TV (or a PC for that matter) by just changing the object. No need to tune the interrupt routines because they don't exist. ANd we don't need to fight over pins. I have my little modules that I can make anything from quite simply. I don't have to go an order that particular PIC/AVR etc because my version doesn't have I2C and SPI or whatever.
I have used the Propeller with groups of kids for 3 years and i learned some things:
Propeller boards are often too expensive for teachers.
Kids like it when it is easy and clear . If it is hard they quit.
So i used rather the Propeller Platform. But four pins for analog input are missing.
Objects are very appreciated but we need a clear library of functions (like the Arduino one) .
A block language simple and easy to use will help a lot to make it friendly for kids.
Jean Paul
Nice for programmers and Hanno is very helpful.I like it.
But if you buy it and a demoboard i think it is rather expensive for teatchers.
And i am not quite sure that it is specific for young kids. A bit hard and complex sometimes .
If you have a look at what is used with Arduino you find more tools and much more applications for kids than for the Propeller .
Last week i tested Minibloq on an Arduino Duemilanove.
After ten minutes it works.
You find it here : http://minibloq.net/
Soon their projects will require doing several things at once: sense environment, control servos, process, read/write to EEPROM. They can see that.
Then I observe that many of these things need exact action at exact times (servos as crude example). If they have to get all of those timings on tpo of each other exactly right they will be overwhelmed. That is new knowledge but easy to understand
Prop has eight microcontrollers that can co-ordinate so you can just assign one task to each cog and never have a problem. Completely logical.
That explanation has basically always worked because they can picture it. So they accept a higher $ to start knowing they will be better off later.
has supposedly sold in the MILLIONS. Yes, I know it's not a raw MC, but it's small
and cheap and people are bitbanging away on that I/O.
If volume and $$ matter, whatever they did right is worth looking into.
It's a 700MHz "proper computer" with 512MB memory, networking, USB, a GPU, running a full up Linux deistribution. Lot's of people just buy it to use as a video player. For it's intended educational purposes it can be programmed in a multitude of high level languages.
The GPIO is iceing on the cake. Not any anything in the league of the Propeller but useful for many thinhgs.
The Raspi is designed by a charity with no need to make a profit or even feed the people who work on it.
The fact that the Raspi became available for 30 odd dollars is quite franky stunning.
I suspect the Props can never compete with all that. And nither should they. They are totally different devices.
That's not to say that there can't be found a huge market for the Prop II doing what it does best.
Anyway having two million Pi in the world is a good thing. When the Pi users hit the limits of what it can do in terms of real world interfacing many of them will be looking for something to solve their problems and the Props will be there.
At the university level and on up, I think the interrupt-less mantra that is seen by so many as -the- key selling point, is actually, possibly, a fatal check against its inclusion or uptake at that level. Most teachers, instructors, professors are obviously going to be 'biased', and want to use what they are most familiar with. Which is obviously some sort of interrupt driven uC.
While they may see some benefits of running multiple cores independently and sans interrupts, one has to wonder if -they think- that is going to be beneficial to their students out in the real world.
Versus getting to understand industry standard interrupt driven architecture and programming, which is almost guaranteed what they will be doing.
I believe that many in the education field do want to help out the people they are teaching. Assuming that, taking limited instruction intervals to teach about a non-mainstream niche product that goes against several industry standard conventions probably doesn't look like it would benefit the average student considering how little time they have to ramp them up to speed, even across 4 years.
I'm currently working on a small project that is very low power, and I took the opportunity to give the MSP430 a look-see as it is supposed to be very low power. At least it was a couple of years ago.
Once I'm done, I'm going to repeat it with a Prop board I've got, and see how much time I save by avoiding interrupts. I expect it to be quite a bit.
However, while there is a small but consistent market for my device, even at a $50-75 unit cost, the BOM costs of $1 vs $7-8 for the Prop makes it a non-starter.
Not sure where the break-even point is with respect to unit price/volume that the Prop would become viable, though I hear that there are some volume buyers of the Prop.
OK, I'll shut-up now.
*EDIT- OK, just thought I'd add that I'm seriously not trying to troll here. I think some of the reading I've been doing over in the P2 forum has got me a bit bugged. I'm hoping I'm wrong and the echo chamber that is the Parallax Prop world isn't going to end up the same as the P4 (Netburst) did.
The core design principle for the Propeller is that for the work each cog does I know what time it will take and that lets me design soft-modules to do the work of hardware modules without needing an interrupt. I can monitor up to 7 other time critical signals without the need to interrupt the main process on the P1. Why would it make sense to put in interrupts just so it looks like 99% of the other products? Any time I go to work on a project that requires me to fuss with ISR's I immediately remember why I never liked them.
There is no doubt that this chip has seen a few hind-sight missteps in marketing to a wider audience. It's also clear that the price is tough for commercial designs were a $1 part will do the job. There are jobs the $1 part will not do well though and some jobs where the Propeller really shines. I came to the Propeller and nearly dismissed it as well. "So I have to code everything?". When I picked it up and wrapped my head around how to use the cores to get things done in parallel I was hooked. My only real gripe has been the lack of floating point math that makes a lot of chores harder than they ought to be. That's where the echo chamber comes from though, it's tough to get people to step in and take a look but a great many will stay once they do. So the question is how do you get them to walk in that door?
When i point to the success of Arduino and Rasppi, I'm talking not about the devices, but the conceptual "marketing".
These success stories tell us what we need to do better to better "place" the prop. Parallax has at last recently taken an interest in promoting the prop with some simple and clear tutorials, and ventured into C, FWIW. Up to now the Prop code was typical engineer coding: efficient and obtuse, in other words code that solves the problem today well, but is weak on legibility, maintainability, and as teaching materials. And teaching doesn't refer to children, it's for everyone who isn't familiar with the very specialized Prop lingo and approach.
Koehler's points on mainstream and interrupts are correct, but teachers don't have to only use one MCU in classes, if there is a lot of good sample code, and the hardware is inexpensive. I don't quite understand why Parallax has to make the same profit ratio on every item. A little prop board analogous to an Arduino Mini (that would use an external FDDI compatible Prop Plug) could be made cheaply in China and sold cheaply to "seed the channel". And of course the USB interface boardlett should be 100% compatible with the FDDI boardletts that are out there by the millions, and not a unique "prop plug". That's my main grief. That Parallax doesn't think in those terms, they seem to think the mountain must come to them.
As to the RaspPi, the Prop is a perfect I/O handler that could be sold to RaspPi developers if it came on a boardlett that was plug-compatible and had all the drivers ready to go, something to schlepp data DMA style right into the RaspPi memory space. It could likewise be sold to Linux developers who need smart I/O. Again, it's a matter of conscious targeting and marketing. It can't be just another MCU chip!
The limited direct memory space of the Prop makes it IMHO all but unsuitable for general programming, exceptional and heroic cases of shoe-horning notwithstanding. So perhaps make it dominate the area it CAN dominate, namely I/O handling?
I'm very happy to see Parallax's new tutorials. It's a great start. The quickstarts are great but priced too high, and they're bulky. Some $10 tiny Arduino-like boards that plug into a protoboard, or can be flying-wired, would be great. The crystal socket can even be optionally empty, and until the Prop2 comes out, the board could be laid out with say 4 channels of super cheap bit-banging Analog inputs, or a cheap mux'ed A/D.
The guys started by designing for a particular goal, using a set of parts that the knew had specs to fit that goal. Right tools for the right job is all they did.
Remember, from day 1 there were folks that claimed the RPi was not feasible, not possible, would never succeed, and could not be useful. Even now there are folks that denounce it as some sort of scam or such.
Again right tool for the right job. If somebody selects a different tool for whatever reason, that is their choice. There's more then one way to skin a cat.
We usually do it the opposite way. Do development first on the prop, because is got tons of power, and we are familliar with it. Once we are completely familliar with the final application and ciruitry, we pare it down and try to stuff is onto the cheapest, smallest device that can scrape by. "Appropriate sizing" they call it. So it doesn't really matter how much the favorite development rig is, the final product will always be cheapest possible, whether its prop or something else will be determined by the applications itself.
When this is done backwards, working based on the cost of the parts first, rather than what the application needs, it tends to turn out poorly.
Again this is about "percevied" right tool for the right job.
For example, my favorite tool, FORTH, tends to be popular among electrical engineers that need to write simple programs on embedded microcontrollers, but don't want the burden of a full CS degree before they can get the job done. Compare this to software engineers, that always tend to use the most powerful, workstation based tools, even on the tiniest microcontroller. Both approaches make perfect sense in the context of the background of each user. Both are right tool for the right job in the proper context.
Teachers, like everybody else, take the path of least resistance. Their goal is to produce "coders" not engineers. That is, the measure of success is whether or not the student successfully wrote a functioning program. Coding is much different than engineering. Engineering is orders of magnitude more difficult. And when kid can type in (or cut and paste) a successful program and meet the measure, the "engineering" need not be addressed any further.
So the only disconnect is the definition of success. If the goal is a functioning program, with a single action, or even several very slow, infrequent actions, and cost is the first consideration, we get what we got in the general case. If the goal is engineering, and many many very quick, time critical actions, we get what we got in the specialized cases. As always, it all about the right set of tools for the job.
I think most here are in agreement on that. I think Parallax is in agreement as well as they do seem to be working on marketing the chip beyond the hobbyist warrior. I especially like the concept of marketing it as having up to 8 I2C, 8 SPI, or 16 UARTS and having ready-to-go code that implements those and up-front information on how to quickly start using them. I know I almost passed over it because I didn't want to code everything from the ground up not realizing at first what all was in the Object Exchange of the day.
Agree. Making this into an easy-to-use real-time I/O handler ought to be a prefect fit for these platforms where they have GPIO but can't do serious time-sensitive work because.... well, Linux is interrupted constantly. Where I keep struggling there is how to interface for programming it in a simple and beginner-friendly way that doesn't take up one of the precious USB ports on the RaspPi or the ONLY USB on the BeagleBone. I'm working on an I/O co-processor now for my Beagle Bone Black for my own project but have not mounted those challenges yet.
The RAM available was fine when you used PASM and SPIN to code it and so I certainly see where that seemed completely reasonable when P1 was developed. When you switched to C/C++ then it got very cramped in a big hurry. Things there are improving greatly though. CMM code can be smaller than SPIN and run at double to triple the speed. Optimize CMM for speed and you can get 10 to 15 times or more SPIN's speed at right at 1.5 times the code size. Problem is that C is just big. Add a few familiar libraries and boom you are running into the limits. We need more libraries similar to Arduino where they do 80% of the work of the big boy libraries but at 30% of the size so people can develop co-processor jobs that warrant the 8 cores. Used to need to printf() to do most debug and watch the code size balloon by 12 or 18K and that all but ended you on anything to terribly complex. Now I can get that debug output from Simple Libraries for a far reduced code-size hit. I program for the ChipKit Uno32 and while it has 128K of flash program memory I can still chew that up fast for anything that uses a lot of library code but I spend a lot less time worried about code size there. The P2 should feel about as roomy I would think so they are trying to address this issue too.
Until there is a nice manual or book that covers these in detail though it's all buried in forum posts, wikis, blogs, and bits and pieces all over. Lots of pages need to be dedicated to using multiple cores in various ways. That has got to get better to bring in more people, and I see effort going into that. I hope that will not get too back-burner though. I think there is too much reliance on people being forum junkies in the way things are now. Lots of things you won't know about or get clear examples on if you don't live around here and know where to start digging.
What they care about is that there's an example sketch that does what they want. They may not (and usually aren't) aware the sketch may use an interrupt or two, or does some tricky things with internal timers.
Robotics, especially, is a good example of where the Propeller can shine. But until recently, there hasn't been a lot of examples. I've showed a couple of Prop-based bots in some SERVO articles, but the real push took Parallax themselves to develop a core robotics platform around the Prop, the ActivityBot. I know they had plans for a long time, and there have been robotics-based examples here and there, but this platform codifies all of it. I think it will make a big difference.
The Prop2 will reintroduce the concepts around the Propeller, making it newsworthy again. Hopefully that will spur more project articles that will in turn showcase the chip, that will in turn bring in more projects, and so on.
I've always felt the best way to truly compare the Propeller and Arduino is to do the same project with both, then review how easy or hard it was. About a year ago, I did a MIDI-based project (an as-yet-to-be-published article for Make) that was sheer interrupt and timer hell using the Arduino. Extremely frustrating to work around all the hardware limitations of the Uno. It took a full four times longer to write and debug the sketch than I anticipated because it pushed the Arduino to its limits. The same project using a Prop would be a cakewalk.
The Prop will always "lose" when comparing gut features like RAM. It can only really be compared in a real-world situation, like a small robot. So when asked to compare the Prop against an Arduino, just *show* them what it can do. How it does it -- hardware underpinnings and all -- is not nearly as important .
Nonetheless I have recently purchased an Arduino Uno as it was actually being sold over the counter here in Kaohsiung, and cheaply. But my whole plan is to simply load AVR Forth into it and never deal with Arduino code. The Propeller should NOT be compared to the Arduino, but the underlying AVR chip.... after all a chip for chip comparison would be a lot more concise. Have both run in Forth. Then, the pros and cons would be much more obvious.
As for the RPI, it is SOC or 'system on a chip' ... a whole computer system in a one chip package.... you use it like you would use a PC. If you don't know much about programing a whole PC system, well the RPI has about the same learning curve -- it is a lot more complex that the average learner needs for an introduction. I have never thought it was appropriate for young children.. too many topics to introduce and too many layers of abstraction. Just because it has more 'stuff' in a $35 package doesn't make it ' the right stuff'.
1) Buy it for $35, and give it to a kid to play with. If it gets broken, no biggie. Much cheaper than risking the laptop.
2) Load Raspbmc and make a media player. Works much better than the software in a disc play. Particularly handy for me since I rarely handle disks any more.
3) put it on a bot, and have it aggregate the sensor from the prop. Send high level control commands back to the prop. Prop does the real time stuff, which the RPi doesn't do so well, RPi does the crunching stuff, that the prop doesn't do so well.
I also tried using RPi as a headless node to run a Reprep. It sort of worked, but had a bunch of stalls during print, which tended to ruin things. I don't know if this was from VNC causing too much load, or if it just too much to send the Gcode from pronterface. I needed a print right away, so I switched back to the desktop pc and never got around to sorting out the RPi.
I think I have to dispute that statement. In recent months I have watched hundreds of hours of videos on youtube of undergraduate lectures in computer science and computer architecture from places like Berkeley. I was curious to see what the kids are up to now a days. Not a mention of interrupts anywhere.
Further, it seems to me that 99.9% of the worlds programmers never have to deal with interrupts. The ones that do are building drivers for things like Linux or whish they did not have that hassle and complication whilst trying to get their embedded applications off the ground.
Quite the reverse. The worlds GUI developers work in an "event driven" world. They hang code off of mouse and keyboard events etc. Similarly the worlds Web developers work in an entirely "even driven" way. There is no other choice with JavaScript in the browser.
In recent times XMOS MCU's are multi-core and have hardware scheduled threads. You work with them in an event driven way. You never have to get into interrupts unless you want to do something really exotic.
That is where the Prop is. An multi-core and now , with the P2 multi-threaded, event driven machine.
It's not our fault if a few old accademics hang on to teaching old ways.
Thank you for the lead-in and introduction, Mr. McComb.
Customers, we need your help to get the ActivityBot into some educational channels. Please consider being part of my "teach a teacher program" right here http://www.parallax.com/news/jul11-2013/introduce-educator-parallax-earn-credit.
Come on everybody, join me! I need some helpers out there! You want your P2s, right? Well, it takes more revenue than P1 can provide to fund P2s.
That's exactly my reason to use the BeagleBoneBlack (Similar but way more GPIO). The Propeller was just a giant pain trying to do math needed for stuff like gyro/accel/magno IMU and fusing the readings and it had little space for lookup tables and so forth to do acceleration for the stepper motors. The BBB can do that math without breaking a sweat and has gobs of space for any data structures I may need. It can read simple 1|0 switches and sensors but it can't properly time a SONAR pulse from a ping sensor or count the pulses from a VCO sensor like a Propeller can without breaking a sweat. Certainly not without making a complicated mess out of it. They fit together like legos though. A serial port and some code and let each handle the parts it excels at.
Doc
A headless computer running VNC is a lot like a computer with keyboard, mouse, and video.
I tried something similar thinking I could use RPi for web browsing on my TV. What a disaster.
An RPi without a window manager might have enough bandwidth to do some useful things.
VNC is a real HOG in that it has to scrape the screescreen all the time. A computer running X can handle the graphics in their entirety, leaving much more resources on the Pi to get things done.
Alas... way too many folks kind of tuned out of multi-user networked GUI capability and here we are with browsers, VNC and other kinds of things.
I don't have a Pi, but perhaps the applications people run on it are still X capable. If so, setting a display host might make running headless more effective. You just need an X server on your "head" machine. There are a few of those out there for the Windows PC, Linux has it just an install away, and Apple either ships it, or in recent releases, refers people to the open X server for OS X.
You may even get the Pi to present a login screen over X, in which case it then becomes trivial to do multiple things on a Pi, with efficient use of its RAM.
Either way, getting the graphics off the Pi could really improve it's overall performance.
As far as VNC goes, you might have luck running it in 8. Bit color to cut down on the massive data transfer requirements.
I came to the same conclusion. Except for the media player, I just ssh in to the RPi's with teraterm or minicom.
The idea of a "headless VNC" is nonsense. VNC requires that graphics is rendered on the server machine and then sent as some kind of compressed bit maps to the client. "Headless" would be more like an X application having it's GUI rendered on your local machine.
Let's face it, the Pi has the power of a PC running Linux back in 2000 or so. Nobody would have expected VNC to work well then.
However, the Pi has a GPU, it plays video very well. way in excess of that year 2000 PC.
Oh, and by the way the Pi can run propgcc and Simple IDE effortlessly. Want a self contained embedded system in some robot or other gizmo , a Pi and a Prop does that.
Honestly, a Pi running as an X server makes great sense! That way the GPU actually contributes nicely. (I know, ducking down now to let the veggies flying my way find an alternative landing...) Not sure what I would do with that, but I may do it one day, just for grins. Maybe get a CAD screen shot or something on a Pi desktop just to mess with people.
Re: Video. I had DVD resolution video in 2000. Matrox made a great set of cards, and one of them was the G400, and it offered up VGA or TV with the right cable. A 300Mhz Intel something or other with 128Mb RAM would blast full frame video perfectly all day long. That card could probably do 720p in the same way, on not much more given a source... I never tried it then. I used this: http://en.wikipedia.org/wiki/Ogle_DVD_Player and that was '02, but the machine was older, 2000 era e-machine something or other given to me to "tinker" with.
IMHO, just getting video done isn't that big of a deal. We've had it for quite some time. What that older PC could not do was higher level 3D graphics, lights, shaders, polys, textures and such. I could put Quake 3 Arena on it and play a reasonable game in 640x480, but anything more intense was just lost on it. A Pi, from what I can tell, does a whole lot more in that department...
VNC was reasonable in that time period, if you had 100-T networking, just FYI. I did it a lot around the 2000's, using an SGI for the VNC client. At one point, I had every machine in the place setup with VNC and the SGI scripted to display any one of them with a couple clicks on an icon. Spent a few weeks getting that all tuned in, but once it was done, doing IT / application support was cake. Seriously lean environment.