My "Ethernet" requirements are for an industrial project requiring a large amount of continuously streamed totally deterministic data at 100 Mbs. It will not require standard protocols, as it is an isolated and dedicated system, so I'm saying "ethernet", and I really mean ethernet signalling but no conventional "stack" of any sort as those simply get in the way, make things non-deterministic, and just complicate things too much.
Going to be a lot of fun if I can pull off interfacing 256 nodes bursting 10Mbs into a 100 Mbs master stream. It will require some serious synchronization methods, but I think I have that cased, so now will need to try that.
I can't believe that all that work has gone into Catalina and BASIC and Forth etc with the associated lengthy threads here but there are so few users.
Here's way more data on FORTH usage than anybody would normally want to hear:
There are four primary used of propforth that I know of, which are the three main thread participants and Sal, the author.
There are three forth users that I know of that do not participate in the threads because they have a private version or do things differently than Sal.
There are two propforth users that I know of that generally do not participate in the threads because they are too advanced for our conversations and/or discuss in a different language than English.
So I estimate six propforth users, and three users of other FORTHs on the prop.
The original version spinFORTH came out in 2008, and the reworked propFORTH came out in April 2009. PropFORTH remained publicly untouched due to a bug that prevented it from running on the DemoBoard until May 2010.
So the current (mostly) working propforth development has only been going strong since May 2010, or about eight months. In that period, the development team has doubled to four volunteer participants.
Does anybody have "statistics" for the other languages?
I can't believe that all that work has gone into Catalina and BASIC and Forth etc with the associated lengthy threads here but there are so few users.
Ah, sorry - I completely missed that comment - I only noticed it when Prof_braino responded.
This result doesn't really surprise me. Your question was "What language are you using in your currentmajor Prop project?". There's only a few here who use anything other than Spin for any projects, and even of these users, in most cases their current major project is probably still done in Spin. There are a lot who try the alternatives (C, Basic, Forth etc) - but most of these would still use mostly Spin even if they also occasionally use other languages.
So I won't speak for the other alternative languages, but you can't interpret these poll results as indicating the total number of Catalina users. Some of the users I know of have not even responded to the poll. However, there is no question that the usage of Catalina is still quite low. I'm well aware that Catalina is only now becomming a practical alternative language for the Prop I (on the Prop II it is likely to be a different story, but many of us may not even be around by the time that chip comes out!).
One of the biggest problems when you start on an alternative language for the Prop is that you end up playing "catch up" for so long (e.g. with the OBEX, and also with the multitude of different hardware platforms our there) that some good alternatives probably never make it past the experimental stage.
Putting this into sharper focus, I think the most recent releases of Catalina (after something like a man year of effort!) are probably the first to actually offer something new to Propeller users (i.e. something that users can't do more easily in Spin). I'm referring to the multithreading kernel, which gives you the possibility of running as many threads of control as you like from a high-level language, transparently spread across as many (or as few) cogs as you have available - so that you never need to worry about whether your VGA driver needs one cog, two cogs or three cogs, or your sound driver needs a cog but you just don't have one to spare!
For me, the possibility of this kind of thing is what makes the Propeller (still!) so exciting, and is in fact what Catalina was intended to achieve in the first place. On the very first project I ever attempted in Spin I ran out of both cogs and code space, and there was nothing I could do about it (at the time!). I have been annoyed ever since that it seems to be so difficult to harness the true potential of the Propeller.
My apologies at the time I voted I was working on learning some Python to communicate with the Propeller. So as I went down the list I checked other meaning at lease to me-Python. When I read "Prop project?" I thought about my project. No mysteries here sorry for the suspense.
Actually you had quite a correct interpretation of the poll question, exploiting the ambiguity that the "project" may contain programmable devices other than Props.
I guess there is no way to change it now. Not to worry.
RossH,
This result doesn't really surprise me. Your question was "What language are you using in your currentmajor Prop project?"
Phrasing Poll questions to get what you want is tricky.
What I wanted to avoid is that many votes accumulate for C, BASIC, Forth from people who have tried these things out, made or making a few experiments with them, but ultimately don't use them for the bulk of their time/effort spent on the Prop. So I put "current major" to try and capture actual serious use on projects.
Of course when dealing with hobbyists things are not so clear cut. That three month flirtation with language X which amounted to nothing and may never be used again may have been a major hobby project and a success anyway just for the voyage of discovery.
Anyway Ross, hope you don't think my poll question and comment about the lack of responses was in any way disparaging of any language or system. I was just itching to see the bars move faster:)
Anyway Ross, hope you don't think my poll question and comment about the lack of responses was in any way disparaging of any language or system. I was just itching to see the bars move faster:)
No - I knew what you wanted, and I think you phrased your poll question correctly. I do know a few people are attempting significant projects with C - but probably not their major project.
I agree that it would be nice to see all the non-Spin bars a bit bigger - but this will happen in time.
You point out another ambiguity in the poll question. "major Prop project" does not necessarily mean "your most major Prop project". Perhaps you have three going on al in different languages. Hence the poll allows multiple selections.
As You know I'm are not much for C --- BUT as many people already stated
> Nothing are impossible with Propeller.
I look both on Forth -- Have used FigForth99 some time ago --- Looks eve little on C.
Looked on PropBasic -- And like it.
Else I program my tests to PCB's I build mostly SPIN/PASM as it is quick to work with -- But had so much work on PCB's that in time it is not much Programing.
No - I knew what you wanted, and I think you phrased your poll question correctly. I do know a few people are attempting significant projects with C - but probably not their major project.
I agree that it would be nice to see all the non-Spin bars a bit bigger - but this will happen in time.
It's not surprising that most people use Spin/PASM on the Prop because that's what Parallax provides. When someone begins to learn how to program the Prop they download the Prop Tool and program in Spin. The standard library that comes with the Prop Tool is written in Spin and PASM. Most of the objects in the OBEX are in Spin and PASM. Most of the objects in the OBEX use objects that come with the Prop Tool to make it easy to use them.
In order to program in a different language a developer would have to download or purchase a compiler provided by someone other than Parallax. They would have to rely on others to provide support and help them learn how to program with non-Parallax tools. This adds to the difficulty of working with the Prop for new users, so most of them stay with Spin/PASM and the Prop Tool.
Parallax plans on providing a C compiler that is compatible with Spin objects. When they do this I would expect more developers will program in C, but Spin/PASM will probably remain as the dominant language.
We need a lot more votes to get a better picture of the "fringe" languages.
I suspect that you are right about Spin/PASM remaining dominant but that need not be the case:
If the Prop II came with support for C out of the box, as the Prop I does with Spin, and if that C was standards compliant and preferably open source I see no reason why hoards of C programmers would not descend on the chip and usurp Spin.
I know Spin has the advantage of all the ready made OBEX objects but having a huge C user base would soon fix that issue for C.
I don't mean to sound like I have a downer on Spin, I don't, it's just that for a billion programmers out there they don't want the hassle of picking up "yet another language". Not that that is hard in itself, but it is an extra complication in the scheme of things.
... C out of the box... hoards of C programmers would not descend on the chip and usurp Spin.
My question is: What percent of C programmers are engaged in microcontroller centered activities?
Then: What fraction of that percent of the hoards would be interested in the prop?
The financial applications programmers probably would continue to be not interested, regardless of C or SPIN.
I'm not up on current events, but last I heard the high tech / high cost / bleeding edge stuff was still the realm of specialist programming, (assembler, etc) and the medium "established" tech stuff was the realm of C, with the focus on "easily replaceable work force". Although C does a lot to help the "high tech" become the commonplace.
With the group of C-on-Prop-users we see on these forums as the exception, I still have the impression that the bulk of "typical" C programmers would find the capabilities of the prop too far ahead of the technology curve, or at least too different from what they are familiar with. I'm still basing this impression on the rarity of mulit-core applications, and the weak implementations of the ones that do exist (i.e. Windows on Intel), and the continued pervasiveness of "bloatware".
Maybe this becomes a marketing question and not a technolofgy question.
You say there is a rarity of multi-core applications. How many Propeller applications are really multi-core? It seems to me that almost all of them break down into a main program written in Spin and a bunch of soft-peripherals running in PASM on the other COGs. That isn't really a multi-core application since the peripheral COGs are really just replacing dedicated peripherals on mainstream microcontrollers and the ISR that services them. Granted the multi-core nature of the Propeller may make it easier to code the handlers for these peripherals than writing ISR code but it isn't really multi-core processing. That would suggest that a single algorithm is spread across multiple cores. Is there a multi-core matri multiply in the OBJEX? :-)
C needs to run on a suitable architecture for optimum performance, and the Propeller isn't really suitable. One reason why the ARM is so popular is that it was designed to run C and similar languages very efficiently.
You say there is a rarity of multi-core applications. How many Propeller applications are really multi-core? It seems to me that almost all of them break down into a main program written in Spin and a bunch of soft-peripherals running in PASM on the other COGs. That isn't really a multi-core application since the peripheral COGs are really just replacing dedicated peripherals on mainstream microcontrollers and the ISR that services them. Granted the multi-core nature of the Propeller may make it easier to code the handlers for these peripherals than writing ISR code but it isn't really multi-core processing. That would suggest that a single algorithm is spread across multiple cores. Is there a multi-core matri multiply in the OBJEX? :-)
Yes, that seems to be the case. Even those people using two or more connected Propellers seem to be using them for additional peripherals, instead of true multi-core applications. The chip wasn't designed for those sort of applications, unlike "that chip which must not be named".
Humanoido claims to have multi-core programs running on his amazing creations, but they don't seem to do much, apart from from flashing LEDs.
...a single algorithm is spread across multiple cores. Is there a multi-core matri multiply in the OBJEX? :-)
Exactly. The concept of creating peripherals in software on separate core seems too different from standard practice for the bulk of programmers to appreciate. The technique of getting multiple cores to work together on a single algorithm seems to be beyond eveybody's (me included) ability except for Leon. There's no "killer app" example that show why either of these differences is valuable.
So I question whether having C for the part is the game changer. We know this thing is called "the wheel" but we can't use it because nobody invented "the road". The analogy is a stretch, but you get my point?
which is attracting a lot of interest. It's one of the XMOS "killer applications"; it can't be done on any other chip, AFAIK.
Standard C isn't suitable for multi-core applications, of course. Something like XC which supports parallelism and inter-process communications is required.
At the risk of sidetracking this thread into yet another pro/anti C thread (which I know was not Heater's intention), I think prof_braino makes some points that are worth discussing ...
My question is: What percent of C programmers are engaged in microcontroller centered activities?
A large percentage. Microcontrollers are one place where "plain old" C (as opposed to C++ or C#) is mostly used these days. And in that domain it still has the majority of the market
Then: What fraction of that percent of the hoards would be interested in the prop?
I'd think a small but significant percentage. The problem is that very few of them know about it - and of those that do know about it, some get put off by Spin, and others get put off by the Parallax's historical association with the Basic Stamp (presumably thinking that a company that specializes in low end hobbyist chips couldn't possibly make something so novel and innovative).
The financial applications programmers probably would continue to be not interested, regardless of C or SPIN.
Financial applications in C? I hate to tell you this, but many financial applications are still written in Cobol! A friend of mine just got a job in a Cobol programming house - I couldn't believe it! I thought Cobol was a dead language when I studied it more than 30 years ago!. But apparently they have more work than they know what to do with!
I'm not up on current events, but last I heard the high tech / high cost / bleeding edge stuff was still the realm of specialist programming, (assembler, etc) and the medium "established" tech stuff was the realm of C, with the focus on "easily replaceable work force". Although C does a lot to help the "high tech" become the commonplace.
Yes, the "bleeding edge" is full of a whole bunch of odd languages created specically for highly specialized purposes - but in there with them is C, since it actually does a pretty good job as a "universal assembler", and every platform (even "bleeding edge" one-offs) can have a C compiler ported to them so easily (probably less than a week's work for a C compiler expert) that there is much less need to resort to assembler than there used to be.
With the group of C-on-Prop-users we see on these forums as the exception, I still have the impression that the bulk of "typical" C programmers would find the capabilities of the prop too far ahead of the technology curve, or at least too different from what they are familiar with.
You make it sound like C programmers are a bunch of ossified old fossils - perhaps because you think of C as an "old" language. This is true, but the reason it is still around is that no-one has ever come up with a better "low-level" high-level language (if you see what I mean) - C is just so flexible. Much modern research is still done in C, since it is so ubiquitous and also because it lends itself so easily to being extended. There are various "bleeding edge" languages (such as Leon's XC) that are fairly simple extensions of C.
I'm still basing this impression on the rarity of mulit-core applications, and the weak implementations of the ones that do exist (i.e. Windows on Intel), and the continued pervasiveness of "bloatware".
Maybe this becomes a marketing question and not a technolofgy question.
Partly - but it is also that concurrent programming is still just so very difficult. The tools are improving, but our knowledge of how to solve problems concurrently - even when we know there must be a way to do it - is still quite rudimentary.
The Propeller could really help here - but only if it can get a foothold in the mainstream - which means it needs a C compiler - whether or not the Propeller is particularly well suited to it or not (which is a whole 'nother argument!)
We need a lot more votes to get a better picture of the "fringe" languages.
You wouldn't be trying to bias the poll by any chance?!
I think the poll speaks for itself. And I think it is a very interesting result. It leads me to some thoughts, but a warning first that these thoughts are a little "controversial".
Ok, my language over the last week has been basic4android. Why? Well, an android tablet with a 800x480 screen in full color is now cheaper that a fully populated propeller board plus display. And this thing is fast. A simple loop in Basic is running nearly a million lines a second. A rich language. An advanced IDE. Downloads are wireless.
But I will be coming back to the propeller because one thing the android lacks is decent input and output. I'm working on using the audio output and might end up using the Bell Modem obex code on the propeller side. So this will be heading towards a propeller I/O board for the Android.
The propeller languages are good, but they all could be better.
1) C is great but it has few examples of Obex code and porting Obex code is not easy. C does have the huge advantage of being able to break out of the 32k memory limit.
2) PropBasic needs more commands.
3) Spin does not take full advantage of the propeller in that nearly half the code space is wasted in loading up cogs. And it is limited to 32k even when external memory is available.
I have pondered this for some time and I think there is a solution and it involves creating portable Obex objects. I'm not even quite sure how best to explain such a thing. Essentially it is the pasm code decoupled from associated spin code, and the pasm code to link to the spin code in as few places as possible, and ideally maybe only with one long. The associated spin code needs to be well commented and so is able to be ported to C and Basic and other languages. The pasm part needs to be able to be compiled separately and hence able to be stored in external storage or external ram. Hub references/interface need to be well documented and ideally standardised. Hub references need to be able to be glued together within the program, eg one Obex might only talk to the cog with a single long, whereas another Obex might be a graphics driver and might use up half the hub ram. But hub ram references should not be fixed - they should be able to be moved around by the compiler. And cog code ought to be all loadable through one common 2k block so as to save hub memory and to enable cog code to be loaded and reloaded as needed and hence use the parallel nature of the propeller more fully.
There, I've gone and said it all. Perhaps I now need to code an example to show how this might work? Maybe a new thread?
I'm very surprised there are not more BASIC users. Propeller is after all a Parallax product.
Everyone including fringe guru's should stand up for their language of choice
Concurrent programming is easy given the right tools, such as occam and XC. I don't see how using a Propeller and C will help, though.
Yes, and look how popular Occam is now!
But seriously, I'm not putting down CSP, or Occam, or XC (or Spin for that matter!). These are all perfectly good tools that help you explore the concurrent programming domain - but they don't by themselves solve anything.
The reason I think the Propeller can help is that it is a very cheap, accessible (and fun!) way of encouraging people to explore this domain - without the traditional expense and very steep learning curve of the more esoteric offerings. The main reason I think Spin doesn't help here is that it is more of a reason for people to turn away from the Propeller rather than to embrace it.
What? Of course it does! The abiliity to execute a Spin method concurrently on another cog is built into the language, as are the fundamentals necessary to support inter-process communications and synchronization - but if you want anything more sophisticated than simple semaphores (e.g. mailboxes, rendezvous, channels etc) then you have to build them yourself.
So you can say that Spin's support for concurrent programming is "rudimentary" - but it does exist!
It doesn't have any of the usual constructs that are provided in concurrent languages. You can't distribute an algorithm across several cogs using a par statement, for instance, and inter-process communications aren't provided as part of the language. I don't think that a computer scientist would recognise it as a concurrent programming language.
Perhaps nothing. Except for the fact they don't work. An iterrupt steals time from what ever was running before the interrupt occurred. If that thing is also time critical.the system fails.
Given a fast enough CPU with fast enough interrupt response and an application whose incoming events don't exceed the speed limits imposed by the CPU/interrupt system then real-time operation can be made to work. If the limits are exceeded the system fails.
The only way out is to get a faster processor, not always possible and there is always a limit with the technology available. Or use more cores in parallel each dedicated to some event.
It's not that writing interrupt handlers is hard as such, but dropping an interrupt handler for a new device into an existing system requires that you know all about the limits of that existing system. Are you really sure you have the time. I you really sure that an interrupt at the wrong moment won't break something. Can you organize priorities to avoid that?
If you can just throw your new events at a new core you don't have to worry about any of that, your existing system will not break. Any required timing determinism is maintained.
That implies :
1) All the apps. you have worked on have had time available that can be used for the new interrupt.
2) You have understood pretty much everything about the operation of the existing code that you can be confident that whenever the new interrupt occurs it won't disturb some time critical processing.
Having multiple cores to throw at jobs at least relives one of the latter, which is very important if you are mixing and matching pre-existing code that you did not write, as we do from the OBEX.
You must admit that in the limit an interrupt system will fail, it just won't have the time in total, or there can be two events that really do need to be done in such close time proximity that a single core and interrupts can't handle it. The only way out is more cores. I have hit these limits a few times along the way. It's not nice when it happens in the later stages of development of avionic control systems:)
Yes an RTOS helps by hiding the details of getting your interrupts to work, managing threads and priorities and making your code somewhat portable between different hardware. BUT it also hinders by taking up valuable processing time. An RTOS does not solve the underlying problems.
Comments
My "Ethernet" requirements are for an industrial project requiring a large amount of continuously streamed totally deterministic data at 100 Mbs. It will not require standard protocols, as it is an isolated and dedicated system, so I'm saying "ethernet", and I really mean ethernet signalling but no conventional "stack" of any sort as those simply get in the way, make things non-deterministic, and just complicate things too much.
Going to be a lot of fun if I can pull off interfacing 256 nodes bursting 10Mbs into a 100 Mbs master stream. It will require some serious synchronization methods, but I think I have that cased, so now will need to try that.
Cheers,
Peter (pjv)
Here's way more data on FORTH usage than anybody would normally want to hear:
There are four primary used of propforth that I know of, which are the three main thread participants and Sal, the author.
There are three forth users that I know of that do not participate in the threads because they have a private version or do things differently than Sal.
There are two propforth users that I know of that generally do not participate in the threads because they are too advanced for our conversations and/or discuss in a different language than English.
So I estimate six propforth users, and three users of other FORTHs on the prop.
The original version spinFORTH came out in 2008, and the reworked propFORTH came out in April 2009. PropFORTH remained publicly untouched due to a bug that prevented it from running on the DemoBoard until May 2010.
So the current (mostly) working propforth development has only been going strong since May 2010, or about eight months. In that period, the development team has doubled to four volunteer participants.
Does anybody have "statistics" for the other languages?
Ah, sorry - I completely missed that comment - I only noticed it when Prof_braino responded.
This result doesn't really surprise me. Your question was "What language are you using in your current major Prop project?". There's only a few here who use anything other than Spin for any projects, and even of these users, in most cases their current major project is probably still done in Spin. There are a lot who try the alternatives (C, Basic, Forth etc) - but most of these would still use mostly Spin even if they also occasionally use other languages.
So I won't speak for the other alternative languages, but you can't interpret these poll results as indicating the total number of Catalina users. Some of the users I know of have not even responded to the poll. However, there is no question that the usage of Catalina is still quite low. I'm well aware that Catalina is only now becomming a practical alternative language for the Prop I (on the Prop II it is likely to be a different story, but many of us may not even be around by the time that chip comes out!).
One of the biggest problems when you start on an alternative language for the Prop is that you end up playing "catch up" for so long (e.g. with the OBEX, and also with the multitude of different hardware platforms our there) that some good alternatives probably never make it past the experimental stage.
Putting this into sharper focus, I think the most recent releases of Catalina (after something like a man year of effort!) are probably the first to actually offer something new to Propeller users (i.e. something that users can't do more easily in Spin). I'm referring to the multithreading kernel, which gives you the possibility of running as many threads of control as you like from a high-level language, transparently spread across as many (or as few) cogs as you have available - so that you never need to worry about whether your VGA driver needs one cog, two cogs or three cogs, or your sound driver needs a cog but you just don't have one to spare!
For me, the possibility of this kind of thing is what makes the Propeller (still!) so exciting, and is in fact what Catalina was intended to achieve in the first place. On the very first project I ever attempted in Spin I ran out of both cogs and code space, and there was nothing I could do about it (at the time!). I have been annoyed ever since that it seems to be so difficult to harness the true potential of the Propeller.
Down with the tyranny of Spin!
Ross.
Ah, you see, this is why you should be careful with these polls. Honour has been impugned. Now the only solution is swords at dawn *grin*.
Seriously though, maybe this means only a small number of people are pushing Spin to its limits?
My apologies at the time I voted I was working on learning some Python to communicate with the Propeller. So as I went down the list I checked other meaning at lease to me-Python. When I read "Prop project?" I thought about my project. No mysteries here sorry for the suspense.
Can I change it?
_Ron
Actually you had quite a correct interpretation of the poll question, exploiting the ambiguity that the "project" may contain programmable devices other than Props.
I guess there is no way to change it now. Not to worry.
RossH,
Phrasing Poll questions to get what you want is tricky.
What I wanted to avoid is that many votes accumulate for C, BASIC, Forth from people who have tried these things out, made or making a few experiments with them, but ultimately don't use them for the bulk of their time/effort spent on the Prop. So I put "current major" to try and capture actual serious use on projects.
Of course when dealing with hobbyists things are not so clear cut. That three month flirtation with language X which amounted to nothing and may never be used again may have been a major hobby project and a success anyway just for the voyage of discovery.
Anyway Ross, hope you don't think my poll question and comment about the lack of responses was in any way disparaging of any language or system. I was just itching to see the bars move faster:)
No - I knew what you wanted, and I think you phrased your poll question correctly. I do know a few people are attempting significant projects with C - but probably not their major project.
I agree that it would be nice to see all the non-Spin bars a bit bigger - but this will happen in time.
Ross.
You point out another ambiguity in the poll question. "major Prop project" does not necessarily mean "your most major Prop project". Perhaps you have three going on al in different languages. Hence the poll allows multiple selections.
As You know I'm are not much for C --- BUT as many people already stated
> Nothing are impossible with Propeller.
I look both on Forth -- Have used FigForth99 some time ago --- Looks eve little on C.
Looked on PropBasic -- And like it.
Else I program my tests to PCB's I build mostly SPIN/PASM as it is quick to work with -- But had so much work on PCB's that in time it is not much Programing.
In order to program in a different language a developer would have to download or purchase a compiler provided by someone other than Parallax. They would have to rely on others to provide support and help them learn how to program with non-Parallax tools. This adds to the difficulty of working with the Prop for new users, so most of them stay with Spin/PASM and the Prop Tool.
Parallax plans on providing a C compiler that is compatible with Spin objects. When they do this I would expect more developers will program in C, but Spin/PASM will probably remain as the dominant language.
We need a lot more votes to get a better picture of the "fringe" languages.
I suspect that you are right about Spin/PASM remaining dominant but that need not be the case:
If the Prop II came with support for C out of the box, as the Prop I does with Spin, and if that C was standards compliant and preferably open source I see no reason why hoards of C programmers would not descend on the chip and usurp Spin.
I know Spin has the advantage of all the ready made OBEX objects but having a huge C user base would soon fix that issue for C.
I don't mean to sound like I have a downer on Spin, I don't, it's just that for a billion programmers out there they don't want the hassle of picking up "yet another language". Not that that is hard in itself, but it is an extra complication in the scheme of things.
My question is: What percent of C programmers are engaged in microcontroller centered activities?
Then: What fraction of that percent of the hoards would be interested in the prop?
The financial applications programmers probably would continue to be not interested, regardless of C or SPIN.
I'm not up on current events, but last I heard the high tech / high cost / bleeding edge stuff was still the realm of specialist programming, (assembler, etc) and the medium "established" tech stuff was the realm of C, with the focus on "easily replaceable work force". Although C does a lot to help the "high tech" become the commonplace.
With the group of C-on-Prop-users we see on these forums as the exception, I still have the impression that the bulk of "typical" C programmers would find the capabilities of the prop too far ahead of the technology curve, or at least too different from what they are familiar with. I'm still basing this impression on the rarity of mulit-core applications, and the weak implementations of the ones that do exist (i.e. Windows on Intel), and the continued pervasiveness of "bloatware".
Maybe this becomes a marketing question and not a technolofgy question.
Yes, that seems to be the case. Even those people using two or more connected Propellers seem to be using them for additional peripherals, instead of true multi-core applications. The chip wasn't designed for those sort of applications, unlike "that chip which must not be named".
Humanoido claims to have multi-core programs running on his amazing creations, but they don't seem to do much, apart from from flashing LEDs.
Exactly. The concept of creating peripherals in software on separate core seems too different from standard practice for the bulk of programmers to appreciate. The technique of getting multiple cores to work together on a single algorithm seems to be beyond eveybody's (me included) ability except for Leon. There's no "killer app" example that show why either of these differences is valuable.
So I question whether having C for the part is the game changer. We know this thing is called "the wheel" but we can't use it because nobody invented "the road". The analogy is a stretch, but you get my point?
XMOS has some nice multi-core applications like this one:
http://www.xmos.com/products/development-kits/usbaudio2mc
which is attracting a lot of interest. It's one of the XMOS "killer applications"; it can't be done on any other chip, AFAIK.
Standard C isn't suitable for multi-core applications, of course. Something like XC which supports parallelism and inter-process communications is required.
A large percentage. Microcontrollers are one place where "plain old" C (as opposed to C++ or C#) is mostly used these days. And in that domain it still has the majority of the market I'd think a small but significant percentage. The problem is that very few of them know about it - and of those that do know about it, some get put off by Spin, and others get put off by the Parallax's historical association with the Basic Stamp (presumably thinking that a company that specializes in low end hobbyist chips couldn't possibly make something so novel and innovative). Financial applications in C? I hate to tell you this, but many financial applications are still written in Cobol! A friend of mine just got a job in a Cobol programming house - I couldn't believe it! I thought Cobol was a dead language when I studied it more than 30 years ago!. But apparently they have more work than they know what to do with! Yes, the "bleeding edge" is full of a whole bunch of odd languages created specically for highly specialized purposes - but in there with them is C, since it actually does a pretty good job as a "universal assembler", and every platform (even "bleeding edge" one-offs) can have a C compiler ported to them so easily (probably less than a week's work for a C compiler expert) that there is much less need to resort to assembler than there used to be.
You make it sound like C programmers are a bunch of ossified old fossils - perhaps because you think of C as an "old" language. This is true, but the reason it is still around is that no-one has ever come up with a better "low-level" high-level language (if you see what I mean) - C is just so flexible. Much modern research is still done in C, since it is so ubiquitous and also because it lends itself so easily to being extended. There are various "bleeding edge" languages (such as Leon's XC) that are fairly simple extensions of C. Partly - but it is also that concurrent programming is still just so very difficult. The tools are improving, but our knowledge of how to solve problems concurrently - even when we know there must be a way to do it - is still quite rudimentary.
The Propeller could really help here - but only if it can get a foothold in the mainstream - which means it needs a C compiler - whether or not the Propeller is particularly well suited to it or not (which is a whole 'nother argument!)
Ross.
http://www.usingcsp.com/
A free copy of his book is available there.
Concurrent programming is easy given the right tools, such as occam and XC. I don't see how using a Propeller and C will help, though.
You wouldn't be trying to bias the poll by any chance?!
I think the poll speaks for itself. And I think it is a very interesting result. It leads me to some thoughts, but a warning first that these thoughts are a little "controversial".
Ok, my language over the last week has been basic4android. Why? Well, an android tablet with a 800x480 screen in full color is now cheaper that a fully populated propeller board plus display. And this thing is fast. A simple loop in Basic is running nearly a million lines a second. A rich language. An advanced IDE. Downloads are wireless.
But I will be coming back to the propeller because one thing the android lacks is decent input and output. I'm working on using the audio output and might end up using the Bell Modem obex code on the propeller side. So this will be heading towards a propeller I/O board for the Android.
The propeller languages are good, but they all could be better.
1) C is great but it has few examples of Obex code and porting Obex code is not easy. C does have the huge advantage of being able to break out of the 32k memory limit.
2) PropBasic needs more commands.
3) Spin does not take full advantage of the propeller in that nearly half the code space is wasted in loading up cogs. And it is limited to 32k even when external memory is available.
I have pondered this for some time and I think there is a solution and it involves creating portable Obex objects. I'm not even quite sure how best to explain such a thing. Essentially it is the pasm code decoupled from associated spin code, and the pasm code to link to the spin code in as few places as possible, and ideally maybe only with one long. The associated spin code needs to be well commented and so is able to be ported to C and Basic and other languages. The pasm part needs to be able to be compiled separately and hence able to be stored in external storage or external ram. Hub references/interface need to be well documented and ideally standardised. Hub references need to be able to be glued together within the program, eg one Obex might only talk to the cog with a single long, whereas another Obex might be a graphics driver and might use up half the hub ram. But hub ram references should not be fixed - they should be able to be moved around by the compiler. And cog code ought to be all loadable through one common 2k block so as to save hub memory and to enable cog code to be loaded and reloaded as needed and hence use the parallel nature of the propeller more fully.
There, I've gone and said it all. Perhaps I now need to code an example to show how this might work? Maybe a new thread?
Everyone including fringe guru's should stand up for their language of choice
Yes, and look how popular Occam is now!
But seriously, I'm not putting down CSP, or Occam, or XC (or Spin for that matter!). These are all perfectly good tools that help you explore the concurrent programming domain - but they don't by themselves solve anything.
The reason I think the Propeller can help is that it is a very cheap, accessible (and fun!) way of encouraging people to explore this domain - without the traditional expense and very steep learning curve of the more esoteric offerings. The main reason I think Spin doesn't help here is that it is more of a reason for people to turn away from the Propeller rather than to embrace it.
Ross.
What is difficult about writing ISR handlers?
Apart from that your other comments about the usage (wastage) of cogs is spot on in terms of what they get used for i.e. soft peripherals.
Cheers
What? Of course it does! The abiliity to execute a Spin method concurrently on another cog is built into the language, as are the fundamentals necessary to support inter-process communications and synchronization - but if you want anything more sophisticated than simple semaphores (e.g. mailboxes, rendezvous, channels etc) then you have to build them yourself.
So you can say that Spin's support for concurrent programming is "rudimentary" - but it does exist!
Ross.
It doesn't have any of the usual constructs that are provided in concurrent languages. You can't distribute an algorithm across several cogs using a par statement, for instance, and inter-process communications aren't provided as part of the language. I don't think that a computer scientist would recognise it as a concurrent programming language.
Perhaps nothing. Except for the fact they don't work. An iterrupt steals time from what ever was running before the interrupt occurred. If that thing is also time critical.the system fails.
Given a fast enough CPU with fast enough interrupt response and an application whose incoming events don't exceed the speed limits imposed by the CPU/interrupt system then real-time operation can be made to work. If the limits are exceeded the system fails.
The only way out is to get a faster processor, not always possible and there is always a limit with the technology available. Or use more cores in parallel each dedicated to some event.
It's not that writing interrupt handlers is hard as such, but dropping an interrupt handler for a new device into an existing system requires that you know all about the limits of that existing system. Are you really sure you have the time. I you really sure that an interrupt at the wrong moment won't break something. Can you organize priorities to avoid that?
If you can just throw your new events at a new core you don't have to worry about any of that, your existing system will not break. Any required timing determinism is maintained.
That implies :
1) All the apps. you have worked on have had time available that can be used for the new interrupt.
2) You have understood pretty much everything about the operation of the existing code that you can be confident that whenever the new interrupt occurs it won't disturb some time critical processing.
Having multiple cores to throw at jobs at least relives one of the latter, which is very important if you are mixing and matching pre-existing code that you did not write, as we do from the OBEX.
You must admit that in the limit an interrupt system will fail, it just won't have the time in total, or there can be two events that really do need to be done in such close time proximity that a single core and interrupts can't handle it. The only way out is more cores. I have hit these limits a few times along the way. It's not nice when it happens in the later stages of development of avionic control systems:)
Yes an RTOS helps by hiding the details of getting your interrupts to work, managing threads and priorities and making your code somewhat portable between different hardware. BUT it also hinders by taking up valuable processing time. An RTOS does not solve the underlying problems.