Nice first post. Did you think about asking for help? There are a lot of very experienced users out here, the education series from Parallax is top notch. The inability to understand your code can go with learning any new language and Spin is different. If you can't get going with Spin then there are several standard languages available that work very well with the Prop.
Like you I came to the Prop with several years of professional programming experience and have dealt with many languages. Spin was easier to learn than most but it accomplishes the job. I agree that the Prop isn't always the right answer but many times it can make a potentially difficult issue much easier depending on how the 8 cores are utilized.
I wish you luck in the future, ask questions and learn along with the rest of us here. I've seen some uses for the Prop that are simply amazing!
They are intended for somewhat different markets, of course. The Arduino was developed for use by artists and design students, with no embedded design experience.
I would partly disagree with Leon in that, having used both, I found the Propeller easier to use, not necessarily more expensive, and definitely not faster for development ... and I've used lots of different instruction sets, programming languages, etc. over the years. On the other hand, the Propeller can't be used with the existing Arduino development environment and classes, books, and existing libraries of sample code for the Arduino can't be used with the Propeller.
Regarding comparisons ... it's like apples and oranges. They're both fruit, but they're used differently. You can compare them, but it's not very meaningful because the differences in how they might be used matter a lot.
When I first discovered microcontrollers, I started learning with the BS2, and then as I wanted to start building equipment, I did some research before finally settling with the Propeller chip because of it's capabilities. So these two are actually the only two that I have ever fiddled with. Could you please give me an example or two when it might be beneficial to use Arduino instead?
I am not about to jump ship now, but I am curious when the competitors product might be more useful for development.
@Fernand - Yep, you are right. The propeller chip isn't really for beginners.
More educational material needs to be developed for it.
Parallax has done a good job supporting it considering how small they are and their company history - go look at their about page for more information.
While getting started with the propeller is harder. You'll find it is much more powerful than the Ardunio and can do alot of interesting things all at once.
Thanks for the replies. I should clarify perhaps, as I didn't mean to sound as angry as I was. I don't have the least problem with SPIN or any other language. SPIN is fine. But I don't think example code should take pride in being "optimized" at the expense of clarity. I don't have the least problem reading schematics or timing diagrams. I don't think the Propeller is more complicated, it's simpler than the ATMegas. I clearly see what the Propeller architecture is capable of. But I resent the $@%^ out of being FORCED to do so much digging to get going, to make a hobby out of using what should be, and is supposed to be, a platform. So if it's just a chip, that a few disconnected people made "reference boards" for, let's not call it an Arduino competitor, it's just a chip. If the debugger is supposed to be THE tool, then in the last few years Parallax should have helped get that app and its docs to a more pro level. Somehow the Arduino people did.
What Martin did with the ASC is the first sensible board I could see. Would Hanno object to getting some people's help with ViewPort and its docs?
One thing I agree with Fernand about is the code. Spin has a lot of clever features but none of them should be seen in the example programs unless really important. A lot of the objects lack comments and I would have found that helpful when learning.
Exactly, I saw a Parallax page where someone proudly showed how he had turned perfectly legible SPIN code into 3 am gobbledygook FORTH code - he called it "optimized" - and for what? Any professional programmer knows how costly it is to maintain cryptic code. I've had to fire coders who couldn't resist writing in "one line does everything" fashion, and took pride in how clever a riddle it was. My concern is that it's a mind set, incurable. I hope I'm wrong, as the Propeller deserves better.
When I first discovered microcontrollers, I started learning with the BS2, and then as I wanted to start building equipment, I did some research before finally settling with the Propeller chip because of it's capabilities. So these two are actually the only two that I have ever fiddled with. Could you please give me an example or two when it might be beneficial to use Arduino instead?
I am not about to jump ship now, but I am curious when the competitors product might be more useful for development.
Bruce
Just look at some Arduino code, and the vast number of shields (add-on boards) that are available, and the software libraries. There are also 32-bit Arduinos with 80 MHz PIC32 devices, which will outperform many Propeller systems.
One thing I agree with Fernand about is the code. Spin has a lot of clever features but none of them should be seen in the example programs unless really important. A lot of the objects lack comments and I would have found that helpful when learning.
How does any of this differ from the Arduino? I often look at Arduino examples and think to myself, "What kind of drugs is this programmer on while writing this big mess?" And the Arduino IDE? Complete Smile. Yes, there is a lot of bad code in the Object Exchange but that will happen in a "free" society. Again, same holds true for the Arduino.
In terms of programming, neither is better or worse, Spin and C are simply languages designed to do a task. In the hands of a competent programmer, both can be used to produce clean, elegant, easy-to-maintain listings. In the hands of an amateur, both can be used to produce junk.
And let us keep in mind that it is C programmers above all who love to write code that nobody else can understand. Frankly, this happens a lot -- though not deliberately -- in the Arduino world given most people that migrate to the Arduino don't want to be bothered to learn proper programming or electronics. That last part I don't understand: Why would one get involved in embedded programming without wanting to understand the fundamentals of the circuits they're ultimately controlling?....
On sheer horsepower, there is no comparison: the Propeller beats the Arduino like a bad habit.
With your vast experience, you are certainly a welcome asset to contribute to the community with properly structured and commented programming examples in SPIN, PASM or using the new PROPGCC C compiler. This effort is underway and will be entering the Beta testing stage soon. If in your 25 years, you've had IDE experience, they would certainly entertain your input on that effort.
The community is always open to someone who can bring something positive to the Forums especially when it can be drawn from 25 years of hardware and software experience.
Many of the OBEX code and examples have been crafted by very skilled Propeller programmers and have been optimized to the point where they squeeze the highest possible performance and resource utilization of the Propeller. Many of the OBEX entries are not of this quality. That is a problem with any code collection with similar origins.
Your energies spent toward the Propeller and the community can be either positive or negative and in the end what you will be either better or worse for what you take away and the community will be either stronger or unchanged.
If you find a passion or interest here, fantastic, let that passion drive your contributions!
Wow.. Having part of the Internet down today sure has made people cranky..
First off all.. Welcome to the forums.. There is a broad range of experience here and many willing folks who are happy to answer questions anytime you are stuck with something. Yes, the code is different from what you will have experienced on a PC, or the Ardunio. It has many strengths and a few weaknesses, but does provide a LOT of flexibility that just isn't there on other micros. I like to think of Spin code a clay which can be molded quickly to anything I can think of! It's growing object library means that I can do incrediable projects without re-inventing the wheel. As for looking back six months later and wondering "who wrote this Smile??!", I have tended to do that with almost every language I've ever written in, (I think Perl was the worst), but sooner or later your brain will start "thinking" in Spin and it isn't hard to follow the code once that happens.
Discussions like this are actually NOT typical of these forums, with most energy here being positive and helpful, but certainly there is room for open for friendly debate and discussion.
Wow.. Having part of the Internet down today sure has made people cranky..
What part of the internet is down today? It's working fine for me. If you're referring to the Wikipedia "blackout", just hit the browser stop button before it re-directs you to its blackout page.
As far as Arduino vs Propeller, with GCC we can run Arduino code on the Prop now. All you need to do is write a few library routines and run it on Martin Hodge's ASC board.
Parallax is working on a whole new set of education material for the Prop. It's going hand in hand with the PropBOE release. There's a bunch of stuff that is just released or about to be released that will go a long way in helping with beginners to the Propeller world. http://learn.parallax.com will be available soon (might be when you read this). There's also this site: https://sites.google.com/site/parallaxinretailstores/home which contains a TON of great info including breadboarding diagrams and source code for using lots of Parallax sensors and other products with Propeller and Arduino. So you can see and compare them. If you haven't already you should check out the links in Jeff's (OldBitCollector) signature on his posts. Especially the one called "Cool projects & easy tutorials" it's awesome stuff to get started with. Finally, some friends of mine (and myself) are doing a podcast that is for beginners of the Propeller here: http://www.firstspin.tv
As a hardware/software guy with 25+ years experience, I just got an Arduino Uno board at Fry's and a Parallax QuickStart at Radio Shack. Although I got LEDs flashing on both within a couple hours, there's a world of difference in the usability of the two. If someone wants to get to a working gizmo as fast as possible, and the gizmo is a simple device that could be done with a hundred gates or relays or whatever, then there is no contest: Arduino wins by miles. The reason is in the approach that is evident in the code samples. The Arduino code is plain old C code, but what matters is it's legible code. The Parallax SPIN code is garbage code. I don't mean the language. It's the kind of code you write one night and a few weeks later you can't figure out what's going on. It's the kind of code you fire programmers for. And the hits keep on coming, second verse, same as the first. The hardware support is not standardized, no effort went into creating a platform, attracting users. There are now some Arduino compatible boards, but my Quickstart is compatible with nothing except remedial boards I can buy to try to make it fit other uses. That "Premier" debugging environment, ViewPoint, is a beauty. I fell in love. And then I realized it did nothing automatically, I'll have to instrument my code to see variables, and any programmer will tell you that's how you introduce new problems. But that's academic, as it doesn't work, it reads an old config file over and over, the docs are bad, and I can't get it to do anything except to load its own demo samples. I tried the developer's forum. Nobody's been on there in a while. I'm back to inserting printf statements. I'm out of love, frustrated and angry that the fate of a beautiful chip like the Propeller is in the hands of cowboys who think leaping in to reverse engineer a microwave oven is a natural way to eat breakfast. I don't find riddles and headaches fun any more. If I want to study the details, I'll come back when I have nothing better to do, but in the meantime I want results. Today. Anybody who'd recommend the Propeller for a beginner class deserves what the students will do to him.
Welcome to the forums.
Hope you will give the Propeller a second chance with the new tools coming out.
One thing that was not mentioned was PropBasic, and the ability to generate PASM code from Basic syntax. See this thread
There are good things and not so good things about both platforms. Much to like about both. If I were designing a product for commercial resale I'd definitely use a Propeller, I can get more bang for the buck out of it. (I realize you wouldn't use an Arduino for a commercial product, but you might base on an ATmega328, and so the hardware pros and cons are still there.)
As a writer of magazine articles for the DIY crowd, the Arduino is what the editors want, and it's a good platform for attaching pre-made modules to. Readers like it. The language is simplified, and hides (yes, hides) a lot of the thorny things you have to deal with if you're writing in GCC.
The Propeller is my preference for robotics because I'm getting eight processors for the price of one. Like the TVOut example in the blog Roy pointed to, I'm always hitting against hardware limits -- Timer1 in an Arduino is used for PWM on pins 9 and 10, the servo library, and many other things. Unless you're using a Mega board, which has more timers, more hardware interrupts, and more hardware UARTs, many projects become a matter of compromise.
But I also understand Fernand's comments. There are many great Prop examples and demos, but maybe not as many as the Arduino, so the Prop has had a tougher time gaining the hearts and minds of users. As Roy says, however, this is rapidly changing. Knowing just a few of Parallax's plans I see going forward much renewed interest in the Prop.
On "dumbing down": This is merely a marketing method to capture the so-called reluctant reader. I somewhat disagree with the blog post Roy mentions in that it's not always practical or useful to detail everything about an electronic component every time you discuss it. Relevancy and scope are important in teaching. No good teacher will try to complicate a subject in a "101 level" class by attempting to cover everything. That's why we have 201, 301, and advanced courses. There's a time and place for everything. It's not about the teacher proving what he or she knows, but getting the information across to first-learners.
And yes, I co-wrote the first edition of Electronics for Dummies (the second edition retains my name, but that's for their marketing; I wasn't involved in the revision). I don't care either way about the Dummies title per se -- the original 'DOS for Dummies' was a simple play on alliteration -- but as an author I don't care for the format. I will tell you this: the top Dummies authors are MILLIONAIRES. I've never made much money with the couple of Dummies books I've written, but somebody must like these things. That has to equate to the books providing value for someone.
I understand the terms 'dummy' and 'idiot' may be offensive to some, but they certainly haven't harmed book sales. To shed some historical perspective, a writing partner and I pitched a series of books to IDG called "In a Day" the same time Dan Gookin was talking up what would become DOS for Dummies. Same first-learner market, similar tutorial/reference design, etc. I don't need to point out which series they went with. Apparently, some people like to be offended!
And let us keep in mind that it is C programmers above all who love to write code that nobody else can understand.
C programmers love to write code nobody can understand? Boy, isn't that a sweeping generalization?
You can write bad code that nobody can understand in any language, and I imagine you're singling out C because it is one of the most widely used languages, particularly in the embedded space. When anything is as widely used as C there will be a substantial amount of Smile written in it due to sheer numbers, but that doesn't mean the language encourages it. I've seen (and written) plenty of clear, easy to understand code in C, and it's no more difficult than doing it in any other language.
Being a new user myself, the code is a bit confusing. As I stick with it the code is getting translated better so now just glancing through it, seeing what is going on is easier.
With spin there seems to be multiple ways to achieve the same goal. This shows me that instead of being limited to a macro command that does a simple function, spin allows people to fine tune exactly what is going on.
Though many times a macro command would be nice to have. A servo command would have been really helpful.
With spin there seems to be multiple ways to achieve the same goal.
This can be said for virtually every programming language. We ultimately find our own style, and groups will agree on what's "best" and most efficient.
A servo command would have been really helpful.
As you point out, there are many ways to do things and as a servo command is simply a pulse sent every 20ms, it can be done in any number of ways. And as _most_ programs do not use servos, why burden the interpreter -- which barely fits in a cog, anyway -- with something that gets so little use?
I'll give you an example of two recent (professional projects) that use servos; each handled them differently:
1) Disneyland used a board I designed called the HC-8+ in the Haunted Mansion; specifically in the gingerbread cake for the 2012 Halloween season. I wrote a program that converted DMX input values to servo position and dimmer values for the board. In this case I used my servo object (you can find it in the Object Exchange).
2) I designed a remote focus/zoom controller for a Boston company. This project only uses two servos and is quite simple: read the ADC (two channels), filter the ADC values, convert to servo values and create the pulses. In this case the main loop of the program runs every 20ms and I create the pulses (using the counter modules) inline.
Flexibility is your friend; don't asked to be shackled because there are plenty of people who will happily do that for/to you. Once you understand the *goal* of a device you can best design the approach that gets you there.
Finally, is no servo command in the Arduino, either; you have to add a library (which is complicated because it uses interrupts); with the Propeller you can use an object I dare say with Propeller objects you have a better chance customizing successfully when you need to. Interrupts are hell on new programmers which is why the Propeller doesn't have them.
As kids we skin up our knees while learn to run -- sadly, many new programmers are afraid of "skinned knees" and don't want to experience a little "pain" that would ultimately make them better programmers. Sheesh.... I'm showing my age.
As you point out, there are many ways to do things and as a servo command is simply a pulse sent every 20ms, it can be done in any number of ways. And as _most_ programs do not use servos, why burden the interpreter -- which barely fits in a cog, anyway -- with something that gets so little use?
I agree with this.
However, it's also possible to define libraries with C for example to define many API (Application Programming Interface) functions for peripherals such as Servos, serial devices, etc.... In the case of such libraries even when there are many generic functions, only the ones used by the program will be included (assuming a correctly assembled library). Libraries have advantages and disadvantages:
Advantages:
User API or ABI (Application Binary Interface) must be well defined.
Functions must be well defined and correctly described.
Every function in the library does not get included in the binary image.
Header declarations allow finding function parameter errors at compile time.
If done well, no one will complain about how complicated a function is.
User's won't see the implementation unless they need to see the source.
Disadvantages:
Requires more work and open source to adapt old code to new purposes.
Library version control is necessary for libraries not build from source every time.
Now, it is possible to provide Spin/PASM libraries, but it would be far more complicated than necessary to do so as we have seen in some threads.
Spin/PASM is designed to be shared at the source level - many of us like it like that, but it does require a certain competency and tolerance level for it to be useful.
However, it's also possible to define libraries with C for example to define many API (Application Programming Interface) functions for peripherals such as Servos, serial devices, etc.... In the case of such libraries even when there are many generic functions, only the ones used by the program will be included (assuming a correctly assembled library). Libraries have advantages and disadvantages:
Advantages:
User API or ABI (Application Binary Interface) must be well defined.
Functions must be well defined and correctly described.
Every function in the library does not get included in the binary image.
Header declarations allow finding function parameter errors at compile time.
If done well, no one will complain about how complicated a function is.
User's won't see the implementation unless they need to see the source.
Disadvantages:
Requires more work and open source to adapt old code to new purposes.
Library version control is necessary for libraries not build from source every time.
Now, it is possible to provide Spin/PASM libraries, but it would be far more complicated than necessary to do so as we have seen in some threads.
Spin/PASM is designed to be shared at the source level - many of us like it like that, but it does require a certain competency and tolerance level for it to be useful.
I'm going to be pedantic on A.3 and D.2. If you are linking against a static library, it will only include the .o that is needed, but with dynamic libraries, it gets the whole lot.
Under the Arduino when a function isn't referenced none of the related object code is compiled in, so it wouldn't even matter if Servo were not an optional library. There would be no overhead unless you at a minimum used the Servo constructor. But I think they provide it as an included library rather than a built-in function because they realized the "standard" implementation isn't for everyone. I think it's the fact that the library is included, and is visible in a pull-down menu, that's the main point here.
The Prop Tool comes with numerous objects that, because they are also included, become the default. Unless I put them there and forgot, the Servo32v7.spin and Ramp files are in my Propeller Tool Library directory. So they're there already, but not many people know it. You need to go to the Librarydirectory to see what's there. The program doesn't offer them as self-discoverable choices.
In the end it's a matter of the user interface, and not the core design of either platform. The Arduino IDE packages things a little neater, and leaves less to chance (chance that first-learners will find things). The Arduino examples, also a pull-down menu away, are a critical part of the learning curve. There's less assumption you'll somehow find things. Anyway, I'm hoping whatever new version of the Propeller Tool that's developed has similar features.
I'm going to be pedantic on A.3 and D.2. If you are linking against a static library, it will only include the .o that is needed, but with dynamic libraries, it gets the whole lot.
Yes, you are absolutely correct However Propeller GCC for example does not support dynamic libraries.
Gordon, I've discussed the idea of pull-down menu devices with Ken and Propeller GCC is designed to support it; however, that will not make it into Beta.
As I point out in my other post there's already a fairly standardized servo object, and it's pretty easy to use. It's just not as "out there" as the reference to the Servo object under the Arduino IDE.
But what I really wanted to point out is that under the Arduino it takes a lot of work to provide speed control of the servos. Their demo sketch uses delays, which are okay for demos but death for most any practical sketch. You have to add in a timer that helps to increment the movement. While not really complex, the code is more than what most first-timers with the Arduino can handle.
The "standard" servo object for the Propeller, on the other hand, has this built in. You can make the servo move at its normal speed, or slow it down to a crawl, just by altering one of the parameters to the function call.
Not everyone needs to control the speed of the servo, but the Propeller makes this very simple to do, and it's part of the regular library most folks use for operating servos. Pretty nifty, and one cog will do a bazillion servos (not really, but it's more than the 12 in the Uno).
I started on the prop about 3 years ago. I have a little longer background in design and programming of micros, having started in 1976 with the MC6800. I had then been comercially programming in assembler for 2+ years, and hardware maintenance, on a mini-computer.
The hardest part back then was to find documentation on the prop. Much has changed since then. There are the stickies at the top of this forum and there is the example programs downloaded as part of the PropTool. Unfortunately, the PropTool is definately a lame development tool - its being re-written so that the source can be released. I think most of us outside Parallax agree that the decision not to release the source, as bad as it was claimed to be, hindered the prop severly. Many of us use bst which was written by Brad Campbell. It runs on PC, *nix, Mac and has optional compiler directives.
There is no excuse for bad code. Like in any language, there are cryptic ways to do things and a lack of comments does not help. So in particular, spin and C are alike here! However, objects are often tuned for speed and so many of these horrid statements perform much faster. They just require better comments. However, you cannot force a donator of the free (MIT licence) software to put in the comments and who is going to take the time to re-publish someone elses code with comments.
Now, when we come to pasm (the prop assembler), often this code is self-contained. While it may not be documented well, it is usually written for speed. Usually, you will only have to interface via spin to it. As it is often self-contained in its own cog (processor core) it is a moot point in understanding how it works. There is a max code space of 496 instructions anyway. So, I have to say, this is not really a problem.
Next, because the prop does not have interrupts, it is not usually necessary to fully understand anyone elses objects that you may use.
So, now we can get to the props advantages. We have 8 cores (we call them cogs) to run with. As they are self-contained objects, apart form the interface, the user software becomes easier. This is not fully evident initially, unless you have worked with multi-processors before. The mini I worked on in the early 70's onwards was a multiprocessor, although it was hardware time sliced, and has a lot of similarities with the prop. So, I can see all the advantages of the prop.
I am not a C programmer because I hate the C shortcut structures. I much preferred VB3-VB6 because it was more readable. WIth that out of the way, let me tell you about my experience with the AVR family (ATtiny family).
I wrote a very simple program to get a LED to flash because I wanted to verify I was programming the ATtiny84 correctly - I used a prop to program it as I dont have an AVR programmer. No go!!! I do not recall which of the 2 AVR compilers I used, but the delay routine did not work!!! Of course I blamed my programming code in the prop. Eventually I put a manual asm loop in my avr code and my led came to life. And I will not tell you how much I hate the AVR compilers because I dont know what they are doing. This will be the same with GCC for the prop. If I back down to just use assembler on the avr then I have an eterneties worth of registers to setup that I dont with the prop.
So, while I am using the ATTiny84 for a few simple projects where the cost matters, my overall choice is the prop because with the one chip I can do anything from 16 UARTs to uarts/spi/i2c, vga, tv (composite video), combinations of them, and almost on any pins. Perhaps this is why we didnt have an arduino type platform - because the prop is so flexible - we used the protoboards initially. And now we build custom boards for the projects we want.
The arduino created a position because it made a platform from which all sorts of add-ons can be plugged in. Not because of the underlying micro. Same as the IBM PC - I think everyone in the know realises that IBM should have used the MC68000 family but they could not buy a piece of Motorola and they did buy a piece of Intel.
"Flexibility is your friend; don't asked to be shackled because there are plenty of people who will happily do that for/to you. "
"Interrupts are hell on new programmers which is why the Propeller doesn't have them."
I can't resist putting your two statements from the same message next to each other. I'm not sure anything but blind faith in the Propeller can allow these two concepts to coexist. So which is it?
It's great that there's a community of true believers, though sincerely and regretfully I don't have the time at the moment to participate on a "positive" level. The reason for my initial post was to give the propeller community the (perhaps valuable) untainted first reaction of someone who's approaching the two leading options for board-level controllers.
As I understand the Propeller has come a long way towards "openness". And with the Prop ASC may be at last having a "stable home" that can interface with the many ready-made shields on the market. Is there a Propeller something like the Arduino nanos, very small size, cheap, say $25 ea, if I need to make 6 units of a device?
Say I want a cluster of linked fishtank monitors for my rec room. Need A/Ds for temp and light sensors, some PWM or D/A outs, general I/O, USB port to program it, serial. I would make a device without an additional circuit board, just solder some parts and wires to a nano, wrap it in tape or pot it with hot glue or caulking if I don't plan to ever re-use the parts, and house it inside some corner of another enclosure, so I'd far prefer very small, not a full-sized shield. THATs a good market, in time, I would think, for normal smart people to be able to be creative in covering their day to day needs, sort of like reaching in the parts box for some wall switches, nuts and bolts. In dealing with my fish-tanks I'd likely find I only have a couple nanos in the drawer, so I'd drive down to get a half dozen blister-pack nanos at the hardware store. That's how innovation will blossom. Not just pros designing toaster ovens to be made in thousands, or hobbyists assembling YARKs (Yet Another Robot Kit).
It's perhaps unfortunate the Propeller board that Radio Shack distributes is the not so cheap and not so effective QuickStart. But at least I got one. Downloaded the software and was blinking LEDs within the hour. But when I got into more sample code, and found that different examples expected LEDs on different pins so every example had to be edited, and then wasted two days on the promise of ViewPort, I felt like I had walked back in time, to when everything was uphill. Almost all programming languages share core syntactical features. SPIN can and should look much like C and BASIC and Delphi and Java. Good startup example code really should only use the most common constructs. Why? Because then it CAN be immediately comprehensible to EVERYBODY who's ever learned ANY language. That way the user can quickly learn what is truly specific to a given environment. The cute features belong in "advanced" tutorials.
Question: Does anybody know whether in ViewPort just putting vp: "Conduit" in my app's OBJ block and then a vp.share(@var1, @var2) in the PUB main block is sufficient to create two working "channels"? I get nothing. It's stuck reading a previous config it seems.
I don't think the the statement "Interrupts are hell on new programmers which is why the Propeller doesn't have them." is correct.
I think it's better to say that the Propeller is architected in such a way that it doesn't need or use interrupts. You can do the same sorts of things you might use an interrupt for on the propeller in simpler ways.
When comparing the "Propeller" to the "Ardunio", you are comparing Apples to Oranges.. One is a chip, the other a system.
The Propeller Quickstart board was originally created as an inexpensive demonstration product for engineers to review using the Propeller for possible use in their own designs. It was later re-tasked to Radio Shack as it's price made it possible to get it in the stores. As for a "shield" based system, I'd invite you to look at the Propeller Platform which is more like Ardunio, except with a Propeller in the core board instead of an Atmel processor.
It's great that there's a community of true believers, though sincerely and regretfully I don't have the time at the moment to participate on a "positive" level.
Ok, guilty as charged, the Propeller does have a fine group of folks who use it. It won't be the answer for everyone, and certainly won't be the answer for every project, but there are a number of things it does exceptionally well, but as they say "Different strokes for different folks.." If you decide you have time later to re-evaluate the Propeller board for uses to which it excels, you'll find plenty of support here.
Comments
Like you I came to the Prop with several years of professional programming experience and have dealt with many languages. Spin was easier to learn than most but it accomplishes the job. I agree that the Prop isn't always the right answer but many times it can make a potentially difficult issue much easier depending on how the 8 cores are utilized.
I wish you luck in the future, ask questions and learn along with the rest of us here. I've seen some uses for the Prop that are simply amazing!
Hi Mike, I hope all is well with you.
Regarding one of your comments:
When I first discovered microcontrollers, I started learning with the BS2, and then as I wanted to start building equipment, I did some research before finally settling with the Propeller chip because of it's capabilities. So these two are actually the only two that I have ever fiddled with. Could you please give me an example or two when it might be beneficial to use Arduino instead?
I am not about to jump ship now, but I am curious when the competitors product might be more useful for development.
Bruce
More educational material needs to be developed for it.
Parallax has done a good job supporting it considering how small they are and their company history - go look at their about page for more information.
While getting started with the propeller is harder. You'll find it is much more powerful than the Ardunio and can do alot of interesting things all at once.
What Martin did with the ASC is the first sensible board I could see. Would Hanno object to getting some people's help with ViewPort and its docs?
Graham
Just look at some Arduino code, and the vast number of shields (add-on boards) that are available, and the software libraries. There are also 32-bit Arduinos with 80 MHz PIC32 devices, which will outperform many Propeller systems.
How does any of this differ from the Arduino? I often look at Arduino examples and think to myself, "What kind of drugs is this programmer on while writing this big mess?" And the Arduino IDE? Complete Smile. Yes, there is a lot of bad code in the Object Exchange but that will happen in a "free" society. Again, same holds true for the Arduino.
In terms of programming, neither is better or worse, Spin and C are simply languages designed to do a task. In the hands of a competent programmer, both can be used to produce clean, elegant, easy-to-maintain listings. In the hands of an amateur, both can be used to produce junk.
And let us keep in mind that it is C programmers above all who love to write code that nobody else can understand. Frankly, this happens a lot -- though not deliberately -- in the Arduino world given most people that migrate to the Arduino don't want to be bothered to learn proper programming or electronics. That last part I don't understand: Why would one get involved in embedded programming without wanting to understand the fundamentals of the circuits they're ultimately controlling?....
On sheer horsepower, there is no comparison: the Propeller beats the Arduino like a bad habit.
Welcome to the Forums!
With your vast experience, you are certainly a welcome asset to contribute to the community with properly structured and commented programming examples in SPIN, PASM or using the new PROPGCC C compiler. This effort is underway and will be entering the Beta testing stage soon. If in your 25 years, you've had IDE experience, they would certainly entertain your input on that effort.
The community is always open to someone who can bring something positive to the Forums especially when it can be drawn from 25 years of hardware and software experience.
Many of the OBEX code and examples have been crafted by very skilled Propeller programmers and have been optimized to the point where they squeeze the highest possible performance and resource utilization of the Propeller. Many of the OBEX entries are not of this quality. That is a problem with any code collection with similar origins.
Your energies spent toward the Propeller and the community can be either positive or negative and in the end what you will be either better or worse for what you take away and the community will be either stronger or unchanged.
If you find a passion or interest here, fantastic, let that passion drive your contributions!
First off all.. Welcome to the forums.. There is a broad range of experience here and many willing folks who are happy to answer questions anytime you are stuck with something. Yes, the code is different from what you will have experienced on a PC, or the Ardunio. It has many strengths and a few weaknesses, but does provide a LOT of flexibility that just isn't there on other micros. I like to think of Spin code a clay which can be molded quickly to anything I can think of! It's growing object library means that I can do incrediable projects without re-inventing the wheel. As for looking back six months later and wondering "who wrote this Smile??!", I have tended to do that with almost every language I've ever written in, (I think Perl was the worst), but sooner or later your brain will start "thinking" in Spin and it isn't hard to follow the code once that happens.
Discussions like this are actually NOT typical of these forums, with most energy here being positive and helpful, but certainly there is room for open for friendly debate and discussion.
OBC
As far as Arduino vs Propeller, with GCC we can run Arduino code on the Prop now. All you need to do is write a few library routines and run it on Martin Hodge's ASC board.
This blog entry by Mark VandeWettering sums up my biggest complaint with Arduino: http://brainwagon.org/2012/01/14/the-downside-of-arduino/
I, also, strongly agree with his very next blog entry, which also applies: http://brainwagon.org/2012/01/14/a-phrase-i-dont-like-dumbing-down/
Parallax is working on a whole new set of education material for the Prop. It's going hand in hand with the PropBOE release. There's a bunch of stuff that is just released or about to be released that will go a long way in helping with beginners to the Propeller world. http://learn.parallax.com will be available soon (might be when you read this). There's also this site: https://sites.google.com/site/parallaxinretailstores/home which contains a TON of great info including breadboarding diagrams and source code for using lots of Parallax sensors and other products with Propeller and Arduino. So you can see and compare them. If you haven't already you should check out the links in Jeff's (OldBitCollector) signature on his posts. Especially the one called "Cool projects & easy tutorials" it's awesome stuff to get started with. Finally, some friends of mine (and myself) are doing a podcast that is for beginners of the Propeller here: http://www.firstspin.tv
What would you consider acceptable in these areas with respect to Propeller?
Welcome to the forums.
Hope you will give the Propeller a second chance with the new tools coming out.
One thing that was not mentioned was PropBasic, and the ability to generate PASM code from Basic syntax. See this thread
Jim
As a writer of magazine articles for the DIY crowd, the Arduino is what the editors want, and it's a good platform for attaching pre-made modules to. Readers like it. The language is simplified, and hides (yes, hides) a lot of the thorny things you have to deal with if you're writing in GCC.
The Propeller is my preference for robotics because I'm getting eight processors for the price of one. Like the TVOut example in the blog Roy pointed to, I'm always hitting against hardware limits -- Timer1 in an Arduino is used for PWM on pins 9 and 10, the servo library, and many other things. Unless you're using a Mega board, which has more timers, more hardware interrupts, and more hardware UARTs, many projects become a matter of compromise.
But I also understand Fernand's comments. There are many great Prop examples and demos, but maybe not as many as the Arduino, so the Prop has had a tougher time gaining the hearts and minds of users. As Roy says, however, this is rapidly changing. Knowing just a few of Parallax's plans I see going forward much renewed interest in the Prop.
-- Gordon
And yes, I co-wrote the first edition of Electronics for Dummies (the second edition retains my name, but that's for their marketing; I wasn't involved in the revision). I don't care either way about the Dummies title per se -- the original 'DOS for Dummies' was a simple play on alliteration -- but as an author I don't care for the format. I will tell you this: the top Dummies authors are MILLIONAIRES. I've never made much money with the couple of Dummies books I've written, but somebody must like these things. That has to equate to the books providing value for someone.
I understand the terms 'dummy' and 'idiot' may be offensive to some, but they certainly haven't harmed book sales. To shed some historical perspective, a writing partner and I pitched a series of books to IDG called "In a Day" the same time Dan Gookin was talking up what would become DOS for Dummies. Same first-learner market, similar tutorial/reference design, etc. I don't need to point out which series they went with. Apparently, some people like to be offended!
-- Gordon
C programmers love to write code nobody can understand? Boy, isn't that a sweeping generalization?
You can write bad code that nobody can understand in any language, and I imagine you're singling out C because it is one of the most widely used languages, particularly in the embedded space. When anything is as widely used as C there will be a substantial amount of Smile written in it due to sheer numbers, but that doesn't mean the language encourages it. I've seen (and written) plenty of clear, easy to understand code in C, and it's no more difficult than doing it in any other language.
With spin there seems to be multiple ways to achieve the same goal. This shows me that instead of being limited to a macro command that does a simple function, spin allows people to fine tune exactly what is going on.
Though many times a macro command would be nice to have. A servo command would have been really helpful.
This can be said for virtually every programming language. We ultimately find our own style, and groups will agree on what's "best" and most efficient.
As you point out, there are many ways to do things and as a servo command is simply a pulse sent every 20ms, it can be done in any number of ways. And as _most_ programs do not use servos, why burden the interpreter -- which barely fits in a cog, anyway -- with something that gets so little use?
I'll give you an example of two recent (professional projects) that use servos; each handled them differently:
1) Disneyland used a board I designed called the HC-8+ in the Haunted Mansion; specifically in the gingerbread cake for the 2012 Halloween season. I wrote a program that converted DMX input values to servo position and dimmer values for the board. In this case I used my servo object (you can find it in the Object Exchange).
2) I designed a remote focus/zoom controller for a Boston company. This project only uses two servos and is quite simple: read the ADC (two channels), filter the ADC values, convert to servo values and create the pulses. In this case the main loop of the program runs every 20ms and I create the pulses (using the counter modules) inline.
Flexibility is your friend; don't asked to be shackled because there are plenty of people who will happily do that for/to you. Once you understand the *goal* of a device you can best design the approach that gets you there.
Finally, is no servo command in the Arduino, either; you have to add a library (which is complicated because it uses interrupts); with the Propeller you can use an object I dare say with Propeller objects you have a better chance customizing successfully when you need to. Interrupts are hell on new programmers which is why the Propeller doesn't have them.
As kids we skin up our knees while learn to run -- sadly, many new programmers are afraid of "skinned knees" and don't want to experience a little "pain" that would ultimately make them better programmers. Sheesh.... I'm showing my age.
I agree with this.
However, it's also possible to define libraries with C for example to define many API (Application Programming Interface) functions for peripherals such as Servos, serial devices, etc.... In the case of such libraries even when there are many generic functions, only the ones used by the program will be included (assuming a correctly assembled library). Libraries have advantages and disadvantages:
Advantages:
- User API or ABI (Application Binary Interface) must be well defined.
- Functions must be well defined and correctly described.
- Every function in the library does not get included in the binary image.
- Header declarations allow finding function parameter errors at compile time.
- If done well, no one will complain about how complicated a function is.
- User's won't see the implementation unless they need to see the source.
Disadvantages:- Requires more work and open source to adapt old code to new purposes.
- Library version control is necessary for libraries not build from source every time.
Now, it is possible to provide Spin/PASM libraries, but it would be far more complicated than necessary to do so as we have seen in some threads.Spin/PASM is designed to be shared at the source level - many of us like it like that, but it does require a certain competency and tolerance level for it to be useful.
I'm going to be pedantic on A.3 and D.2. If you are linking against a static library, it will only include the .o that is needed, but with dynamic libraries, it gets the whole lot.
The Prop Tool comes with numerous objects that, because they are also included, become the default. Unless I put them there and forgot, the Servo32v7.spin and Ramp files are in my Propeller Tool Library directory. So they're there already, but not many people know it. You need to go to the Librarydirectory to see what's there. The program doesn't offer them as self-discoverable choices.
In the end it's a matter of the user interface, and not the core design of either platform. The Arduino IDE packages things a little neater, and leaves less to chance (chance that first-learners will find things). The Arduino examples, also a pull-down menu away, are a critical part of the learning curve. There's less assumption you'll somehow find things. Anyway, I'm hoping whatever new version of the Propeller Tool that's developed has similar features.
-- Gordon
Gordon, I've discussed the idea of pull-down menu devices with Ken and Propeller GCC is designed to support it; however, that will not make it into Beta.
As I point out in my other post there's already a fairly standardized servo object, and it's pretty easy to use. It's just not as "out there" as the reference to the Servo object under the Arduino IDE.
But what I really wanted to point out is that under the Arduino it takes a lot of work to provide speed control of the servos. Their demo sketch uses delays, which are okay for demos but death for most any practical sketch. You have to add in a timer that helps to increment the movement. While not really complex, the code is more than what most first-timers with the Arduino can handle.
The "standard" servo object for the Propeller, on the other hand, has this built in. You can make the servo move at its normal speed, or slow it down to a crawl, just by altering one of the parameters to the function call.
Not everyone needs to control the speed of the servo, but the Propeller makes this very simple to do, and it's part of the regular library most folks use for operating servos. Pretty nifty, and one cog will do a bazillion servos (not really, but it's more than the 12 in the Uno).
-- Gordon
I started on the prop about 3 years ago. I have a little longer background in design and programming of micros, having started in 1976 with the MC6800. I had then been comercially programming in assembler for 2+ years, and hardware maintenance, on a mini-computer.
The hardest part back then was to find documentation on the prop. Much has changed since then. There are the stickies at the top of this forum and there is the example programs downloaded as part of the PropTool. Unfortunately, the PropTool is definately a lame development tool - its being re-written so that the source can be released. I think most of us outside Parallax agree that the decision not to release the source, as bad as it was claimed to be, hindered the prop severly. Many of us use bst which was written by Brad Campbell. It runs on PC, *nix, Mac and has optional compiler directives.
There is no excuse for bad code. Like in any language, there are cryptic ways to do things and a lack of comments does not help. So in particular, spin and C are alike here! However, objects are often tuned for speed and so many of these horrid statements perform much faster. They just require better comments. However, you cannot force a donator of the free (MIT licence) software to put in the comments and who is going to take the time to re-publish someone elses code with comments.
Now, when we come to pasm (the prop assembler), often this code is self-contained. While it may not be documented well, it is usually written for speed. Usually, you will only have to interface via spin to it. As it is often self-contained in its own cog (processor core) it is a moot point in understanding how it works. There is a max code space of 496 instructions anyway. So, I have to say, this is not really a problem.
Next, because the prop does not have interrupts, it is not usually necessary to fully understand anyone elses objects that you may use.
So, now we can get to the props advantages. We have 8 cores (we call them cogs) to run with. As they are self-contained objects, apart form the interface, the user software becomes easier. This is not fully evident initially, unless you have worked with multi-processors before. The mini I worked on in the early 70's onwards was a multiprocessor, although it was hardware time sliced, and has a lot of similarities with the prop. So, I can see all the advantages of the prop.
I am not a C programmer because I hate the C shortcut structures. I much preferred VB3-VB6 because it was more readable. WIth that out of the way, let me tell you about my experience with the AVR family (ATtiny family).
I wrote a very simple program to get a LED to flash because I wanted to verify I was programming the ATtiny84 correctly - I used a prop to program it as I dont have an AVR programmer. No go!!! I do not recall which of the 2 AVR compilers I used, but the delay routine did not work!!! Of course I blamed my programming code in the prop. Eventually I put a manual asm loop in my avr code and my led came to life. And I will not tell you how much I hate the AVR compilers because I dont know what they are doing. This will be the same with GCC for the prop. If I back down to just use assembler on the avr then I have an eterneties worth of registers to setup that I dont with the prop.
So, while I am using the ATTiny84 for a few simple projects where the cost matters, my overall choice is the prop because with the one chip I can do anything from 16 UARTs to uarts/spi/i2c, vga, tv (composite video), combinations of them, and almost on any pins. Perhaps this is why we didnt have an arduino type platform - because the prop is so flexible - we used the protoboards initially. And now we build custom boards for the projects we want.
The arduino created a position because it made a platform from which all sorts of add-ons can be plugged in. Not because of the underlying micro. Same as the IBM PC - I think everyone in the know realises that IBM should have used the MC68000 family but they could not buy a piece of Motorola and they did buy a piece of Intel.
Sorry for my rambling. But, the prop rules IMHO.
I can't resist putting your two statements from the same message next to each other. I'm not sure anything but blind faith in the Propeller can allow these two concepts to coexist. So which is it?
It's great that there's a community of true believers, though sincerely and regretfully I don't have the time at the moment to participate on a "positive" level. The reason for my initial post was to give the propeller community the (perhaps valuable) untainted first reaction of someone who's approaching the two leading options for board-level controllers.
As I understand the Propeller has come a long way towards "openness". And with the Prop ASC may be at last having a "stable home" that can interface with the many ready-made shields on the market. Is there a Propeller something like the Arduino nanos, very small size, cheap, say $25 ea, if I need to make 6 units of a device?
http://solderslingers.com/cart/index.php?main_page=product_info&products_id=246&zenid=c13c77cf2d5796900aaa1454b6dd53a0
Say I want a cluster of linked fishtank monitors for my rec room. Need A/Ds for temp and light sensors, some PWM or D/A outs, general I/O, USB port to program it, serial. I would make a device without an additional circuit board, just solder some parts and wires to a nano, wrap it in tape or pot it with hot glue or caulking if I don't plan to ever re-use the parts, and house it inside some corner of another enclosure, so I'd far prefer very small, not a full-sized shield. THATs a good market, in time, I would think, for normal smart people to be able to be creative in covering their day to day needs, sort of like reaching in the parts box for some wall switches, nuts and bolts. In dealing with my fish-tanks I'd likely find I only have a couple nanos in the drawer, so I'd drive down to get a half dozen blister-pack nanos at the hardware store. That's how innovation will blossom. Not just pros designing toaster ovens to be made in thousands, or hobbyists assembling YARKs (Yet Another Robot Kit).
It's perhaps unfortunate the Propeller board that Radio Shack distributes is the not so cheap and not so effective QuickStart. But at least I got one. Downloaded the software and was blinking LEDs within the hour. But when I got into more sample code, and found that different examples expected LEDs on different pins so every example had to be edited, and then wasted two days on the promise of ViewPort, I felt like I had walked back in time, to when everything was uphill. Almost all programming languages share core syntactical features. SPIN can and should look much like C and BASIC and Delphi and Java. Good startup example code really should only use the most common constructs. Why? Because then it CAN be immediately comprehensible to EVERYBODY who's ever learned ANY language. That way the user can quickly learn what is truly specific to a given environment. The cute features belong in "advanced" tutorials.
Question: Does anybody know whether in ViewPort just putting vp: "Conduit" in my app's OBJ block and then a vp.share(@var1, @var2) in the PUB main block is sufficient to create two working "channels"? I get nothing. It's stuck reading a previous config it seems.
I think it's better to say that the Propeller is architected in such a way that it doesn't need or use interrupts. You can do the same sorts of things you might use an interrupt for on the propeller in simpler ways.
When comparing the "Propeller" to the "Ardunio", you are comparing Apples to Oranges.. One is a chip, the other a system.
The Propeller Quickstart board was originally created as an inexpensive demonstration product for engineers to review using the Propeller for possible use in their own designs. It was later re-tasked to Radio Shack as it's price made it possible to get it in the stores. As for a "shield" based system, I'd invite you to look at the Propeller Platform which is more like Ardunio, except with a Propeller in the core board instead of an Atmel processor.
Ok, guilty as charged, the Propeller does have a fine group of folks who use it. It won't be the answer for everyone, and certainly won't be the answer for every project, but there are a number of things it does exceptionally well, but as they say "Different strokes for different folks.." If you decide you have time later to re-evaluate the Propeller board for uses to which it excels, you'll find plenty of support here.
OBC