Is C the way to go with Propeller?
macrobeak
Posts: 354
After previous efforts to become competent with Spin and Propeller I am about to launch into another campaign.
I am time-poor and I really want to make sure that my efforts are not wasted so I had a good search around the website and forums before launching off.
I seem to detect an emerging thread that C is the way forward with Propeller and Parallax.
Is there any substance in this theme? If there is then I will just plunge into C for the Propeller. After all C seems to be the dominant industry language and something that is useful to master. I could never get a real grip on Spin anyway (but that may be me).
I will be interested to find out any other thoughts/knowledge on this topic out there.
I am time-poor and I really want to make sure that my efforts are not wasted so I had a good search around the website and forums before launching off.
I seem to detect an emerging thread that C is the way forward with Propeller and Parallax.
Is there any substance in this theme? If there is then I will just plunge into C for the Propeller. After all C seems to be the dominant industry language and something that is useful to master. I could never get a real grip on Spin anyway (but that may be me).
I will be interested to find out any other thoughts/knowledge on this topic out there.
Comments
C is one of the standard languages in-use for microcontrollers in Education and the Industry. I think Parallax needed to provide a solution for its customers that were looking for a more traditional language for their students and employees. Of course C is a truly compiled language (to machine code), whereas Spin gets compiled to byte-code that runs in an interpreter at run time. C compiled programs 'can' run faster, though included libraries and such make the compiled output rather large, requiring large memory models, SD, Flash RAM and EEPROM-based code execution. These methods are great, but do take a toll on performance. C provides a solution, but it has plusses & minuses compared to Spin or ASM.
You say " I could never get a real grip on Spin anyway (but that may be me)."
Well, I can't say that C will be easier to learn than Spin as there's way more options to consider and more complexity. Spin was developed by Parallax folks to be simple, easy to learn and very easy to get results from. Of course "your mileage may vary" but be prepared for a larger learning curve for C. It's much more generic, but does have a lot of support that you can find by searching Google, Yahoo or Bing.
Parallax has just provided a great "integrated development environment" in SimpleIDE for C which also provides development support for Spin and GAS (gnu-based assembler that works on Propeller chips). Check it out, by going to: http://learn.parallax.com/propellerc
You can always ask questions at this forum as well: http://forums.parallax.com/forumdisplay.php/49-Learn
Good luck!
dgately
That said, there are some libraries that take a lot of memory in C and you have to look for 'light' versions. Also, only the basic objects are translated in to the C system as of yet, so SPIN will still have a lot more objects you can just use right away.
It really depends on your goals.
If you intend to work mainly with the propeller chip Spin is an excellent choice. On the other hand, if your goal is to learn about embedded programming for multiple microcontrollers C is the way to go since that seems to be the standard language of choice for most chips.
OTOH, Spin skills will not translate one-for-one to other microcontrollers, whereas C skills more likely will. So it all depends on your objectives. For narrowly-focused rapid app development on the Propeller, Spin (and PASM) are, IMO, the better choice. For acquiring a more broadly-applicable skillset, C would probably be the preferable option (but don't you dare tell anyone I said so).
Also, be sure to take a look at Forth. If it dovetails with the way your mind works, you may fall in love with it.
-Phil
* Remember: gratification delayed is gratification denied!
Header files are one of the more annoying parts of C/C++. You have to repeat method signatures in both the header and source, but the method access and data members are only present in the header file. Modern languages (e.g. Java, C#, Python) avoid headers and only have source, the compiled binary is used by consumers to determine method access and data members. While header files might have been OK in 1983, C++ really needs a reboot to generate such information from markup in the source to be up to 2013 standards.
That said I used C++ frequently and I count my blessings I'm not programming in Objective-C.
I tried PropForth and it is interesting, but I can't seem to get the knack of stack management. I'm always finding what I need is two cells beyond where I need it.
C is a great alternative is you already know C and cannot or will not use another tool. C is a great tool for designing operating systems on workstations. There are other tools for other purposes. For example, a hammer and a screw driver have specific purposes, and you could use either to open a can of paint, and to stir the paint, but there are other tools better suited for particular purposes.
If you are considering spending the effort to learn C as some career advantage, consider that you will be placing yourself in a large pool of candidates, most of which will have more experience and/or be will to work more cheaply that you.
A computer scientist or software engineer can use pretty much ANY tool or environment with minimal effort (at least that what they tell us when they charge us tuition). If you just to do coding in one language on one environment, you limit yourself. An electrical engineer for example, doesn't particularly need to worry about this, the software is just something to get the -circuit- to work.
I have always though that all this header file business is a waste of human life. Seems many agree as many modern languages have avoided them.
However, mark up in the source of C++ to enable module linkage would make the whole thing even more hideous than it is already.
You're probably right. Although Java almost looks like a C++ header file with inline member functions, so it might be possible to pull it off.
Not to hijack the thread, but usually any given given word should at most use two elements off the stack. There are exceptions, but these are not so common. Most of the time the stack will only grow a couple elements deep, or there is a problem with the algorithm or code. But this is the bit you either get or you don't.
Phil's "dovetail" comment seems very appropriate.
Either you like it or you don't. And when you don't ... never mind.
Right tool for the right job.
Or in my case, a real tool with no job.
Yeah, it's not a criticism of the Forth language, but my thinking in C while using that language. Local variables in C are stack allocations and accessing their values is looking back on the stack. Three cells deep would be nothing for a typical C program.
Mind you I still haven't given up the idea of making even the simplest Forth program of my own. Just for the experience.
To answer the OP instead of dealing with distractions ....
Straight C offers transferable skills. Once you know C, you can learn 20 other serious languages easily. Additionally, you will have access to programming other micro-controllers easily because most offer C or C-like solutions.
That being said, C in the "standard form" is a bit big for micro-controllers. There are ways to get around the bigness of C, and as long as the solutions are fully open source it doesn't really matter if they are standard or not (although non-standard is more work).
My experience has been that Spin is a great solution for Propeller because it is minimalist in that the code can be as compact as you like or as complicated as you like. Spin is a little complicated in some ways because it offers probably a dozen more operators than other languages.
Parallax explained why C is important to them already. If you missed it, check Ken's presentation in the video here starting at 2:07:30 https://www.youtube.com/watch?feature=player_embedded&v=JppmjNWZ8x0#!
Ken describes exactly why C is important around 2:24:30 in the video.
If not I'm a bit worried about advising getting into C, or any other language for that matter.
My reason for saying that is that Spin is about one of the easiest languages there is on any micro-contoller and it is specifcally designed for/with the Propeller to make life as easy as possible and make efficient use of the resources available.
On top of that we have the host of ready made code waiting to be used from the OBEX.
Great alternatives to printf and scanf are are being tested now in the Parallax Propeller-C Simple Libraries.
Spin is "C like". Why not just use that on the prop? Because both are tools for specific purposes, and while one can use one in place of the other, each is more suited for its designed purpose.
20 serious languages easily? Maybe for YOU, but the OP has already contradicted this, by saying he had troubles with the C like spin language.
Zealots are a nuisance, but not for simply telling folks there is an option that afford certain advantages. The nuisance is when they say "my tool is the best way for YOU, regardless of your own opinion". Zealot like you and me, we must be careful to separate opinion from functionality.
I will be interested hearing if the OP tries prop GCC/ simpleIDE, and impressions of usability and learning curve for the tool itself as well as the language. I am considering offering a C version for the LittleRobot once the tools are stable and we get some takers to do the C programming.
This is a good point. Spin is definitely in the Algol family of languages as is C. Learning it will teach you block structure, structured flow of control, variable scope, and argument passing. Initially it will seem friendly because everything is an integer, so there's no funky type conflicts to worry about. Although I always need to find an example of the repeat syntax to get it right and passing byte or word variables as function arguments is a gotcha.
Something I find humorous is that I hated C when I was first exposed to C in 1984. It's syntax is frankly a mess of some of the least used characters on the keyboard. It lacks the ease of use of Basic, the elegance Lisp/Logo/Scheme, or the intellectual chops of Pascal/Modula-2. But I program in it more than any other language. Plus, so many people use C family languages that its syntax has become fairly universal.
I also don't think the concept of multiple CPUs should be that hard to handle, why not add main1(), main2() ... main7() to the language. The "linker" can figure out how to launch them all. Globals would all go into hub memory or beyond.
The real issue is how seamless can you make the transition as your code expands beyond the 4K COG memory? Maybe limit code to within the main for that space? Maybe expand the main1() but call it _1_function() would link into the COG RAM. You just need a more graceful method than *** TOO BIG OF A PROGRAM DUMMY *** (I'm exaggerating)
For larger memories 1 or more COGs becomes the LMM server, and how graceful is that transition, and how much of a performance hit (assumes the LMM can be shared).
Spin while novel, is really a disservice to the educational community, how many employers are looking for SPIN experience? Basically none, however there is still a large demand for people in the embedded world that know how to program on bare metal with C.
If you take a twelve year old, say, who has never programmed before, does not even know what a program is, does not even know it is possible to "program" things, probably his maths skills are not developed and all those mysterious "squiggles" of C would be blinding, then Spin is a perfect introduction to even just the idea of programming. Spin has the great advantage there of the super simple Spin Tool. It takes almost no effort to get your first program running.
In the past BASIC, for example, was developed to serve exactly that introductory purpose. Other attempts were Logo and Scratch.
At this level we don't care what employers want. We just want to get someone started.
The educational community I hope is there to educate, to stimulate interest and curiosity, to share knowledge and ideas, even to have fun. It's not to provide job training.
After "Does it support C?", the next question is usually something like "when do they plan to add support for interrupts?". The biggest advantage of the prop, its elimination of interrupts, is seen as a disadvantage. Basic understanding, of how to use the device on the part of the engineer, cannot be built into the compiler.
Understanding the implication and trade offs of moving from 4K cog ran, to 32K hub ran, to X external RAM also cannot be built into the compiler.
We can pretend that we are working on a workstation, but its still really just a micro controller, and thats what we have to work with. If folks are not used to this, and the tool further hides this, it makes working more difficult rather than less, which is counter to the purpose of a tool.
This is problematic. An experienced programmer (using any set of tools) already understands this. A new guy does not; we are worried about new guys here.
There is always SPIN + PASM, and those two are not hard. Edit: I didn't read your first post well. Maybe for you they don't resonate. This is a great reason to try C.
The way I see it, if you are jumping in and have some curiosity about C, satisfy it! You may have a great time, no worries. That's possible now. You might not find it's optimal for you, and that's OK. Know SPIN and PASM are out there, and they are a nice safety net.
Frankly, the reverse is true! Enjoy.
Which ever path you take, we are a great crowd, Parallax is just an awesome little company doing big things, you can get lots of competent help, and I can assure you will get as good as you give here. Jump in, share what your experiences are and you will find it all will progress nicely enough.
Could you tell me where to get one of these new Propeller chips with twice the COG memory? :-)
I had never programmed in Spin until last Saturday as I have been experimenting with PropBASIC of which I am a HUGE fan!
However, I have an urgent project and could not believe my luck when I discovered that not only does a forum-poster, Coley, live within a couple of miles of where I am right now but he also has a Prop-based board that is perfect for my project (16 ins, 16 outs, RS232, screw terminals, etc.)
So, I need to interface to a quadrature encoder, a bunch of DIO and communicate with my Android tablet-based UI via bluetooth.
I am not ready for all of this as far as PropBASIC is concerned so I decided to tackle Spin because of the already available objects, etc.
This came together so easily that I can't believe it. By Monday evening, I had everything working on my desktop and I should have it installed on the actual machine before the end of the week.
Without the pre-written (PASM) objects, I would not have been able to complete this project and once I got in to Spin, I found it an absolute breeze....and I am a BASIC programmer!
I think that for microcontrollers, a new language is only a "Monday-Tuesday" problem as we used to say....except for Forth
It's all good stuff and I am loving it!
Regards,
Mickster
http://forums.parallax.com/showthread.php/148401-Propeller-Chip-runs-a-mostly-unmodified-Arduino-program-(video)
It's this sort of thing that keeps C/C++ going because the network effects of the language.
This mirrors my own experience. Like a lot of folks, I needed a video display, so I fetched a video driver from OBEX. After admiring the demo screen for a few minutes, it was time to figure out how to use the object. This turned out to be so much easier than I'd imagined. The project was done in a flash, and I was left stunned and amazed. Spin sort-of wrote itself. It worked the way you would think a computer language ought to work. In several instances I didn't look at the manual because my first stab at a function worked the first time, just from guessing.