I am not trying to be funny, but I can't immediately see the advantages of programming the Prop in basic as opposed to spin or C.
Could one of you experts please explain the advantages of basic, as you see it.
I am sure I am missing something!
Thanks in advance.
Different people are comfortable with different languages. More options mean more people can use the Propeller. Also, Parallax has their legacy BASIC Stamp product and the users of that product are used to programming in BASIC. Providing a way to program the Propeller in BASIC could help some of those customers transition to the Propeller and ease them into multi-core programming.
I am not trying to be funny, but I can't immediately see the advantages of programming the Prop in basic as opposed to spin or C.
Could one of you experts please explain the advantages of basic, as you see it.
I am sure I am missing something!
Thanks in advance.
Spin is always interpreted, so can be compact, but s-l-o-w.
PropBasic can compile to run in a COG, and gets close to PASM Speed.
That said, Prop C is getting close to the same performance & choices.
Also, Parallax has their legacy BASIC Stamp product and the users of that product are used to programming in BASIC. Providing a way to program the Propeller in BASIC could help some of those customers transition to the Propeller and ease them into multi-core programming.
Certainly true, and I'm surprised Parallax are not more proactive on this upgrade pathway.
I am not trying to be funny, but I can't immediately see the advantages of programming the Prop in basic as opposed to spin or C.
Could one of you experts please explain the advantages of basic, as you see it.
I am sure I am missing something!
Thanks in advance.
PropBASIC uses a BASIC syntax but in reality, it's a high-level PASM or a sort of RAD for PASM. To me, it's better described as a translator because that's what ProBASIC does....translates directly to PASM without any overhead whatsoever.
You can write Cog code or LMM code or a mixture of both.
Personally, I don't see why anyone would use C on the Prop.....it's still trying to catch up with PropBASIC.
Microcontrollers: Isn't the objective to achieve maximum performance with the minimum power consumption and to be able to write/develop code in the least amount of time?
I just don't get why PropBASIC isn't more popular.
PropBASIC uses a BASIC syntax but in reality, it's a high-level PASM or a sort of RAD for PASM. To me, it's better described as a translator because that's what ProBASIC does....translates directly to PASM without any overhead whatsoever.
I guess that is true as long as you do not use LMM or...
You can write Cog code or LMM code or a mixture of both.
Hmm, I guess you cannot do that with PropC:-), but you can do XMM code with PropC.
Personally, I don't see why anyone would use C on the Prop.....it's still trying to catch up with PropBASIC.
I think that is backwards, try thinking in terms of drivers for SD, and other related driver items.
Microcontrollers: Isn't the objective to achieve maximum performance with the minimum power consumption and to be able to write/develop code in the least amount of time?
I thought I was getting very quick in developing code in PropC.
I just don't get why PropBASIC isn't more popular.
I just don't get why PASM isn't more popular. Or, I just don't get why FORTH(any version) isn't more popular.
Since I have developed code in PropC, PropBasic, and Spin, my order of usage preference is - PropC, PropBasic, Spin.
Now, that PropBasic has finally gotten a decent IDE, and is readably useful, my order of usage might change. But, a lot has to occur, it has to get past the fast coding of an LED blinker program, I think even FORTH has gotten way past that.
If you take the Activity board as an example, how far could you get using PropBasic with that board? For right now, PropBasic, works quite well with the QuickStart board, until you start to add peripherals that you want to use.
Now, that I think about it, somebody should pose the question to the Basic Stamp users - why aren't you using PropBasic?
I really like the details panel -- especially that it shows external libraries as collapsible elements, and that subs, funcs, vars, and IO pins are marked. That said, yesterday I went back to a project and most of the details panel was missing. I tried re-opening and it didn't make a difference.
I'm sure this is a minor snag and will be worked out; I just wanted to bring it to your attention.
I have noticed this behavior on occasion but I haven't gotten to the bottom of it yet. Does it help to re-compile? I also noticed that some of your files have .lib extensions. Should this be added as a recognized extension for PropBASIC?
However.... now I'd like to revert PropellerIDE to allowing compilation of traditional spin code... How to do that?
I'm getting compiler errors, so I guess the compiler choice needs to be changed back to spin language, but PropellerIDE GUI doesn't seem to allow that?
(not sure if this has been covered elsewhere- I thought I saw you mention something about the compiler choice being stuck at the moment... but cannot find that message!)
If your file has a .spin extension, it will compile as spin, and if it has a .pbas extension, it will compile as propbasic. PropellerIDE has no way of knowing how it should treat the file other than the file extension.
I noticed (at least on Mac OS X) that Propeller IDE is using bstc for .spin compiles, but the executable for openspin is also included within the app package. I get that bstc allows @@@ and since PropBasic emits @@@, there's good reason to have bstc available. But, shouldn't the Preferences panel allow me to use the openspin compiler for my .spin files (a personal choice, I know!)?
I really prefer to use a compiler whose source code is available/maintained/etc when I can (I get that PropBasic needs bstc for the interim and it's a smart decision to make bstc the default compiler for the .spin that PropBasic emits). So, can the Prefs panel allow me to switch spin compilers?
Thanks for all your hard work (having PropBasic available in an excellent IDE is a fantastic option)!
dgately
I absolutely intend to add alternative compiler support back in. See, the way it works now is that you can define build procedures in multiple steps, but it's extra work to have multiple procedures. So right now I can only one option, like this:
PropBasic:
- propbasic > bstc
Spin:
- bstc
But most of the hooks are in to support something more like this:
I am not trying to be funny, but I can't immediately see the advantages of programming the Prop in basic as opposed to spin or C.
Could one of you experts please explain the advantages of basic, as you see it.
I am sure I am missing something!
Thanks in advance.
I think that supporting more languages and environments on the Propeller adds value and gives people new ways to explore the platform. It's been my dream since I took over PropellerIDE to see it become home to all the wacky things out there for the Propeller. Maybe some day it could support Blockly, or you could program the Basic Stamp with it, and you could use the same tools on every platform you work on. Having PropBASIC gives people another tool in their tool chest to try, and that's awesome.
Maybe that isn't the question you were asking, but that's what I have to say on the matter. :P
It's been my dream since I took over PropellerIDE to see it become home to all the wacky things out there for the Propeller.
Is there a chance it will support C/C++ at some point?
When it does, it will complete the circle!!
Jazzed begot SimpleIDE to support C/C++ and then Spin was added and then it was made more Simple and finally Spin was removed which spawned PropellerIDE to support Spin in a cross-platform IDE and then PropBASIC was added and at some point, C/C++ will go back in so it has a non-Simple IDE and we're pretty much back where Jazzed started it all except we've gained PropBasic in a cross-platform IDE....How cool is that!!
Yep, starting to get way to complex. PropellerIDE should go back to a cross-platform Spin program, using the openspin compiler. Then when the P2 arrives, their can be a PropellerIDE2, strictly for use with the P2, do not want to make that to complex and have to deal with P1 stuff. Those that want to use PropBasic, you can use BST. For those that want to use C/C++, you can use Simple IDE, eventually that should be worked back to Simple IDE. This way everything is Simple and straight forward, you can choose what it is that you want to work with, Life is Good.
AFAIR OpenSpin does not support @@@. That is needed in PropBasic.
Great work Brett!
Homespun does support @@@ though I do not know if it's in the same stagnated status as BSTC. I would like to hear what Roy's feelings re supporting @@@ are currently. I seem to recall that he wasn't real hot on the idea in the past though I could be wrong. Brett, indeed, deserves accolades!
I have noticed this behavior on occasion but I haven't gotten to the bottom of it yet. Does it help to re-compile? I also noticed that some of your files have .lib extensions. Should this be added as a recognized extension for PropBASIC?
I use .lib extension just to keep my files straight. If there is no disagreement from others, I don't see why it couldn't be added to the list of recognized files.
Q: Since you're using BSTC, are you setting the switch so that it does dead code removal?
Suggestion: When all the tabs are closed, have the IDE invoke File\New so that the details panel gets cleaned-up.
I have noticed this behavior on occasion but I haven't gotten to the bottom of it yet. Does it help to re-compile? I also noticed that some of your files have .lib extensions. Should this be added as a recognized extension for PropBASIC?
I use .lib extension just to keep my files straight. If there is no disagreement from others, I don't see why it couldn't be added to the list of recognized files.
No disagreement here. I think that is a good proposal.
With my limited testing today on a win 10 system it ran most of my old source files except for those using Viewport gadgets. Of course I had never re installed it on this system! Glad to have basic for prop back!!
Homespun does support @@@ though I do not know if it's in the same stagnated status as BSTC. I would like to hear what Roy's feelings re supporting @@@ are currently...
Neither BSTC nor Homespun is actively supported, so I don't understand why it would be good to switch from BSTC to Homespun. I've never used Homespun, but I suspect it doesn't have all of the features of BSTC.
Neither BSTC nor Homespun is actively supported, so I don't understand why it would be good to switch from BSTC to Homespun. I've never used Homespun, but I suspect it doesn't have all of the features of BSTC.
To rephrase the question then, what is needed to retire any not-actively-supported, but necessary, parts of the program flow ?
Clearly the @@@ would have to be implemented in OpenSpin. In theory this shouldn't be that hard. However, I'm guessing that OpenSpin doesn't know the absolute addresses until the very end of the process. I'm basing this on some assumptions on how the Prop Tool compiles and links objects, and since OpenSpin is a port of the PropTool compiler it probably works the same. It appears that the Prop Tool removes duplicate objects at the very end of the compile and link process. I think BST does duplicate object removal as it's linking objects. At least this would explain why BST can handle programs that reference large objects many times, and the Prop Tool cannot. The Prop Tool will complain that such a program will overflow 64K of RAM even though the program is less than 32K in size. I don't know if OpenSpin has the same problem or not.
The @@@ operator could be implemented in OpenSpin by maintaining a list of address that would need to be resolved once the absolute addresses can be determined. That shouldn't be too hard.
There still may be 64K problem in OpenSpin that should be fixed also. Someone would need to test that to see if the problem exists in OpenSpin like it does in the Prop Tool.
I absolutely intend to add alternative compiler support back in. See, the way it works now is that you can define build procedures in multiple steps, but it's extra work to have multiple procedures. So right now I can only one option, like this:
PropBasic:
- propbasic > bstc
Spin:
- bstc
But most of the hooks are in to support something more like this:
This is probably a PropBasic and a PropellerIDE question. Below is a short snippet to show a general idea as to where I want to go.
In PropellerIDE, it has access to files like FDS, for use with Spin, in PropBasic you can INCLUDE Spin files, now how do you make PropBasic make use of these already available Spin files? It seems like there are some Spin file code that addresses some peripherals that are available and could be used as is? I guess the trick is to figure out what PropBasic can use from an existing Spin file.
The OBEX is loaded with all kinds of Spin objects, how could you make some of them work for PropBasic, and maybe be available within PropellerIDE?
Ray
' test3.pbas
'
DEVICE P8X32A, XTAL1, PLL16X
FREQ 80_000_000
INCLUDE "FullDuplexSerial.spin"
PROGRAM Start
start(31,30,0,115200)
END
I am not trying to be funny, but I can't immediately see the advantages of programming the Prop in basic as opposed to spin or C.
Could one of you experts please explain the advantages of basic, as you see it.
I am sure I am missing something!
Transition from the Parallax's many BASIC Stamp products - BOE Bot for example...
@Brett and Bean - Fantastic! Sorry I missed this when first posted.
Comments
PropBasic can compile to run in a COG, and gets close to PASM Speed.
That said, Prop C is getting close to the same performance & choices.
Certainly true, and I'm surprised Parallax are not more proactive on this upgrade pathway.
PropBASIC uses a BASIC syntax but in reality, it's a high-level PASM or a sort of RAD for PASM. To me, it's better described as a translator because that's what ProBASIC does....translates directly to PASM without any overhead whatsoever.
You can write Cog code or LMM code or a mixture of both.
Personally, I don't see why anyone would use C on the Prop.....it's still trying to catch up with PropBASIC.
Microcontrollers: Isn't the objective to achieve maximum performance with the minimum power consumption and to be able to write/develop code in the least amount of time?
I just don't get why PropBASIC isn't more popular.
Thus far, lack of supported IDE for one !
Hmm, I guess you cannot do that with PropC:-), but you can do XMM code with PropC.
I think that is backwards, try thinking in terms of drivers for SD, and other related driver items.
I thought I was getting very quick in developing code in PropC.
I just don't get why PASM isn't more popular. Or, I just don't get why FORTH(any version) isn't more popular.
Since I have developed code in PropC, PropBasic, and Spin, my order of usage preference is - PropC, PropBasic, Spin.
Now, that PropBasic has finally gotten a decent IDE, and is readably useful, my order of usage might change. But, a lot has to occur, it has to get past the fast coding of an LED blinker program, I think even FORTH has gotten way past that.
If you take the Activity board as an example, how far could you get using PropBasic with that board? For right now, PropBasic, works quite well with the QuickStart board, until you start to add peripherals that you want to use.
Now, that I think about it, somebody should pose the question to the Basic Stamp users - why aren't you using PropBasic?
Ray
I have noticed this behavior on occasion but I haven't gotten to the bottom of it yet. Does it help to re-compile? I also noticed that some of your files have .lib extensions. Should this be added as a recognized extension for PropBASIC?
If your file has a .spin extension, it will compile as spin, and if it has a .pbas extension, it will compile as propbasic. PropellerIDE has no way of knowing how it should treat the file other than the file extension.
I absolutely intend to add alternative compiler support back in. See, the way it works now is that you can define build procedures in multiple steps, but it's extra work to have multiple procedures. So right now I can only one option, like this:
PropBasic:
- propbasic > bstc
Spin:
- bstc
But most of the hooks are in to support something more like this:
PropBasic:
- propbasic > bstc
- propbasic > homespun
Spin:
- bstc
- openspin
- homespun
Just gotta go the extra step.
I think that supporting more languages and environments on the Propeller adds value and gives people new ways to explore the platform. It's been my dream since I took over PropellerIDE to see it become home to all the wacky things out there for the Propeller. Maybe some day it could support Blockly, or you could program the Basic Stamp with it, and you could use the same tools on every platform you work on. Having PropBASIC gives people another tool in their tool chest to try, and that's awesome.
Maybe that isn't the question you were asking, but that's what I have to say on the matter. :P
Jazzed begot SimpleIDE to support C/C++ and then Spin was added and then it was made more Simple and finally Spin was removed which spawned PropellerIDE to support Spin in a cross-platform IDE and then PropBASIC was added and at some point, C/C++ will go back in so it has a non-Simple IDE and we're pretty much back where Jazzed started it all except we've gained PropBasic in a cross-platform IDE....How cool is that!!
Ray
AFAIR OpenSpin does not support @@@. That is needed in PropBasic.
Great work Brett!
Mike R.
I use .lib extension just to keep my files straight. If there is no disagreement from others, I don't see why it couldn't be added to the list of recognized files.
Q: Since you're using BSTC, are you setting the switch so that it does dead code removal?
Suggestion: When all the tabs are closed, have the IDE invoke File\New so that the details panel gets cleaned-up.
nice work. Keep improving it.
BTW: it will be nice to be able to choose the installation path during the setup
No disagreement here. I think that is a good proposal.
Ray
Great job, cut my teeth on a BS2.
Good call Ray.
Yes, or even .pblib, to make that clearer still
On this topic, can BSTC now be retired ?
ie is the @@@ in Homespun equivalent enough to use, and can Homespun do dead code removal ?
To rephrase the question then, what is needed to retire any not-actively-supported, but necessary, parts of the program flow ?
The @@@ operator could be implemented in OpenSpin by maintaining a list of address that would need to be resolved once the absolute addresses can be determined. That shouldn't be too hard.
There still may be 64K problem in OpenSpin that should be fixed also. Someone would need to test that to see if the problem exists in OpenSpin like it does in the Prop Tool.
Sounds great, one recent tool that was looking simple and flexible, was
fastspin compiler for P2 by @ersmith
http://forums.parallax.com/discussion/comment/1374633/#Comment_1374633
Generates P1 or P2 output, and has in-line asm.
You could add that to the tools-list ?
In PropellerIDE, it has access to files like FDS, for use with Spin, in PropBasic you can INCLUDE Spin files, now how do you make PropBasic make use of these already available Spin files? It seems like there are some Spin file code that addresses some peripherals that are available and could be used as is? I guess the trick is to figure out what PropBasic can use from an existing Spin file.
The OBEX is loaded with all kinds of Spin objects, how could you make some of them work for PropBasic, and maybe be available within PropellerIDE?
Ray
Transition from the Parallax's many BASIC Stamp products - BOE Bot for example...
@Brett and Bean - Fantastic! Sorry I missed this when first posted.