High-level overview of Prop I/II programming environments please
ags
Posts: 386
I've looked at the stickies, and the first few tutorials (thinking the basics would be in the beginning not the advanced content). I still am not following what the new direction is (or maybe additional direction).
Is the Propeller Tool being deprecated, in favor of Prop gcc?
Will the SPIN interpreter still be embedded in Prop II ROM and loaded in cog RAM to execute SPIN bytecode?
Is gcc for both Prop I & II? Is it capable of producing SPIN byte code (optionally?) just as the Propeller Tool does, but from C source?
Or is SPIN itself no longer being supported on Prop II at all?
It looks like Prop gcc will require a kernel running in each cog. Is that just for startup or will this work like the current Prop I running SPIN bytecode, except it will be different byte code produced by Prop gcc?
Without understanding these basics the more advanced discussions are beyond me.
This was all started because I am looking for a way to open/edit (not execute) SPIN (including PASM too) source files on a Mac, and the Propeller Tool doesn't support Mac (is that correct?). I started downloading BST (Brad's Spin Tool) for Mac and saw some comments about support being reduced and pointers to gcc for Propeller instead. Is there something simple that I could use to edit SPIN/PASM with correct indentation (like an Eclipse plug-in)?
If these are answered in another post I'd appreciate a pointer there.
Thanks.
Is the Propeller Tool being deprecated, in favor of Prop gcc?
Will the SPIN interpreter still be embedded in Prop II ROM and loaded in cog RAM to execute SPIN bytecode?
Is gcc for both Prop I & II? Is it capable of producing SPIN byte code (optionally?) just as the Propeller Tool does, but from C source?
Or is SPIN itself no longer being supported on Prop II at all?
It looks like Prop gcc will require a kernel running in each cog. Is that just for startup or will this work like the current Prop I running SPIN bytecode, except it will be different byte code produced by Prop gcc?
Without understanding these basics the more advanced discussions are beyond me.
This was all started because I am looking for a way to open/edit (not execute) SPIN (including PASM too) source files on a Mac, and the Propeller Tool doesn't support Mac (is that correct?). I started downloading BST (Brad's Spin Tool) for Mac and saw some comments about support being reduced and pointers to gcc for Propeller instead. Is there something simple that I could use to edit SPIN/PASM with correct indentation (like an Eclipse plug-in)?
If these are answered in another post I'd appreciate a pointer there.
Thanks.
Comments
The Propeller 2 does not have a Spin bytecode interpreter in ROM. It just has a simple COG loader that reads a COG image from a SPI flash chip and starts it. That COG image will likely be a second-stage loader that loads the user program which could be either C/C++ or Spin or anything else.
PropGCC supports a variety of runtime environments. One just compiles code to run directly on a COG with pretty much no runtime overhead. This is called COG mode. LMM mode executes Propeller instructions from hub memory using Bill Henning's Large Memory Model idea. XMM is like LMM exept that it executes code from external memory like SPI flash, SRAM, or SDRAM. CMM mode is like LMM mode except that it uses compressed versions of Propeller instructions to allow more code to fit into hub memory. PropGCC does not have a mode that produces Spin bytecodes. They are not a good match for C semantics.
If Spin is supported on Prop2, but there is no Spin bytecode interpreter in ROM, is it up to the user (or the programming tool) to "find" one, load it into cog memory, or does PropGCC now compile Spin to native cog code?
Will the current Propeller Tool (or something like it) still be provided by Parallax for Prop2 - or is PropGCC the only environment provided (or sanctioned, or supported - not sure of the relationship) by Parallax?
Try SimpleIDE, I use it on my Mac all the time for Spin and PropGCC coding. It's still being developed but this release has been very stable for me.
Here's a link to some documentation.
I expect that I'll move into the modern age and adopt C (again) soon. Just not now, in the middle of a project.
SimpleIDE version 0-8-5 (link provided by Mindrobots above) can compile SPIN programs using BSTC. It does not work like Propeller Tool though because SimpleIDE uses projects. Open a SPIN file with SimpleIDE File->Open menu and press the blue COG on the toolbar. That will create a SPIN project from the file you have open. Look at page 10 of the pdf link below to learn more about the buttons.
You can follow the SimpleIDE pdf document (a little out of date) for more detailed information on using SimpleIDE: https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxwcm9wZWxsZXJnY2N8Z3g6NGU1NDU0NDQ5NmZjMjg2Nw
There has been talk of a SPIN only version of SimpleIDE which behaves more like the Propeller Tool. Work could start on that before summer, but an actual plan is still to be determined.
I have to ask - and please, this is really just a question, let's not let it become a flame war - why build another IDE rather than using Eclipse? Is there some barrier to creating a PropGCC plugin?
I recommended Eclipse for the IDE. SimpleIDE was written as a demo of how some things could work with Propeller-GCC and the loader. Parallax started the Eclipse plug-in, but it became a resource sink. I've begged them privately to put in on line for some team to finish.
Interesting to me that requiring users install Java has recently become a (bigger) issue because of security concerns. Has Oracle responded with a solution?
For a taste of what can be done, take a look at this: http://wudsn.com/ And that effort is all done. The various assemblers have the syntax highlighting done, hooks to build things are there, and emulation is linked in so that everything flows.
That's an Eclipse environment all setup to do assembly language programming on 8 bit computers. Atari, Apple, etc... One of my hobby projects aligns with this right now. I was setup and running in a day. IMHO, Eclipse is a little "busy", but a video or two gets people right to the good stuff, at which point they very likely ignore the rest, until they get there or need it. I bumped into this thing a few months ago, and happened to have Eclipse on hand. Honestly, I had avoided Eclipse prior. Didn't need it, didn't think I wanted it. Heard various things here and there. The reality was nearly all positive.
I would easily second a release of what was done so far when it makes sense.
@Steve, nothing intended toward SimpleIDE. I like it a lot. Just wanted to post my Eclipse impressions on topic.
The only error information you will get from the 0-8-x IDE is what is shown in the Build Status tab.
While there is truth in this comment, there is more to it for Parallax. You can ask them to explain it. No one would believe me.
I'll just summarize: all the active members of this forum using SPIN can not make up for customers lost by not having a Parallax C solution.
Clearly it's a good idea to have a C (as well as others) solution available for the Propeller. I just wouldn't put too much stock in its making everything new and better from a marketing standpoint.
Back to the technical stuff: I think the reason I'm reluctant to move from SPIN is because I've finally figured out how it works - almost down to bare metal. True, I'm not (nor do I intend to become) an expert in the SPIN bytecode interpreter. But I know how the stack works, how memory alignment impacts what is happening, etc. It may not be very different when using C, but I just have to get my head around it and get comfortable with it - particularly the basic operation of the cog kernel.
As for the existing OBEX of SPIN code, is there currently support for mixed-language projects? I first was thinking of the mechanics of calling a SPIN object from a C function (which does seem feasible - although it will occupy another cog for the SPIN bytecode interpreter) but then realized it could just be "magic" under the IDE covers that runs the spin2cpp (?) translator as needed.
BTW, in no way am I suggesting I understand Parallax's market, or the uC market in general for that matter. I'm just sharing some thoughts from the perspective of someone who stumbled upon the Propleller accidentally, and is now interested in developing small projects on this platform.
Having SPIN is good. The work being done on C right now will be good too.
Truth is, many who actually try it Chip's way find it's potent. The problem is the number of people willing to do that is a fraction of the people willing to give a Propeller a try using something they know; namely, C.
Additionally, P1 capability serves a fraction of the people served by P2 capability. That's becoming obvious now that we have the emulation performing as it does.
With that comes bigger programs, bigger data, more complexity overall. Where that's true, the barrier to adopting the new technology rises some, and where it's true in addition to a new programming language and or inability to integrate that into existing environments and tool chains, the barrier to adoption rises high. With each barrier raised the fraction of people who won't ever try a Propeller no matter what grows --and it's highly likely that is not linear growth either.
Because of those dynamics, having C "in the house" as well as a presentation that's aimed differently than we experience here literally mean the difference between success and failure from a business stand point. The size of the investment required to make a chip like this is significant relative to the size of Parallax, and the pay back required to have it all make sense is linked to new technology adopters outside the pool of people who would adopt a Propeller easily.
We need C. In fact, we need C++ and we need it to be fricking great so that it counters the barrier to entry seen with Propellers operating very differently than pretty much anything else!
Think of it this way:
1. It has no interrrupts
For each differentiator like that, some of us in the family think it's cool and we can very easily articulate why and how that is. But, each statement like that raises a barrier to entry that must be checked with enabling tools and messages to prevent it from harming adoption rates too much, or the technology will not see wider scale adoption outside of niches where those statements make obvious sense.
Contrary to popular belief here, a statement like that does not make obvious sense to the vast majority of potential technology adopters. Read users who pay for chips and ideally some niches where users pay for a whole lot of chips.
2. No code protection.
We dealt with this one. P2 will have what it takes to remove this exception from the table. Had the P1 offered this capability, adoption rates would have been significantly higher IMHO.
3. Multi-core vs multi-processor or the word "cog".
Same as #1
4. Software peripherals.
To us, we say "sweet!" and we know what that means, particularly if we have been SPIN + PASM users. It rocks, we all know it. Blah, blah, blah... To the rest of the world, they say, "Wut?" and something along the lines of, "Who is going to debug that?" etc.... Wonder why the C effort is so important now? With a solid set of basic library peripherals that just work, programmers can write to them like they do hardware ones and it will work and they will be pleased with that like they would be pleased by changing out chips on a design that fit the requirements better only on a Prop solution they won't change chips they will change libraries.
And so it goes.
There is company size, single sourcing and overall perception of viability, stability, etc... People know they can select technology from big companies and be "safe" the TI, Atmel, Motos of the world sell tons and tons of chips.
Here is a reality check for you! I would wager that selecting a 6502 from the Western Design Center, yes a 6502! for embedding into a consumer grade device is significantly easier than selecting a propeller. And that's an old 8 bit CPU I have in my Apple //e computer from the late 80's! Guess what?
There is at least two kick *** C compilers for that chip, and there is a reason for that and the reason is they don't want to miss the chance to be selected having to work in assembly or some other thing.
Folks, we need this. Ken, Chip, Parallax needs this to work. In fact, this community will be significantly impacted if it doesn't work. And given the top notch service, support, care, feeding and pure fun we've all been granted, helping to make it work is the right thing to do. At the least, not beating it down all the time is a great benefit. The team works hard, and making C work for this new technology is not easy either. The highly differentiated Propeller presents lots of challenges that need solutions.
Those solutions are possible, practical, potent, viable, necessary.
Memory, for example, is always the first or nearly the first knock you'll hear made on the Propeller. In this day and age, engineers, even many hobbyists and educators, aren't going to have much patience with a memory constrained controller, even if there are not terribly difficult or expensive ways around that. Just not going to happen. Code protection, very important. Good thing it's being addressed. Ability to implement peripherals in software is a selling point, something that sets the Propeller apart. Sell that, rather than run from it. Embrace and accept that the market is mostly a niche one and likely always will be.
Fundamentally the problem the Propeller has, not unlike many other micros, is that there is an awful lot of competition out there. So many 8- and 32-bit processors with huge amounts of memory and an ever-growing, already large mix-and-match selection of peripherals. Amazing performance too (100 MIPS 8051s!), with additional multi-core devices becoming available all the time. ARMs everywhere you look. Add to that lower-priced but still extremely flexible and powerful FPGAs (even CPLDs) and DSPs, and the engineer has a withering number of devices to choose from nowadays. So it all comes down to "what does this do for me, that others don't? how much does it cost and how easy is it to use, again compared to my (many) other choices?" Then, of course, there is the issue of Parallax being seen as a credible chip supplier for commercial/industrial products.
Thus, to my mind ags is spot on when he/she says that "C language support may be necessary, but is not likely sufficient to dramatically change the market landscape for the Prop."
For P1, I agree with you and said as much, though I did not say it directly. IMHO, the EDU market may well benefit from improved P1 C tools. That's significant for Parallax, and given the P2 taking shape, potentially a source of Prop friendly people entering the market. Won't take too many of those to seriously improve technology adoption rates for P2.
Your other comments about competition are valid, however I must point out share is a relative thing. At Parallax current size, a doubling of the company would only present a very small fraction share change of the market overall. And that difference is what counts, not so much the metrics we see in the trade rags / websites.