I'd LOVE to see the ability to specify a com port to program with. I am often programming two props at the same time and am starting a project where I will want to program 3. Right now I run two versions of the prop IDE and it's a hassel.
Something like a define at the top would be great.
Goes a bit beyond just the tool itself, but I think integrated debugging in a chip of this class is something I'm sorely missing, and my trial experience with Viewport as a substitute was not terribly successful.
Another random thought which would be much easier to accomodate: :-)
Since indenting is critical to program execution interpretation, I occasionally found myself needing to indent/outdent large chunks of code to get it to match up to other nearby blocks, but the only way to do this was line-by-line, which is a little error-prone. It would be nice to be able to highlight a large block and have a toolbar button or kb shortcut to indent/outdent the whole block.
It is my hope that this post will gain momentum and that Parallax will take some of our suggestions and add them to the existing Propeller Tool. I personally have my hands full at the moment, however, I am sure that there are a lot of good programming editor templates available that could simplify the making of a better Propeller Tool.
Whilst everyone has a wish list of suggestions for the Prop Tool perhaps it's better that Parallax keeps it's resources focused on the Prop II chip.
Given that we have the Prop Tool, BST and HomeSpun I'm not sure the world needs yet another Spin compiler. Especially if it is using a different language syntax than standard Parallax Spin. Although there are those who would like to see an open source compiler for the Prop.
There are a few things mixed up together here, there are editor features we would like to see, like block indenting, but changes to the actual language syntax should be thought about carefully.
I'm not sure I have ever seen a compiled language that warns about running off the end of arrays and other such programming errors. It's hard to do in simple cases and in the general case probably impossible. For example
How does the compiler know that index maybe out of bounds without analysing the entire program execution and being aware of any inputs that may affect the index?
Having said all that I'd like for Spin methods to have local scope for the names of their local variables.
It is my hope that this post will gain momentum and that Parallax will take some of our suggestions and add them to the existing Propeller Tool.
If this were the case the Propeller tool would have toolbars and many other features of standard programming editors; and BST (Brad's Spin Tool -- something Parallax links to on its Propeller software page) wouldn't have been created. The better bet is to give Brad Campbell the suggestions as he seems much more open to incorporating user suggestions into BST, which also runs on multiple platforms (another suggestion Parallax has not made any apparent motion on).
Lest anyone misunderstand my tone, I'm not taking shots at my friends at Parallax. They only have so many resources and hours of the day in which to work with them. Thankfully, they have provided the tools in which to create 3rd-party programming products for the Propeller. This is good for everyone.
For future reference, I will not verify whether a desirable enhancement already exists or whether it is possible.
A debugger pane could definitely indicate an out of bounds array, during a debug run, but then it would also require programming to back it up.
Heater -> Open source sure would help the issue. I use the Propeller Tool because it is supplied by Parallax and they control the syntax. My wish list stems from a desire for better programming interface. If source code was supplied, I would not have to wish anymore, I could just create my own editor. But since the source code is unavailable, I have to rely on Parallax to provide a good editor for me. I am happy with all of Parallax's product's and services, except for the Propeller Tool.
I can fully understand Parallax being apprehensive about devulging all their source code. However, if they do not wish to provide this source code or a better editor, at the very least, it would be nice to have access to a Dynamic Link Library that is well documented.
Or if you are building your own editor/IDE and just need a compiler then why not use BSTC/BSTL or HomeSpun? Of course that does not help much with language extensions.
Of course that does not help much with language extensions.
A very rich potpourri of language extensions could be brought online via a preprocessor, without any need to tweak the existing compiler. Moreover, there's a distinct advantage in mapping to plain old Spiin, in that the lingua franca of Propeller programming remains intact without splintering into incompatible dialects. At the most fundamental level, what the Propeller Tool needs more than anything else is a set of hooks to user-scriptable preprocessors, which can be written in the language of one's choosing. But I despair of even that simple request ever being honored by Parallax, given Jeff's workload and/or other apparent priorities. I've made a complete nuisance of myself in the past regarding the Propeller Tool. And, although official acknowledgement has been forthcoming, the hoped-for action has never materialized -- even for something as simple as fixing the annoying block indent bug. The only feeling that remains after years of suggesting, cajoling, and complaining is one of utter despair, I'm afraid.
I have been to that page a hundred times and just passed right over the Propellent Library. I just cannot believe I have missed that all this time. But yes that is a very good start. At first glance it appears everything needed to create a better editor is in there, but I will have to mess with it a while just to check it out.
Hold onto your boots boys and girls, the Bruce is loose, and he is a C++ programming fool. I do not promise anything quickly, but I do promise to inspect the Propellent Library, and if it all works out the way I want it to, I just may create a C++ open source editor that links to the Propellent Library.
Have you messed the Propellent Library at all? It appears that the editor can be left out and the editing can be done by the program that links to it. If this is the case, then block indenting should not be that big of a deal if creating a new editor. Or at least I would not think so.
As for hooking user-scriptable preprocessors, could explain more so that I fully understand what you want. Picture this, a new editor program links to the Propellent DLL, but the new editor offers hooking user-scriptable preprocessors before compiling. Off hand I would not know how to hook user-scriptable preprocessors, but I am fairly certain that it is possible, because it will not compile until the new editor instruct the DLL to compile, so all preprocessing should be able to be done before telling the DLL to compile.
Given that we have the Prop Tool, BST and HomeSpun I'm not sure the world needs yet another Spin compiler.
We need a fully open source compiler written in C/C++ and compilable with any minimum ANSI C89 compiler/tool-chain. Parallax is finished with the current Propeller Tool. The rest is up to the community.
Yes indeed, a lot can be done with a pre-processor. After all the original C++ compiler, cfront, could be thought of as a pre-processor for C.
Bruce,
Glad to be of some little help. Sounds like you have got yourself a project:)
Can I suggest you have a look at Qt as a framework to build it on. There is a nice text edit class in Qt that is easy to add syntax highlighting to.
Us Linux users are going to be left out in the cold with the propellent DLL. Perhaps there should be an option to use BSTC or HomeSpun as the compiler.
We need a fully open source compiler written in C/C++ and compilable with any minimum ANSI C89 compiler/tool-chain. Parallax is finished with the current Propeller Tool. The rest is up to the community.
<edited> I'm just old and bitter.Ignore the man behind the curtain!
<edited> I'm just old and bitter.Ignore the man behind the curtain!
I won't venture to guess what was said behind the curtain. If BSTC was fully open source it might help those who "need something" that is fully open source. But that will never happen?
Don't get me wrong. I use BSTC and BST all the time and definitely appreciate the effort given. Let's all just hope you don't totally lose interest or find yourself otherwise impaired.
Meanwhile the closest potential we have to fully open source is Sphinx on a SpinSimulator.
Time to re-ask Parallax the old question... Why not pay Brad to open up the bst source (compiler and editor) or Michael to open up the homespun source (compiler)?
Why not pay Brad to open up the bst source (compiler and editor) or Michael to open up the homespun source (compiler)?
I have the greatest respect for both Brad and Michael and stand in awe of their respective accomplishments. But this, unfortunately, is not a solution for Parallax, unless they intend to jettison their own Prop Tool and start over (which might not be such a bad idea).
To understand why, go back to Parallax's beginning when the shoe was on the other foot. Parallax was the "Brad and Michael" to Microchip's PIC assembler. The Parallax PIC assembler had much superior mnemonics to the completely opaque and convoluted Microchip syntax (which was inherited from General Instruments). And, although it gained some traction among hobbyists and small-business PIC programmers (myself included), it never enjoyed an imprimatur from Microchip, since they had their own development tools. For the Parallax assembler to rise to the top, Microchip would have had to dump their own assembler (and the likes of MOVWF) for the more rational (and Intel-like) Parallax syntax.
What Parallax needs to do is either clear the deck for Jeff to concentrate on the Parallax Prop Tool, hand it off completely to another programmer, or jettison it entirely in favor of third-party software (which Parallax would have to buy outright and maintain in-house). The present situation is simply untenable. In any event, multiple standards cannot be allowed to rule, as such a situation would muddy the waters too much for selling the Propeller chip to large OEMs.
The Propeller 1 is a great processor and was a real breakthrough in processor design. I think its time to start
thinking about the Propeller II chip and how to adapt the Propeller Tool to support the new chip.
Many of us have maxed out the Prop 1 and spent lots of time converting spin code to assembly just to fit our
programs in such a small ram. I think Parallax is doing a great job considering what they have to work with.
Its amazing that just a handful of guys can do so much.
Not that I have experience on par with contributors to this thread, but the Prop tool is primarily an editor/compiler which requires the user to create little code inserts to debug their main code. There is no real time memory window or simulator to allow stepping through a sequence to verify ones attempt. I thought the free SX editor-compiler-debugger was well done all in one software. Again this may be relative to lack of experience or knowledge of other programs that work this way for the prop.
That leaves noobs to use the $150 Viewport, which from my understanding is intended to be used in concert with Prop tool. Going back and forth between them is quite a test in patience since they don't use common functions on the same keys, Dho! got me again! That's not what I wanted to do..... So, while switch windows editing the same code does not trigger the mind to shift procedures accordingly. It does have some swift features, but consumes resources on the chip to do so. Although it is annoying the variables on the watch list do not update the small memory window viewing the same memory address as expected. Still a lack of experience? The quite small user base could be a clue to that question.
It would be nice to have something cohesive without hoops and 3 ring circus tricks to prove code efficiently. Relative to the SX software, it was a conditional compiler that could alter the code accordingly to the chip being used. Don't see off hand why the prop or prop II would be that different to handle likewise. I don't think it too much to ask that it contains the editor/compiler/debugger or open source to allow the community to upgrade it while Parallax uses its talent resources on future growth of this product to sustain it as long term forward compatible.
Considering how the obex is a free open resource. It is a gift that keeps on giving and helps Parallax sell the platform line. It would appear a kick in the teeth to keep a cap on tools which make that possible and a community so willing to take the prop tool over from here. Unless of course there are non-competition or nondisclosure clause limitations to worry about.
It was good to read there is something in the source library, so maybe there is hope for improvements after all!
I thought the free SX editor-compiler-debugger was well done all in one software. Again this may be relative to lack of experience or knowledge of other programs that work this way for the prop.
Many people enjoy debuggers. Those who don't enjoy them have big egos or some other problem
Hmm. I thought it would be better to just delete this post, but apparently we no longer have that power.
That was a nice response. I found your viewpoint interesting and it also made me think a bit. Since being informed of the Propellent Library, I have been mulling this whole thing over, about whether to use some of my time to create a new open source editor. With the availability of Propellent, creating a better editor than the Propeller Tool really would not be a major endeavor, but a good run-time debugger that would step through the code, well that is quite a different issue. I think that might be quite more of an undertaking than I am capable of, but that is the kind of suggestions that I was looking for. It has been a while since I have done any major C++ programming, and I will have to brush up a bit on the debugger and debugger panes. I do not believe that utilizing Full Duplex in a seperate pane within an editor would be that big of a deal either, but in my opinion, that is not a true debugger.
Hi Jazzed,
That is one thing about this forum that I have not seen is the contrite ego's. At least with those I have read and been offered assistance from. Everyone seems to be quite helpful here. The purist in some realms senses he has earned his stripes the hard way.
I am from a machinist/tool maker/machine designer/electronic CNC field service tech back ground; now a Facilities/Maintenance Manager. You might imagine the ego's which go with that territory, but you can't kick'm to the curb when they have talents needed on the team, if ya know what I mean. LOL!
Bruce,
You are way ahead of me in having the ability to recognize how to get from point A to B on these tools. I can understand the run-time debugger being a challenge, but the only thing real time window I'd desire is seeing memory reflect my expectations or edit my way of coding it to meet the chips expectations. Which is one of the nice things Viewport does looking at variables in different bases you might be working with for that particular unit?
Stepping through the code would not need to be real time if not for some external event being time critical. But it could be halted with a break point to verify the expected change took place or find what failed in short order.
I wish I had the capability to offer more help than just adding wishes. My hat is off to those that can though!
We need a fully open source compiler written in C/C++ and compilable with any minimum ANSI C89 compiler/tool-chain. Parallax is finished with the current Propeller Tool. The rest is up to the community.
How about if we achieved this, almost exactly as you defined it above?
We've talked about open-sourcing the Propeller compiler in assembly, but have been hesitant due to (a) the language; (b) potential assistance required from Chip; and (c) giving away this piece of core intellectual work done by Parallax. However, I think we've got some good news to report! We've been able to assemble a plan involving a skilled programmer (and friend/customer) right here on these forums - Roy Eltham. Roy programs in C/C++ day in and day out, yet he's a humble guy and probably won't attempt to impress us with his skills or progress on this particular project. However, we've given him the source less than a few weeks ago and early reports are that he's 25-30% through the port to C/C++. If all goes according to plan the many enhancements you desire will be far more possible to achieve. We're taking a step-by-step approach to achieving the goal, and haven't defined what kind of open-source license we'd attach to the compiler. Not only must the code by converted, it must be tested in entirety and the release plan must be approved by Chip.
With the above being said, we'll turn it over to Roy for further comment. . . . he's probably not to sure what to divulge but I'll be sure he's got fairly loose fingers to answer any questions.
What an interesting development! I'm very happy to see some action being taken along these lines. What are the implications for the current Prop Tool? Is it to be replaced eventually, or will Roy's work be offered in parallel? Or is it too soon to tell?
I am pleased that someone from Parallax has paid attention to this post, thank you so much Ken. See guys, was that so hard?
Bruce
Happy New Year Bruce -- we appreciate the thread. You can certainly bet we're paying attention, even though I haven't posted anything on the forums in a couple of weeks. Chip just got his forum login straightened out last night - the first time since we moved to this new vBulletin tool. And Jeff is sequestered for software development so you won't be seeing him on the forums unless I inform him of an important post (like this one). Considering the forums are the single most important exchange with our customers we should be doing a much better job addressing these issues head-on. I'd like to share some general direction we're taking at the moment regarding software development inside Parallax.
A year from now, 2011 will be viewed as an important year in Parallax's history as we will have evolved the company to properly support Propeller sales to OEMs. This progress should stand next to our other past achievements: PIC Tools and emulators, BASIC Stamp 1 and 2 (and the BS2 SX-based models), Stamps in Class, the SX chip and tools and the development and release of the Propeller. Just like Leon pointed out, if we want to be taken seriously in the chip industry then a big part of our plan should include more professional development tools.
Our software development strategy has two approaches, and a third one that's a bit too early to discuss but I'll tell you about it anyway. Phil will get a bit cranky with this multi-faceted approach, but everybody can write it like they see it - no problems with that whatsoever. As I see it, we have customers who benefit from each aspect of what we're planning for software. These forums are a free place. . . except for the lack of post-delete that jazzed pointed out above. I'll have to look into that again - seems I've already made the request to allow deletion of posts by somehow I got overruled by our web team who recently took charge over forum administration.
The top priority is to increase our internal software team, currently consisting primarily of Jeff Martin. During December Jeff was working on making an auto-configurator for the new WiFi module, an important piece of hardware for the BASIC Stamp side of our business. Once this is finished he'll make the improvements to the Propeller Tool and BASIC Stamp IDE to support WiFi downloading and serial I/O with all of our processors. This shouldn't take much longer to complete, pending success with our latest WiFi module prototype being assembled next week. Following this project Jeff is working on an educational C translator (specification was posted on these forums, but has not been updated). It's very clear to you that we have the need for more software development, so we continue to look for a software developer with Delphi experience (for maintenance) so we can meet the requests identified above. And there will be no future key software efforts done in Delphi by Parallax - it will have to be a multi-platform tool where we can open-source our work. A total rewrite of the Propeller Tool is not likely. I can't comment on the debugger request just yet. The goal to increase our software team is aimed at commercial users, but will benefit everybody.
The second part of our Propeller Tool plan relates to open-source, to support the efforts of others who wish to improve upon our source code. Above I mentioned that the assembly compiler is being ported to C/C++. We're holding back decision-making on how to integrate this into the Propeller Tool until we're done, but it's possible (as we've done with the SX) that a developer could choose between the Parallax assembly compiler or the C/C++ code. Hold your fire on how this could done for now - I'll need to bring together the right people so I shouldn't say anything else since it creates issues with code bases and OBEX. Also, you've recently seen Propellent and Parallax Serial Terminal both released as open-source software. And the current WiFi Configurator is being done in Lazarus, so it should be useful to those without Delphi development tools. And finally, we're really close to open-sourcing the whole Propeller Tool. The only hangup is that we're using a licensed edit control from the Dream Company (now acquired by Altium). We've made contact with the right people at Altium and discussed the exact software license, but nary a soul in the whole company knows the history of this particular software component. We only need to obtain a signature from an Altium representative and then we'll post the Propeller Tool source. I expect this to happen no later than the end of January. The open-source Propeller effort is aimed at hobby and education, but we think it will have positive return for commercial users as well.
The third part of the tool strategy - and these points have certainly not been listed in order of priority - is to work closely with Brad regarding BST. I presently have a message from Brad in my PM inbox so it's too early to say where we're headed, but we're interested in supporting the completion of an open-source release of BST plus close consideration towards making it the primary tool for our Propeller educational projects.
I'll be back to check on this thread soon, but need to switch gears towards the family for the rest of the day.
Thank you for your time. I hope I conveyed our software plan with some clarity. There's much more in our non-software Propeller plan that I'm anxious to share, but I want to do that when results are readily visible to you. The last two months have centered on planning within Parallax.
idbruce
Posts: 6,197
Comments
Something like a define at the top would be great.
Jonathan
Another random thought which would be much easier to accomodate: :-)
Since indenting is critical to program execution interpretation, I occasionally found myself needing to indent/outdent large chunks of code to get it to match up to other nearby blocks, but the only way to do this was line-by-line, which is a little error-prone. It would be nice to be able to highlight a large block and have a toolbar button or kb shortcut to indent/outdent the whole block.
VAR byte myArray[9] PUB main | index repeat index from 0 to 9 myArray[index] := indexI've done the above several times. It would be nice to have a warning about such cases.
Is this improved Prop Tool something you'd write or is this a wish list to send to Parallax?
I personally haven't tried Brad's BST yet but I think he has a bunch of features not in the Prop Tool.
Duane
It is my hope that this post will gain momentum and that Parallax will take some of our suggestions and add them to the existing Propeller Tool. I personally have my hands full at the moment, however, I am sure that there are a lot of good programming editor templates available that could simplify the making of a better Propeller Tool.
Bruce
You can do this already. Highlight a block, then tab or shift-tab.
Given that we have the Prop Tool, BST and HomeSpun I'm not sure the world needs yet another Spin compiler. Especially if it is using a different language syntax than standard Parallax Spin. Although there are those who would like to see an open source compiler for the Prop.
There are a few things mixed up together here, there are editor features we would like to see, like block indenting, but changes to the actual language syntax should be thought about carefully.
I'm not sure I have ever seen a compiled language that warns about running off the end of arrays and other such programming errors. It's hard to do in simple cases and in the general case probably impossible. For example
PUB overRunArray (index) anArray[index] := somethingHow does the compiler know that index maybe out of bounds without analysing the entire program execution and being aware of any inputs that may affect the index?
Having said all that I'd like for Spin methods to have local scope for the names of their local variables.
If this were the case the Propeller tool would have toolbars and many other features of standard programming editors; and BST (Brad's Spin Tool -- something Parallax links to on its Propeller software page) wouldn't have been created. The better bet is to give Brad Campbell the suggestions as he seems much more open to incorporating user suggestions into BST, which also runs on multiple platforms (another suggestion Parallax has not made any apparent motion on).
Lest anyone misunderstand my tone, I'm not taking shots at my friends at Parallax. They only have so many resources and hours of the day in which to work with them. Thankfully, they have provided the tools in which to create 3rd-party programming products for the Propeller. This is good for everyone.
A debugger pane could definitely indicate an out of bounds array, during a debug run, but then it would also require programming to back it up.
Heater -> Open source sure would help the issue. I use the Propeller Tool because it is supplied by Parallax and they control the syntax. My wish list stems from a desire for better programming interface. If source code was supplied, I would not have to wish anymore, I could just create my own editor. But since the source code is unavailable, I have to rely on Parallax to provide a good editor for me. I am happy with all of Parallax's product's and services, except for the Propeller Tool.
Bruce
I can fully understand Parallax being apprehensive about devulging all their source code. However, if they do not wish to provide this source code or a better editor, at the very least, it would be nice to have access to a Dynamic Link Library that is well documented.
Bruce
You mean like this one:
http://www.parallax.com/ProductInfo/Microcontrollers/PropellerGeneralInformation/PropellerDownloads/PropellentLibraryandExecutable/tabid/650/Default.aspx
Or if you are building your own editor/IDE and just need a compiler then why not use BSTC/BSTL or HomeSpun? Of course that does not help much with language extensions.
-Phil
I have been to that page a hundred times and just passed right over the Propellent Library. I just cannot believe I have missed that all this time. But yes that is a very good start. At first glance it appears everything needed to create a better editor is in there, but I will have to mess with it a while just to check it out.
Hold onto your boots boys and girls, the Bruce is loose, and he is a C++ programming fool. I do not promise anything quickly, but I do promise to inspect the Propellent Library, and if it all works out the way I want it to, I just may create a C++ open source editor that links to the Propellent Library.
Thanks for pointing that out to me Heater.
Bruce
Have you messed the Propellent Library at all? It appears that the editor can be left out and the editing can be done by the program that links to it. If this is the case, then block indenting should not be that big of a deal if creating a new editor. Or at least I would not think so.
As for hooking user-scriptable preprocessors, could explain more so that I fully understand what you want. Picture this, a new editor program links to the Propellent DLL, but the new editor offers hooking user-scriptable preprocessors before compiling. Off hand I would not know how to hook user-scriptable preprocessors, but I am fairly certain that it is possible, because it will not compile until the new editor instruct the DLL to compile, so all preprocessing should be able to be done before telling the DLL to compile.
Does that sound right?
Bruce
Yes indeed, a lot can be done with a pre-processor. After all the original C++ compiler, cfront, could be thought of as a pre-processor for C.
Bruce,
Glad to be of some little help. Sounds like you have got yourself a project:)
Can I suggest you have a look at Qt as a framework to build it on. There is a nice text edit class in Qt that is easy to add syntax highlighting to.
Us Linux users are going to be left out in the cold with the propellent DLL. Perhaps there should be an option to use BSTC or HomeSpun as the compiler.
I'm right there with you, Phil -- and I suspect with all the time Jeff has to devote to assisting Chip with the Propeller II things will not improve.
<edited> I'm just old and bitter.Ignore the man behind the curtain!
Don't get me wrong. I use BSTC and BST all the time and definitely appreciate the effort given. Let's all just hope you don't totally lose interest or find yourself otherwise impaired.
Meanwhile the closest potential we have to fully open source is Sphinx on a SpinSimulator.
To understand why, go back to Parallax's beginning when the shoe was on the other foot. Parallax was the "Brad and Michael" to Microchip's PIC assembler. The Parallax PIC assembler had much superior mnemonics to the completely opaque and convoluted Microchip syntax (which was inherited from General Instruments). And, although it gained some traction among hobbyists and small-business PIC programmers (myself included), it never enjoyed an imprimatur from Microchip, since they had their own development tools. For the Parallax assembler to rise to the top, Microchip would have had to dump their own assembler (and the likes of MOVWF) for the more rational (and Intel-like) Parallax syntax.
What Parallax needs to do is either clear the deck for Jeff to concentrate on the Parallax Prop Tool, hand it off completely to another programmer, or jettison it entirely in favor of third-party software (which Parallax would have to buy outright and maintain in-house). The present situation is simply untenable. In any event, multiple standards cannot be allowed to rule, as such a situation would muddy the waters too much for selling the Propeller chip to large OEMs.
-Phil
thinking about the Propeller II chip and how to adapt the Propeller Tool to support the new chip.
Many of us have maxed out the Prop 1 and spent lots of time converting spin code to assembly just to fit our
programs in such a small ram. I think Parallax is doing a great job considering what they have to work with.
Its amazing that just a handful of guys can do so much.
Happy New Year Parallax,
Russ
That leaves noobs to use the $150 Viewport, which from my understanding is intended to be used in concert with Prop tool. Going back and forth between them is quite a test in patience since they don't use common functions on the same keys, Dho! got me again! That's not what I wanted to do..... So, while switch windows editing the same code does not trigger the mind to shift procedures accordingly. It does have some swift features, but consumes resources on the chip to do so. Although it is annoying the variables on the watch list do not update the small memory window viewing the same memory address as expected. Still a lack of experience? The quite small user base could be a clue to that question.
It would be nice to have something cohesive without hoops and 3 ring circus tricks to prove code efficiently. Relative to the SX software, it was a conditional compiler that could alter the code accordingly to the chip being used. Don't see off hand why the prop or prop II would be that different to handle likewise. I don't think it too much to ask that it contains the editor/compiler/debugger or open source to allow the community to upgrade it while Parallax uses its talent resources on future growth of this product to sustain it as long term forward compatible.
Considering how the obex is a free open resource. It is a gift that keeps on giving and helps Parallax sell the platform line. It would appear a kick in the teeth to keep a cap on tools which make that possible and a community so willing to take the prop tool over from here. Unless of course there are non-competition or nondisclosure clause limitations to worry about.
It was good to read there is something in the source library, so maybe there is hope for improvements after all!
$0
Hmm. I thought it would be better to just delete this post, but apparently we no longer have that power.
That was a nice response. I found your viewpoint interesting and it also made me think a bit. Since being informed of the Propellent Library, I have been mulling this whole thing over, about whether to use some of my time to create a new open source editor. With the availability of Propellent, creating a better editor than the Propeller Tool really would not be a major endeavor, but a good run-time debugger that would step through the code, well that is quite a different issue. I think that might be quite more of an undertaking than I am capable of, but that is the kind of suggestions that I was looking for. It has been a while since I have done any major C++ programming, and I will have to brush up a bit on the debugger and debugger panes. I do not believe that utilizing Full Duplex in a seperate pane within an editor would be that big of a deal either, but in my opinion, that is not a true debugger.
Bruce
That is one thing about this forum that I have not seen is the contrite ego's. At least with those I have read and been offered assistance from. Everyone seems to be quite helpful here. The purist in some realms senses he has earned his stripes the hard way.
I am from a machinist/tool maker/machine designer/electronic CNC field service tech back ground; now a Facilities/Maintenance Manager. You might imagine the ego's which go with that territory, but you can't kick'm to the curb when they have talents needed on the team, if ya know what I mean. LOL!
Bruce,
You are way ahead of me in having the ability to recognize how to get from point A to B on these tools. I can understand the run-time debugger being a challenge, but the only thing real time window I'd desire is seeing memory reflect my expectations or edit my way of coding it to meet the chips expectations. Which is one of the nice things Viewport does looking at variables in different bases you might be working with for that particular unit?
Stepping through the code would not need to be real time if not for some external event being time critical. But it could be halted with a break point to verify the expected change took place or find what failed in short order.
I wish I had the capability to offer more help than just adding wishes. My hat is off to those that can though!
$0
How about if we achieved this, almost exactly as you defined it above?
We've talked about open-sourcing the Propeller compiler in assembly, but have been hesitant due to (a) the language; (b) potential assistance required from Chip; and (c) giving away this piece of core intellectual work done by Parallax. However, I think we've got some good news to report! We've been able to assemble a plan involving a skilled programmer (and friend/customer) right here on these forums - Roy Eltham. Roy programs in C/C++ day in and day out, yet he's a humble guy and probably won't attempt to impress us with his skills or progress on this particular project. However, we've given him the source less than a few weeks ago and early reports are that he's 25-30% through the port to C/C++. If all goes according to plan the many enhancements you desire will be far more possible to achieve. We're taking a step-by-step approach to achieving the goal, and haven't defined what kind of open-source license we'd attach to the compiler. Not only must the code by converted, it must be tested in entirety and the release plan must be approved by Chip.
With the above being said, we'll turn it over to Roy for further comment. . . . he's probably not to sure what to divulge but I'll be sure he's got fairly loose fingers to answer any questions.
Thank you,
Ken Gracey
Parallax Inc.
Bruce
What an interesting development! I'm very happy to see some action being taken along these lines. What are the implications for the current Prop Tool? Is it to be replaced eventually, or will Roy's work be offered in parallel? Or is it too soon to tell?
Thanks for posting!
-Phil
Happy New Year Bruce -- we appreciate the thread. You can certainly bet we're paying attention, even though I haven't posted anything on the forums in a couple of weeks. Chip just got his forum login straightened out last night - the first time since we moved to this new vBulletin tool. And Jeff is sequestered for software development so you won't be seeing him on the forums unless I inform him of an important post (like this one). Considering the forums are the single most important exchange with our customers we should be doing a much better job addressing these issues head-on. I'd like to share some general direction we're taking at the moment regarding software development inside Parallax.
A year from now, 2011 will be viewed as an important year in Parallax's history as we will have evolved the company to properly support Propeller sales to OEMs. This progress should stand next to our other past achievements: PIC Tools and emulators, BASIC Stamp 1 and 2 (and the BS2 SX-based models), Stamps in Class, the SX chip and tools and the development and release of the Propeller. Just like Leon pointed out, if we want to be taken seriously in the chip industry then a big part of our plan should include more professional development tools.
Our software development strategy has two approaches, and a third one that's a bit too early to discuss but I'll tell you about it anyway. Phil will get a bit cranky with this multi-faceted approach, but everybody can write it like they see it - no problems with that whatsoever. As I see it, we have customers who benefit from each aspect of what we're planning for software. These forums are a free place. . . except for the lack of post-delete that jazzed pointed out above. I'll have to look into that again - seems I've already made the request to allow deletion of posts by somehow I got overruled by our web team who recently took charge over forum administration.
The top priority is to increase our internal software team, currently consisting primarily of Jeff Martin. During December Jeff was working on making an auto-configurator for the new WiFi module, an important piece of hardware for the BASIC Stamp side of our business. Once this is finished he'll make the improvements to the Propeller Tool and BASIC Stamp IDE to support WiFi downloading and serial I/O with all of our processors. This shouldn't take much longer to complete, pending success with our latest WiFi module prototype being assembled next week. Following this project Jeff is working on an educational C translator (specification was posted on these forums, but has not been updated). It's very clear to you that we have the need for more software development, so we continue to look for a software developer with Delphi experience (for maintenance) so we can meet the requests identified above. And there will be no future key software efforts done in Delphi by Parallax - it will have to be a multi-platform tool where we can open-source our work. A total rewrite of the Propeller Tool is not likely. I can't comment on the debugger request just yet. The goal to increase our software team is aimed at commercial users, but will benefit everybody.
The second part of our Propeller Tool plan relates to open-source, to support the efforts of others who wish to improve upon our source code. Above I mentioned that the assembly compiler is being ported to C/C++. We're holding back decision-making on how to integrate this into the Propeller Tool until we're done, but it's possible (as we've done with the SX) that a developer could choose between the Parallax assembly compiler or the C/C++ code. Hold your fire on how this could done for now - I'll need to bring together the right people so I shouldn't say anything else since it creates issues with code bases and OBEX. Also, you've recently seen Propellent and Parallax Serial Terminal both released as open-source software. And the current WiFi Configurator is being done in Lazarus, so it should be useful to those without Delphi development tools. And finally, we're really close to open-sourcing the whole Propeller Tool. The only hangup is that we're using a licensed edit control from the Dream Company (now acquired by Altium). We've made contact with the right people at Altium and discussed the exact software license, but nary a soul in the whole company knows the history of this particular software component. We only need to obtain a signature from an Altium representative and then we'll post the Propeller Tool source. I expect this to happen no later than the end of January. The open-source Propeller effort is aimed at hobby and education, but we think it will have positive return for commercial users as well.
The third part of the tool strategy - and these points have certainly not been listed in order of priority - is to work closely with Brad regarding BST. I presently have a message from Brad in my PM inbox so it's too early to say where we're headed, but we're interested in supporting the completion of an open-source release of BST plus close consideration towards making it the primary tool for our Propeller educational projects.
I'll be back to check on this thread soon, but need to switch gears towards the family for the rest of the day.
Thank you for your time. I hope I conveyed our software plan with some clarity. There's much more in our non-software Propeller plan that I'm anxious to share, but I want to do that when results are readily visible to you. The last two months have centered on planning within Parallax.
Happy New Year!
Ken Gracey
Parallax Inc.