Whoever wrote the description was obviously not aware of all the boards that are available - several from Parallax, the Gadget Gangster boards, Wolfden, Rayslogic, etc. I expect there are probably at least as many different Propeller boards available as there are significant variations of Arduino boards (most Arduino boards are identical or very similar to the originals). I'm not counting generic AVR boards here, just the ones targeted at Arduino (not all of which look anything like the official boards).
Also, I can't figure out where the language being close to assembly comes from. Spin doesn't really look like any assembly I've ever dealt with. I assume that whoever was looking at this must have looked at spin code with embedded assembly. Either that or they are completely lost.
They’re ideas that usually wouldn’t actually happen, things we normally just dream about. But now these fantastic ideas are brought to life, and it’s very likely a non-engineer made them.
That’s a big deal because engineers tend to design platforms for other engineers, not for artists, weirdos, or kids who want to connect stuff up in a simple way to share an idea. The Arduino team is not made up of hardcore electrical engineers.
So basically, if you don't have time for a manual, there is a tutorial for whatever you want to do whereas the rest of the stuff is build for heavy readers.
Why would Make alienate part of their existing audience? (ie: customer base)
I'm pretty sure it's not just just us Propeller heads that are feeling stung by what is happening at Make, there are several other popular platforms that have firm ground and a user base. Seems like poor business sense to me. Mr. Torrone is shooting himself in the foot by writing articles like that.
I agree with some of his points. I disagree with others.
But, I don't feel particularly alienated.
I still think the thing to do is not to try and compete directly with Arduino. Nobody is going to be able to right now based on numbers alone (boards out there, number of people using them, and variety of posted/documented projects).
But there is no reason to compete.
If the Prop is going to become better known there need to be more things visible to the public. We don't want people to rely on the misinformation presented about the Propeller in the Make summary referenced above. I don't believe that Make was maliciously trying to misrepresent the Prop - I think they just aren't very familiar with it.
In other magazines like Nuts & Volts the coverage is much more even and spread out among different processors.
I've said it before - the thing to do is to get articles about the Prop submitted to Make. I don't think they will avoid printing them. But, I expect that the more they have to do with interacting with the physical world the better. These are the articles that are typically more interesting in Make and I expect more likely to be accepted.
I don't think it needs to be too involved. Take a Gadget Gangster board (something very easy for an Arduino user to understand) and add an interface to some physical "something." Show how easy it is to have a display on TV/VGA.
I think that will get peoples' attention.
Another idea - there's lot's of talk about video games here. Show Make readers how easy (I hope) it is to create video games on the Prop.
Articles like these will definitely interest more people. The article can point people to this forum and other resources as well.
Again, I think this may be all that's needed. There's no reason to see the Arduino platform as an enemy.
I don't think it needs to be too involved. Take a Gadget Gangster board (something very easy for an Arduino user to understand) and add an interface to some physical "something." Show how easy it is to have a display on TV/VGA.
I think that will get peoples' attention.
Another idea - there's lot's of talk about video games here. Show Make readers how easy (I hope) it is to create video games on the Prop.
You mean like this? Or something more complicated?
So if there's a Chinese 6502, then it's just a matter of time before there's a Chinese SX! (Please don't criticize my flawed logic...it's all I've got left.)
Meanwhile...the Ardunio bores me to death. It's far too slow. If it's a C-like language that one seeks, skip the Ardunio and use an ARM Cortex M3.
So if there's a Chinese 6502, then it's just a matter of time before there's a Chinese SX! (Please don't criticize my flawed logic...it's all I've got left.)
I see it like this, each system (prop, arduino, pic's, etc.) has their own place in projects, like using different type of meat for different recipes, bottom roast is great for stews and sirloins are great for fajitas, different processors = different ingredients. i like the arduino for its simplicity (in my mind) and adc functions built in, and the fact that 'it just works' without alot of time spent trying to reverse-engineer a program or object to fit your needs. but in the other hand, if i want to read in sensor data in real-time and control multiple things at once, my choice is a prop hands down, no questions asked. In my opinion, a prop paired with an arduino is a match made in heaven, it makes a system that is capable pretty much of doing anything and 'playing nice' with each other without having to use alot of external support components and spending time to design the support circuitry, lets you move on to doing what you started out to do, bring a project from the imagination to working project. just my $0.02 worth.
I think something like that would probably be pretty good. I've read through your tutorial already (but I'll admit I haven't run the code).
For Make, you would want to emphasize the hardware over the software, I think - even though there isn't too much involved. The fact that you handle joystick and keyboard interfaces is good. You would not write up all the detail you have in the tutorial - Make articles are often kind of light in the software details.
But you have a very good tutorial online to refer people to - much better than a lot of what I've seen where there's just a link to code to download.
If you read through Make, some the articles that don't involve making hardware are usually pretty short. It shouldn't be too hard to write something up. The article could describe why the Prop is ideal for this sort of application, why it's easy to use (an Arduino-like board [1] and a few extra components), and where you can go from there. Describe the framework of the game and mention the tutorial.
I think it would be good for people to see how easy it is to plug some hardware together and get these kinds of results. In this case, you should probably emphasize the learning aspect of the process.
[1] I'd also mention other hardware that it can run on - proto boards, C3, versions of Gadget Gangster board, etc.
I was thinking about that all along as I typed my post but I forgot at the most important time. I have one sitting on my desk - I intended it to be in the list.
I want to first want to say that Oldbitcollector I like reading you post and comments but I have say that I am very sorry that I disagree and here is why
language is too complicated for beginners — more like assembly language than any of the others
I have to agree with this part I am trying to learn spin and find it hard to learn so to me this is not so far fetched of an Idea
I not trying to start any thing But.....>>>> Plentiful examples on • Parallax site, and some user-generated code on the web —but not many basic examples
Getting Started guides: There is no Getting Started guide. Reference manual is very thorough, but it’s not for the beginner; assumes familiarity with computer architecture and assembly language syntax.
I like Parallax as a company have bought allot of stuff from them in the past there customer service is out standing allot better than most company
But when it come to the Propeller Chip and making easy to understand here is where I think it has fallen short Propeller Lab kit is nice but it a little hard to understand part of it where as the What is a Micro Controller was a lot easier to understand
I can SEE why the review are the way that are here is why
For my self I do not have a programing back ground
P BASIC form What is a Micro Controller which was for the most part easy to learn
Now for Propeller Lab kit if I had start with this first I do not think would keep trying to understand after a while
because yes you can get the LED to flash But can you understand how it done in code and all of the other command line of code that another thing all together
For example
Chapter 5 Methods and Cogs Lab Calling a Method is a litter hard to follow but I can some what understand the concept Parameter Passing is also a little hard to follow but I can some what understand the concept
Where they talk about Stopping Cogs completely lost do not understand the concept How Much Stack Space for a Method Launched into a Cog completely lost do not understand the concept Using a Method's Result is a litter hard to follow but I can some what understand the concept
These are only a few of the other topics that are cover
To me it would help to have spend more time explaining the concept in example that are give
line by line name as in the code example as well as the what in figure 5. which every one was being cover
It hard to follow because it was not written for a beginner to understand that never used a Micro Controller this to me is what I mean when I said it fallen short .......... I am sorry that I feal this way ....... Parallax and or to the writer of the Propeller Lab kit
I hope that every one can understand where I am coming from what I have said above
Like I said Parallax has great product great customer service but when it come to the Propeller this to ME has fallen short of what is a great product
It is a good tutorial. I applaud his efforts in making that tutorial but that means having to buy another board or matching the pins up on another board. The problem is that I can't go two minutes in my house without being interrupted.
I already have two packages / boards so if I'm already interrupted and don't have the time to learn one platform then I view a third board like the one above in an appreciative way but I base my buying pattern on past results which means I already have two boards with little time and it doesn't motivate me to go buy a third board. I already have some good tutorials for Microchip to get started but I already know that there is an abundance of free tutorials on another platform and they are short. My object is to get started, be a producer and not just a consumer.
In reference to sam_sam_sam's message. I can definitely see the need to quit talking in technical jargon when we approach a perspective new user with the Propeller. Let's bring them the fun first, in easy, non-technical terms.
Once they are hooked and want to go deeper, then let's tell them about cogs, stack, longs, parameter passing.
It's time to quit trying to teach the "new driver" how internal combustion works, when they really just want to push the gas pedal down and see how fast the car can go, and hear the sound of the V8. Let's get them hooked first.
It is a good tutorial. I applaud his efforts in making that tutorial but that means having to buy another board or matching the pins up on another board. The problem is that I can't go two minutes in my house without being interrupted.
This has been one of our disadvantages over the Ardunio. We are running in 40 directions with 40 completely different board designs that there hasn't been a singular focus. I personally decided a couple a months ago to try to center my efforts down to a couple of Propeller boards. As a group it would probably help our cause to agree on a single direction.
This is the kind of thing that need a very good explanation of what each one dose and why
This very very good
Connect the pin to ground with:
dira[pin] := 1
outa[pin] :=0
Connect the pin to V+ with:
dira[pin] := 1
outa[pin] := 1
sense if the pin is connected to a low or high signal (high impedance state):
dira[pin] := 0 (default on bootup)
pinstatus := ina[pin]
One comment why is this need ( := )
•PRI methods cannot be called by other objects.
PRI methods can only be called from within their object. They cannot be called directly from another object.
One comment What dose PIR mean ?
How objects aren't just a collection of methods•Variables are only scoped to their object.
Variables declared in an object's VAR block(s) are only available to methods in the same object. There are some ways to get around this, though.
•PRI methods cannot be called by other objects.
PRI methods can only be called from within their object. They cannot be called directly from another object.
Here it would have been nice to have a very simple example of how you would do this
•You can create multiple instances of a single object
In the OBJ block, if you do 'PWM[2] : 'PWM', you've declared 2 instances of the PWM object (PWM[0] and PWM[1]). Each object will have the same program code (PUB, PRI, DAT), but different VAR code.
_______________________________________________________________________________________________________________________________
•Other objects can read the CONstants from another object.
Values declared in an object's CON block(s) can be read with the hash; objectname#Convalue. If your display object has a contstant called 'pin', you can read that from another object with display#pin. Remember that CONstants cannot be changed in runtime.
Very easy to understand
The PST.Start(115200) gets the object up and running on another cog with a Baud Rate of 115,200. Think of the Baud Rate as the speed setting our program and the PST program will use to talk to each other. Make a quick note of the speed as we will need to set PST to the same setting.
Notice that I’ve inserted some lines which start with pst.str after each of the outa statements. Monitoring the code from Parallax Serial Terminal, we can tell that the code is working correctly even if the LED is defective or removed from the circuit.
The method, pst.str is used to send a line of text to the Parallax Serial Terminal. See that 13 toward the end of the line? The ASCII code “13” is a carriage return telling the terminal to jump to the next line.
What happen to Waitcnt(clkfreq + cnt) to me this need as well
For the most part you have the right Idea and i will read all of the one that you have posted Keep up the good work
@Sam - Feedback is much appreciated! Looks like we need some more clarity on the different operators (:=, ==) and maybe some cleaning up on the serial stuff.
As you read through them please let me know what else doesn't make sense, needs clarifying, etc.
Looks like we need some more clarity on the different operators (:=, ==) ...
Good documentation on operators is always important - especially for beginners. Spin has so many that I often find myself refering to the documentation to figure out which is which.
Assignment and comparison operators like := and == are always "fun" in lots of different languages. Even when I know what the correct one to use is, "typos" confusing these are often very difficult to track down - the code "looks right" even though it isn't.
Basic tutorials should just use a few simple operators. After the beginner is familiar with them, it might be good to have an operator-specific tutorial. It doesn't have to do very much, just introduce a person with some experience to all the options that are available. They don't have to use them right away, but when an unkown operator in example code comes up they will know where to look for an explanation. Also, if they realize that they need an operation like "shift" remembering that there is an operator for it, even if they don't remember what it is, is good.
As an aside, I still can't really figure out why people think Spin looks like assembly.
Interesting exchange here. Thanks much for your input as a newbie, sam_sam_sam, it can be very hard for those of us who have been doing it a long time to see how it looks to you.
I think the Spin expression evaluator is a work of genius but it's also a very unusual thing, and it's very poorly explained in the official documentation; it's far enough from the norm that even seasoned programmers trip on it by either failing to realize some shortcut is possible or by innocently using >= instead of => with disastrous results. I've been programming for 30 years and I'd frankly welcome a good solid introduction that starts with the basics and shows how you spiral out to all the really cool stuff that is possible.
I think the original idea was that the Demoboard would be the Propeller's Arduino, but it's too expensive and not as easily incorporated permanently into a project. None of the standard boards (except the rather expensive PPDB and the rather limited PropRPM) have a normal RS232 port, which is a major shortcoming in embedded controller land, where RS232 is still king for a lot of purposes. For a lot of purposes, it's still pretty hard to use a Propeller if you don't know how to solder, and while there are a lot of solutions out there finding them can be hard. (If Bill Henning's PropCade perfectly fits your requirements, how will you find out if your only contact with the product is Parallax? Other than reading this post I suppose?)
I still wince when I type := in Spin. I'm not sure why becuase I liked Pascal back in the 80's and even ported a Pascal compiler to the 6502. It's just syntactically a throwback.
Yes, yes, yes! Bemoaning the fact that MAKE does an Arduino-only issue is like getting angry because Entertainment Tonight does stories about American Idol. Everybody loves Arduino. That is a fact. Instead of crying in your beer, help promote the Propeller by building things and promoting your things somewhere other than here.
And don't forget to make a bunch of noise about this all being part of the "open source hardware" revolution. This attracts a sizable demographic from the software world.
Comments
I remember reading that when the issue came out.
Whoever wrote the description was obviously not aware of all the boards that are available - several from Parallax, the Gadget Gangster boards, Wolfden, Rayslogic, etc. I expect there are probably at least as many different Propeller boards available as there are significant variations of Arduino boards (most Arduino boards are identical or very similar to the originals). I'm not counting generic AVR boards here, just the ones targeted at Arduino (not all of which look anything like the official boards).
Also, I can't figure out where the language being close to assembly comes from. Spin doesn't really look like any assembly I've ever dealt with. I assume that whoever was looking at this must have looked at spin code with embedded assembly. Either that or they are completely lost.
Don't hold back OBC, Let us know how you really feel... ;-)
http://blog.makezine.com/archive/2011/02/why-the-arduino-won-and-why-its-here-to-stay.html
So basically, if you don't have time for a manual, there is a tutorial for whatever you want to do whereas the rest of the stuff is build for heavy readers.
Why would Make alienate part of their existing audience? (ie: customer base)
I'm pretty sure it's not just just us Propeller heads that are feeling stung by what is happening at Make, there are several other popular platforms that have firm ground and a user base. Seems like poor business sense to me. Mr. Torrone is shooting himself in the foot by writing articles like that.
OBC
But, I don't feel particularly alienated.
I still think the thing to do is not to try and compete directly with Arduino. Nobody is going to be able to right now based on numbers alone (boards out there, number of people using them, and variety of posted/documented projects).
But there is no reason to compete.
If the Prop is going to become better known there need to be more things visible to the public. We don't want people to rely on the misinformation presented about the Propeller in the Make summary referenced above. I don't believe that Make was maliciously trying to misrepresent the Prop - I think they just aren't very familiar with it.
In other magazines like Nuts & Volts the coverage is much more even and spread out among different processors.
I've said it before - the thing to do is to get articles about the Prop submitted to Make. I don't think they will avoid printing them. But, I expect that the more they have to do with interacting with the physical world the better. These are the articles that are typically more interesting in Make and I expect more likely to be accepted.
I don't think it needs to be too involved. Take a Gadget Gangster board (something very easy for an Arduino user to understand) and add an interface to some physical "something." Show how easy it is to have a display on TV/VGA.
I think that will get peoples' attention.
Another idea - there's lot's of talk about video games here. Show Make readers how easy (I hope) it is to create video games on the Prop.
Articles like these will definitely interest more people. The article can point people to this forum and other resources as well.
Again, I think this may be all that's needed. There's no reason to see the Arduino platform as an enemy.
You mean like this? Or something more complicated?
http://www.gadgetgangster.com/tutorials/358
Meanwhile...the Ardunio bores me to death. It's far too slow. If it's a C-like language that one seeks, skip the Ardunio and use an ARM Cortex M3.
I've been told this is already the case.
- Ken
I think something like that would probably be pretty good. I've read through your tutorial already (but I'll admit I haven't run the code).
For Make, you would want to emphasize the hardware over the software, I think - even though there isn't too much involved. The fact that you handle joystick and keyboard interfaces is good. You would not write up all the detail you have in the tutorial - Make articles are often kind of light in the software details.
But you have a very good tutorial online to refer people to - much better than a lot of what I've seen where there's just a link to code to download.
If you read through Make, some the articles that don't involve making hardware are usually pretty short. It shouldn't be too hard to write something up. The article could describe why the Prop is ideal for this sort of application, why it's easy to use (an Arduino-like board [1] and a few extra components), and where you can go from there. Describe the framework of the game and mention the tutorial.
I think it would be good for people to see how easy it is to plug some hardware together and get these kinds of results. In this case, you should probably emphasize the learning aspect of the process.
[1] I'd also mention other hardware that it can run on - proto boards, C3, versions of Gadget Gangster board, etc.
Please don't forget.
|
|
|
V
Sorry, Martin.
I was thinking about that all along as I typed my post but I forgot at the most important time. I have one sitting on my desk - I intended it to be in the list.
total rubbish!
I want to first want to say that Oldbitcollector I like reading you post and comments but I have say that I am very sorry that I disagree and here is why
language is too complicated for beginners — more like assembly language than any of the others
I have to agree with this part I am trying to learn spin and find it hard to learn so to me this is not so far fetched of an Idea
I not trying to start any thing But.....>>>>
Plentiful examples on • Parallax site, and some user-generated code on the web — but not many basic examples
Getting Started guides: There is no Getting Started guide. Reference manual is very thorough, but it’s not for the beginner; assumes familiarity with computer architecture and assembly language syntax.
I like Parallax as a company have bought allot of stuff from them in the past there customer service is out standing allot better than most company
But when it come to the Propeller Chip and making easy to understand here is where I think it has fallen short Propeller Lab kit is nice but it a little hard to understand part of it where as the What is a Micro Controller was a lot easier to understand
I can SEE why the review are the way that are here is why
For my self I do not have a programing back ground
P BASIC form What is a Micro Controller which was for the most part easy to learn
Now for Propeller Lab kit if I had start with this first I do not think would keep trying to understand after a while
because yes you can get the LED to flash But can you understand how it done in code and all of the other command line of code that another thing all together
For example
Chapter 5 Methods and Cogs Lab Calling a Method is a litter hard to follow but I can some what understand the concept
Parameter Passing is also a little hard to follow but I can some what understand the concept
Where they talk about Stopping Cogs completely lost do not understand the concept
How Much Stack Space for a Method Launched into a Cog completely lost do not understand the concept
Using a Method's Result is a litter hard to follow but I can some what understand the concept
These are only a few of the other topics that are cover
To me it would help to have spend more time explaining the concept in example that are give
line by line name as in the code example as well as the what in figure 5. which every one was being cover
It hard to follow because it was not written for a beginner to understand that never used a Micro Controller this to me is what I mean when I said it fallen short .......... I am sorry that I feal this way ....... Parallax and or to the writer of the Propeller Lab kit
I hope that every one can understand where I am coming from what I have said above
Like I said Parallax has great product great customer service but when it come to the Propeller this to ME has fallen short of what is a great product
It is a good tutorial. I applaud his efforts in making that tutorial but that means having to buy another board or matching the pins up on another board. The problem is that I can't go two minutes in my house without being interrupted.
I already have two packages / boards so if I'm already interrupted and don't have the time to learn one platform then I view a third board like the one above in an appreciative way but I base my buying pattern on past results which means I already have two boards with little time and it doesn't motivate me to go buy a third board. I already have some good tutorials for Microchip to get started but I already know that there is an abundance of free tutorials on another platform and they are short. My object is to get started, be a producer and not just a consumer.
So somewhere there may be more SX chips being made? It would be nice to know that the SX28 and SX48 may yet still live on....
If you are a struggling beginner, I value your input VERY HIGHLY.
Could you do me a favor?
Could you give me a detailed review of:
http://www.gadgetgangster.com/tutorials.html
from the eyes of a struggling beginner?
Nick and I are VERY motivated to change this problem.
Thanks
OBC
Once they are hooked and want to go deeper, then let's tell them about cogs, stack, longs, parameter passing.
It's time to quit trying to teach the "new driver" how internal combustion works, when they really just want to push the gas pedal down and see how fast the car can go, and hear the sound of the V8. Let's get them hooked first.
OBC
This has been one of our disadvantages over the Ardunio. We are running in 40 directions with 40 completely different board designs that there hasn't been a singular focus. I personally decided a couple a months ago to try to center my efforts down to a couple of Propeller boards. As a group it would probably help our cause to agree on a single direction.
OBC
This very very good
Connect the pin to ground with:
dira[pin] := 1
outa[pin] :=0
Connect the pin to V+ with:
dira[pin] := 1
outa[pin] := 1
sense if the pin is connected to a low or high signal (high impedance state):
dira[pin] := 0 (default on bootup)
pinstatus := ina[pin]
One comment why is this need ( := )
•PRI methods cannot be called by other objects.
PRI methods can only be called from within their object. They cannot be called directly from another object.
One comment What dose PIR mean ?
How objects aren't just a collection of methods•Variables are only scoped to their object.
Variables declared in an object's VAR block(s) are only available to methods in the same object. There are some ways to get around this, though.
•PRI methods cannot be called by other objects.
PRI methods can only be called from within their object. They cannot be called directly from another object.
_____________________________________________________________________________________________________________________________
Here it would have been nice to have a very simple example of how you would do this
•You can create multiple instances of a single object
In the OBJ block, if you do 'PWM[2] : 'PWM', you've declared 2 instances of the PWM object (PWM[0] and PWM[1]). Each object will have the same program code (PUB, PRI, DAT), but different VAR code.
_______________________________________________________________________________________________________________________________
•Other objects can read the CONstants from another object.
Values declared in an object's CON block(s) can be read with the hash; objectname#Convalue. If your display object has a contstant called 'pin', you can read that from another object with display#pin. Remember that CONstants cannot be changed in runtime.
Very easy to understand
The PST.Start(115200) gets the object up and running on another cog with a Baud Rate of 115,200. Think of the Baud Rate as the speed setting our program and the PST program will use to talk to each other. Make a quick note of the speed as we will need to set PST to the same setting.
Notice that I’ve inserted some lines which start with pst.str after each of the outa statements. Monitoring the code from Parallax Serial Terminal, we can tell that the code is working correctly even if the LED is defective or removed from the circuit.
The method, pst.str is used to send a line of text to the Parallax Serial Terminal. See that 13 toward the end of the line? The ASCII code “13” is a carriage return telling the terminal to jump to the next line.
What happen to Waitcnt(clkfreq + cnt) to me this need as well
For the most part you have the right Idea and i will read all of the one that you have posted Keep up the good work
I would also like to see someone do a a good tutorial on
The most important parts of the video, keyboard, serial terminal, and other very useful object which to me are the best selling point of the Propeller
so that some one who has NEVER use a micro controller can understand
As you read through them please let me know what else doesn't make sense, needs clarifying, etc.
Good documentation on operators is always important - especially for beginners. Spin has so many that I often find myself refering to the documentation to figure out which is which.
Assignment and comparison operators like := and == are always "fun" in lots of different languages. Even when I know what the correct one to use is, "typos" confusing these are often very difficult to track down - the code "looks right" even though it isn't.
Basic tutorials should just use a few simple operators. After the beginner is familiar with them, it might be good to have an operator-specific tutorial. It doesn't have to do very much, just introduce a person with some experience to all the options that are available. They don't have to use them right away, but when an unkown operator in example code comes up they will know where to look for an explanation. Also, if they realize that they need an operation like "shift" remembering that there is an operator for it, even if they don't remember what it is, is good.
As an aside, I still can't really figure out why people think Spin looks like assembly.
I think, to them, anything that's not C looks like asm.
I think the Spin expression evaluator is a work of genius but it's also a very unusual thing, and it's very poorly explained in the official documentation; it's far enough from the norm that even seasoned programmers trip on it by either failing to realize some shortcut is possible or by innocently using >= instead of => with disastrous results. I've been programming for 30 years and I'd frankly welcome a good solid introduction that starts with the basics and shows how you spiral out to all the really cool stuff that is possible.
I think the original idea was that the Demoboard would be the Propeller's Arduino, but it's too expensive and not as easily incorporated permanently into a project. None of the standard boards (except the rather expensive PPDB and the rather limited PropRPM) have a normal RS232 port, which is a major shortcoming in embedded controller land, where RS232 is still king for a lot of purposes. For a lot of purposes, it's still pretty hard to use a Propeller if you don't know how to solder, and while there are a lot of solutions out there finding them can be hard. (If Bill Henning's PropCade perfectly fits your requirements, how will you find out if your only contact with the product is Parallax? Other than reading this post I suppose?)
And don't forget to make a bunch of noise about this all being part of the "open source hardware" revolution. This attracts a sizable demographic from the software world.