SimpleIDE Update and Propeller GCC
jazzed
Posts: 11,803
in Propeller 1
We are planning a SimpleIDE update for a relatively new Parallax product.
Items of concern for a plan of action:
1. I would like to move to the default branch of Propeller GCC. I need to know from the Propeller GCC users whether or not anyone has found problems with (default branch) alpha_1_9 vintage. We can't maintain release_1_0 and alpha_1_9 together forever. Eventually release_1_0 needs to be retired. But if there is some pressing issue, we can stay with the fall-back release_1_0. Please provide feedback in this concern.
2. Further, we plan to deprecate XMM variations in SimpleIDE. There is no plan to change Propeller GCC in that regard AFAIK so that backwards compatibility will be maintained for those who really need it. Part of the motive here is to replace propeller-load.
3. Additionally, SimpleIDE will stop supporting config files and will maintain the ActivityBoard clock configuration as the standard clock (PLL16x/5MHz Crystal). C code will allow users to specify the the clock and crystal for non standard clock settings. Part of the motive here is also to replace propeller-load.
4. The SD Card download button will be deprecated as it relies on propeller-load and config file attributes for proper function.
5. Finally, Spin projects may no longer be supported (not finalized), but Spin/PASM files will still be allowed for COG code.
Other aspects of SimpleIDE, especially those Parallax deem sacred, will remain in tact.
There are other ideas we are considering, but the above items are all we have time for in the near future.
Items of concern for a plan of action:
1. I would like to move to the default branch of Propeller GCC. I need to know from the Propeller GCC users whether or not anyone has found problems with (default branch) alpha_1_9 vintage. We can't maintain release_1_0 and alpha_1_9 together forever. Eventually release_1_0 needs to be retired. But if there is some pressing issue, we can stay with the fall-back release_1_0. Please provide feedback in this concern.
2. Further, we plan to deprecate XMM variations in SimpleIDE. There is no plan to change Propeller GCC in that regard AFAIK so that backwards compatibility will be maintained for those who really need it. Part of the motive here is to replace propeller-load.
3. Additionally, SimpleIDE will stop supporting config files and will maintain the ActivityBoard clock configuration as the standard clock (PLL16x/5MHz Crystal). C code will allow users to specify the the clock and crystal for non standard clock settings. Part of the motive here is also to replace propeller-load.
4. The SD Card download button will be deprecated as it relies on propeller-load and config file attributes for proper function.
5. Finally, Spin projects may no longer be supported (not finalized), but Spin/PASM files will still be allowed for COG code.
Other aspects of SimpleIDE, especially those Parallax deem sacred, will remain in tact.
There are other ideas we are considering, but the above items are all we have time for in the near future.
Comments
All sound great to me. I'm all for SimpleIDE being simple.
I do hope any new loader works with the GPIO pins on the Raspberry Pi (And other ARM and MIPS boards). My changes to the prop-gcc loader were incorporated into prop-gcc a while back. This does require a means for the user to select a GPIO pin to be used as the Propeller reset signal.
Is Parallax looking to stop supporting XMM models and leave them as truly deprecated, or do they simply wish to remove support in SimpleIDE so as to decrease complexity?
Having a standalone loader application is planned. It will be in github for pull requests.
SimpleIDE will use one loader that gives us "just the features" we need. The effect of that is removing under-used features. This simplifies SimpleIDE to a point, but it is more work for me. There is no plan that I know of to deprecate XMM capability in propeller-gcc itself.
Parallax never supported XMM. It was a bonus that David and I added which made sense at the time.
Cool.
Will such a new loader be a separate command line program with it's own github repo?
However, don't judge it to harshly. It isn't done yet. I'm also working on a version that uses Qt. It actually works better but I haven't figured out yet how to distribute Qt apps.
Ouch! Point taken.
Personally I think C/C++ is not the best language for the Prop. The binaries are big and eat HUB memory, it' complex to use (Until SimpleIDE becomes simple again) and I don't think the support has matured yet.
On the other hand, the Prop was designed hand in hand with the Spin language. The Prop Tool well proven, dead easy to use and just works. The manual other documentation is great, there are tons of useful Spin objects for all kind of things in OBEX, help on this forum is always forthcoming. Easy and powerful.
I would never go back to the PIC or AVR unless I really need very small, very cheap and not much capability.
Outside the Prop I'd be looking at the STM2 F4 or such devices for that step up in program size and speed. But they cannot touch many things the Prop can do with ease.
It does sound like some significant portion of your troubles come from the move away from PINK - which as far as I can tell has nothing to do with the Propeller, BS2, Prop Tool, or SimpleIDE.
Do you have a library for the PINK that works with your BS2 in Basic but not the Propeller in C/C++? If so, that is a valid complaint that I'm sure someone here would be happy to help you with.
I feel your pain with the C/C++ support. It helped me understand a lot when Andy explained in another thread what Parallax's goal with SimpleIDE/PropGCC was. In short, the general public was not a primary goal, but rather education and only education. Parallax still recommend Spin and Prop Tool for professional development - whether you're a professional developer or not.
With that being said, there is ongoing work make things better. I'm not good at reading large blocks of text though, so maybe if you break it out into a simple and concise bulleted list of problem areas, we can address them one-by-one and either say "yes, we're working on that" or "sorry, we have no plans to change that."
That is a complicated tale of frustration, with which I sympathize, but where is the problem actually?
You were happy with the BS2 and PINK but things went wrong with the Prop and WIZnet?
I know nothing about PINK or WIZnet. I imagine using the PINK is as simple as sending it commands over a serial link. This can be done very easily with the Prop and the FullDuplexSerial object.
With your experience of Java, PHP and such I'm surprised you find Spin a problem. It has its quirks and "gotchas", every language does especially if you are used to some other language. Like the white space block delimiting of Python and the strange operators from God know where, but it's a simple thing for all of that.
I do agree that C/C++ is not ready for prime time on the Prop. And perhaps this is why you have had such a hard time. The tools and documentation are not there yet. I also think C/C++ is not a good idea on the Prop. Hopefully things will be very different on the Prop 2, we shall see.
Well that's a depressing dose of reality if I've ever seen one.
I love the Prop and Spin and PASM and OBEX and even the PropTool if it comes to it. Thank God for BST and now Propeller IDE. This is all simple, well documented, well supported by OBEX and the forum and "just works". Giving you the power of the 8 core 32 bit machine that the Propeller is with only the conceptual difficulty of BASIC on a Commodore C64. The Prop and Spin were designed together as a harmonious whole. Thank you Chip Gracey.
I also love C and C++. I am the person who first ever got a C program to run on the Prop, with BDSC running under the ZiCog Z80 emulator and CP/M operating system. (Still the only way to self-host C on the Prop as far as I know). Then there was my ZPU emulator, ZOG, allowing one to run GCC compiled C/C++ on the Prop.
Then came the wonderful world of Catalina and prop-gcc, which blew any simple thing I could do out of the water
And now the downer...
I basically don't think the Propeller is a good platform for C/C++. Because:
1) Generally compilers compile to 32 bit wide instructions that soon eats the tiny HUB memory.
Yes we have C on small PICs and AVRs but they are 8 bit machines. Code density is much better.
2) Generally compilers for the Prop have to produce Large Memory Model (LMM) code. That's neat but kills the performance you expect from C.
I know, there are ways around all that. Get GCC to compile to real native high speed COG code, But then you are hit with the COG space limit and it adds a whole level of complexity to actually using the thing.
And there is "Compact Memory Model", again adds a whole level of complexity to actually using the thing.
This all takes us far away from the ease of use of the Arduino, for example. That's before we get into the crazy world of "External Memeory Models" (XMM) and all this "board type" nonsense.
Poor old Ralph here has found himself lost in the middle of all that chaos. I haven't even mentioned the issues with SimpleIDE yet....
Bottom line for me is that C/C++ on the Prop is not for normal people to use. It is I hope the springboard to wonderful things in C/C++ on the Prop II which will be a much more suitable target.
Also, if C/C++ on the Prop is not for normal people then I guess it's not for anyone since Parallax recommends Spin for advanced users.
So I switched to Spin. Of course, this entailed tailoring my own curriculum to the class objectives (navigation and data acquisition last year; mechanisms and time-keeping this year), which is a lot of work outside of class. But the switch was worth it, given the limited amount of in-class time I have with the kids. And, of course, the Propeller Tool is drop-dead easy to get along with; my students took to it right away. They still forget to indent from time to time, but those errors are easier to see and track down than hunting for mismatched braces.
There were some initial questions from the school about why I chose to teach a proprietary language instead of C. But I was able to explain that this is an academic setting, not a vocational one, and that programming skills, once mastered, transfer easily from one language to another. I do find, however, that students these days are more visually than verbally oriented; and some of them who are extremely good at CAD (the other part of the class) continue to struggle with programming -- even in Spin.
All-in-all, however, it's been a rewarding experience, regardless of which language I was teaching.
-Phil
Who knows what they are at first glance? It would be fine if one or other of LMM or CMM was the target of the compiler and that's it. Yes indeed, I have no problem with that idea. So let's keep prop-gcc simple, at least as presented in SimpleIDE, and use CMM only. I really don't know what to make of that statement. Sounds nuts to me.
C/C++ is used everyday by "normal people". On their Arduinos. Most of them don't even know they are using C++. Last time I checked the Arduino documentation refrained from mentioning "C++"" or trying to document it's massive feature set. Very wise.
On the other hand, my impression is that Chip designed the Prop and Spin and the Prop Tool, together, to be ultra simple, for those new to programming and micros, in the spirit of the old BASIC machines. Certainly not "advanced" users.
... with one possible exception being OmniaCreator. But I never actually tried it for myself. I'm curious, Phil, if you ever saw it and considered using it for your class.
That age range is also old enough that I would think they might be capable of handling something as complex as CLion or Eclipse.
I see the difficulty of C on the P1 as a matter of scale more than anything else.
The quick look we got at C on the more roomy and faster P2 was favorable. I believe there will be a lot more C development on P2, for size and speed reasons.
As for learning, I agree with Phil. C requires a person to track and know more to get things done. The Arduino people saw that and packaged up a lot of things to marginalize the impact.
This is not a critique of C. Those things are there for good reasons. But, people need to walk before they run. Take those visual CAD type students. Programming is difficult for many of them, and the leaner the programming is, the more focus they can apply to their goals.
According to our many discussions here, SPIN is actually missing a lot of advanced features! But, what it does have is easy and lean.
Let me share an observation:
A guy here in Portland made a compiled BASIC for the old Atari 2600. That machine is one of the hardest things there is to program on. It has 128 bytes of RAM, 4K of assembly language ROM code space, no interrupts, no frame buffer and a near completely software display.
Making it do something is a rite of passage of sorts.
That compiled BASIC offered inline assembly super easy, and a standard and small set of features. It didn't do much, but what it did was fast and easy.
Something interesting happened. More new game programs were created by people in the couple years after that basic was released than we saw from everyone over the 20 years prior!
Many of those people knew next to nothing about peogramming, yet there they were writing programs and even short assembly language sequences! They share them as snippets, no less! Multiply by 7 kinds of things.
C isn't really possible, or it is, but silly, and it's due to the size. Assembly language is the best, but a compiled BASIC is the second best!
The guy who wrote it did exactly what Chip did with SPIN. Stripped out all the stuff, until there was enough to do fun things without also doing a lot of work, or where there is work, it is obvious work.
P1 suffers from this, IMHO. It is really hard to trump SPIN for maximizing a Propeller, and I mean SPIN plus PASM, because they are one thing. Baggers put a level of WOLF3D on a Prop in SPIN plus PASM. It's packed to the gills!
Doing that in C is likely possible, but I submit a lot more work really knowing C as much as it is the task. It's harder due to that. Many people doing this take the easy path be a use they want something to happen as much or often more than they want to learn about a language to make it happen.
We are seeing C libraries very highly optimized for P1, and that is a lot of work to do, and in particular, mor work generally than a PASM or SPIN object is, and it often takes more space than PASM and SPIN objects do too. Improve that on P1 and it would help. On P2 it won't matter in the same way.
Now, back to that BASIC. Some of those guys are now writing advanced programs. They got started and are now programmers. Phil is right about this. Walk, then run, and walk however makes the best sense. One of them was a kid, who is now pretty damn good at assembly language, among other things. He wanted to make a PONG game to get started.
C isn't always a best fit in this way.
Now, on P2, there is room, inline PASM will make sense due to direct hub execute, and meaningful libraries will fit. There is more room to abstract the hard bits away Arduino style too.
SPIN will still rock hard, and that will still be due to its unified nature with PASM, and it's simple, lean expressions and lack of too many complicated options too.
Given the better match, C should prove far more useful and practical because it's a better fit than it currently is on P1.
Re: Heavy hitters
Well, I did a lot on P1 for fun. SPIN is fun. At present, C is work. SPIN is easier most of the time too. I like easy.
Frankly, I am most likely to write PASM and inline it with some SPIN where it makes sense. Doing that will be super easy and lean in SPIN.
That is where the fun is.
I also see a lot of fun looking C code I might want to see on the P2. Could be fun. We shall see.
Lamenting about how C doesn't get the attention isn't on any of us having fun. I'd there us no fun, we won't be here, and there will be no code. And the fun is something code gets us to. Code itself may be fun too, but often it is just something one does to have the fun too.
This is why easy attracts people. They see a lean, effective path to their goal.
No, it's on those who love C to put it out there and make contributions same as anyone does.
Think center of gravity. SPIN is one center of gravity, and the mass is the body of code out there to draw from, and the people there to draw from.
When C gets those, it too will be a center of gravity and I suspect will do just fine.
I think that means evaluating what is worth what too. If C gets simplified like the Arduino people did, then more people will attempt it. That won't necessarily help them write more pure or proper C, but it will get them writing programs in a C like syntax.
And that contributes to the center of gravity.
Is doing that worth it? I don't know.
Put another way, Chip took what he thought was fun about programming and electronics and put it into the Prop, SPIN and PASM. That is happening again on P2, and it will be fun, because that is actually a goal for the P2, same as it was the P1.
Do you think C is fun?
Share that. Others will catch the fever and guess what? C will then be fun. Package up the fun and do the work to put that fun front and center so people can see it and do it easily.
Simple as that.
As an example, I think assembly is fun. That is where the bits are. It is also where the signaks, modes, and other basic things are. I write about that, I help people do that, and I share doing that and the product of that. Video displays are fun too.
Long ago, an assembly language programmer did that for me. He shared the fun, and yes a 6502, Z80, 6809, etc... are pretty fun. So is a P1 or P2.
So, when we get C on the P2, make some fun things people can play with and build on. Share the fun, and there will be more fun, and by extension, more C.
That is why the Arduino is a hit. That is why the Prop Tool is a hit, as PhiPi says above. That is why those old 8 bitters with their BASIC and later Visual BASIC were hits.
Heck, I'm still finding VIM with its syntax highlighting and bracket matching a match for any IDE. Sadly VIM does not have a beginner friendly keyboard command interface
By the way Phill, you can tell the Spin detractors that Spin is not a "proprietary language". It is as open as any other, the openspin reference implementation is on github and there have been other implementations, HomeSpun, BST.
I still don't understand why they can't offer the basics, like a red squigly for syntax errors (mis-matched braces and missing semicolons would be the easiest). That would take care of 90% of bugs that trip up newbies.
It does seem that way, and it's too bad. My experience using SimpleIDE / gcc to code the new flight controller has actually been really good. The CMM compiled code is only marginally bigger than Spin, but significantly faster, and there are things you can do in C/C++ that are *really* hard in Spin, like objects / functions shared all over the code, conditional compilation (#ifdef), unused code pruning, and so on.
C/C++ is actually very good on the Prop. I agree that the documentation needs to be better, and it'd be nice if there were more advanced examples available, but SimpleIDE and C/C++ on the Prop are good.
I think a big part of the issue for normal users right now would be the lack of objects, particularly the ones people are used to. (video out, for example). As more of the most used objects in Spin/PASM get ported to C/C++ (which hopefully happens) it'll get more and more useful, easier to get started with, and less prone to "why not just use Spin?"