Well, as the old saying goes, "if you can't beat them, join them!"... So it seems that one of the best things that the P2 could do is show how easily you could use it with those devices. ...a couple of the Arduino models immediately come to mind....If the P2 can get mind share in this way, it is inevitable that some of the users will start to ask the question "can I do what I need with just the P2?".....
Seairth, I think you are right about all this. That's where the market is right now, and it would probably be a good strategy to pitch the Prop2 as a helper chip, which would lead people into using it for more, later on.
I recently attended a robot "fest" and was surprised, if not downright shocked, at all the Arduinos in use. In fact, I didn't see anything else. I stopped and asked one of the "artists" whom I noticed was using Arduinos and she was oh-so excited about it, how she was new at this automation thing and didn't really understand what she was doing but that didn't matter because she was just cutting and pasting code and getting her sculptures to move around, all for "free". She seemed so enthusiastic about this magical phrase "open source" even though she couldn't really tell me what that meant other than she got to cut and paste code, whose operation she didn't understand, all for "free."
Also, recently I've been pestered to help some youngsters with their Arduino projects, so I bit the bullet and started learning about it. In my opinion, the Arduino's success must be a cultural one, not a technical one. This interrupt business is totally idiotic to me. And I can't seem to breathe without counter modules to work with. Nevertheless, the Arduino is everywhere. Everybody seems to be adapting their stuff to it, or figuring out ways to interface with it. I noticed recently that there's a language called ROBOTC, which apparently works on Lego Mindstorms, VEX, and - you guessed it - Arduinos. Up until recently, my local school system was debating whether to teach with Lego or Vex but now they don't have to worry so much because, I guess, ROBOTC bridges those two worlds???
A couple days ago, I had wanted to start a thread and ask forum members here what sort of Arduino shields they might be working on using the Propeller, but I decided against it because I thought it might be inappropriate to discuss a "competing" product here on the Parallax forum. But, honestly, for all its popularity, I find the Arduino to be clunky to use. Yet, I can easily see how Propeller-based shields would not only give the Arduino the brains it is lacking but they would also serve as a gateway drug for the Propeller by itself. Once Arduino users find out how liberating these new shields would be, I'm sure a great number of them would want to start hacking into the shield itself, only to find it is an awesome, easy-to-use device in its own right.
Personally, I will continue using Propeller chips for my own gadgets, but it would be great to see Parallax grab the bull by the horns and embrace this Arduino thing a little bit so that I don't get so many blank looks when I tell people what my gadgets are using. I know the Propeller is about as open-sourced as it needs to be for 99% of the users out there, but as I said, this appears to be a cultural phenomenon, not a technical one. The way into the hearts of the masses might be to get into the shield business and lure in customers by enticing them to look under the hood.
I recently attended a robot "fest" and was surprised, if not downright shocked, at all the Arduinos in use. In fact, I didn't see anything else. I stopped and asked one of the "artists" whom I noticed was using Arduinos and she was oh-so excited about it, how she was new at this automation thing and didn't really understand what she was doing but that didn't matter because she was just cutting and pasting code and getting her sculptures to move around, all for "free". She seemed so enthusiastic about this magical phrase "open source" even though she couldn't really tell me what that meant other than she got to cut and paste code, whose operation she didn't understand, all for "free."
Also, recently I've been pestered to help some youngsters with their Arduino projects, so I bit the bullet and started learning about it. In my opinion, the Arduino's success must be a cultural one, not a technical one. This interrupt business is totally idiotic to me. And I can't seem to breathe without counter modules to work with. Nevertheless, the Arduino is everywhere. Everybody seems to be adapting their stuff to it, or figuring out ways to interface with it. I noticed recently that there's a language called ROBOTC, which apparently works on Lego Mindstorms, VEX, and - you guessed it - Arduinos. Up until recently, my local school system was debating whether to teach with Lego or Vex but now they don't have to worry so much because, I guess, ROBOTC bridges those two worlds???
A couple days ago, I had wanted to start a thread and ask forum members here what sort of Arduino shields they might be working on using the Propeller, but I decided against it because I thought it might be inappropriate to discuss a "competing" product here on the Parallax forum. But, honestly, for all its popularity, I find the Arduino to be clunky to use. Yet, I can easily see how Propeller-based shields would not only give the Arduino the brains it is lacking but they would also serve as a gateway drug for the Propeller by itself. Once Arduino users find out how liberating these new shields would be, I'm sure a great number of them would want to start hacking into the shield itself, only to find it is an awesome, easy-to-use device in its own right.
Personally, I will continue using Propeller chips for my own gadgets, but it would be great to see Parallax grab the bull by the horns and embrace this Arduino thing a little bit so that I don't get so many blank looks when I tell people what my gadgets are using. I know the Propeller is about as open-sourced as it needs to be for 99% of the users out there, but as I said, this appears to be a cultural phenomenon, not a technical one. The way into the hearts of the masses might be to get into the shield business and lure in customers by enticing them to look under the hood.
My 0.02 yuans worth.
Good observations and suggestions, I think, ElectricAye.
We had several stabs at the single-chip SD card OS based standalone general purpose computer with P1 but it just didn't quite have the RAM to pull it off. P2 should be well over the hump for that even without external RAM.
EA, the difference between how Arduino was marketed and how P1 was marketed is this:
The Arduino folks streamlined the development system, concealed the nuts and bolts as much as possible, and made it especially easy to do that code cut-and-pasting even though, under the hood, the Arduino conceals an incredibly byzantine and hazard-prone interrupt system, counter array, and notoriously easy to misuse C++ language renamed "sketches." They then aggressively positioned it as a tool for non-technical people like artists to do technical stuff like making their sculptures move and react to viewers.
Parallax marketed the P1, like the Basic Stamp, as an educational system which would, through use, help a person become technical. The Spin language is shot through with teaching gimmicks that force you to deal with finite math, memory spans, and binary logic operations in order to get anything done. It's extremely, fantastically powerful once you get used to it and prepares you well for any of the other more common languages, where in particular the expression evaluators are almost all subsets of the Spin evaluator. It denies you GOTO and global vars and workarounds instead forcing you to think about structurally organizing a program. It is about the only language other than Forth I can think of that really, honestly, has no available equivalent for GOTO, for reals, no kidding, really.
What Spin is not is a sexy dressing gown for an ugly little package designed to make it attractive to artists and non-technical types as well as kids. If you want to understand why there is an Arduino on every page of MAKE: magazine and a Propeller in every other issue, that's the reason in a nutshell. I don't believe the Arduino developers were sinister, but I do believe they were more interested in getting a tool into the hands of artists than they were in getting the artists to understand that tool, and that's why it's got the market share it does.
Chip was not interested in making it unnecessary for us to think about our software; Chip was interested in teaching us how to think about our software. One of those things will be more popular than the other every time.
You know, the BASIC Stamp once occupied that mantle the Arduino sits on now. I can't help but wonder if you took the super simplicity of BASIC and made it run (really run, like the Stamp) on the Propeller 2, if that wouldn't push adoption in the hobby crowd.
One of the chief virtues of the BASIC Stamp was the simple language and relatively confined design. I find that the more versatile we make things, the less apt they are to be used because the majority of folks don't find them simple enough; people want boundaries to confine them.
The Arduino is a good example of this ethos. It is constrained, it doesn't do everything, but by virtue of its C roots, people *can* extend it more than the neophytes would.
Spin isn't a bad language, it is actually a really fine language in a lot of respects, but the "oh not another language" sigh is heard often.
Perhaps making a BASIC compiler available along side the Spin compiler wouldn't be a bad thing for the hobby crowd.
QBASIC is a very useful, but simple addition to the original BASIC language, I think that would be an excellent starting point, syntactically, for a language.
I'm simply stating that making the technology accessible is important. The real tragedy is that Chip designed an assembly instruction set that is really intended for programmer to use, not compilers, yet this elegant and complex instruction set can only be appreciated by an elite few in the scope of potential users.
EA, the difference between how Arduino was marketed and how P1 was marketed is this:
The Arduino folks streamlined the development system, concealed the nuts and bolts as much as possible, and made it especially easy to do that code cut-and-pasting even though, under the hood, the Arduino conceals an incredibly byzantine and hazard-prone interrupt system, counter array, and notoriously easy to misuse C++ language renamed "sketches." They then aggressively positioned it as a tool for non-technical people like artists to do technical stuff like making their sculptures move and react to viewers.
Parallax marketed the P1, like the Basic Stamp, as an educational system which would, through use, help a person become technical. The Spin language is shot through with teaching gimmicks that force you to deal with finite math, memory spans, and binary logic operations in order to get anything done. It's extremely, fantastically powerful once you get used to it and prepares you well for any of the other more common languages, where in particular the expression evaluators are almost all subsets of the Spin evaluator. It denies you GOTO and global vars and workarounds instead forcing you to think about structurally organizing a program. It is about the only language other than Forth I can think of that really, honestly, has no available equivalent for GOTO, for reals, no kidding, really.
What Spin is not is a sexy dressing gown for an ugly little package designed to make it attractive to artists and non-technical types as well as kids. If you want to understand why there is an Arduino on every page of MAKE: magazine and a Propeller in every other issue, that's the reason in a nutshell. I don't believe the Arduino developers were sinister, but I do believe they were more interested in getting a tool into the hands of artists than they were in getting the artists to understand that tool, and that's why it's got the market share it does.
Chip was not interested in making it unnecessary for us to think about our software; Chip was interested in teaching us how to think about our software. One of those things will be more popular than the other every time.
Sounds like Parallax needs to step up its game of "SPREADING DEMOCRACY".
But, its time to do better. It's very much possible now to bring professional level clean and polished tools to the hobbyist community for free. Open source tools like Scintilla allow easy integration of real coding features into native platform IDEs. Integration of tools like CMake or SCons allow for a real build system to be under the hood of the IDE so that you can tweak your code easily to do more than the default.
Once you start looking for things to do better than the Arduino, you find many. There are so many useful features that can be built into the tools you use to code easily. Not even talking about hardware, one can build much better software.
I've actually been working on building a really good IDE for this stuff for a while now. One super easy thing to do but which would be so valuable is to include graph support into the IDE itself.
Like... have you ever wanted to just print values to a graph, for a sensor of whatever? Well, its not that hard to build right into the IDE and create nice looking graphs from your development board. Here's of example of what I'm working on will be able to support: http://www.workslikeclockwork.com/index.php/components/qt-plotting-widget/.
By just simple making it so that the IDE intercepts built in ACSII commands sent to the serial port you can easily add graph features to the IDE (yes, maybe a packet or two gets corrupted here or there, but that's okay).
Or, what about having built in graphics features you you can display custom images from your microcontroller? With Qt, its easy to make an image and paint whatever you want to it controlled by the serial port.
.... or what about having the built in ability to read, write, modify the EEPROM for settings control? A built in hex editor? Maybe there's an SD card card socket on the microcontroller board by default so that becomes a standard feature? Then we can build in remove file transfer through the IDE to the SD card...
...there's like a never ending list of features you can build in.
---
Anyway, all that said, its the user experience that matters. Arduino is not pushing the limits of this in their software at all. I attend to do this now. It's something incredibly compelling for me to do and I have enough experience and free time now to really push the envelope.
I think with an awesome IDE on the computer coupled with matching hardware that is flexible and not full of complications and holes will allow the propeller 2 to do very well.
What's more important than hardware features is your ability to get your project done quickly and easily. That is what the Arduino has over the propeller right now. Its very easy on the Arduino to do a few things (but, not a lot of things... the Arduino starts to break down then). What the propeller 2 will give people is the ability to do a lot of things well.
Imagine, by default, the library supports - servo/debounced i/o/pwm/stepper/encoder/quadrature encoder/adc/dac/etc... on every pin at the same time! Default SD card support! Fast programming with built in code protection! There are plenty of things to just have built in.
---
Right now I'm still working on crafting my project idea. I won't have anything ready for release soon. But, hopefully by August I'll have enough of the programming environment done to start working on C libraries for the propeller. It's perfectly possible to have full Arduino support. Interrupts? Well, we can simulate them with event driven code. While the user will still be able to bug everything with an infinite loop in their code, you more or less can easily have Arduino code compatibility.
...
Anyway, I've said enough on this for now. Back to work.
I've been quietly lurking this forum for the last few weeks. I've even made a PM'd comment or two to a couple people.
I've kept quiet because I didn't spring for the FPGA, hoping I could wait for a working chip from the run. (You guys have made me sorry I waited. {looking at you Baggers!} )
EA, the difference between how Arduino was marketed and how P1 was marketed is this:
The Arduino folks streamlined the development system, concealed the nuts and bolts as much as possible, and made it especially easy to do that code cut-and-pasting even though, under the hood, the Arduino conceals an incredibly byzantine and hazard-prone interrupt system, counter array, and notoriously easy to misuse C++ language renamed "sketches." They then aggressively positioned it as a tool for non-technical people like artists to do technical stuff like making their sculptures move and react to viewers.
I hear this feedback from a couple people who are close to me and use the Propeller. They have limited time to play and want to quickly do cool projects they are interested in, not have to go to school to learn why the microcontroller is doing what it is doing.
Chip was not interested in making it unnecessary for us to think about our software; Chip was interested in teaching us how to think about our software. One of those things will be more popular than the other every time.
Keep in mind that "thinking" is hard. The "masses" aren't interested in that kind of work.
You know, the BASIC Stamp once occupied that mantle the Arduino sits on now. I can't help but wonder if you took the super simplicity of BASIC and made it run (really run, like the Stamp) on the Propeller 2, if that wouldn't push adoption in the hobby crowd....
I've been thinking this very thing myself. I'm not a huge fan of BASIC (unless it's used in a REPL fashion I don't see much advantage to it), but I do know that for many many people it's a familiar, comfortable environment in which to develop code. I've seen the "not another language" knock on Spin often enough to realize that in the minds of many it matters, rightly or wrongly. And this observation comes from someone who doesn't dislike Spin at all, and has even defended it here on occasion.
The Arduino has benefited from its watered-down dialect of C++ and all the copy-n-paste code ready-made for use without much thought. It's a bit too simplistic a platform, I think, for much of what I would call real engineering work, nor is it a good platform for teaching microcontroller programming, either. That said, there are lessons to be learned from its success that could possibly be applied to the Propeller (both I and II).
Will Propgcc bridge the divide? That doesn't seem likely. So, Pedward has a valid point: A robust full-featured BASIC language tool for the Propeller, one that is easy to use but doesn't obfuscate the hardware details, could be a huge boon to the Prop.
You know, the BASIC Stamp once occupied that mantle the Arduino sits on now. I can't help but wonder if you took the super simplicity of BASIC and made it run (really run, like the Stamp) on the Propeller 2, if that wouldn't push adoption in the hobby crowd.
One of the chief virtues of the BASIC Stamp was the simple language and relatively confined design. I find that the more versatile we make things, the less apt they are to be used because the majority of folks don't find them simple enough; people want boundaries to confine them.
The Arduino is a good example of this ethos. It is constrained, it doesn't do everything, but by virtue of its C roots, people *can* extend it more than the neophytes would.
Spin isn't a bad language, it is actually a really fine language in a lot of respects, but the "oh not another language" sigh is heard often.
Perhaps making a BASIC compiler available along side the Spin compiler wouldn't be a bad thing for the hobby crowd.
QBASIC is a very useful, but simple addition to the original BASIC language, I think that would be an excellent starting point, syntactically, for a language.
I'm simply stating that making the technology accessible is important. The real tragedy is that Chip designed an assembly instruction set that is really intended for programmer to use, not compilers, yet this elegant and complex instruction set can only be appreciated by an elite few in the scope of potential users.
What about Bean's PropBasic. I think it looks a lot like pbasic and is already available for the P1 and I imagine he probably plans to support it on the P2 as well.
Perhaps making a BASIC compiler available along side the Spin compiler wouldn't be a bad thing for the hobby crowd.
I think this provides a migration strategy for existing STAMP users more than it would be an attraction to "new" people. I think that people unfamiliar with the field are more likely to gravitate toward a C-like language based on what their peers, magazine articles, available books at B&N, and the web are telling them. This would result in little more than Parallax poaching their own customer base.
Spin isn't a bad language, it is actually a really fine language in a lot of respects, but the "oh not another language" sigh is heard often.
Agreed. Further, there's the issue that it's interpreted and the perceived performance issues related to that (regardless of the actual merits of the argument). Realistically, for arduino-like applications, Spin on the P2 would be more than sufficient. But to convince a novice of this is a real challenge.
The real tragedy is that Chip designed an assembly instruction set that is really intended for programmer to use, not compilers...
I wonder if it would be possible to develop a replacement syntax for PASM that didn't look like assembler. All the power of PASM, but a more "high level" look and feel...
There's a point I think wanting to be made that a major difference between P1 and P2 is the way the interpreter is spawned. In P1 the Spin interpreter is a significant resource, and a much greater fraction of all available resources than 2K of code will be in P2. P1 is pretty much married to Spin unless you want to significantly reduce potential application complexity. P2 will be much more language agnostic, even if the preferred high-level is *some* interpreted bytecode language. The playing field can be much more level between Spin2, C, some good structured Basic, Forth, and whatever else might present itself.
In fact, with the appropriate *cough* spin, P2 might be the platform that out-Arduinos the Arduino, by offering a similarly attractive thought-free playland with all that so un-Arduino-like general purpose I/O on one dev system, while providing the raw power for cutting-edge projects with multichannel nanosecond timing that the Arduino could never duplicate on another. But the marketing could be tricky; a lot of artists like shiny things but they don't want to think you're going to turn them into engineers, who everyone (in certain circles at least) knows have no imagination and the artistic sense of HAL 9000.
Of course not all Arduino users are like that, but that's what got Arduino so much exposure. It broke loose from the hobby computer hobby robot and maker crowd into a larger population of non-technical art and crafts people. The technical people tend to see Arduino for what it is but they use it anyway because there's so much Smile made for it now.
Edit: It would be kind of hilarious if P2 could host Arduino sketches. Just a thought.
I wonder if it would be possible to develop a replacement syntax for PASM that didn't look like assembler. All the power of PASM, but a more "high level" look and feel...
Of course. There are a few examples of High Level Assembler out there... HLA by Randall Hyde, and PL/M was a step above assembler.
That said, I think the GCC can generate ASM (for small code blocks, of course), and provided it can also in-line ASM, and list well, then it should give All the power of PASM, but a more "high level" look and feel...
This would result in little more than Parallax poaching their own customer base.
Meh, I'm not so sure. BASIC remains very popular. Generally when a BASIC is available for a particular chip family, it attracts users (BASCOM, mikroBASIC, PICBASIC...). It's still considered by not a few people to provide a good environment for beginning coders, rapid development, learning, etc.
Agreed. Further, there's the issue that it's interpreted and the perceived performance issues related to that (regardless of the actual merits of the argument). Realistically, for arduino-like applications, Spin on the P2 would be more than sufficient. But to convince a novice of this is a real challenge.
Certainly performance is one knock. The other being simply that it's an obscure, one-off language. In fact, most objections you see fall along those lines. Thus, practically any firmly established language would be an easier sell. But one which naturally lends itself to more of a RAD-type work flow (real or widely perceived) would be even better yet.
This would result in little more than Parallax poaching their own customer base.
I should add that having seen posts here on the forums I would say that Parallax are in danger of losing some of these customers anyway, if they don't reach out to them somehow.
Edit: It would be kind of hilarious if P2 could host Arduino sketches. Just a thought.
AFIK Arduino sits on top of Gcc. Once Gcc is feature complete on the propeller, I really don't see why you couldn't run Arduino sketches. Well it'd be best to port the Arduino library and maybe the boot-loader. (only thing the prop1 is missing is an ADC...)
Here's a viewpoint I have, which will certainly be controversial with David, but I assure you, there is a rationale.
The reason why SPIN and PASM are a good fit for the Propeller architecture is because of the architecture itself.
Compiled high level languages are designed to run in one monolithic memory space, not the heterogeneous design of the Propeller. This creates the obvious conflicts of needing an LMM kernel to bridge that divide.
In my opinion, the bytecode and interpreter route is a very robust way to attack this architecture. SPIN uses 8bit bytecodes, effectively increasing code density and reducing the memory pressure put on the hub.
Taking the same underlying architecture of SPIN, but marrying it with an advanced BASIC would give users who fear hearing of a new proprietary language, an option that sounds familiar.
For that matter, if you extend this model, you really end up with a design where you have a general purpose bytecode interpreter that is re-targetable by choosing a different bytecode compiler.
The compiler can compile C, BASIC, Java, SPIN, etc.
Maybe BASIC isn't the right language, but I see a few valuable things about it from a lexical standpoint:
BASIC doesn't use arcane characters for delimiters; you don't enclose blocks with curly braces, you use IF THEN ELSE ENDIF WHILE..WEND
BASIC has limited operators, giving users less choices to break their programs, unlike SPIN which has a lot of operators and some non-conventional syntax (less than/greater than or equal)
BASIC is rather limited as a language, even with MS Visual Basic extensions, it's still limited, which is generally good for neophyte programmers.
Java is less complex in many ways than C++, but is still difficult to properly master.
SPIN, while sharing many attributes with other good languages, relies on whitespace for block control, which is very difficult for many non-programmers to understand.
High level languages drag with them some very important things for neophytes: the implementation is defined in the language and thus must be implemented on the back end.
Things like file I/O and console I/O are defined as part of the BASIC language, which forces a BASIC interpreter to support the nuts and bolts transparently. Because the interpreter must support a lot of low level stuff, it makes running programs on the hardware, very transparent.
SPIN and C require the user to include objects to do even the most simplest of interfacing, though the PropGCC folks did a lot of work to make the runtime full featured and transparent.
BASIC would be required to support SD file I/O, console, serial, etc.
While BASIC may not give the user 8 COGS, if the runtime used 4 COGs and left the user to run the interpreter in 4 COGs, that would be a ton of processing power, especially with all of the acceleration and helpers implemented by the 4 COG kernel on the other part of the chip.
Just think, video modes are determined in the same manner as QBASIC, MODE 13h, MODE 10, etc. Handling I/O to various devices is already been solved in the language, so there isn't any re-invention.
I'm just laying out some of my thoughts, I know David said they have a CMM mode for GCC, but while that solves a technical issue in the backend, the language is still not as accessible.
P1 is pretty much married to Spin unless you want to significantly reduce potential application complexity. P2 will be much more language agnostic, even if the preferred high-level is *some* interpreted bytecode language. The playing field can be much more level between Spin2, C, some good structured Basic, Forth, and whatever else might present itself.
I don't know about that. In my C++ application I have 7500 LOC taking up 21KB in CMM mode. I think that's pretty level with Spin in terms of program complexity.
Edit: PropGCC does some really amazing optimization. If I compile the same program with no optimization in LMM mode it comes out to 96KB! With optimization it's about 38KB in LMM, and 21KB in CMM. 4x code size reduction all told.
Once Gcc is feature complete on the propeller, ...
What's missing? As far as I know, it's all there (including GDB in the most recent builds).
I too have hear the "Not another language" refrain. I know somebody who implemented his project in VHDL rather than on the Propeller just because he could cut and paste modules that he found online.
Things like file I/O and console I/O are defined as part of the BASIC language, which forces a BASIC interpreter to support the nuts and bolts transparently. Because the interpreter must support a lot of low level stuff, it makes running programs on the hardware, very transparent.
Despite the fact that I don't care for BASIC, there have been many times I've used GWBASIC as a glorified graphics calculator because of the transparency pedward mentions. I can start setting pixels 10 seconds after invoking GW, and have a useable graph of a function, filter response, or root locus in a few minutes. I harbor a secret desire to do whatever it takes, leveraging whatever tools are available, to have this same sort of functionality on the P2. In fact, I'd like to create a sort-of engineering workstation out of the P2, kind of like Tektronix used to have, only vastly faster and with much higher resolution.
It wasn't completely clear to me, but it seemed Kye is heading in this same direction. It's a fabulous pursuit, imho.
I harbor a secret desire to do whatever it takes, leveraging whatever tools are available, to have this same sort of functionality on the P2. In fact, I'd like to create a sort-of engineering workstation out of the P2, kind of like Tektronix used to have, only vastly faster and with much higher resolution.
It wasn't completely clear to me, but it seemed Kye is heading in this same direction. It's a fabulous pursuit, imho.
Kinda going off on a tangent, but I seem to recall that a basic compiler isn't that hard to write...
From a parser-lexer standpoint it should be fairly straightforward to write a parser for.
Eons ago I wrote a compiler and bytecode interpreter for a project at work. I seem to recall it was a fun endeavor, I'm sure Chip has fond memories of writing PBASIC.
With this tangent about BASIC, there's something I'm confused about.
Is there a dialect of BASIC that allows for variable scope?
(Local variables and global variables)
I say this because I too see the desire for "copy and paste" of source code.
If every variable is a global variable, then this code reuse concept falls flat on its face.
Example: the variable "A" is used somehow in the main loop, then calls a subroutine which also uses "A". Most BASIC variants will assume this is the same memory location. This will discourage and confuse the dont-really-want-to-learn-want-immediate-gratification users. Creating "rules" about making unique variable names also would kill the fun.
In some regards, this is why the object exchange wasn't so great for reuse. More often than not, you can't non-thinkingly drop in an object because the source file including the object also needed some nontrivial things written in it to support the object (constants, variables, arrays, etc.). Thankfully, an example project was pretty much included to show what to declare and how to use the object.
It's an interesting concept to think of an object as more than just the algorithm: it also includes the variables, constants, settings, and documentation surrounding it. Is there a better way to package these to drop them in more completely with an "import wizard" within the IDE?
You know, those old Tektronix workstations were capable of a lot. A company I worked for in the 80's had two of them. They used a tape cartridge for application storage. I think it would do data storage that way too, but these were equipped with paper tape read / write stations. (170K bytes per roll, BTW)
They used them to process sheet metal parts for manufacturing. One would input a tool definition via paper tape, run the application from the system tape drive, then proceed to input an NC program. Once that was done, a simulator could be loaded from the tape, and it would parse the NC program displaying the punch operations onto the storage phosphor display. If it looked good, write it to tape, if not, load editor and continue.
Among the tapes was one that was just a default system tape containing the Tek BASIC like language. It was quite powerful! The vector based storage phosphor worked a lot like a bitmap does today. You could issue a clear for the whole screen, or a region, then plot whatever you wanted to with fairly sophisticated commands. If you wanted hard copy of that display, the best option was a pen-plotter, but a camera worked in a pinch too, so long as the lights were out and the exposure time was reasonable.
UI consisted of an analog joystick, keyboard and a few dedicated system buttons. That workstation got used for all sorts of manufacturing calculations. Insert that tape and suddenly you could do stress plots, calculate bend factors, and do tonnage calculations for a variety of operations, among many other things.
A P2 running with the nice, fast storage we've got today can host a ton of useful programs, and the I/O can perform many tasks. Yeah, count me in for the "bench computer" I think it would be extremely useful.
Kinda going off on a tangent, but I seem to recall that a basic compiler isn't that hard to write...
From a parser-lexer standpoint it should be fairly straightforward to write a parser for.
Eons ago I wrote a compiler and bytecode interpreter for a project at work. I seem to recall it was a fun endeavor, I'm sure Chip has fond memories of writing PBASIC.
Comments
I recently attended a robot "fest" and was surprised, if not downright shocked, at all the Arduinos in use. In fact, I didn't see anything else. I stopped and asked one of the "artists" whom I noticed was using Arduinos and she was oh-so excited about it, how she was new at this automation thing and didn't really understand what she was doing but that didn't matter because she was just cutting and pasting code and getting her sculptures to move around, all for "free". She seemed so enthusiastic about this magical phrase "open source" even though she couldn't really tell me what that meant other than she got to cut and paste code, whose operation she didn't understand, all for "free."
Also, recently I've been pestered to help some youngsters with their Arduino projects, so I bit the bullet and started learning about it. In my opinion, the Arduino's success must be a cultural one, not a technical one. This interrupt business is totally idiotic to me. And I can't seem to breathe without counter modules to work with. Nevertheless, the Arduino is everywhere. Everybody seems to be adapting their stuff to it, or figuring out ways to interface with it. I noticed recently that there's a language called ROBOTC, which apparently works on Lego Mindstorms, VEX, and - you guessed it - Arduinos. Up until recently, my local school system was debating whether to teach with Lego or Vex but now they don't have to worry so much because, I guess, ROBOTC bridges those two worlds???
A couple days ago, I had wanted to start a thread and ask forum members here what sort of Arduino shields they might be working on using the Propeller, but I decided against it because I thought it might be inappropriate to discuss a "competing" product here on the Parallax forum. But, honestly, for all its popularity, I find the Arduino to be clunky to use. Yet, I can easily see how Propeller-based shields would not only give the Arduino the brains it is lacking but they would also serve as a gateway drug for the Propeller by itself. Once Arduino users find out how liberating these new shields would be, I'm sure a great number of them would want to start hacking into the shield itself, only to find it is an awesome, easy-to-use device in its own right.
Personally, I will continue using Propeller chips for my own gadgets, but it would be great to see Parallax grab the bull by the horns and embrace this Arduino thing a little bit so that I don't get so many blank looks when I tell people what my gadgets are using. I know the Propeller is about as open-sourced as it needs to be for 99% of the users out there, but as I said, this appears to be a cultural phenomenon, not a technical one. The way into the hearts of the masses might be to get into the shield business and lure in customers by enticing them to look under the hood.
My 0.02 yuans worth.
Good observations and suggestions, I think, ElectricAye.
The Arduino folks streamlined the development system, concealed the nuts and bolts as much as possible, and made it especially easy to do that code cut-and-pasting even though, under the hood, the Arduino conceals an incredibly byzantine and hazard-prone interrupt system, counter array, and notoriously easy to misuse C++ language renamed "sketches." They then aggressively positioned it as a tool for non-technical people like artists to do technical stuff like making their sculptures move and react to viewers.
Parallax marketed the P1, like the Basic Stamp, as an educational system which would, through use, help a person become technical. The Spin language is shot through with teaching gimmicks that force you to deal with finite math, memory spans, and binary logic operations in order to get anything done. It's extremely, fantastically powerful once you get used to it and prepares you well for any of the other more common languages, where in particular the expression evaluators are almost all subsets of the Spin evaluator. It denies you GOTO and global vars and workarounds instead forcing you to think about structurally organizing a program. It is about the only language other than Forth I can think of that really, honestly, has no available equivalent for GOTO, for reals, no kidding, really.
What Spin is not is a sexy dressing gown for an ugly little package designed to make it attractive to artists and non-technical types as well as kids. If you want to understand why there is an Arduino on every page of MAKE: magazine and a Propeller in every other issue, that's the reason in a nutshell. I don't believe the Arduino developers were sinister, but I do believe they were more interested in getting a tool into the hands of artists than they were in getting the artists to understand that tool, and that's why it's got the market share it does.
Chip was not interested in making it unnecessary for us to think about our software; Chip was interested in teaching us how to think about our software. One of those things will be more popular than the other every time.
One of the chief virtues of the BASIC Stamp was the simple language and relatively confined design. I find that the more versatile we make things, the less apt they are to be used because the majority of folks don't find them simple enough; people want boundaries to confine them.
The Arduino is a good example of this ethos. It is constrained, it doesn't do everything, but by virtue of its C roots, people *can* extend it more than the neophytes would.
Spin isn't a bad language, it is actually a really fine language in a lot of respects, but the "oh not another language" sigh is heard often.
Perhaps making a BASIC compiler available along side the Spin compiler wouldn't be a bad thing for the hobby crowd.
QBASIC is a very useful, but simple addition to the original BASIC language, I think that would be an excellent starting point, syntactically, for a language.
I'm simply stating that making the technology accessible is important. The real tragedy is that Chip designed an assembly instruction set that is really intended for programmer to use, not compilers, yet this elegant and complex instruction set can only be appreciated by an elite few in the scope of potential users.
Sounds like Parallax needs to step up its game of "SPREADING DEMOCRACY".
But, its time to do better. It's very much possible now to bring professional level clean and polished tools to the hobbyist community for free. Open source tools like Scintilla allow easy integration of real coding features into native platform IDEs. Integration of tools like CMake or SCons allow for a real build system to be under the hood of the IDE so that you can tweak your code easily to do more than the default.
Once you start looking for things to do better than the Arduino, you find many. There are so many useful features that can be built into the tools you use to code easily. Not even talking about hardware, one can build much better software.
I've actually been working on building a really good IDE for this stuff for a while now. One super easy thing to do but which would be so valuable is to include graph support into the IDE itself.
Like... have you ever wanted to just print values to a graph, for a sensor of whatever? Well, its not that hard to build right into the IDE and create nice looking graphs from your development board. Here's of example of what I'm working on will be able to support: http://www.workslikeclockwork.com/index.php/components/qt-plotting-widget/.
By just simple making it so that the IDE intercepts built in ACSII commands sent to the serial port you can easily add graph features to the IDE (yes, maybe a packet or two gets corrupted here or there, but that's okay).
Or, what about having built in graphics features you you can display custom images from your microcontroller? With Qt, its easy to make an image and paint whatever you want to it controlled by the serial port.
.... or what about having the built in ability to read, write, modify the EEPROM for settings control? A built in hex editor? Maybe there's an SD card card socket on the microcontroller board by default so that becomes a standard feature? Then we can build in remove file transfer through the IDE to the SD card...
...there's like a never ending list of features you can build in.
---
Anyway, all that said, its the user experience that matters. Arduino is not pushing the limits of this in their software at all. I attend to do this now. It's something incredibly compelling for me to do and I have enough experience and free time now to really push the envelope.
I think with an awesome IDE on the computer coupled with matching hardware that is flexible and not full of complications and holes will allow the propeller 2 to do very well.
What's more important than hardware features is your ability to get your project done quickly and easily. That is what the Arduino has over the propeller right now. Its very easy on the Arduino to do a few things (but, not a lot of things... the Arduino starts to break down then). What the propeller 2 will give people is the ability to do a lot of things well.
Imagine, by default, the library supports - servo/debounced i/o/pwm/stepper/encoder/quadrature encoder/adc/dac/etc... on every pin at the same time! Default SD card support! Fast programming with built in code protection! There are plenty of things to just have built in.
---
Right now I'm still working on crafting my project idea. I won't have anything ready for release soon. But, hopefully by August I'll have enough of the programming environment done to start working on C libraries for the propeller. It's perfectly possible to have full Arduino support. Interrupts? Well, we can simulate them with event driven code. While the user will still be able to bug everything with an infinite loop in their code, you more or less can easily have Arduino code compatibility.
...
Anyway, I've said enough on this for now. Back to work.
I've kept quiet because I didn't spring for the FPGA, hoping I could wait for a working chip from the run. (You guys have made me sorry I waited. {looking at you Baggers!}
I hear this feedback from a couple people who are close to me and use the Propeller. They have limited time to play and want to quickly do cool projects they are interested in, not have to go to school to learn why the microcontroller is doing what it is doing.
Keep in mind that "thinking" is hard. The "masses" aren't interested in that kind of work.
Jeff
The Arduino has benefited from its watered-down dialect of C++ and all the copy-n-paste code ready-made for use without much thought. It's a bit too simplistic a platform, I think, for much of what I would call real engineering work, nor is it a good platform for teaching microcontroller programming, either. That said, there are lessons to be learned from its success that could possibly be applied to the Propeller (both I and II).
Will Propgcc bridge the divide? That doesn't seem likely. So, Pedward has a valid point: A robust full-featured BASIC language tool for the Propeller, one that is easy to use but doesn't obfuscate the hardware details, could be a huge boon to the Prop.
I think this provides a migration strategy for existing STAMP users more than it would be an attraction to "new" people. I think that people unfamiliar with the field are more likely to gravitate toward a C-like language based on what their peers, magazine articles, available books at B&N, and the web are telling them. This would result in little more than Parallax poaching their own customer base.
Agreed. Further, there's the issue that it's interpreted and the perceived performance issues related to that (regardless of the actual merits of the argument). Realistically, for arduino-like applications, Spin on the P2 would be more than sufficient. But to convince a novice of this is a real challenge.
I wonder if it would be possible to develop a replacement syntax for PASM that didn't look like assembler. All the power of PASM, but a more "high level" look and feel...
In fact, with the appropriate *cough* spin, P2 might be the platform that out-Arduinos the Arduino, by offering a similarly attractive thought-free playland with all that so un-Arduino-like general purpose I/O on one dev system, while providing the raw power for cutting-edge projects with multichannel nanosecond timing that the Arduino could never duplicate on another. But the marketing could be tricky; a lot of artists like shiny things but they don't want to think you're going to turn them into engineers, who everyone (in certain circles at least) knows have no imagination and the artistic sense of HAL 9000.
Of course not all Arduino users are like that, but that's what got Arduino so much exposure. It broke loose from the hobby computer hobby robot and maker crowd into a larger population of non-technical art and crafts people. The technical people tend to see Arduino for what it is but they use it anyway because there's so much Smile made for it now.
Edit: It would be kind of hilarious if P2 could host Arduino sketches. Just a thought.
Of course. There are a few examples of High Level Assembler out there... HLA by Randall Hyde, and PL/M was a step above assembler.
That said, I think the GCC can generate ASM (for small code blocks, of course), and provided it can also in-line ASM, and list well, then it should give All the power of PASM, but a more "high level" look and feel...
Certainly performance is one knock. The other being simply that it's an obscure, one-off language. In fact, most objections you see fall along those lines. Thus, practically any firmly established language would be an easier sell. But one which naturally lends itself to more of a RAD-type work flow (real or widely perceived) would be even better yet.
AFIK Arduino sits on top of Gcc. Once Gcc is feature complete on the propeller, I really don't see why you couldn't run Arduino sketches. Well it'd be best to port the Arduino library and maybe the boot-loader. (only thing the prop1 is missing is an ADC...)
Lawson
The reason why SPIN and PASM are a good fit for the Propeller architecture is because of the architecture itself.
Compiled high level languages are designed to run in one monolithic memory space, not the heterogeneous design of the Propeller. This creates the obvious conflicts of needing an LMM kernel to bridge that divide.
In my opinion, the bytecode and interpreter route is a very robust way to attack this architecture. SPIN uses 8bit bytecodes, effectively increasing code density and reducing the memory pressure put on the hub.
Taking the same underlying architecture of SPIN, but marrying it with an advanced BASIC would give users who fear hearing of a new proprietary language, an option that sounds familiar.
For that matter, if you extend this model, you really end up with a design where you have a general purpose bytecode interpreter that is re-targetable by choosing a different bytecode compiler.
The compiler can compile C, BASIC, Java, SPIN, etc.
Maybe BASIC isn't the right language, but I see a few valuable things about it from a lexical standpoint:
BASIC doesn't use arcane characters for delimiters; you don't enclose blocks with curly braces, you use IF THEN ELSE ENDIF WHILE..WEND
BASIC has limited operators, giving users less choices to break their programs, unlike SPIN which has a lot of operators and some non-conventional syntax (less than/greater than or equal)
BASIC is rather limited as a language, even with MS Visual Basic extensions, it's still limited, which is generally good for neophyte programmers.
Java is less complex in many ways than C++, but is still difficult to properly master.
SPIN, while sharing many attributes with other good languages, relies on whitespace for block control, which is very difficult for many non-programmers to understand.
High level languages drag with them some very important things for neophytes: the implementation is defined in the language and thus must be implemented on the back end.
Things like file I/O and console I/O are defined as part of the BASIC language, which forces a BASIC interpreter to support the nuts and bolts transparently. Because the interpreter must support a lot of low level stuff, it makes running programs on the hardware, very transparent.
SPIN and C require the user to include objects to do even the most simplest of interfacing, though the PropGCC folks did a lot of work to make the runtime full featured and transparent.
BASIC would be required to support SD file I/O, console, serial, etc.
While BASIC may not give the user 8 COGS, if the runtime used 4 COGs and left the user to run the interpreter in 4 COGs, that would be a ton of processing power, especially with all of the acceleration and helpers implemented by the 4 COG kernel on the other part of the chip.
Just think, video modes are determined in the same manner as QBASIC, MODE 13h, MODE 10, etc. Handling I/O to various devices is already been solved in the language, so there isn't any re-invention.
I'm just laying out some of my thoughts, I know David said they have a CMM mode for GCC, but while that solves a technical issue in the backend, the language is still not as accessible.
SPIN on P2 will be on par with PASM on P1. I'm not sure performance will be such an issue, particularly if in line LMM were an option.
No, its not! (See links in my SIG!)
I don't know about that. In my C++ application I have 7500 LOC taking up 21KB in CMM mode. I think that's pretty level with Spin in terms of program complexity.
Edit: PropGCC does some really amazing optimization. If I compile the same program with no optimization in LMM mode it comes out to 96KB! With optimization it's about 38KB in LMM, and 21KB in CMM. 4x code size reduction all told.
What's missing? As far as I know, it's all there (including GDB in the most recent builds).
I too have hear the "Not another language" refrain. I know somebody who implemented his project in VHDL rather than on the Propeller just because he could cut and paste modules that he found online.
Despite the fact that I don't care for BASIC, there have been many times I've used GWBASIC as a glorified graphics calculator because of the transparency pedward mentions. I can start setting pixels 10 seconds after invoking GW, and have a useable graph of a function, filter response, or root locus in a few minutes. I harbor a secret desire to do whatever it takes, leveraging whatever tools are available, to have this same sort of functionality on the P2. In fact, I'd like to create a sort-of engineering workstation out of the P2, kind of like Tektronix used to have, only vastly faster and with much higher resolution.
It wasn't completely clear to me, but it seemed Kye is heading in this same direction. It's a fabulous pursuit, imho.
Yes, yes, yes! That's what I want to see, too.
From a parser-lexer standpoint it should be fairly straightforward to write a parser for.
Eons ago I wrote a compiler and bytecode interpreter for a project at work. I seem to recall it was a fun endeavor, I'm sure Chip has fond memories of writing PBASIC.
Is there a dialect of BASIC that allows for variable scope?
(Local variables and global variables)
I say this because I too see the desire for "copy and paste" of source code.
If every variable is a global variable, then this code reuse concept falls flat on its face.
Example: the variable "A" is used somehow in the main loop, then calls a subroutine which also uses "A". Most BASIC variants will assume this is the same memory location. This will discourage and confuse the dont-really-want-to-learn-want-immediate-gratification users. Creating "rules" about making unique variable names also would kill the fun.
In some regards, this is why the object exchange wasn't so great for reuse. More often than not, you can't non-thinkingly drop in an object because the source file including the object also needed some nontrivial things written in it to support the object (constants, variables, arrays, etc.). Thankfully, an example project was pretty much included to show what to declare and how to use the object.
It's an interesting concept to think of an object as more than just the algorithm: it also includes the variables, constants, settings, and documentation surrounding it. Is there a better way to package these to drop them in more completely with an "import wizard" within the IDE?
You know, those old Tektronix workstations were capable of a lot. A company I worked for in the 80's had two of them. They used a tape cartridge for application storage. I think it would do data storage that way too, but these were equipped with paper tape read / write stations. (170K bytes per roll, BTW)
They used them to process sheet metal parts for manufacturing. One would input a tool definition via paper tape, run the application from the system tape drive, then proceed to input an NC program. Once that was done, a simulator could be loaded from the tape, and it would parse the NC program displaying the punch operations onto the storage phosphor display. If it looked good, write it to tape, if not, load editor and continue.
Among the tapes was one that was just a default system tape containing the Tek BASIC like language. It was quite powerful! The vector based storage phosphor worked a lot like a bitmap does today. You could issue a clear for the whole screen, or a region, then plot whatever you wanted to with fairly sophisticated commands. If you wanted hard copy of that display, the best option was a pen-plotter, but a camera worked in a pinch too, so long as the lights were out and the exposure time was reasonable.
UI consisted of an analog joystick, keyboard and a few dedicated system buttons. That workstation got used for all sorts of manufacturing calculations. Insert that tape and suddenly you could do stress plots, calculate bend factors, and do tonnage calculations for a variety of operations, among many other things.
A P2 running with the nice, fast storage we've got today can host a ton of useful programs, and the I/O can perform many tasks. Yeah, count me in for the "bench computer" I think it would be extremely useful.
There are several organizational constructs: Namespaces, Modules, Procedures, and Blocks.
Namespace is probably borrowed from C++ in many ways, I'm not familiar or interested in this.
Modules are the equivalent of Objects in SPIN.
Procedures are subroutines defined within a program or Module.
Block are language block level elements such as do..loop, while..wend, and if..end if.
Within a Module you can define variables with DIM, Public, and Private. DIM and Private are synonyms at this level.
Within a procedure or block, DIM declares a variable only within that scope.
For simplicity, I would recommend support for confining scope to public (global), module, and procedure.
Here's a reference: http://msdn.microsoft.com/en-us/library/1t0wsc67.aspx
What BASIC does lack is an adopted or recognized standard, there are some but mostly ignored.
I work on ON-CHIP Basic interpreter that will made P2 like old Basic computer's
But my version will be single variable scope
And old fasion with line numbers
Basic is simple, but it has so many flavours, it is hard to nail down.
Ideally, it needs to deliver BOTH an Interpreter AND a Compiler to PASM pathway flow, with minimal source-block changes.