This library is not going to use rendezvous tables.
Also, OpenSpin is largely without a maintainer, and to my knowledge, there are no new Spin compilers being developed. Thus, this library is to be limited to the current capabilities of OpenSpin unless a viable alternative Spin compiler emerges.
This library is not going to use rendezvous tables.
Also, OpenSpin is largely without a maintainer, and to my knowledge, there are no new Spin compilers being developed. Thus, this library is to be limited to the current capabilities of OpenSpin unless a viable alternative Spin compiler emerges.
That is not entirely true. OpenSpin is a verified compiler producing the same binaries as the PropToool does. It is written by a long time forum member with support of Parallax and Chip. It is open source and runs on a lot of different platforms.
I am quite sure that Chip will produce a Spin2 and then OpenSpin will be updated too.
There is also a ongoing effort to have Spin1 running on the P2 FPGA, quite promising!
This library is not going to use rendezvous tables.
Also, OpenSpin is largely without a maintainer, and to my knowledge, there are no new Spin compilers being developed. Thus, this library is to be limited to the current capabilities of OpenSpin unless a viable alternative Spin compiler emerges.
Is this going to be an official Parallax library? If so, don't they have to be consulted about what will and will not be included? Or is this your personal library?
Is this going to be an official Parallax library? If so, don't they have to be consulted about what will and will not be included? Or is this your personal library?
Hopefully, the singular, focussed vision of one individual will not be corrupted by groupthink.
I wonder if this will become the place to post a complete project including schematics?
This project does not replace OBEX. It is a collection of generic objects to improve the out-of-box experience of Propeller Spin. Anyone can propose additions to the library, however.
Thanks! Haha, hopefully integration into this project will prevent that from happening again. =P
Well, actually I'm going to attempt to make a contribution on the standard Parallax drivers.
Unless someone does the work to roll a lot of other stuff into this thing, the truth is the lost will remain lost, and a forum search along with grabbing some code to include in a project will remain the primary means of accessing those things. And perhaps that's just the best scenario too. It's a *lot* of work to get the many ways people have done video compliant with any standard at all. Likely not worth it. But, if someone has a project requirement that can be met, maybe taking a little time to work some code they find into it will be worth it. It's just not a one size fits all kind of thing.
Honestly, the ease with which people can do that in SPIN makes doing that plausible.
The primary reason I'm willing to give the Parallax drivers a shot here is their general utility, and if it's going to be labeled any kind of "standard", including the basics that have been included all along only makes sense, particularly given the amount and quality of documentation available. No other driver set has anything even close. That's supporting a good experience. And, a lot can be done with those basic drivers.
So this at least won't "lose" the basics. All good.
It will be a bit. Hopefully, not too long.
Perhaps a "Standard Documentation" project would make a nice compliment to this kind of thing. Or at the least, a list of references by some kind of topic. We've done 'em many times before though... Who knows?
This library is not going to use rendezvous tables.
Also, OpenSpin is largely without a maintainer, and to my knowledge, there are no new Spin compilers being developed. Thus, this library is to be limited to the current capabilities of OpenSpin unless a viable alternative Spin compiler emerges.
That is not entirely true. OpenSpin is a verified compiler producing the same binaries as the PropToool does. It is written by a long time forum member with support of Parallax and Chip. It is open source and runs on a lot of different platforms.
I am quite sure that Chip will produce a Spin2 and then OpenSpin will be updated too.
There is also a ongoing effort to have Spin1 running on the P2 FPGA, quite promising!
Interesting times are coming to us.
Mike
Ah, perhaps that was misleading. I am well-aware of the state of OpenSpin and have talked at length with Chip and a number of other people about a future Spin compiler.
The main point is that this project targets current Spin capabilities for current Propeller 1 offerings, including PropTool and PropellerIDE. It is a repackaging of available objects and should not require new compiler features to improvement.
In the future, new features may open up new possibilities, but this library is needed for current products before future ones.
This library is not going to use rendezvous tables.
Also, OpenSpin is largely without a maintainer, and to my knowledge, there are no new Spin compilers being developed. Thus, this library is to be limited to the current capabilities of OpenSpin unless a viable alternative Spin compiler emerges.
Is this going to be an official Parallax library? If so, don't they have to be consulted about what will and will not be included? Or is this your personal library?
Yes, I am directing this project as part of PropellerIDE.
Thanks! Haha, hopefully integration into this project will prevent that from happening again. =P
Well, actually I'm going to attempt to make a contribution on the standard Parallax drivers.
Unless someone does the work to roll a lot of other stuff into this thing, the truth is the lost will remain lost, and a forum search along with grabbing some code to include in a project will remain the primary means of accessing those things. And perhaps that's just the best scenario too. It's a *lot* of work to get the many ways people have done video compliant with any standard at all. Likely not worth it. But, if someone has a project requirement that can be met, maybe taking a little time to work some code they find into it will be worth it. It's just not a one size fits all kind of thing.
Honestly, the ease with which people can do that in SPIN makes doing that plausible.
Yes, I understand there are many scenarios that we couldn't possibly address. At the end of it all, this library will be more of a starting point than anything. But a starting point is a good thing to have, and more we can give people, the better the reaction they'll have when they buy their first Propeller.
Hopefully more people will want to contribute their objects as this project moves forward. =P
The primary reason I'm willing to give the Parallax drivers a shot here is their general utility, and if it's going to be labeled any kind of "standard", including the basics that have been included all along only makes sense, particularly given the amount and quality of documentation available. No other driver set has anything even close. That's supporting a good experience. And, a lot can be done with those basic drivers.
So this at least won't "lose" the basics. All good.
Perhaps a "Standard Documentation" project would make a nice compliment to this kind of thing. Or at the least, a list of references by some kind of topic. We've done 'em many times before though... Who knows?
I have a plan for this, which is why I'm enforcing markdown syntax in doc comments. Eventually I'm going to be introducing a revamped documentation view into PropellerIDE. It's going to be kind of like PropTool, but it's going to render the documentation into styled HTML for viewing. So Spin objects will be their own documentation, and it'll look nice, without any additional software. There can even be hyperlinks between objects and images! Woohoo!
I have a plan for this, which is why I'm enforcing markdown syntax in doc comments. Eventually I'm going to be introducing a revamped documentation view into PropellerIDE. It's going to be kind of like PropTool, but it's going to render the documentation into styled HTML for viewing. So Spin objects will be their own documentation, and it'll look nice, without any additional software. There can even be hyperlinks between objects and images! Woohoo!
I have a plan for this, which is why I'm enforcing markdown syntax in doc comments. Eventually I'm going to be introducing a revamped documentation view into PropellerIDE. It's going to be kind of like PropTool, but it's going to render the documentation into styled HTML for viewing. So Spin objects will be their own documentation, and it'll look nice, without any additional software. There can even be hyperlinks between objects and images! Woohoo!
I've seen that around the forums before. You did a really fantastic job on it! Unfortunately, I can't really use it. =(
One, it was written in Perl, whereas PropellerIDE is Qt/C++, and I need the IDE to be self-contained for use on mobile platforms. Two, I'm using Markdown, since support and processors for Markdown are very widely available which makes a lot of peripheral things much easier.
The fact that AUTODOC is written in Perl should not be a factor barring its adoption. I have an .exe that runs alongside the Prop Tool that places a DOC button on the Prop Tool's menu bar. If you press the DOC button, the Spin program currently showing in the edit window is examined for markup code. If such code exists, AUTODOC takes over and the doc view is shown in the user's default browser. If no markup code exists, the user is given the option to have markup boilerplate added, from which he can fill in the details. The same could be done with PropellerIDE on a variety of platforms.
Markdown is a generic markup system (originally written in Perl, BTW) for which allowances must be made to accommodate Spin's syntax. AUTODOC was designed from the ground up to be compatible with Spin in a way that barely makes a footprint on native Spin source code.
Anyway, AUTODOC is fait accompli; and in my immodest option, the output from it looks damn good. Why reinvent the wheel?
The fact that AUTODOC is written in Perl should not be a factor barring its adoption. I have an .exe that runs alongside the Prop Tool that places a DOC button on the Prop Tool's menu bar. If you press the DOC button, the Spin program currently showing in the edit window is examined for markup code. If such code exists, AUTODOC takes over and the doc view is shown in the user's default browser. If no markup code exists, the user is given the option to have markup boilerplate added, from which he can fill in the details. The same could be done with PropellerIDE on a variety of platforms.
Markdown is a generic markup system (originally written in Perl, BTW) for which allowances must be made to accommodate Spin's syntax. AUTODOC was designed from the ground up to be compatible with Spin in a way that barely makes a footprint on native Spin source code.
Anyway, AUTODOC is fait accompli; and in my immodest option, the output from it looks damn good. Why reinvent the wheel?
-Phil
Well, nothing is set in stone, but we're getting into a whole other topic entirely. I'll message you so we can talk about it in more detail.
I've finished renaming the functions in math.float. The pesky non-removable Fs in function names are now at the end of function names so auto-complete is easier. I've also simplified the API for com.spi so you don't have to keep passing the pins and modes to send and receive.
Calculator is a little integer calculator over the serial terminal. I'd like to create an alternate version of this demo that uses a 4x4 keypad and character LCD. That'd be cool. =P
This library is not going to use rendezvous tables.
Also, OpenSpin is largely without a maintainer, and to my knowledge, there are no new Spin compilers being developed. Thus, this library is to be limited to the current capabilities of OpenSpin unless a viable alternative Spin compiler emerges.
Is this going to be an official Parallax library? If so, don't they have to be consulted about what will and will not be included? Or is this your personal library?
Yes, I am directing this project as part of PropellerIDE.
Okay, thanks for clarifying. As Phil mentioned in another post, a single vision has some advantages. However, I would hope you would be open to good ideas presented by others even if they require adjusting your philosophy a bit. I haven't done that much Spin programming so I won't push any of my ideas very strongly but I think there are others here who do have more experience with Spin than either of us and who are likely to have good ideas.
Also, OpenSpin is largely without a maintainer, and to my knowledge, there are no new Spin compilers being developed. Thus, this library is to be limited to the current capabilities of OpenSpin unless a viable alternative Spin compiler emerges.
spin2cpp is still under development. I admit that it's been sporadic, but it is absolutely my intention to make it possible to use spin2cpp (+ propgcc) as a drop in replacement for OpenSpin in tools like PropellerIDE, and perhaps eventually to provide some Spin language extensions. Which is a whole other topic and probably needs a new thread.
JonnyMac has a great template/skeleton program that has been a big help to me starting out Spin projects. I think some skeleton items like this included in the standard library would be a big help to beginners.
There is also a lot of great code scattered throughout the threads that isn't in OBEX for one reason or another. Some are just little snippets and tricks but very valuable pieces of "standard code".
It's a lot of the code that Potatohead mentioned (Mr. Spud?) I'm not sure how we round all that up into a useful collection. Read through all the postings from JonnyMac, PhiPi, Duane, Clusso99, Peter, Mike Green, Bill Henning, etc., etc.??
Also, OpenSpin is largely without a maintainer, and to my knowledge, there are no new Spin compilers being developed. Thus, this library is to be limited to the current capabilities of OpenSpin unless a viable alternative Spin compiler emerges.
spin2cpp is still under development. I admit that it's been sporadic, but it is absolutely my intention to make it possible to use spin2cpp (+ propgcc) as a drop in replacement for OpenSpin in tools like PropellerIDE, and perhaps eventually to provide some Spin language extensions. Which is a whole other topic and probably needs a new thread.
Eric
Quite a while back I suggested that spin2cpp might be considered as the official Spin compiler for P2. With the larger hub memory and hubexec, it would make sense to have a natively compiled version of Spin and spin2cpp already has much of what is necessary.
Brett, I will get a Prop setup to take a pass at the standard video system.
Should there be display.tv.demoxxx ?
So three cases...
Text, Graphics, Demo. They can turn it on as text, can turn it on as graphics, optionally use the graphics cog, and run some graphics on it.
I'm thinking about the demo object, because it is documented, and a few other simple demo objects that address colors, tiles and such like I have in the one I linked to you.
RE:spud. Of course. Let's say the powers that be aren't on board with spud, bit that does not bean we can't use it anyway. I like to have a bit of fun with that stuff, and it's all good.
@msrobots, yeah. Baby steps. I thought on that last night while making some P2 code, and I think the best move is to help get basics done, then when there is traction, others may assemble submissions. Too much, and it won't ever get done. And a lot of code will take considerable effort to make compliant. I don't see that happening, unless people have a reason.
Honestly, those basics can do a lot. A newbie should be able to get going, then jump into the deep waters with the rest of us.
JonnyMac has a great template/skeleton program that has been a big help to me starting out Spin projects. I think some skeleton items like this included in the standard library would be a big help to beginners.
I second that. I have found JonnyMac's template and spin programs extremely good value.
I would like to see his thoughts and input on this new library thread.
JonnyMac has a great template/skeleton program that has been a big help to me starting out Spin projects. I think some skeleton items like this included in the standard library would be a big help to beginners.
The new organization guidelines include a templates/ folder that will show up inside PropellerIDE when the library is in the path. Adding the support in PropellerIDE is on my to-do list. Please feel free to submit any code skeletons that you're fond of!
There is also a lot of great code scattered throughout the threads that isn't in OBEX for one reason or another. Some are just little snippets and tricks but very valuable pieces of "standard code".
It's a lot of the code that Potatohead mentioned (Mr. Spud?) I'm not sure how we round all that up into a useful collection. Read through all the postings from JonnyMac, PhiPi, Duane, Clusso99, Peter, Mike Green, Bill Henning, etc., etc.??
This thread was opened for any and all suggestions of Spin code to include. I don't know where all of it is, so I need everyone's help to put it together. Don't be shy!
The suggestions I've gotten so far have been extremely helpful. I'm almost finished integrating Kye's ASCII0_STREngine as string.spin, and it's awesome, and I didn't even realize such a library existed before. In fact, with refactoring, and with a few of my own additions, there are now lots of string libraries and a corresponding reduction in duplicate code.
char.type - string char functions ( isUpper, isLower, etc.)
...
...
string - core string operations (like copy, append, etc.)
string.type - string type tests (like isUpper, isLower, etc.)
string.float - convert between floating point numbers and strings
string.integer - convert between integer numbers and strings
So please, keep the suggestions coming! Help me dig up new objects! Share your favorites that you can't live without! You are helping make this library possible!
Brett, I will get a Prop setup to take a pass at the standard video system.
Should there be display.tv.demoxxx ?
So three cases...
Text, Graphics, Demo. They can turn it on as text, can turn it on as graphics, optionally use the graphics cog, and run some graphics on it.
I'm thinking about the demo object, because it is documented, and a few other simple demo objects that address colors, tiles and such like I have in the one I linked to you.
If the core object lives in display.tv.spin, so the demos for that object will go in:
demos/display/tv/
Then, if there are these different wrappers around it:
display.tv.graphic
display.tv.text
Their demos will go in:
demos/display/tv/graphic/
demos/display/tv/text/
That way there can be multiple demos for each object and it's unambiguously known where to find them.
RE:spud. Of course. Let's say the powers that be aren't on board with spud, bit that does not bean we can't use it anyway. I like to have a bit of fun with that stuff, and it's all good.
@msrobots, yeah. Baby steps. I thought on that last night while making some P2 code, and I think the best move is to help get basics done, then when there is traction, others may assemble submissions. Too much, and it won't ever get done. And a lot of code will take considerable effort to make compliant. I don't see that happening, unless people have a reason.
Honestly, those basics can do a lot. A newbie should be able to get going, then jump into the deep waters with the rest of us.
Yeas to this as well. I expected that much of the integration work would fall on me signing up for this project, maybe all of it, but I think it's important, and the only chance of people getting excited and wanting to contribute is if they can see the value in it for themselves, and that'll take time.
I mean, heck, I'm thrilled to finally have a string library. I've needed one of those for years, but I always just worked around not having one. I'm very excited about this idea.
JonnyMac has a great template/skeleton program that has been a big help to me starting out Spin projects. I think some skeleton items like this included in the standard library would be a big help to beginners.
I second that. I have found JonnyMac's template and spin programs extremely good value.
I would like to see his thoughts and input on this new library thread.
Yes, that is a conversation that needs to happen. JonnyMac has made many fantastic contributions to the Propeller. I'd like to work with him and incorporate as much of it as I can.
Comments
Also, OpenSpin is largely without a maintainer, and to my knowledge, there are no new Spin compilers being developed. Thus, this library is to be limited to the current capabilities of OpenSpin unless a viable alternative Spin compiler emerges.
Thanks! Haha, hopefully integration into this project will prevent that from happening again. =P
That is not entirely true. OpenSpin is a verified compiler producing the same binaries as the PropToool does. It is written by a long time forum member with support of Parallax and Chip. It is open source and runs on a lot of different platforms.
I am quite sure that Chip will produce a Spin2 and then OpenSpin will be updated too.
There is also a ongoing effort to have Spin1 running on the P2 FPGA, quite promising!
Interesting times are coming to us.
Mike
-Phil
This project does not replace OBEX. It is a collection of generic objects to improve the out-of-box experience of Propeller Spin. Anyone can propose additions to the library, however.
Well, actually I'm going to attempt to make a contribution on the standard Parallax drivers.
Unless someone does the work to roll a lot of other stuff into this thing, the truth is the lost will remain lost, and a forum search along with grabbing some code to include in a project will remain the primary means of accessing those things. And perhaps that's just the best scenario too. It's a *lot* of work to get the many ways people have done video compliant with any standard at all. Likely not worth it. But, if someone has a project requirement that can be met, maybe taking a little time to work some code they find into it will be worth it. It's just not a one size fits all kind of thing.
Honestly, the ease with which people can do that in SPIN makes doing that plausible.
The primary reason I'm willing to give the Parallax drivers a shot here is their general utility, and if it's going to be labeled any kind of "standard", including the basics that have been included all along only makes sense, particularly given the amount and quality of documentation available. No other driver set has anything even close. That's supporting a good experience. And, a lot can be done with those basic drivers.
So this at least won't "lose" the basics. All good.
It will be a bit. Hopefully, not too long.
Perhaps a "Standard Documentation" project would make a nice compliment to this kind of thing. Or at the least, a list of references by some kind of topic. We've done 'em many times before though... Who knows?
Ah, perhaps that was misleading. I am well-aware of the state of OpenSpin and have talked at length with Chip and a number of other people about a future Spin compiler.
The main point is that this project targets current Spin capabilities for current Propeller 1 offerings, including PropTool and PropellerIDE. It is a repackaging of available objects and should not require new compiler features to improvement.
In the future, new features may open up new possibilities, but this library is needed for current products before future ones.
Yes, I am directing this project as part of PropellerIDE.
One can only hope. =P
Yes, I understand there are many scenarios that we couldn't possibly address. At the end of it all, this library will be more of a starting point than anything. But a starting point is a good thing to have, and more we can give people, the better the reaction they'll have when they buy their first Propeller.
Hopefully more people will want to contribute their objects as this project moves forward. =P
I'm excited to see what you come up with. =D
I have a plan for this, which is why I'm enforcing markdown syntax in doc comments. Eventually I'm going to be introducing a revamped documentation view into PropellerIDE. It's going to be kind of like PropTool, but it's going to render the documentation into styled HTML for viewing. So Spin objects will be their own documentation, and it'll look nice, without any additional software. There can even be hyperlinks between objects and images! Woohoo!
You can see how the S2.spin object is rendered by AUTODOC here:
-Phil
I've seen that around the forums before. You did a really fantastic job on it! Unfortunately, I can't really use it. =(
One, it was written in Perl, whereas PropellerIDE is Qt/C++, and I need the IDE to be self-contained for use on mobile platforms. Two, I'm using Markdown, since support and processors for Markdown are very widely available which makes a lot of peripheral things much easier.
The fact that AUTODOC is written in Perl should not be a factor barring its adoption. I have an .exe that runs alongside the Prop Tool that places a DOC button on the Prop Tool's menu bar. If you press the DOC button, the Spin program currently showing in the edit window is examined for markup code. If such code exists, AUTODOC takes over and the doc view is shown in the user's default browser. If no markup code exists, the user is given the option to have markup boilerplate added, from which he can fill in the details. The same could be done with PropellerIDE on a variety of platforms.
Markdown is a generic markup system (originally written in Perl, BTW) for which allowances must be made to accommodate Spin's syntax. AUTODOC was designed from the ground up to be compatible with Spin in a way that barely makes a footprint on native Spin source code.
Anyway, AUTODOC is fait accompli; and in my immodest option, the output from it looks damn good. Why reinvent the wheel?
-Phil
Well, nothing is set in stone, but we're getting into a whole other topic entirely. I'll message you so we can talk about it in more detail.
So, since the last report, I've been reworking the following objects.
https://github.com/parallaxinc/spin-standard-library/tree/master/library
I've finished renaming the functions in math.float. The pesky non-removable Fs in function names are now at the end of function names so auto-complete is easier. I've also simplified the API for com.spi so you don't have to keep passing the pins and modes to send and receive.
I added the following demos.
https://github.com/parallaxinc/spin-standard-library/tree/master/library/demos
Calculator is a little integer calculator over the serial terminal. I'd like to create an alternate version of this demo that uses a 4x4 keypad and character LCD. That'd be cool. =P
spin2cpp is still under development. I admit that it's been sporadic, but it is absolutely my intention to make it possible to use spin2cpp (+ propgcc) as a drop in replacement for OpenSpin in tools like PropellerIDE, and perhaps eventually to provide some Spin language extensions. Which is a whole other topic and probably needs a new thread.
Eric
There is also a lot of great code scattered throughout the threads that isn't in OBEX for one reason or another. Some are just little snippets and tricks but very valuable pieces of "standard code".
It's a lot of the code that Potatohead mentioned (Mr. Spud?) I'm not sure how we round all that up into a useful collection. Read through all the postings from JonnyMac, PhiPi, Duane, Clusso99, Peter, Mike Green, Bill Henning, etc., etc.??
Should there be display.tv.demoxxx ?
So three cases...
Text, Graphics, Demo. They can turn it on as text, can turn it on as graphics, optionally use the graphics cog, and run some graphics on it.
I'm thinking about the demo object, because it is documented, and a few other simple demo objects that address colors, tiles and such like I have in the one I linked to you.
RE:spud. Of course. Let's say the powers that be aren't on board with spud, bit that does not bean we can't use it anyway.
@msrobots, yeah. Baby steps. I thought on that last night while making some P2 code, and I think the best move is to help get basics done, then when there is traction, others may assemble submissions. Too much, and it won't ever get done. And a lot of code will take considerable effort to make compliant. I don't see that happening, unless people have a reason.
Honestly, those basics can do a lot. A newbie should be able to get going, then jump into the deep waters with the rest of us.
I second that. I have found JonnyMac's template and spin programs extremely good value.
I would like to see his thoughts and input on this new library thread.
The new organization guidelines include a templates/ folder that will show up inside PropellerIDE when the library is in the path. Adding the support in PropellerIDE is on my to-do list. Please feel free to submit any code skeletons that you're fond of!
This thread was opened for any and all suggestions of Spin code to include. I don't know where all of it is, so I need everyone's help to put it together. Don't be shy!
The suggestions I've gotten so far have been extremely helpful. I'm almost finished integrating Kye's ASCII0_STREngine as string.spin, and it's awesome, and I didn't even realize such a library existed before. In fact, with refactoring, and with a few of my own additions, there are now lots of string libraries and a corresponding reduction in duplicate code.
So please, keep the suggestions coming! Help me dig up new objects! Share your favorites that you can't live without! You are helping make this library possible!
If the core object lives in display.tv.spin, so the demos for that object will go in:
Then, if there are these different wrappers around it:
Their demos will go in:
That way there can be multiple demos for each object and it's unambiguously known where to find them.
Yerp. =D Thank you, MIT license!
Yeas to this as well. I expected that much of the integration work would fall on me signing up for this project, maybe all of it, but I think it's important, and the only chance of people getting excited and wanting to contribute is if they can see the value in it for themselves, and that'll take time.
I mean, heck, I'm thrilled to finally have a string library. I've needed one of those for years, but I always just worked around not having one. I'm very excited about this idea.
Yes, that is a conversation that needs to happen. JonnyMac has made many fantastic contributions to the Propeller. I'd like to work with him and incorporate as much of it as I can.
Thanks, that's what I was hoping to hear!