Parallax could adopt Fastspin as their base compiler platform, updated with Spin2 support. It's only the compiler, not the IDE. FlexGUI is Eric's IDE
I'd like to see Parallax release a Spin 2 compiler in C which Eric and others could then add features to (@@@ for example). It would be a clear, baseline example that works with the official Spin interpreter (I prefer to program in Spin). The other benefit is that a person wanting to develop a new interpreted language for the P2 (maybe P2-BASIC) would have a working reference of both sides the equation.
-- It's not from Parallax, so I won't use it with my client jobs.
-- It's not 100% compatible with Spin 2 as defined by Chip, so I won't use it.
So you'll only use official Parallax tools, regardless of what your needs are and what those tools provide? I would personally choose the right tool for the right job, which will vary. But obviously it's your choice.
Brad (creator of BST) walked away from the tool he created and the Propeller community.
One major difference is that fastspin and flexgui are open source tools. Even if something should happen to me, others can pick up the source code and maintain it. @"Roy Eltham" has already made significant contributions to the simpletools support, and others have provided bug fixes.
That said, Parallax cannot count on -- although they should be supportive of -- 3rd party tool builders if they want the P2 to be taken seriously.
I think Parallax is too small a company *not* to count on 3rd parties to create tools and libraries. If they try to do it all themselves I don't think they'll succeed. Part of what made the P1 such a hit was all the contributions from third parties (including some great libraries you wrote, Jon). And I hope that the community will also support third party tools and libraries for the P2.
Parallax could adopt Fastspin as their base compiler platform, updated with Spin2 support. It's only the compiler, not the IDE. FlexGUI is Eric's IDE
I'd like to see Parallax release a Spin 2 compiler in C which Eric and others could then add features to (@@@ for example). It would be a clear, baseline example that works with the official Spin interpreter (I prefer to program in Spin). The other benefit is that a person wanting to develop a new interpreted language for the P2 (maybe P2-BASIC) would have a working reference of both sides the equation.
Spin2 is just a language. There is nothing magical about Chip's implementation of it. If you just want to use that language I'm sure Eric could extend FastSpin to support it or a superset of it. He could even add byte code generation if people really think 512K is not going to be enough. There is no need for a hand translation of Chip's x86 code to C or C++.
I'd like to see Parallax release a Spin 2 compiler in C which Eric and others could then add features to (@@@ for example).
They already had such a compiler for Spin 1, in the form of openspin. For some reason (language preference I suppose) Chip decided not to use that as the basis for Spin 2. It's too bad, because if Parallax had started with either fastspin or openspin they'd be much further along now in terms of multi-platform support, and probably would have been finished faster.
I'd like to see Parallax release a Spin 2 compiler in C which Eric and others could then add features to (@@@ for example).
They already had such a compiler for Spin 1, in the form of openspin. For some reason (language preference I suppose) Chip decided not to use that as the basis for Spin 2. It's too bad, because if Parallax had started with either fastspin or openspin they'd be much further along now in terms of multi-platform support, and probably would have been finished faster.
If they started with FastSpin they would also have ended up with a far superior toolset that includes Spin as well as BASIC and C all working together and they would also have the ability to generate native code. There is really no comparison. Why they would choose an inferior single platform solution I will never understand.
It's good timing to bring this up right now. Chip was always intent on thrashing out Spin2 on his own. He's done that now and is moving into how to deploy.
Fastspin integrating spin2 and then a selection of IDE's built on top of that. One can be built into an ESP32 for Parallax's educational deployments.
With OpenSpin, while Parallax did pay me for a good portion of the work, they didn't really support it in any other way officially. I did a bunch of work (5+ years ago) to make it so that OpenSpin could be easily integrated into PropTool (they had expressed interested in that at one point), but then that never happened. As a result almost no one used it. People demanded features, which I tried to do (and did for most), but aside from ersmith and David Betz the contributions were non-existent.
OpenSpin is better than the official Spin1 compiler in every way. It produces more correct floating point values, compiles all programs faster, works on most any platform, has unused method/object elimination, has a preprocessor, handles longer symbol names, handles larger numbers of symbols and constants, and so on.
What makes anyone think that anything will be different if I or someone else updates OpenSpin for P2? At this time, I have zero motivation to do anything with OpenSpin. There is literally no point, Fastspin is already far better, and it's what Parallax should adopt as it's official compiler. They should support Eric and officially put it out there as the compiler for P1 & P2 across all platforms. I'll even go so far as to say that doing anything else is huge mistake.
The ESP32 is far more powerful than the 8266, and so far IME far better designed. Being dual-core it can hold the WiFi fort while also doing other time-sensitive functions. It has a lot more memory -- the difference being comparable to that between P1 and P2 -- but it's not a von Neumann architecture and there are weird limitations in how much RAM can be used for what. It seems a bit less than 100K can be used for global variables, at least in the Arduino IDE implementation (which I understand is very closely related to the Expressif SDK). That's still a lot of RAM compared to the 8266, and it seems like it should be enough to implement a pretty comprehensive development system. It's also not that much more expensive. Yes, $12 instead of $3 for a breakout board might seem steep but don't forget the closest competing product on the market was over $40 per unit when the 8266 came out, and nothing else has really stepped up to compete since then.
I'd like to see Parallax release a Spin 2 compiler in C which Eric and others could then add features to (@@@ for example).
They already had such a compiler for Spin 1, in the form of openspin. For some reason (language preference I suppose) Chip decided not to use that as the basis for Spin 2. It's too bad, because if Parallax had started with either fastspin or openspin they'd be much further along now in terms of multi-platform support, and probably would have been finished faster.
If they started with FastSpin they would also have ended up with a far superior toolset that includes Spin as well as BASIC and C all working together and they would also have the ability to generate native code. There is really no comparison. Why they would choose an inferior single platform solution I will never understand.
A classic example of short-term thinking, where the niche-you-know, is preferred over the far more widely portable and supportable you-have-not-yet-learnt.
With OpenSpin, while Parallax did pay me for a good portion of the work, they didn't really support it in any other way officially. I did a bunch of work (5+ years ago) to make it so that OpenSpin could be easily integrated into PropTool (they had expressed interested in that at one point), but then that never happened. As a result almost no one used it. People demanded features, which I tried to do (and did for most), but aside from ersmith and David Betz the contributions were non-existent.
OpenSpin is better than the official Spin1 compiler in every way. It produces more correct floating point values, compiles all programs faster, works on most any platform, has unused method/object elimination, has a preprocessor, handles longer symbol names, handles larger numbers of symbols and constants, and so on.
What makes anyone think that anything will be different if I or someone else updates OpenSpin for P2? At this time, I have zero motivation to do anything with OpenSpin. There is literally no point, Fastspin is already far better, and it's what Parallax should adopt as it's official compiler. They should support Eric and officially put it out there as the compiler for P1 & P2 across all platforms. I'll even go so far as to say that doing anything else is huge mistake.
There are things I want to develop debug-wise that are going to be incremental and I just don't know how to get their using other people's code. It's a limitation I don't see a way of overcoming. I will need to modify my own code at deep levels, in order to get to where I want to go. I don't even know exactly how this is going to work, yet. Trying to get there with a code base I'm not familiar with seems like scaling a vertical wall. It's too much to bite.
There's no guarantee anything I make is going to be more reliable than what Eric makes. We'll both have strengths and weaknesses. If I can get a debugging framework lined out, though, Eric can use it, too.
Debug should be left out for the moment. It can be added in at any date. Documentation is becoming an issue as more people want to learn about what is a substantially more complex beast.
Just remember there is almost no write registers readable. You can't expect to pry into the state of the hardware with any debugger. For that you'd want a simulator. Much better to just have good documentation.
Just remember there is almost no write registers readable. You can't expect to pry into the state of the hardware with any debugger. For that you'd want a simulator. Much better to just have good documentation.
"almost no write registers readable" - what does this mean exactly? Implies some "write registers" are readable - doesn't this make them read/write? The debugger can read all of hub/cog/lut including special registers. Whats left? Smartpin X and Y, locks,
Can't we have good documentation and a good debugger?
Just remember there is almost no write registers readable. You can't expect to pry into the state of the hardware with any debugger. For that you'd want a simulator. Much better to just have good documentation.
Whats left? Smartpin X and Y, locks,
Yes, I think that was what evanh meant, with the 'pry into the state of the hardware with any debugger' comment.
Can't we have good documentation and a good debugger?
Yes, but the debugger has limits.
A simulator that can report the smart-pin settings would be very useful for new users.
I've seen other vendors offer semi-graphical peripheral state displays, and that's easier in a simulator.
The GUI part of a Debugger, can clip-onto a simulator, like Atmel do on their AVR systems. - ICE or SImulator.
Yes, all the WRPIN configs and smartpin X/Y parameters, Streamer config, Cmod, Cordic, HUBSET does more than just sysclock, Events, Interrupts, ... LUT sharing is another ... and SETSCP. Maybe even the FIFO config.
There are things I want to develop debug-wise that are going to be incremental and I just don't know how to get their using other people's code. It's a limitation I don't see a way of overcoming. I will need to modify my own code at deep levels, in order to get to where I want to go. I don't even know exactly how this is going to work, yet. Trying to get there with a code base I'm not familiar with seems like scaling a vertical wall. It's too much to bite.
If I can get a debugging framework lined out, though, Eric can use it, too.
I look forward to seeing what you come up with, but I'm not sure how I'll be able to use a debugging framework that's deeply embedded into your code.
What I (and I suspect many others) could really use would be a stand-alone PASM debugger with basic functionality: displaying memory contents (COG, LUT, and HUB), displaying disassembled code, breakpoints, and single step. It would be nice if that stand-alone debugger could accept a symbol table in some standard format, and even nicer if it had a way to link code addresses with an original source file so it could display the source. But those last two features are gravy, and could be added later.
The key there is "stand alone": if it's integrated into PNut then it's less generally useful, I think.
There are things I want to develop debug-wise that are going to be incremental and I just don't know how to get their using other people's code. It's a limitation I don't see a way of overcoming. I will need to modify my own code at deep levels, in order to get to where I want to go. I don't even know exactly how this is going to work, yet. Trying to get there with a code base I'm not familiar with seems like scaling a vertical wall. It's too much to bite.
There's no guarantee anything I make is going to be more reliable than what Eric makes. We'll both have strengths and weaknesses. If I can get a debugging framework lined out, though, Eric can use it, too.
Are you talking about debugging at the byte code level or at the PASM level? I would think debugging support at the byte code level would mostly depend on the design of the byte code virtual machine and be relatively independent of the compiler. I guess large fluctuations in the definition of the byte codes would make it difficult to keep the compiler code generator up to date but other than that the higher level parts of the compiler could be largely independent of your byte code design. Maybe you could partition the tools effort and concentrate on the low-level byte code details yourself and pass off the compiler and assembler implementation to people like Eric. Then we could have cross-platform tools but still have your clever low-level design.
MS keeps changing thier dev tools....my cnc interface did all this but was built in 2010 or 2011...it became the week link and it worked like Smile....
i started by hacking the terminal in sphinx
i then hooked the 8266 up...about a weeks worth of work
i already had a txt/ascii editor on my website
last year i did have the esp8266 acting as a webserver....it works the caveat is it seems yo only do htyp1.1 which means u need file length before sending
maybe i can find that archive
here is an idea:
1) load and build a compiler/loader into eeprom-- build a parallax controlled compiler/loader and compiler in pasm...no tricky coding...readable and reuasable...changeable
so others can make it better and use it...this would be a parallax responsibility
2) a simple editor on a website...or an app...or a.exe...or a i give up
3) push code to the esp8266
4) 8266 pushes code to prop2
5) prop2 compiles the code and runs it in ram
ur sticking point is that the esp8266 cant hold alot...but the prop 2 should be fast enough to keep its buffers clean
i had to slow the esp8266 down...and use a quick php script that only pushed15000 characters at a time....yes all in all i pushed 115000 or so but thats becuase the sever pushes faster than the prop1 can handle
do u have a simple pasm linker/assembler by any chance.....thats what we need
so many people would play with a cog that can code
Ugh. I have a ton of Parallax stuff. Anyone want it?
Okay, maybe that was a knee jerk reaction. I don't intend to stop using Parallax products. However, I do want to clean out my inventory and would happily give nearly all of it to someone who can make use of it. I'd just keep a few ActivityBoards, FLIP modules, and my P2 Eval board.
If you're looking for a small, inexpensive device the ESP32 is quite nice for what it is. For a similar price the Pi Zero W is right there as well. I've been using them as the *nix universe is much easier for me to get my head quickly wrapped around something much faster than the Extensa/Ardiono etc. toolset. Just relating what I've been doing along these lines recently. The Pi Zero has a lot more potential than the ESP32 as well. You need to log large amounts of data? Use a big uSD card, problem solved very quickly.
If you're looking for a small, inexpensive device the ESP32 is quite nice for what it is. For a similar price the Pi Zero W is right there as well. I've been using them as the *nix universe is much easier for me to get my head quickly wrapped around something much faster than the Extensa/Ardiono etc. toolset. Just relating what I've been doing along these lines recently. The Pi Zero has a lot more potential than the ESP32 as well. You need to log large amounts of data? Use a big uSD card, problem solved very quickly.
Good point although it has a much longer boot time.
With OpenSpin, while Parallax did pay me for a good portion of the work, they didn't really support it in any other way officially. I did a bunch of work (5+ years ago) to make it so that OpenSpin could be easily integrated into PropTool (they had expressed interested in that at one point), but then that never happened. As a result almost no one used it. People demanded features, which I tried to do (and did for most), but aside from ersmith and David Betz the contributions were non-existent.
OpenSpin is better than the official Spin1 compiler in every way. It produces more correct floating point values, compiles all programs faster, works on most any platform, has unused method/object elimination, has a preprocessor, handles longer symbol names, handles larger numbers of symbols and constants, and so on.
What makes anyone think that anything will be different if I or someone else updates OpenSpin for P2? At this time, I have zero motivation to do anything with OpenSpin. There is literally no point, Fastspin is already far better, and it's what Parallax should adopt as it's official compiler. They should support Eric and officially put it out there as the compiler for P1 & P2 across all platforms. I'll even go so far as to say that doing anything else is huge mistake.
Excellent point - the nearly instant-on of the ESP is very nice. They can't be beat for a reliable wifi- or BLE-serial bridge. I'm sure with the braintrust around here a nice self contained, small, efficient instant-on IDE could be a reality on the ESP32. Horses for courses, something like that... :-)
Excellent point - the nearly instant-on of the ESP is very nice. They can't be beat for a reliable wifi- or BLE-serial bridge. I'm sure with the braintrust around here a nice self contained, small, efficient instant-on IDE could be a reality on the ESP32. Horses for courses, something like that... :-)
Sounds like it might require an external SPI RAM because I've heard that not much of the internal 512K of RAM is available to user programs.
Interesting. I'll be looking at those, thanks for mentioning. I'm using Raspbian Lite with only Samba as an additional boot service and I'm looking at ~30 second boot times. I haven't gotten around to disabling all the things I don't need such as BT, audio, etc. I had looked at dietpi - it booted much faster but was squirrelly with disabling the serial console and remapping the hardware UART from BT to ttyAMA0. This is all on a Zero. I have a Pi4 running Raspbian lite and that's up in ~6 seconds.
Ugh. I have a ton of Parallax stuff. Anyone want it?
Okay, maybe that was a knee jerk reaction. I don't intend to stop using Parallax products. However, I do want to clean out my inventory and would happily give nearly all of it to someone who can make use of it. I'd just keep a few ActivityBoards, FLIP modules, and my P2 Eval board.
I might be interested in some items for my summer computer/electronics workshop. Do you have a list?
Comments
One major difference is that fastspin and flexgui are open source tools. Even if something should happen to me, others can pick up the source code and maintain it. @"Roy Eltham" has already made significant contributions to the simpletools support, and others have provided bug fixes.
I think Parallax is too small a company *not* to count on 3rd parties to create tools and libraries. If they try to do it all themselves I don't think they'll succeed. Part of what made the P1 such a hit was all the contributions from third parties (including some great libraries you wrote, Jon). And I hope that the community will also support third party tools and libraries for the P2.
If they started with FastSpin they would also have ended up with a far superior toolset that includes Spin as well as BASIC and C all working together and they would also have the ability to generate native code. There is really no comparison. Why they would choose an inferior single platform solution I will never understand.
Fastspin integrating spin2 and then a selection of IDE's built on top of that. One can be built into an ESP32 for Parallax's educational deployments.
OpenSpin is better than the official Spin1 compiler in every way. It produces more correct floating point values, compiles all programs faster, works on most any platform, has unused method/object elimination, has a preprocessor, handles longer symbol names, handles larger numbers of symbols and constants, and so on.
What makes anyone think that anything will be different if I or someone else updates OpenSpin for P2? At this time, I have zero motivation to do anything with OpenSpin. There is literally no point, Fastspin is already far better, and it's what Parallax should adopt as it's official compiler. They should support Eric and officially put it out there as the compiler for P1 & P2 across all platforms. I'll even go so far as to say that doing anything else is huge mistake.
A classic example of short-term thinking, where the niche-you-know, is preferred over the far more widely portable and supportable you-have-not-yet-learnt.
Yup, agreed.
There's no guarantee anything I make is going to be more reliable than what Eric makes. We'll both have strengths and weaknesses. If I can get a debugging framework lined out, though, Eric can use it, too.
I’m used to getting by without but would be wonderful to have...
"almost no write registers readable" - what does this mean exactly? Implies some "write registers" are readable - doesn't this make them read/write? The debugger can read all of hub/cog/lut including special registers. Whats left? Smartpin X and Y, locks,
Can't we have good documentation and a good debugger?
Yes, but the debugger has limits.
A simulator that can report the smart-pin settings would be very useful for new users.
I've seen other vendors offer semi-graphical peripheral state displays, and that's easier in a simulator.
The GUI part of a Debugger, can clip-onto a simulator, like Atmel do on their AVR systems. - ICE or SImulator.
I look forward to seeing what you come up with, but I'm not sure how I'll be able to use a debugging framework that's deeply embedded into your code.
What I (and I suspect many others) could really use would be a stand-alone PASM debugger with basic functionality: displaying memory contents (COG, LUT, and HUB), displaying disassembled code, breakpoints, and single step. It would be nice if that stand-alone debugger could accept a symbol table in some standard format, and even nicer if it had a way to link code addresses with an original source file so it could display the source. But those last two features are gravy, and could be added later.
The key there is "stand alone": if it's integrated into PNut then it's less generally useful, I think.
MS keeps changing thier dev tools....my cnc interface did all this but was built in 2010 or 2011...it became the week link and it worked like Smile....
i started by hacking the terminal in sphinx
i then hooked the 8266 up...about a weeks worth of work
i already had a txt/ascii editor on my website
last year i did have the esp8266 acting as a webserver....it works the caveat is it seems yo only do htyp1.1 which means u need file length before sending
maybe i can find that archive
here is an idea:
1) load and build a compiler/loader into eeprom-- build a parallax controlled compiler/loader and compiler in pasm...no tricky coding...readable and reuasable...changeable
so others can make it better and use it...this would be a parallax responsibility
2) a simple editor on a website...or an app...or a.exe...or a i give up
3) push code to the esp8266
4) 8266 pushes code to prop2
5) prop2 compiles the code and runs it in ram
ur sticking point is that the esp8266 cant hold alot...but the prop 2 should be fast enough to keep its buffers clean
i had to slow the esp8266 down...and use a quick php script that only pushed15000 characters at a time....yes all in all i pushed 115000 or so but thats becuase the sever pushes faster than the prop1 can handle
do u have a simple pasm linker/assembler by any chance.....thats what we need
so many people would play with a cog that can code
thats what i been bouncing around in my head
Totally agree
That's more of an issue with Raspbian. Raspbian lite boots faster. Arch boots even faster. I think Slitaz boots even more fasterer?
I might be interested in some items for my summer computer/electronics workshop. Do you have a list?
PS good to hear you will be around.