I've just uploaded a new patch release (3.0.4) for Catalina, which contains the new spinc utility that allows the execution of Spin programs from C. See the main Catalina 3.0 thread for details, or visit the Catalina SourceForge site.
Hmmm. I just noticed this bit. Seems to be some serious confusion about Catalina here.
There is no misunderstanding.
The problem is that most of the power that make files should have is buried in your build scripts and target spin code. Your particular vision of a C tool chain is very different from most.
Catalina provides a plethora of built-in devices on target platforms with a huge amount of spin code managed by build-all scripts which can be added to make files. Adding make files is like an after thought. Adding new hardware platforms and devices require and in depth knowledge of spin, appreciation of your code hierarchy, and delving through several not very good manuals. While that is fine for users of your supported devices, anyone who needs to build their own system is stuck with a huge learning curve or hiring a Catalina consultant for the job.
Catalina is much less flexible and carries a greater cost than more desirable C solutions.
Catalina will be used by C programmers who want to write embedded software for the Propeller. GCC will be used by everybody else.
I don't know if this is "laughing" funny. It has been my experience that that as C is a "commodity langauge"; it is very easy to find C programmers, but these will not necessaily be engineers capabale of writing an embedded application for atime critical process. This is often seen as a fine distinction, and it is, until one is dealing with a time critical application. This distintion appears to be lost on non engineers, including programmers but especially management.
Using a "programmer" when an engineer is required results in failure or a very costly success (in my small experience). As a result, the tools are blamed, then the programmers, and never the management that made the original (clueless) decision.
Is it just me, or is this something other folks have noticed? Possibly the folks on this thread have not noticed this, as they are the engineers that do not suffer this type of failure.
My question is: Is this going to be a source of future complaints against the propeller? In making the prop "easy to use", it is being made "easy to use badly"?
That is, as the proportion of programmers to engineers increases, so will the proportion of "failure stories" to "success stories" (regarding time critical embedded applications)?
My question is: Is this going to be a source of future complaints against the propeller? In making the prop "easy to use", it is being made "easy to use badly"?
That is, as the proportion of programmers to engineers increases, so will the proportion of "failure stories" to "success stories" (regarding time critical embedded applications)?
The problem is to achieve success, one must be able to serve as many customers as possible. In the case of Forth what you are talking about is probably not an issue because of the specialization required to use the language (yes, most languages use an RPN stack, but that annoying issue is hidden). Fortunately most desired languages use ideas that are taught in mathematics classes the world over from K-12 and beyond. That means that to get the most customers, one must offer a desired language - C, Basic, Spin, and 20+ other popular languages provide a platform for success in getting the most possible customers. Being narrow is not the solution.
@Prof: I think that's a wonderful problem to have.
If we do see broad use like you describe, there will then be a market for "engineering" materials, cookbooks, reference circuits, peripherals, etc... Bring it on!
re: Build process. I am eager to see the differences, and watch that competition happen. Everybody benefits in the end, IMHO.
The problem is to achieve success, one must be able to serve as many customers as possible.
I would modify this statement to say "to achieve DOMINANCE, one must be able to serve as many customers as possible". But dominance is NOT the goal, the tool itself is NOT the product being sold for money. The goal is a useful tool. The question become "How do we define useful, and how do we define the intended users?"
To achive success, one must define the goals, an ensure those goals are accomplished.
In the case of Forth what you are talking about is probably not an issue because of the specialization required to use the language.
Actually, this issue is precisely the root cause as to why forth is not more widely used today. The initial stunning successes attracted a large influx of users "lower on the technology curve", which resulted in a large number of failure stories. Subsequent successes were overshadowed by the anecdotes of these failures.
Fortunately most desired languages use ideas that are taught in mathematics classes the world over from K-12 and beyond. That means that to get the most customers, one must offer a desired language - C, Basic, Spin, and 20+ other popular languages provide a platform for success in getting the most possible customers. Being narrow is not the solution.
This is like saying "Chinese is spoken by the largest number of people, to succede one must speak Chinese". This is only true if your target is China, but not true if your target is France. Just because something is taught in schools does not mean it is best or right or even correct, it only means it is common. As Chinese is taught in China, French is taught in France, one does not make the other incorrect, or right for anybody else.
The goal is NOT to be narrow, the goal is to define the targeted area of specialization, so we know what constitutes "broad and flexible" within that area, and what constitutes "out of scope".
@potatohead: I'm sure the prop community will resolve this type of issue either directly or indirectly. I agree, I just point stuff out as early as possible to give the opportunity to consider the topic. A conscious decision to do or not do is better than an unconscious desision to not do.
A quantitive definition of Quality is "degree of conformance to requirements". This is where this line of inquiry is coming from, I just thought I'd memtion it for what its worth.
In the case of Forth what you are talking about is probably not an issue because of the specialization required to use the language.
Actually, this issue is precisely the root cause as to why forth is not more widely used today.
If the specialization referred to is mastery of RPN, it would be hard to explain the wild popularity of the HP calculator line in that context. I've programmed in both Forth and Postscript. Postscript, another stack-oriented language, is much easier. I believe that Forth's Achilles heel is not RPN per se but its requirement for strict stack maintenance, which can become very unwieldy for large programs. Postscript addresses this difficulty with its mark and cleartomark words, which permit the programmer to establish and to clear an entire stack frame without having to keep track of how many words it consumes. IMO, hobbling Forth with Chuck Moore purity is what impedes the language's adoption, not its stack-oriented semantics. But this is an impediment that could easily be alleviated by something like mark and cleartomark, if only Forth implementers had the courage to step outside the corner that Mr. Moore has painted them into.
I should have said "a root cause" not "the root cause". But in any case, the discussion is not about forth, its about C, (don't want to hijack the thread on this tangent) and this particular line of inquiry is about "embedded software C" vs plain old C. Clearly the current participants are familliar with what the engineer has to do and what can be left to the tool to do. How will the effort take into consideration the programmers that are not particularly aware of the embedded/realtime considerations that are the engineering part of using the prop? If this question is a non-issue, ok; I just wanted to bring it up once.
As far as the forth considerations for the mark and cleartomark words, you may be happy to find support to directly access any stack position in v5.0, which make make impelmenting these words eaiser. Please bring this up in the v5.0 thread when it is released August/September.
The problem is that most of the power that make files should have is buried in your build scripts and target spin code. Your particular vision of a C tool chain is very different from most.
Catalina provides a plethora of built-in devices on target platforms with a huge amount of spin code managed by build-all scripts which can be added to make files. Adding make files is like an after thought. Adding new hardware platforms and devices require and in depth knowledge of spin, appreciation of your code hierarchy, and delving through several not very good manuals. While that is fine for users of your supported devices, anyone who needs to build their own system is stuck with a huge learning curve or hiring a Catalina consultant for the job.
Catalina is much less flexible and carries a greater cost than more desirable C solutions.
Wow! Where to start with this?
If you would rather use makefiles than batch files, then by all means do so. The main reason I do not provide makefiles is that many Windows users are unfamiliar with them, and imposing them means you are forcing your users not only to learn make, but also to install MingW (or Cygwin, or some other Unix environment).
Neither of these are currently not necessary to use Catalina.
Catalina uses Spin code to provide a Hardware Abstraction Layer. There are complexities to this, but also several advantages - the main one is that this is precisely what allows me to offer the plethora of built-in devices and hardware platforms you mentioned. I'm not aware of any other compiler for the Propeller that comes anywhere close to offering the rich set of built-in functionality and platform support that Catalina offers. It also means that anyone wishing to write C programs for the Propeller does not not need to worry about the drivers at all in most cases, and can therefore concentrate on writing C code (isn't that what all this is about?).
However, I do realize this approach is contrary to what here in the forums would prefer to see - but that's because many of us here in the forums do not actually write any applications - we prefer to tinker with things like the hardware, peripherals, drivers and tools. And then argue with each other about them. Catalina is not intended for users like that - it is intended for users who simply want to write applications in C for the Propeller - and who couldn't give two hoots for makefiles, device drivers, Spin, or the internal intricacies of the toolchain itself. Why should you need to know all this stuff just to program in C?
Yes, adding new device drivers requires both knowledge of Spin and of the architecture of Catalina. But how does this differ from any other environment? For example, would you expect a novice Linux user to be able to add a new device driver to Linux without knowledge of either assembly language or the kernel architecture? Of course not! However, as I have recently demonstrated, you can now use Spin objects taken directly from the OBEX with Catalina C.
Also, you still seem to misunderstand the Catalina build process. Neither the 'build_all" scripts nor any makefiles have anything to do with Catalina itself. They are not required to build Catalina programs. They are simply utilities I provide to try and simplify things for new users. If they are confusing you, then don't use them. You can either use the command line directly, or Code::Blocks.
As for "not very good manuals" - I acknowledge on page 5 of the reference manual that they are a bit thin - feel free to assist me in improving them.
And as for Catalina being "much less flexible and carries a greater cost than more desirable C solutions" - well, I suggest we carry on this part of the discussion when there is an alternative available to compare it against.
Catalina uses Spin code to provide a Hardware Abstraction Layer. There are complexities to this, but also several advantages - the main one is that this is precisely what allows me to offer the plethora of built-in devices and hardware platforms you mentioned. I'm not aware of any other compiler for the Propeller that comes anywhere close to offering the rich set of built-in functionality and platform support that Catalina offers. It also means that anyone wishing to write C programs for the Propeller does not not need to worry about the drivers at all in most cases, and can therefore concentrate on writing C code (isn't that what all this is about?).
I think this may be the disconnect. You are right that people who write C programs on PC's or Mac's or Linux machines generally expect to be able to compile and run a program without having to worry about what driver gets used to talk to the hard drive, display, or keyboard. However, I don't think this is generally true for people programming microcontrollers. There they are likely to want tight control over what drivers are used and how they interface with the C code. Of course a standard UART driver that allows debug printfs is handy and maybe people would like it if that was built in. I suspect they would want far more control over any other devices and drivers though.
I think this may be the disconnect. You are right that people who write C programs on PC's or Mac's or Linux machines generally expect to be able to compile and run a program without having to worry about what driver gets used to talk to the hard drive, display, or keyboard. However, I don't think this is generally true for people programming microcontrollers. There they are likely to want tight control over what drivers are used and how they interface with the C code. Of course a standard UART driver that allows debug printfs is handy and maybe people would like it if that was built in. I suspect they would want far more control over any other devices and drivers though.
Yes, I acknowledge that - but I also assume that typical microcontroller programmers would be willing to spend the relatively modest amount of time required to learn the details necessary to add their own device drivers. What you (and jazzed also, to some extent) seem to be suggesting is that embedded C programmers would expect to take a new microcontroller and be able add a new device driver in a matter of minutes. This is directly contrary to my own experience, and (even if your experience is different) the unorthodox nature of the Propeller, and the convolutions you have to go through to support C at all, mean it is not likely to ever be true on the Propeller.
As you may have gathered from the (original) topic of this thread - Catalina's direction from now on is going to be more accomodating of Spin, in order to encourage existing Propeller users to experiment with C. I will happily leave it for others to try and entice users to grapple with the complexities of MinGW, GCC, binutils, makefiles, autotools and ELF file formats etc etc - not to mention being required to write their own device drivers - just to to get a simple "hello, world" C programs to run on their Propeller.
I will happily leave it for others to try and entice users to grapple with the complexities of MinGW, GCC, binutils, makefiles, autotools and ELF file formats etc etc - not to mention being required to write their own device drivers ....
That's the domain of the ParallaxSemiconductor professional GCC/Eclipse tool-chain.
Demo applications, device drivers, and infrastructure examples will be provided of course.
The goal of serving both audiences is to increase sales by catering to hobbyists and high volume commercial customers.
I encourage you to keep doing things the way you see fit. Don't get discouraged.
As they say, the race often goes to he who keeps running.
Parallax is interested in seeing a GCC tool chain for the Propeller, for the sake of wide acceptance, but this is probably not a panacea. There is room for lots of tools.
I encourage you to keep doing things the way you see fit. Don't get discouraged.
As they say, the race often goes to he who keeps running.
Parallax is interested in seeing a GCC tool chain for the Propeller, for the sake of wide acceptance, but this is probably not a panacea. There is room for lots of tools.
Chip
Hi Chip,
Thanks for the encouragement. I understand and support Parallax's commerical reasons for GCC (even when I think the way it is being done is sometimes a bit ... well, ummm ... odd!).
However, I will continue to putter along with Catalina - for my own enjoyment as much as anything else. The reasons I originally chose LCC rather than GCC still stand. On an unorthodox and heavily constrained architecture like the Prop 1 (and also for the moving target that is currently the Prop 2!) Catalina has to be lean, mean and agile.
Catalina is a Corvette Stingray, GCC is an Abrams Tank. Sometimes you need one, sometimes you need the other. But only one of them is fun to drive!
Comments
I've just uploaded a new patch release (3.0.4) for Catalina, which contains the new spinc utility that allows the execution of Spin programs from C. See the main Catalina 3.0 thread for details, or visit the Catalina SourceForge site.
Ross.
The problem is that most of the power that make files should have is buried in your build scripts and target spin code. Your particular vision of a C tool chain is very different from most.
Catalina provides a plethora of built-in devices on target platforms with a huge amount of spin code managed by build-all scripts which can be added to make files. Adding make files is like an after thought. Adding new hardware platforms and devices require and in depth knowledge of spin, appreciation of your code hierarchy, and delving through several not very good manuals. While that is fine for users of your supported devices, anyone who needs to build their own system is stuck with a huge learning curve or hiring a Catalina consultant for the job.
Catalina is much less flexible and carries a greater cost than more desirable C solutions.
I don't know if this is "laughing" funny. It has been my experience that that as C is a "commodity langauge"; it is very easy to find C programmers, but these will not necessaily be engineers capabale of writing an embedded application for atime critical process. This is often seen as a fine distinction, and it is, until one is dealing with a time critical application. This distintion appears to be lost on non engineers, including programmers but especially management.
Using a "programmer" when an engineer is required results in failure or a very costly success (in my small experience). As a result, the tools are blamed, then the programmers, and never the management that made the original (clueless) decision.
Is it just me, or is this something other folks have noticed? Possibly the folks on this thread have not noticed this, as they are the engineers that do not suffer this type of failure.
My question is: Is this going to be a source of future complaints against the propeller? In making the prop "easy to use", it is being made "easy to use badly"?
That is, as the proportion of programmers to engineers increases, so will the proportion of "failure stories" to "success stories" (regarding time critical embedded applications)?
The problem is to achieve success, one must be able to serve as many customers as possible. In the case of Forth what you are talking about is probably not an issue because of the specialization required to use the language (yes, most languages use an RPN stack, but that annoying issue is hidden). Fortunately most desired languages use ideas that are taught in mathematics classes the world over from K-12 and beyond. That means that to get the most customers, one must offer a desired language - C, Basic, Spin, and 20+ other popular languages provide a platform for success in getting the most possible customers. Being narrow is not the solution.
If we do see broad use like you describe, there will then be a market for "engineering" materials, cookbooks, reference circuits, peripherals, etc... Bring it on!
re: Build process. I am eager to see the differences, and watch that competition happen. Everybody benefits in the end, IMHO.
I would modify this statement to say "to achieve DOMINANCE, one must be able to serve as many customers as possible". But dominance is NOT the goal, the tool itself is NOT the product being sold for money. The goal is a useful tool. The question become "How do we define useful, and how do we define the intended users?"
To achive success, one must define the goals, an ensure those goals are accomplished.
Actually, this issue is precisely the root cause as to why forth is not more widely used today. The initial stunning successes attracted a large influx of users "lower on the technology curve", which resulted in a large number of failure stories. Subsequent successes were overshadowed by the anecdotes of these failures.
This is like saying "Chinese is spoken by the largest number of people, to succede one must speak Chinese". This is only true if your target is China, but not true if your target is France. Just because something is taught in schools does not mean it is best or right or even correct, it only means it is common. As Chinese is taught in China, French is taught in France, one does not make the other incorrect, or right for anybody else.
The goal is NOT to be narrow, the goal is to define the targeted area of specialization, so we know what constitutes "broad and flexible" within that area, and what constitutes "out of scope".
@potatohead: I'm sure the prop community will resolve this type of issue either directly or indirectly. I agree, I just point stuff out as early as possible to give the opportunity to consider the topic. A conscious decision to do or not do is better than an unconscious desision to not do.
A quantitive definition of Quality is "degree of conformance to requirements". This is where this line of inquiry is coming from, I just thought I'd memtion it for what its worth.
-Phil
As far as the forth considerations for the mark and cleartomark words, you may be happy to find support to directly access any stack position in v5.0, which make make impelmenting these words eaiser. Please bring this up in the v5.0 thread when it is released August/September.
-Phil
Wow! Where to start with this?
If you would rather use makefiles than batch files, then by all means do so. The main reason I do not provide makefiles is that many Windows users are unfamiliar with them, and imposing them means you are forcing your users not only to learn make, but also to install MingW (or Cygwin, or some other Unix environment).
Neither of these are currently not necessary to use Catalina.
Catalina uses Spin code to provide a Hardware Abstraction Layer. There are complexities to this, but also several advantages - the main one is that this is precisely what allows me to offer the plethora of built-in devices and hardware platforms you mentioned. I'm not aware of any other compiler for the Propeller that comes anywhere close to offering the rich set of built-in functionality and platform support that Catalina offers. It also means that anyone wishing to write C programs for the Propeller does not not need to worry about the drivers at all in most cases, and can therefore concentrate on writing C code (isn't that what all this is about?).
However, I do realize this approach is contrary to what here in the forums would prefer to see - but that's because many of us here in the forums do not actually write any applications - we prefer to tinker with things like the hardware, peripherals, drivers and tools. And then argue with each other about them. Catalina is not intended for users like that - it is intended for users who simply want to write applications in C for the Propeller - and who couldn't give two hoots for makefiles, device drivers, Spin, or the internal intricacies of the toolchain itself. Why should you need to know all this stuff just to program in C?
Yes, adding new device drivers requires both knowledge of Spin and of the architecture of Catalina. But how does this differ from any other environment? For example, would you expect a novice Linux user to be able to add a new device driver to Linux without knowledge of either assembly language or the kernel architecture? Of course not! However, as I have recently demonstrated, you can now use Spin objects taken directly from the OBEX with Catalina C.
Also, you still seem to misunderstand the Catalina build process. Neither the 'build_all" scripts nor any makefiles have anything to do with Catalina itself. They are not required to build Catalina programs. They are simply utilities I provide to try and simplify things for new users. If they are confusing you, then don't use them. You can either use the command line directly, or Code::Blocks.
As for "not very good manuals" - I acknowledge on page 5 of the reference manual that they are a bit thin - feel free to assist me in improving them.
And as for Catalina being "much less flexible and carries a greater cost than more desirable C solutions" - well, I suggest we carry on this part of the discussion when there is an alternative available to compare it against.
Ross.
Please do - I much prefer this tangent to the direction the rest of this thread is taking!
Ross.
I think this may be the disconnect. You are right that people who write C programs on PC's or Mac's or Linux machines generally expect to be able to compile and run a program without having to worry about what driver gets used to talk to the hard drive, display, or keyboard. However, I don't think this is generally true for people programming microcontrollers. There they are likely to want tight control over what drivers are used and how they interface with the C code. Of course a standard UART driver that allows debug printfs is handy and maybe people would like it if that was built in. I suspect they would want far more control over any other devices and drivers though.
Yes, I acknowledge that - but I also assume that typical microcontroller programmers would be willing to spend the relatively modest amount of time required to learn the details necessary to add their own device drivers. What you (and jazzed also, to some extent) seem to be suggesting is that embedded C programmers would expect to take a new microcontroller and be able add a new device driver in a matter of minutes. This is directly contrary to my own experience, and (even if your experience is different) the unorthodox nature of the Propeller, and the convolutions you have to go through to support C at all, mean it is not likely to ever be true on the Propeller.
As you may have gathered from the (original) topic of this thread - Catalina's direction from now on is going to be more accomodating of Spin, in order to encourage existing Propeller users to experiment with C. I will happily leave it for others to try and entice users to grapple with the complexities of MinGW, GCC, binutils, makefiles, autotools and ELF file formats etc etc - not to mention being required to write their own device drivers - just to to get a simple "hello, world" C programs to run on their Propeller.
Ross.
That's the domain of the ParallaxSemiconductor professional GCC/Eclipse tool-chain.
Demo applications, device drivers, and infrastructure examples will be provided of course.
The goal of serving both audiences is to increase sales by catering to hobbyists and high volume commercial customers.
A rising tide lifts all boats.
... unless the boat you are on is the Titanic.
Ross.
You mean --- Unless HE not BUILD Titanic.
As I dont think Parallax itself are Titanic - BUT all talk on GCC looks for me little as Titanic.
I encourage you to keep doing things the way you see fit. Don't get discouraged.
As they say, the race often goes to he who keeps running.
Parallax is interested in seeing a GCC tool chain for the Propeller, for the sake of wide acceptance, but this is probably not a panacea. There is room for lots of tools.
Chip
Hi Chip,
Thanks for the encouragement. I understand and support Parallax's commerical reasons for GCC (even when I think the way it is being done is sometimes a bit ... well, ummm ... odd!).
However, I will continue to putter along with Catalina - for my own enjoyment as much as anything else. The reasons I originally chose LCC rather than GCC still stand. On an unorthodox and heavily constrained architecture like the Prop 1 (and also for the moving target that is currently the Prop 2!) Catalina has to be lean, mean and agile.
Catalina is a Corvette Stingray, GCC is an Abrams Tank. Sometimes you need one, sometimes you need the other. But only one of them is fun to drive!
Ross.