Let's chat.. I'm taking Propellerpowered to the streets. Is it time to go C?
Oldbitcollector (Jeff)
Posts: 8,091
Propellerpowered phase 1 is pretty much complete.
A shiny, well functioning store with what I think are reasonable prices is in operation and inventory is on the shelves.
It's time for phrase 2.. Actually finding customers to shop at Propellerpowered. ..uh..em.. Building a decent documentation archive to help folks get started with the Propeller.
Let's face it. While Propellerpowered is great and all (at least we think so). The regulars here are comfortable with shopping direct with a lot of the same sources I do, yes, while some of you visit, and a few of you shop. There isn't enough action to keep Propellerpowered open with current traffic levels. I'm hunting for new blood as always.. (says the vampire) and certainly any continued recruiting benefits us all.
So I'm getting ready to overhaul the original Propellerpowered.com domain and convert it to a documentation haven. I have a lot of stuff that has been earmarked for a revision of the Propeller Cookbook, materials that have found their way into current Instructables, and a bunch of getting started guides..
So let's get to the original intent of this...
Spin (who I dearly love) has always been considered a "red headed stepchild" by the mainstream.
He's grown up to become a teenager and has a lot of natural ability, but he doesn't have the maturity of his grandfather, C. Spin is even pretty smart for his age, but he's been having a hard time being taken seriously.
Is it time to bit a fond farewell to Spin and start producing guides, materials, and Instructables in C?
You guys are my peers. Is it time to press forward with something more industry standard in this regard?
Jeff
A shiny, well functioning store with what I think are reasonable prices is in operation and inventory is on the shelves.
It's time for phrase 2.. Actually finding customers to shop at Propellerpowered. ..uh..em.. Building a decent documentation archive to help folks get started with the Propeller.
Let's face it. While Propellerpowered is great and all (at least we think so). The regulars here are comfortable with shopping direct with a lot of the same sources I do, yes, while some of you visit, and a few of you shop. There isn't enough action to keep Propellerpowered open with current traffic levels. I'm hunting for new blood as always.. (says the vampire) and certainly any continued recruiting benefits us all.
So I'm getting ready to overhaul the original Propellerpowered.com domain and convert it to a documentation haven. I have a lot of stuff that has been earmarked for a revision of the Propeller Cookbook, materials that have found their way into current Instructables, and a bunch of getting started guides..
So let's get to the original intent of this...
Spin (who I dearly love) has always been considered a "red headed stepchild" by the mainstream.
He's grown up to become a teenager and has a lot of natural ability, but he doesn't have the maturity of his grandfather, C. Spin is even pretty smart for his age, but he's been having a hard time being taken seriously.
Is it time to bit a fond farewell to Spin and start producing guides, materials, and Instructables in C?
You guys are my peers. Is it time to press forward with something more industry standard in this regard?
Jeff
Comments
C implies all the stuff we associate with a linux workstation. That is, there are standard libraries that automagically have everything built in and it just works. Whatever technical knowledge is required is accounted for in the compiler.
This appears to be fine for something like an arduino model. But in the prop model that are lots of things that are different for example 8 cores, no interrupts, and 32K hub main memory, and 2K cog registers. These are the exact differences that make the prop useful and different from other offerings, and the reason why we need spin in the first place. We have to understand what these differences are, and what they imply, and how to best work with them to our advantage, when using any language or tool set.
Moving to C does not eliminate the need to understand the uniqueness of the prop. Not understanding makes moving to C even harder, as a bunch of our assumptions are no longer correct.
By all means take advantage of C, but let the prop GCC guys lead.
Long answer: I believe that SPIN is the reason why the Propeller has followers, not users. When discussing the Propeller with customers that are using other microcontrollers, there are two reasons why they won't look at the Prop: an industry standard C IDE (~80%) and comparable cost (~30%). With an industry accepted C IDE, the cost factor will reduce considerably once users learn how to take advantage of the Propeller's features. Although I consider SPIN easy to learn, most of the Engineers I deal with learned C in college and have chosen to lock into it for any solution they design. Need to tap that market with the prop.
edit: of course do as Mike and Prof_Braino suggest: jump on the GCC train!
So you end up re-writing almost everything because you cannot use any of the objects in OBEX.
Bean
I have a feeling there are a lot of people who dont use the prop because they dont want to learn SPIN, as others have stated, now C is here but there is really no reason for them to use the Prop still because theres no documentation demonstrating C on a propeller.
The other issue with C on the prop, in my eyes, is theres so much stuff in OBEX, its great, but doesnt work with C this means most drivers will have to be written from scratch... I know this is only problem that can be solved over time, but it will only be solved when regular people can get started with the propeller and C and start writing drivers. Right now C on the prop is only accessible to the GURU type people like jazzed who have years of experince with both C and Low Level micro programming.
The multitude of replies have provided a great sounding board! Thanks to all of you!
@Larry, you might have had the best advice of all.. Do both.. That message is coming through 5-by-5.
Jeff
But wanting to go further , have a lot of problems with paths and including libraries.
So i came back to Spin !
The beta version of GCC and Simple IDE needs a more extended documentation, more exemples and tools in Obex.
After a promising start the beta version as not shown much progress recently. Is the Propeller II using all the energies ?
Jean Paul
The steps we've been through to get to this point have been necessary. We're building a nice C system from the GCC compiler and I am certain our educational customers will be more excited than ever from it's ease of use and very good capability.
Edit: oops! I see Ken beat me to it. He, of course, speaks with authority. I'm just guessing. :-)
It's a shame they can't be compiled to object code, and then called from whatever language the programmer wants to use. Or is this somehow possible already? ...
-- Gordon
The GCC byte code interpreter isn't compatible with Spin byte codes, and there are significant differences. Many of the most important objects such as video drivers consist of PASM with the Spin code mostly implementing the communications for controlling the PASM cog(s) which do the real work. These will range from needing very little work other than translating simple wrappers from Spin to C, to needing a lot of work to make the control scheme compatible with C data structures.
Spin will remain the key language of course, but expect to see C grow for educational purposes. I can't say if C will be more powerful in the end, but it will provide amazing power very easily. Can't answer any more questions for the time being.
I have had this debate with RossH a few times. I'd don't think having a C compiler available implies anything about having all those libraries. People program in C for all kinds of things many times with no standard libraries present at all. Just like you do in Spin. The Arduino is a prime example of this, all be it with a very thin layer of it's own support software.
I can guess, based on our discussion where you said variables and constants are NOT associated with memory locations, that you know much more than I, and love to debate.
I have NOT seen anyone program in C with no standard libraries, this is my disadvantage. You better continue your discussion with RossH, he's a lot smarter than me, maybe he can help you.
While you certainly can write C code without the standard libraries, these libraries exist because they solve common problems. So why not use them rather than write your own slightly buggy version of them? To fight bloat a good compiler and library implementation are usually modular enough that you'll only pull in what you explicitly call.
Besides the Arduino library, many of the standard libraries are also available for things like trigonometry. They're pretty lean and I've fit a fair amount into 16 kB.
I was confused because on the one hand you statement suggested C implied all the
baggage of the standard librarie and was best suited for workstations. On the
other hand it said "...appears to be fine for an Arduino...". So which is it?
ASIDE: I don't remember clearly enough to quote myself but I'm sure I did not
say "variables and constants are NOT associated with memory locations". Rather
I was taking issue with your statement that a variable was a short hand for a
memory location. My only small point there is that "memory location" is a
feature of the hardware design of our computers whereas "variable" is a
semantic construct of some language definition which can mean whatever the
language designer chooses. I'm still composing an email reply for you my view
of that.
Sure you have, one of the biggest, most complex and wide spread pieces of C code
in history, the Linux kernel, does not use standard libraries. How can it the
standard libraries depend on it and it has nothing underneath except hardware.
There are plenty of examples of standard lib free code in the propgcc package.
Pretty much all Arduino projects do not use standard libs. It's everywhere.
"Propeller Powered" means Propeller first and foremost right? Focus on that, and the languages that get used, tools that appear, all should be there with your value add being to present them in ways people find attractive.
Yes, I think that PropGCC is ready for use, and a better alternative than Spin.
I've been using PropGCC for about three months now, every day, and it hasn't disappointed. Everything is available, from object oriented programming to real pointers to type checking to a better build system. In addition, it's cross platform and currently supported (as opposed to Spin on Mac/linux).
One of the cool features about PropGCC is that you can have inline PASM. I remember how difficult it was to learn PASM with Spin when I took up the challenge years ago. I had to spend a bunch of time setting everything up with a new cog and PASD (great tool, but windows only), and then single step through the program. Now, in C++, I can have inline PASM with a prinf at the end. Much easier and faster build and test cycle.
The main downside is that there is't too much learning material for PropGCC.
For my production code, I'm not using any of the standard libraries*. I found that I prefer the flexibility and power of using current objects, converted via spin2cpp.
*Ok, I do use strlen and strcat...
I do appreciate the standard libraries, though. I use printf and putc for quick testing of code, where size doesn't matter.
I'd be willing to bet that there's a few people "working like crazy" on that also.
Despite the drawback of seeming new and foreign (and pointless) to some, Spin is still the best way to get into the Prop and start doing/learning stuff - and perhaps will be for some time. If it were my decision, I'd continue to make Spin the priority (though I would certainly continue to support other tools/languages, and not just GCC either).
SimpleIDE already supports both and seems to be undergoing a lot of unannounced improvements.