I guess that my decision will depend on what do I want to do with the chip, so here goes a brief description: I have a project in mind that will use some serial communication with another module and then plot out the results on a TV. These plots may be just text but I would like to explore the possibility of making graphics as well.
Based on my preliminary research, the use of the TV out capabilities of the propeller will require most of the available memory in the chip, leaving you with almost no room for your code. This is the reason why i was asking about which language could use external memory modules. Heaters response favors C over SPIN in this aspect.
Would it make sense to try spin first and, if I run out of memory, try C?
Or, in the other hand, focus on learning C and then learn Spin if I find some more spare time for it?
And the most discouraging for anyone who has had anything to do with the creation of PropGCC. And I still maintain that if the Propeller isn't a good choice for developing professional Propeller applications then there is no point in learning C on the Propeller at all. Better to learn it on a platform where your knowledge can be applied beyond just the "simple" educational exercises.
Yes. I haven't invested as much energy as you in PropGCC, but I've definitely committed. I think it's ready for commercial applications. My device (50+ units so far!) is running on PropGCC.
In regards to PropGCC vs Spin Libraries: you can find a list of libraries here. For the most part, PropGCC has more basic but complete libraries. If you want to interface to specific devices you need to write the higher level interface code directly.
And a little self-promotion: if you're interested in C++, there's libpropeller.
I guess that my decision will depend on what do I want to do with the chip, so here goes a brief description: I have a project in mind that will use some serial communication with another module and then plot out the results on a TV. These plots may be just text but I would like to explore the possibility of making graphics as well.
Based on my preliminary research, the use of the TV out capabilities of the propeller will require most of the available memory in the chip, leaving you with almost no room for your code. This is the reason why i was asking about which language could use external memory modules. Heater’s response favors C over SPIN in this aspect.
Would it make sense to try spin first and, if I run out of memory, try C?
Or, in the other hand, focus on learning C and then learn Spin if I find some more spare time for it?
If you're not really concerned about being able to use the code that you write on the Propeller on other MCUs and if you don't already have a body of code written in C that you want to move to the Propeller, Spin would probably be a very good choice. As has already been mentioned, you'll find it pretty easy to put together a set of objects from OBEX to get started quickly on a new project. Also, there are more people here who can support you in Spin programming than in C programming at least at the moment. On the other side though, if you want to try using C, I'd be happy to help if I can.
"mutant" as in all so called Forth's are different.
"zombie" as in dead for years but just won't stay down.
"onslaught" and "army" as in there seems to be a plague of them on the forums for a while now.
...prepare for the future!...
Mark my words young man: The future belongs to JavaScript. (Of course we will still need C/C++ to build the JS engines with )
I'm gearing up for retirement......I'll leave all those new languages for the kids, I'll code with what I already like and know (Except P2 PASM), do things I consider fun, make sawdust and let the world go rushing by me.
I'm gearing up for retirement......I'll leave all those new languages for the kids, I'll code with what I already like and know (Except P2 PASM), do things I consider fun, make sawdust and let the world go rushing by me.
Sounds like a good plan to me! Sorry about your keyboard.
C and Spin enthusiasts must join forces and stand firm in their belief in structured programming against the increasing onslaught of the mutant Forth zombie army.
Oops, getting a bit carried away there.
I'm afraid to admit it, but FORTH has attracted my interest and I've been given some guidance by someone here that shall remain nameless to protect the guilty!
So far I'm just working through "Starting Forth" using the evaluation version of Swift FORTH on my PC.
I'm afraid to admit it, but FORTH has attracted my interest and I've been given some guidance by someone here that shall remain nameless to protect the guilty!
So far I'm just working through "Starting Forth" using the evaluation version of Swift FORTH on my PC.
C.W.
At the risk of getting blasted by some of the forum participants, I'd like to suggest that Forth has a lot in common with the Propeller itself. It is interesting because it's different. Forth isn't just another Algol/Fortran clone and the Propeller certainly isn't just an ARM clone. They both have interesting unique features that make them compelling to investigate. I'm not saying that Forth is the best language for programming the Propeller. I don't want to get into that kind of battle. I'm just saying that they both have unique features that makes them worth examining closer.
As a matter of fact, I have. There is a thread called Propeller Digital Dash? in where somebody did exactly what I want to do (chefski I believe his nickname is). I tried to contact him to no avail, thats why I decided to write my own code.
I understand how the OBD-II interface works but I figure that I better learn how to program the propeller first and then jump into prototyping the project.
There is also an OBDII-CAN object created by Chris Gadd that was written in spin. I guess this will give me a good start on my project if I decide to go to SPIN.
The plus for C is that is a cross-platform language that has been adopted by many educators and other micros, not to mention that I have some limited experience with it, but its development on the propeller should be considered a work in progress, meaning that support may be limited.
Not to put too sharp of a point on it, but cross-platform? From Propeller - to WHAT?
Programmer training is a different matter, but the Propeller architecture would be tough
to translate to any other platform.
Not to put too sharp of a point on it, but cross-platform? From Propeller - to WHAT?
Programmer training is a different matter, but the Propeller architecture would be tough
to translate to any other platform.
You're right that you probably couldn't easily port an entire Propeller C program to a different platform easily but you could certainly take certain modules or libraries if they mostly implement program logic and don't interface to the hardware directly. For many Propeller programs there would be little if any code of that sort but for others there might be quite a lot. For example, all of the interpreters I've written can easily be ported to other platforms by replacing the hardware/os abstraction layer with one written for the new platform. Whether code can be ported or not has to be decided on a case-by-case basis.
I agree with those who say that the best answer is to start with Spin and then move to C.
But (naturally!) when you move to C, I'd suggest you consider Catalina!
Catalina is suitable for (and used in) both hobbyist and commercial applications.
Catalina is probably the easiest high-level language to move to once you are familiar with Spin. This is because:
Catalina already has a very rich set of plugins - most of which are derived directly from the same objects in the OBEX you will have used from Spin.
Additional OBEX objects can generally be incorporated into Catalina with only trivial modifications (to turn them into Catalina plugins).
In many cases, Spin programs and OBEX objects can be executed completely unmodified in conjunction with Catalina programs.
Catalina's own run-time environment is loaded and initialed using Spin, and is therefore very easy to extend or modify should this be required for specific applications.
Catalina supports the largest set of Propeller base platforms and XMM add-on boards, for when your application gets too large to fit in Hub RAM.
Catalina offers a seamless transition from compact memory model programs (most directly comparable to the code size and speed of Spin programs) through to external memory model programs (which can be many megabytes in size).
Not to put too sharp of a point on it, but cross-platform? From Propeller - to WHAT?
Easy, my Fast Fourier Transform written in C especially for the Propeller runs just as well on the Propeller as any other machine.
Now, get this, the C code version runs almost as fast as the hand crafted PASM version which has been optimized with the help of some gurus on this forum.
Now, get this other thing, the C code version can spread it's work over 2, 4 or 8 cogs with no change in the source code. Like it can do on my multi-core Intel PC.
Now admittedly there is always a lot of hardware specific code in any embedded project. Neither C or Spin or whatever language can help you there. But there is also a lot of higher level stuff that should be reusable.
In many cases, Spin programs and OBEX objects can be executed completely unmodified in conjunction with Catalina programs.
For this reason alone, I think Parallax should have adopted Catalina as opposed to gcc! What happened that this was not the case? There would be much less infighting if GCC were never part of the picture. Heck, even I would at least tolerate C if it could co-exist with Spin/PASM objects!
Heck, even I would at least tolerate C if it could co-exist with Spin/PASM objects!
-Phil
Doubtful
We asked Parallax if they wanted SPIN support early on, and they said no. I was in one meeting with Parallax where the ARMY Doc asked about this (last year?), the answer was still no. Why don't you ask them for it?
We asked Parallax if they wanted SPIN support early on, and they said no. I was in one meeting with Parallax where the ARMY Doc asked about this (last year?), the answer was still no.
I frankly don't get it. At all. I feel like switching the entire robotics curriculum that I've been teaching to Catalina, just so we can take advantage of some Spin objects.
We asked Parallax if they wanted SPIN support early on, and they said no. I was in one meeting with Parallax where the ARMY Doc asked about this (last year?), the answer was still no. Why don't you ask them for it?
Just my 2c worth (and probably worth even less) but I think some people in Parallax thought that trying to support Spin in conjunction with C would damage their credibility with "serious" embedded C application developers - especially after the "Parallax Micro C" episode. So they opted to go with gcc instead, believing to it be some kind of de-facto industry standard.
Maybe they were correct. Who knows? But it is worth keeping in mind that these are the same people that also thought adopting Eclipse as an IDE would be a good idea .
Not to turn this into a C thread, I am starting to really wonder where Parallax is taking SimpleIDE/PropGCC as a learning system? Since I really do like C, maybe it's time to give Catalina C another look?
As to your OP question, sure, start with Spin, get a feel for what and how it will fit your needs, then you can start investigating other languages like C and Forth. Maybe in the near future another language will appear for the Propeller which will be better suited to use all of the Propeller features, and be amazingly fast and responsive.
For this reason alone, I think Parallax should have adopted Catalina as opposed to gcc! What happened that this was not the case? There would be much less infighting if GCC were never part of the picture. Heck, even I would at least tolerate C if it could co-exist with Spin/PASM objects!
-Phil
I'm not sure what Ross means by this but it is certainly possible to use the PASM part of Spin objects in PropGCC programs. We've used that approach to port a number of drivers including FDS and various video drivers. You can also use the entire Spin object including the Spin code if you use spin2cpp. What special support does Catalina have for using Spin objects?
I think PropGCC can use unmodified Spin objects the same way Catalina can. There may be some missing glue code, but I think this can be generated with spin2cpp. Catalina also has support for some low-level driver OS drivers, which weren't widely accepted by the Prop community. But then again, none of our OSes have been widely accepted.
Ok, I am a beginner, had some college programming courses many years ago. I am not by any means a 'programmer' and all I do is hobby stuff. I have written whole applications in Pascal (still my favorite language), Visual Basic, Business Basic, C, and Spin. I would like to learn PASM.
I wrote one application for my Prop in Spin and learned Spin as I went along. The concepts of writing code are the concepts of writing code, no matter what the environment. Spin is not that bad, it has some nuances I do not like at all. It has others that are sweet. I found that C was a bit more complicated for the Prop than the Spin. I am working on learning the C.
I think it is more a question of the libraries. What is out there for the projects you want to do? Much of the C stuff has had to be re-written to allow for a smaller memory module albeit some of that actually makes C easier.
Not looked into Forth yet, probably will, would also like a good resource to learn PASM, not having ever done assembly.
My current plan is to finish learning the GCC and rewrite my Spin program in C and see which I prefer.
So my advice is to play with a project that isn't too big, get a successful program in one language and them do it in the other and see which fits you better. I still haven't decided. C does have issues with memory in the Prop and I kinda think unless it is a tiny program one will need to access some RAM to really run effectively, but the C can do that.
Just my 2c worth (and probably worth even less) but I think some people in Parallax thought that trying to support Spin in conjunction with C would damage their credibility with "serious" embedded C application developers - especially after the "Parallax Micro C" episode. So they opted to go with gcc instead, believing to it be some kind of de-facto industry standard.
Maybe they were correct. Who knows? But it is worth keeping in mind that these are the same people that also thought adopting Eclipse as an IDE would be a good idea .
Ross.
I tried to get you involved with PropGCC a number of times but you didn't seem interested. I still think you could make a big contribution to the project. As has been pointed out before, one reason Parallax decided to go with GCC instead of LCC (which is the basis of Catalina) is because GCC supports C++ as well as C. It also has a better optimizer. In any case, the majority of the work you've done on Catalina seems to be in the area of runtime support and libraries and PropGCC is in need of that sort of work as well. Is there any chance we could find a way to merge our efforts rather than trying to outdo each other? It seems like that would be the best way forward. Like it or not, the Parallax C offering will be based on GCC but that doesn't mean we can't work together. The compiler itself is only one piece of the entire C/C++ system.
Ok, I am a beginner, had some college programming courses many years ago. I am not by any means a 'programmer' and all I do is hobby stuff. I have written whole applications in Pascal (still my favorite language), Visual Basic, Business Basic, C, and Spin. I would like to learn PASM.
If any of your applications require the highest speed of execution possible (as most of mine do) then you will find PASM essential and in all honesty rather easy to learn. Parallax did a fantastic job with PASM.
There are not that many commands to learn and most are rather self explanatory. Any effort in learning PASM will be well spent. Visual Basic sure will help in creating programs external to the Prop. Without getting into a programming food fight, it is too bad IMO that VB was not used for both programming and simulation like had been done for another Micro. The IDE in VB6 was so helpful but not to be for the Prop.
Ideally one could point either compiler at a project and build it. Just as easily as I can swap gcc for clang for example.
Yes, if someone wants to program the Prop in C it shouldn't matter too much whether they use Catalina or PropGCC. Anything that compiles under one compiler should compile under the other one. I'm assuming that Catalina supports ANSI, C99 and the other variants of C. The debate over Catalina versus PropGCC is silly, and we should focus more on C code that runs under either compiler.
Of course, for someone that wants to write object oriented code in C++ they would need to use PropGCC.
If any of your applications require the highest speed of execution possible (as most of mine do) then you will find PASM essential and in all honesty rather easy to learn. Parallax did a fantastic job with PASM.
There are not that many commands to learn and most are rather self explanatory. Any effort in learning PASM will be well spent. Visual Basic sure will help in creating programs external to the Prop. Without getting into a programming food fight, it is too bad IMO that VB was not used for both programming and simulation like had been done for another Micro. The IDE in VB6 was so helpful but not to be for the Prop.
One cannot write complete applications in PASM as the Prop only has room for 512 longs in each cog, that would make a very very small application. On any other processor you don't have this limitation and you can write large assembly files but why would you? You have HLLs for this and that is what this thread is about, Spin or C (which C) and of course there are other options......
For any beginner to the Prop in general I would say "learn Spin" as it is simple and the obex is huge, there are plenty of examples etc. After becoming familiar with the Prop in this environment one can make a choice from there, if they feel the need.
Easy, my Fast Fourier Transform written in C especially for the Propeller runs just as well on the Propeller as any other machine.
Now, get this, the C code version runs almost as fast as the hand crafted PASM version which has been optimized with the help of some gurus on this forum.
Now, get this other thing, the C code version can spread it's work over 2, 4 or 8 cogs with no change in the source code. Like it can do on my multi-core Intel PC.
Now admittedly there is always a lot of hardware specific code in any embedded project. Neither C or Spin or whatever language can help you there. But there is also a lot of higher level stuff that should be reusable.
This FFT port comes up quite a bit almost as if it were a RGB (255,0,0) herring. If I need FFT on an embedded system it's time for A. micro-computer or B. a cheap ALU chip
This FFT port comes up quite a bit almost as if it were a RGB (255,0,0) herring. If I need FFT on an embedded system it's time for A. micro-computer or B. a cheap ALU chip
Ok, but what about other algorithms? Say for string comparison, matrix math, calibrations, linked lists, sorting, ...
All sorts of algorithms don't really care about where they run. And, for publication, they're usually written in C. It's much easier to adopt something already written than to roll your own.
Comments
I guess that my decision will depend on what do I want to do with the chip, so here goes a brief description: I have a project in mind that will use some serial communication with another module and then plot out the results on a TV. These plots may be just text but I would like to explore the possibility of making graphics as well.
Based on my preliminary research, the use of the TV out capabilities of the propeller will require most of the available memory in the chip, leaving you with almost no room for your code. This is the reason why i was asking about which language could use external memory modules. Heaters response favors C over SPIN in this aspect.
Would it make sense to try spin first and, if I run out of memory, try C?
Or, in the other hand, focus on learning C and then learn Spin if I find some more spare time for it?
Yes. I haven't invested as much energy as you in PropGCC, but I've definitely committed. I think it's ready for commercial applications. My device (50+ units so far!) is running on PropGCC.
In regards to PropGCC vs Spin Libraries: you can find a list of libraries here. For the most part, PropGCC has more basic but complete libraries. If you want to interface to specific devices you need to write the higher level interface code directly.
And a little self-promotion: if you're interested in C++, there's libpropeller.
That's:
"mutant" as in all so called Forth's are different.
"zombie" as in dead for years but just won't stay down.
"onslaught" and "army" as in there seems to be a plague of them on the forums for a while now. Mark my words young man: The future belongs to JavaScript. (Of course we will still need C/C++ to build the JS engines with
@David, Noooo, did one of them bite you or something?
Thanks! Now there's coffee all over my keyboard!!
I'm gearing up for retirement......I'll leave all those new languages for the kids, I'll code with what I already like and know (Except P2 PASM), do things I consider fun, make sawdust and let the world go rushing by me.
I'm afraid to admit it, but FORTH has attracted my interest and I've been given some guidance by someone here that shall remain nameless to protect the guilty!
So far I'm just working through "Starting Forth" using the evaluation version of Swift FORTH on my PC.
C.W.
As a matter of fact, I have. There is a thread called Propeller Digital Dash? in where somebody did exactly what I want to do (chefski I believe his nickname is). I tried to contact him to no avail, thats why I decided to write my own code.
I understand how the OBD-II interface works but I figure that I better learn how to program the propeller first and then jump into prototyping the project.
There is also an OBDII-CAN object created by Chris Gadd that was written in spin. I guess this will give me a good start on my project if I decide to go to SPIN.
Not to put too sharp of a point on it, but cross-platform? From Propeller - to WHAT?
Programmer training is a different matter, but the Propeller architecture would be tough
to translate to any other platform.
I agree with those who say that the best answer is to start with Spin and then move to C.
But (naturally!) when you move to C, I'd suggest you consider Catalina!
Catalina is suitable for (and used in) both hobbyist and commercial applications.
Catalina is probably the easiest high-level language to move to once you are familiar with Spin. This is because:
- Catalina already has a very rich set of plugins - most of which are derived directly from the same objects in the OBEX you will have used from Spin.
- Additional OBEX objects can generally be incorporated into Catalina with only trivial modifications (to turn them into Catalina plugins).
- In many cases, Spin programs and OBEX objects can be executed completely unmodified in conjunction with Catalina programs.
- Catalina's own run-time environment is loaded and initialed using Spin, and is therefore very easy to extend or modify should this be required for specific applications.
- Catalina supports the largest set of Propeller base platforms and XMM add-on boards, for when your application gets too large to fit in Hub RAM.
- Catalina offers a seamless transition from compact memory model programs (most directly comparable to the code size and speed of Spin programs) through to external memory model programs (which can be many megabytes in size).
Ross.Now, get this, the C code version runs almost as fast as the hand crafted PASM version which has been optimized with the help of some gurus on this forum.
Now, get this other thing, the C code version can spread it's work over 2, 4 or 8 cogs with no change in the source code. Like it can do on my multi-core Intel PC.
Now admittedly there is always a lot of hardware specific code in any embedded project. Neither C or Spin or whatever language can help you there. But there is also a lot of higher level stuff that should be reusable.
-Phil
Doubtful
We asked Parallax if they wanted SPIN support early on, and they said no. I was in one meeting with Parallax where the ARMY Doc asked about this (last year?), the answer was still no. Why don't you ask them for it?
-Phil
Just my 2c worth (and probably worth even less) but I think some people in Parallax thought that trying to support Spin in conjunction with C would damage their credibility with "serious" embedded C application developers - especially after the "Parallax Micro C" episode. So they opted to go with gcc instead, believing to it be some kind of de-facto industry standard.
Maybe they were correct. Who knows? But it is worth keeping in mind that these are the same people that also thought adopting Eclipse as an IDE would be a good idea
Ross.
As to your OP question, sure, start with Spin, get a feel for what and how it will fit your needs, then you can start investigating other languages like C and Forth. Maybe in the near future another language will appear for the Propeller which will be better suited to use all of the Propeller features, and be amazingly fast and responsive.
Ray
I wrote one application for my Prop in Spin and learned Spin as I went along. The concepts of writing code are the concepts of writing code, no matter what the environment. Spin is not that bad, it has some nuances I do not like at all. It has others that are sweet. I found that C was a bit more complicated for the Prop than the Spin. I am working on learning the C.
I think it is more a question of the libraries. What is out there for the projects you want to do? Much of the C stuff has had to be re-written to allow for a smaller memory module albeit some of that actually makes C easier.
Not looked into Forth yet, probably will, would also like a good resource to learn PASM, not having ever done assembly.
My current plan is to finish learning the GCC and rewrite my Spin program in C and see which I prefer.
So my advice is to play with a project that isn't too big, get a successful program in one language and them do it in the other and see which fits you better. I still haven't decided. C does have issues with memory in the Prop and I kinda think unless it is a tiny program one will need to access some RAM to really run effectively, but the C can do that.
Ideally one could point either compiler at a project and build it. Just as easily as I can swap gcc for clang for example.
If any of your applications require the highest speed of execution possible (as most of mine do) then you will find PASM essential and in all honesty rather easy to learn. Parallax did a fantastic job with PASM.
There are not that many commands to learn and most are rather self explanatory. Any effort in learning PASM will be well spent. Visual Basic sure will help in creating programs external to the Prop. Without getting into a programming food fight, it is too bad IMO that VB was not used for both programming and simulation like had been done for another Micro. The IDE in VB6 was so helpful but not to be for the Prop.
Of course, for someone that wants to write object oriented code in C++ they would need to use PropGCC.
One cannot write complete applications in PASM as the Prop only has room for 512 longs in each cog, that would make a very very small application. On any other processor you don't have this limitation and you can write large assembly files but why would you? You have HLLs for this and that is what this thread is about, Spin or C (which C) and of course there are other options......
For any beginner to the Prop in general I would say "learn Spin" as it is simple and the obex is huge, there are plenty of examples etc. After becoming familiar with the Prop in this environment one can make a choice from there, if they feel the need.
This FFT port comes up quite a bit almost as if it were a RGB (255,0,0) herring. If I need FFT on an embedded system it's time for A. micro-computer or B. a cheap ALU chip
Ok, but what about other algorithms? Say for string comparison, matrix math, calibrations, linked lists, sorting, ...
All sorts of algorithms don't really care about where they run. And, for publication, they're usually written in C. It's much easier to adopt something already written than to roll your own.