Catalina: From C to shining C ...
RossH
Posts: 5,519
@All,
Attached is a demo of a Catalina C program runnning in multiple cogs. The demo does not require any special hardware (e.g. SD card or XMM RAM) and could run on any Propeller - however, the enclosed version has been compiled to run on a HYDRA.
Now you can use all 8 Propeller cogs to run C simultaneously. Doing so is as easy as it is from SPIN. You can start a new C function in any cog, shut it down again later, and then re-use it to run another C function. All the cogs have access to all the library functions and plugins.
No special programming is required if all the C functions are independant, or you can use locks if several C functions may need to access the same plugins at the same time.
Here is the actual C code that is running in the attached demo program:
The locked_printf functions is simply a printf wrapped in a lockset and lockclr which prevents two cogs writing to the HMI plugin simultaneously. The reason cogs 0, 1 and 2 do not respond to the ping is that they are already in use - in this case cog 0 is running the main C program, and cog 1 and cog 2 are running the HMI drivers. If we didn't need the HMI to print the output messages then all the cogs could be running C - i.e. one cog running main, and 7 cogs running cog_function.
Note that you will need Catalina 2.6 (as yet unreleased) or later to make use of this new functionality. However, I should point out that I did this primarily for use in my own projects, and I am not planning to release a new Catalina for a while yet. In fact, I am currently considering making this type of advanced functionality available only in a 'commercial' version of Catalina. If you think you would like to use it, please let me know whether you would be willing to pay a nominal amount for it - the cost is intended mainly to cover the ongoing costs of developing and maintaining Catalina.
Ross.
Attached is a demo of a Catalina C program runnning in multiple cogs. The demo does not require any special hardware (e.g. SD card or XMM RAM) and could run on any Propeller - however, the enclosed version has been compiled to run on a HYDRA.
Now you can use all 8 Propeller cogs to run C simultaneously. Doing so is as easy as it is from SPIN. You can start a new C function in any cog, shut it down again later, and then re-use it to run another C function. All the cogs have access to all the library functions and plugins.
No special programming is required if all the C functions are independant, or you can use locks if several C functions may need to access the same plugins at the same time.
Here is the actual C code that is running in the attached demo program:
/***************************************************************************\
* *
* Multiple Cogs Demo *
* *
* This program shows how to use the utility function C_coginit to start *
* many cogs running C functions *
* *
\***************************************************************************/
/*
* include the definitions of some useful multi-cog utility functions:
*/
#include "utilities.h"
/*
* define some global variables that all cogs will share:
*/
static int ping;
static int lock;
/*
* ping_function : C function that can be executed in a cog.
* (the only requirement for such a function is that it
* be a void function that requires no parameters - to
* share data with it, use commmon variables)
*/
void ping_function(void) {
int me = _cogid();
cogsafe_print_int(lock, "Cog %d started!\n", me);
while (1) {
if (ping == me) {
cogsafe_print_int(lock, "... Cog %d pinged!\n", me);
ping = -1;
}
}
}
/*
* main : start up to 7 cogs, then ping each one in turn
*/
void main() {
int i = 0;
int cog = 0;
unsigned long stacks[STACK_SIZE* 7];
// assign a lock to be used to avoid plugin contention
lock = _locknew();
// start instances of ping_function until there are no cogs left
do {
cog = C_coginit(&ping_function, &stacks[STACK_SIZE*(++i)]);
} while (cog >= 0);
// now loop forever, pinging each cog in turn
while (1) {
for (cog = 0; cog < 8; cog++) {
cogsafe_print_int(lock, "Pinging cog %d ...\n", cog);
ping = cog;
// slow things down a bit so we can see the messages
wait(200);
}
}
}
You can run the program using payload:
payload multiple_cogsThe output of this program is:
Cog 3 started! Cog 4 started! Cog 5 started! Cog 6 started! Cog 7 started! Pinging cog 0 ... Pinging cog 1 ... Pinging cog 2 ... Pinging cog 3 ... ... Cog 3 pinged! Pinging cog 4 ... ... Cog 4 pinged! Pinging cog 5 ... ... Cog 5 pinged! Pinging cog 6 ... ... Cog 6 pinged! Pinging cog 7 ... ... Cog 7 pinged!
The locked_printf functions is simply a printf wrapped in a lockset and lockclr which prevents two cogs writing to the HMI plugin simultaneously. The reason cogs 0, 1 and 2 do not respond to the ping is that they are already in use - in this case cog 0 is running the main C program, and cog 1 and cog 2 are running the HMI drivers. If we didn't need the HMI to print the output messages then all the cogs could be running C - i.e. one cog running main, and 7 cogs running cog_function.
Note that you will need Catalina 2.6 (as yet unreleased) or later to make use of this new functionality. However, I should point out that I did this primarily for use in my own projects, and I am not planning to release a new Catalina for a while yet. In fact, I am currently considering making this type of advanced functionality available only in a 'commercial' version of Catalina. If you think you would like to use it, please let me know whether you would be willing to pay a nominal amount for it - the cost is intended mainly to cover the ongoing costs of developing and maintaining Catalina.
Ross.
Comments
Catalina is a great piece of work and I would imagine it is a real labour of love for you.
I'm not a big user of Catalina which is mainly because I just can't get to grips with the syntax of C all those curly brackets confuse the hell out of me.
If you do go with a commercial version then I hope you can keep the price sensible, I'd hate to see you get all bitter that nobody was buying it in favour of the free version. I am willing to pay for great software and development tools, I just hope others feel the same too.
Just purely out of curiosity how many users out there are actually using C to program their Propellers?
Regards,
Coley
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PropGFX - The home of the Hybrid Development System and PropGFX Lite
Re Coley "I'm not a big user of Catalina which is mainly because I just can't get to grips with the syntax of C all those curly brackets confuse the hell out of me."
Me too till I worked out what was going on. I come from the world of structured basic
myprocedure begin instruction instruction endIn structured basic, the begin and end are important parts of many instructions. You usually indent them as above because it makes reading the code easier.
In Spin, the indent becomes the begin/end. So translating structured basic to spin - just leave out the 'begin' and 'end'
In C, 'begin' is the same as "{" and 'end' is the same as "}"
But C is often written with the '{' on the same line;
myprocedure { instruction instruction }I would write it more like
myprocedure { instruction instruction }but I think in the C community such heresy tends to start flame wars [noparse]:)[/noparse]
But C compilers don't really care which way you write it - only the human readers.
Going back to this thread...
I've now suddenly got all sorts of questions: How do you combine pasm and C in a cog? How fast is the compiled C? Do things that are Spin/pasm hybrids and that fit in a cog also fit with pasm and C? Or C by itself (which might be possible given much of C translates very closely to assembly language). Are things like a keyboard driver practical in C? Could one envisage a library of such C objects? Does one write a C program as one big file, or is it in pieces like Spin?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Dr_A: Oh goody let's have another indentation fight [noparse]:)[/noparse]
Yes, it would help if Ross would put his braces in the right places.
I prefer the ANSI style:
while (x == y) { something(); somethingelse(); } finalthing();If only because it looks less cluttered and confusing. I will always use braces even if there is only one statement in the block. Just keeps things clearer and avoids funny mistakes when you decide to add another statement.
One can write a whole program in one file but it's better to divide things up as you would objects in Spin.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes, Catalina was largely a labor of love - but one that will now have to pay its own way if it is going to go any further. However, if I do decide to commercialize it, it will only be to recover some of the ongoing costs - C on the Propeller is not ever likely to make anyone wealthy. The Propeller has very little penetration into the kind of markets that would be willing to pay a reasonable price for such a compiler, or offer a significant volume of sales. I kept hoping Catalina would help change that, but it really needed some backing from Parallax to do so.
I know others will disagree, but my own belief is that many potential professional users lose interest in the Propeller when they realize the only option for taking advantage of its parallel processing capabilities is either to use SPIN (which is non-standard and also fairly slow) or PASM (which is fast, but very complex to program and very limited at only 496 instructions per processor).
I still maintain that C is the ideal compromize - 4 to 8 times faster than SPIN, but with each processor able to use the full 32kb of RAM as code space if necessary. Now that Catalina makes it so easy to utilize multiple processors it may attract a bit more interest. Sure, on the current Propeller LMM PASM is slower than native PASM - but now you can throw up to eight processors at the same problem - and using a language that most people already know.
And of course, think of what becomes possible with the next generation Propellers - Catalina's support for XMM RAM is partly preparation for what will become possible when we have 384k of hub RAM to play with, and also can execute LMM PASM at speeds comparable with "native" PASM.
@Dr_Acula,
Catalina always compiles C to LMM PASM - which must be executed by an LMM kernel. So the C code is not run directly on any cog - each cog runs a modified version of the LMM kernel, and each cog has its own stack and its own set of local variables. This is quite similar to SPIN, which should come as no surprise - this is quite a natural model for the Propeller. However, the global variables and code are shared between all kernels, so each processor may be executing either identical C code or independent C code, and all programs can communicate quite naturally using global variables (as is illustrated in the example).
Of course, if you want to run pure PASM in a particular cog (e.g. for speed) you can do that as well. Catalina now makes all this quite easy - easier than SPIN, in fact. While this new version of Catalina makes it possible to write drivers in either C or LMM PASM, I think it is more likely that they continue to be written in native PASM - at least on the current Propeller. When the next generation Propeller arrives (and gives us a bit more elbow room) then I think writing drivers in C will become more common.
It is already practical to have libraries of C functions - building new libraries intended to be shared between Catalina projects (or even with other Catalina users) is quite easy. Maybe I should add a new technical note about that - I think many people don't realize how easy this is. This new version of Catalina will allow this to be extended to sharing C "modules" that contain code to be executed on their own processors - or on multiple processors.
As to C coding styles, there are many variations, including those you propose - some of them are discussed in more detail at en.wikipedia.org/wiki/Indent_style. I think which one you prefer depends on which languages you knew before you start using C. They each have their merits.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Catalina is a great tool, one that I can hardly wait to use extensively. And I really appreciate you adding Morpheus support.
One of the reasons my PropellerBasic development has slowed to a crawl is precisely due to it not being able to make money - so I certainly understand you trying to generate a revenue stream.
May I suggest that you try to offer the following services?
- paid tech support for Catalina on the prop, for companies who just can't wait for the next release to fix a bug
- paid feature requests, where the paid-for features are rolled back into the open source Catalina
I suspect you will find that companies will be far happier to pay for tech support, or for getting pet features / library calls added faster, than to pay for binary only / additional commercial features. Cygnus makes a decent living doing this, and so do many other companies.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA
The first post in Ross' Catalina thread link in his sig has the catalina_codeblocks.zip.
You should also get familiar with the catalina_manuals.zip in the second post.
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Just a point of reference - ICC supports multiple cog at first release. I don't think adding this feature will increase Catalina's usage.
Best of luck regardless.
// richard
I wasn't claiming Catalina was the first - just the best
Seriously though, thanks for the good wishes - I know you have experienced frustrations similar to mine with the lack of penetration of C on the Propeller.
Foolishly, I keep thinking that "just one more killer Catalina feature" might help make it happen:
- Rich set of device drivers (screen, keyboard, mouse, SD card, real-time clock etc, etc) - check.
- Full file system support - check.
- External RAM support - check.
- Graphical development environment - check.
- Multi-prop system support - check
- Source level as well as assembly level debuggers - check.
- SD card-based operating system - check.
- Multi-cog support - check.
Having now reached the end of my original "wish list" (or at least the end of the easy stuff) I can't help wondering just what it is that is still preventing the Propeller from achieving wider recognition. As these forums attest, the Prop is truly a hobbyist's dream machine - but perhaps this is also its Achilles' Heel? That would be very sad!There are a couple of other things that I think may be preventing the Propeller from achieving the mainstream success it deserves:
- The unit price. This is seriously out of line with the competition. Not true for local buyers in the US, perhaps - but I just looked up the local mainstream electronics supplier here in Australia (from whom we buy tens of thousands of processors per year). From them I can buy (one off) a similarly spec'd ATMEL for A$9.83 - or a Propeller for ... wait for it ... A$52.35!!! Makes you want to cry - but it also makes me wonder why Parallax doesn't do something about it. Don't they want to sell their products?
- The lack of free professional development tools offered direct from Parallax. The reality is that while professional users will often be prepared to pay extra for premium development tools, they still expect a usable one to be provided "out of the box" for nothing. But with the Propeller this means you have the choice of SPIN or ... er, well, nothing! (Apologies in advance to the authors of PropBasic, Forth, Java etc - but none of these are languages likely to find favor with a company looking to develop a new embedded controller for a washing machine or industrial controller).
Ross.@Bill - thanks for the suggestions, but I wouldn't feel comfortable asking money for "one off" support or feature requests when I couldn't also guarantee delivery to any reasonable schedule. Obviously there wouldn't be enough such requests to justify giving up my day job, and this means I would have to squeeze them in to the odd hour here and there. Such a modus operandi is ok for open source support - but it is not ok when people and companies have forked out their hard-earned money and are depending on you.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 6/21/2010 1:03:03 AM GMT
As jazzed has pointed out, Code::Blocks which would seem to meet all your needs. It would also be possible to add blackbox, blackcat and payload as tools to the Code::Blocks menus (check out Tools->Configure Tools) - so you never need to open a DOS window at all.
Catalina does not really need any significant amount of installation (except possibly on 64 bit versions of Windows) - just unzip it to the appropriate location. Code::Blocks is a bit more complex, but there is now a document explaining how to install and configure Code::Blocks included with Catalina ("Getting Started with CodeBlocks").
If there is some particular problem with the Catalina/CodeBlocks installation process that is giving you trouble, let me know and I will try and fix it.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I'm sure you are now saying, wait-a-minute, support for CB should be a 5 min job... and you would be right. Minimal support for CB would be a 5 min job. What we did though, among other things, was to spend the effort to port the compiler project option interface to the CB. So that for example the user can select a device and CB generates the right compiler flags. For the AVR where there are 30+ devices (I lost count
My point? We came in the Propeller market sort of hoping that it will work. Once certain weakness in the market are apparent, we throttled back. On your list above, the only one that makes sense to me is the debugger support, but even that, I knew it will not help in any meaning metric. Understanding what the market wants and needs is essential. Occasionally the two sets only overlap slightly. Opportunities arise in such cases, and so are missteps.
I've though about writing a Catalina-specific plugin for Code::Blocks (I notice that the 'generic' compiler plugin in the latest Code::Blocks release now supports LCC, so this would be a relatively straightforward job). However, I probably won't bother. I personally prefer to use a command line interface (much simpler and much faster!) I keep hoping someone else will volunteer to do it, but no-one has stepped up yet - so on this one ICC will probably remain in front. I take your point about it being necessary to reduce the compilications of the AVR. Perhaps Catalina will eventually get that complicated (actually, if you take into account all the HMI and multi-processor proxy device combinations, it's probably nearly there already).
I agree about the debugger being the most desirable "add on" from a professional perspective (and for this one Bob Anderson gets most of the credit, not me!). After that I would add muti-cog support (because it allows you to really make full use the Propeller's unique capabilities). Then the SD card file system, since I can see this being utilized "in the field" (field-programmable devices, data logging devices etc). It is probably true to say that some of the other features (e.g. multi-prop support) were added mainly because I thought they were cool and wanted to do them
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I'm not quite sure about that, but I think it might involve advertising in the electronics press, a nice glossy photo, a board showing video, keyboard, sd card all working as one unit, and a photo of a hot sexy babe holding your board *grin*
When it comes to takeup, yes, the propeller price is very expensive. The cheapest supplier in Australia is $25, and I must say, when Cluso first came out with the Triblade, the first thing I wanted to do is try to squish the contents of three chips into one. The first CP/M emulation still came in as more expensive on a propeller compared with using real chips ($1.95 for a Z80 CPU, 40c for glue chips etc). I guess the cost issue is Parallax's problem...
Meanwhile, my situation is a little unique but possibly relevant. I'm coding with C on a propeller, but using BDS C as part of a CP/M emulation. I guess it is somewhat daunting to think about a complete conversion to Catalina. For instance, if I want to send something out of a port on a CP/M machine, that is one instruction, and it goes out the serial port using reams and reams of spin and pasm behind the scenes. For a complete conversion to Catalina, that somehow involves linking in some serial driver code. Maybe that is already done? But let's see - the serial driver code I am using started life as the standard version, was modified by one very clever individual to drive 4 ports with 64 byte buffers, then modified by another very clever individual to drive two ports but with 256 byte buffers and still fits in one cog. Could the code that does this be ported into Catalina in some way?
Thinking further along those lines, I wonder if hybrid models could be used? C plus Pasm in an object? A translation program that takes a Prop object and converts the Spin to C and leaves the pasm alone? Can code::blocks handle inline pasm code and compile it correctly?
Inline LMM sounds fascinating. Maybe it needs explaining more, as a google search for LMM brings up a lot of posts on this forum, but very few actually link to something that explains what LMM does.
I'm just thinking about the barriers to making Catalina easier to use. Say I wanted to convert a custom serial object above into something Catalina can use. I know I will never understand how it works, so I want the process to be easy. First problem - if you changed Spin to C, would it still fit? (some Obex objects fit with only a few longs spare). Second issue - can you explicitly select between 'fit totally in a cog' vs LMM that looks like it fits but does not? And does LMM execute at the same speed as real pasm in a cog - and if not, will timing critical code like serial drivers actually work?
I'm trying to think of a way of leveraging off the many man/women years of work that have gone into the Obex and to try to build on that rather than reinventing it all. Having delved a bit into how the BDS C compiler works, I'm guessing it could be quite possible to convert Spin to C almost on a 1 for 1 line translation, and possibly even save space.
Could one consider such a thing as an object that is a simple text file that combines C and Pasm?
Hmm - I'm starting to think about C to Spin and Spin to C converters. What about a program that can handle a text file that mixes Spin and C in the same file? Convert it all to C and compile. Convert it all to Spin and compile. Then see which one used the least code. How hard can it be to convert this into Spin;
for (cog = 0; cog < 8; cog++) {or vice versa?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Ross & Richard (ImageCraft) & Bill, etc: Unfortunately this forum is mostly filled by enthusiastic hobbyists (me included). A lot of us are (ex-)professionals with a lot of experiences in many fields. However, we are still using the Prop in a hobbyist manner.·My pcbs also fall here. Unless you have a product that falls into this category it is lost.
I·truly hope that Catalina & ICC open up the professional market for you. However, I have my doubts until the PropII arrives. If Parallax can successfully market this chip as a more powerful second generation of the Prop aimed at the truly professional market then you will see the fruits of your labour. If the PropII can guarnish some good press, then the existing Prop will gain some recognition there too. I do hope so, because engineers do not understand the prop's advantages in a huge number of applications.
As for pricing (in volume) make no doubt that professionals will sort out pricing issues. Believe me, no-one in Australia, or the UK, or anywhere else, is not going to check out the pricing from Parallax, etc, so they achieve the correct pricing.
I have a professional project (which I will never be able to discuss here) that has some operational issues delaying it at present. It uses a Prop and I·expect sales in 10,000-100,000 if I can resolve the issues. Why am I using the prop? Well this is·very interesting and worth relaying. Previously I·always chose the cheapest micro for the task if I expected volume sales. This time, cost is not an issue - yes 100,000 x $4 is still worthwhile. I can easily use a PIC, AVR,·Freescale MC9S...·worth <$3 and maybe <$2. I can learn either PIC/AVR and I know the MC6805 family which the MC9S is loosely based (I have been out of the industry for ~10 yrs). I could save the eeprom with a pic/avr/mc9s.
Well, I am a little older and want to have more fun with my projects, so I am using a chip that I LOVE. I do not need the features of the Prop. So, I am choosing the Prop because I want to. If I achieve the sales, then the lost $0.5M will not be an issue.
Now we have to get that attitude - the fun style that the prop can do anything - out there.·There will almost always be a cost consideration (unlike mine). However, the prop is a very special chip in that it has a powerhouse of customisable peripherals and 8 fast 32bit processors. It uses low power (some new chips are extremely low power), it has 32KB sram + 8 * 2KB sram (some new chips have more than this now). However, it is the flexibility of the prop that makes it shine. Instead of 100's of variants in a family, it has 1 because it can do·them all. It is·akin to·having a multiprocessor and FPGA combined and the FPGA is customisable with software.
The availability of two C programs (thanks to Richard & Ross) may just finally open this up with the Prop II and then back to the Prop I. Do not lose heart guys, the Prop has come a long way this past 6 months. Perhaps the ability to emulate all those other older processors (and new Zog) may just give it some well deserved publicity. This is what it needs to get it in front of engineers. Parallax has to somehow transition the perceived perception of a hobbyist chip into the mainstream while keeping it's hobbyist appeal at the same time.
..... this is just my observations
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Follow this link... this is the thread from 2006 in which I originally introduced LMM. I explained the basic concepts in it, and I think you will find the thread a good read [noparse]:)[/noparse]
http://forums.parallax.com/showthread.php?p=615022
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
I'm still trying to think of the cool things Ross' code can do. Lots of possibilities.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Interesting observations from several sources here. My main comment (primarily in response to Cluso's post) is that I think there is a fairly limited window of opportunity for the Propeller to make any impact ouside the hobbyist/enthusiast domain - and this window may already be closing (leaving aside special cases like your mystery application, of course!)
While we all talk about the Propeller mk II being the "killer chip" that will save the day (how long have we been saying this?) - I really no longer see any compelling reasons as to why this should turn out to be the case. The Propeller mk II is a fantastic progression from the Propeller mk I - but Moore's Law applies to the Propeller like it does to every other processor. The Propeller mk I was released in 2006, so by now we would expect to be seeing a new version three or four times as complex/powerful/fast. This will just maintain current Propeller market share - it won't necessarily generate any new markets or sales.
Ross.
@Dr_Acula - I recently posted a set of files ("Catalina_Using_PASM.zip") in the fist post of the Catalina thread that might help you understand the difference between "native" or "pure" PASM and "LMM" PASM. As to your other points - why redevelop working PASM code just for the sake of it - just run it in conjunction with a Catalina C program. Catalina offers several ways to do this - and this is also discussed in the README.TXT file in the aforementioned zip file. Also, I'll try and find a cool demo of Catalina impementing a parallel algorithm in C.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
They've shown over time that share isn't everything. Margin and repeat business is. At any given time there are products being developed. That means, at any given time, the potential for savings is on the table. It is true the expectation of overall capability is always escalating, and that accounts for new buzz and other important things. I think that part of things is valid.
Having said that, there are a ton of things to be done that would benefit from propellers. That was true a while back, and it's true now, and it will be true going forward too. Prop II is going to be able to do some things that people currently use single board mini-computers for. That cost savings will be a bigger jump in dollars than the current attributes of the Prop I allow for.
Honestly, a Prop I with 64 pins, instead of the 32, would open the door for some expansion of the current market, and would be a welcome addition while waiting on Prop II. 64 pins would make using external RAM less costly in terms of control capability, for example. Without the RAM, the Prop can easily play "traffic cop" replacing other expensive components, or by freeing some of the design cycle to code, etc...
Once there is a series, it's no longer a one chip wonder kind of thing, and I wonder how much that perception is causing people to hold back.
The other thing of note, regarding Moore's law, is the growing importance of power and BOM management. It's no longer always the sure bet to just crank the specs and let the thermal / layout engineers sort it out. Smaller, potent, efficient and robust devices do not always need the peak specifications as much as they need lower part counts, or to operate very efficiently.
Finally, Moore's law appears to be bending in the horizontal direction more than the vertical. There is a general emphasis on multi-core / multi-processing (which I do not see as the same thing). IMHO, the way Propellers operate is very well aligned with this trend, and that's going to be a good thing over time.
Those things said, I just took a look at an ATMEGA game box, similar to the HYDRA. One of the hype bullet points was "X features", "fully interrupt driven". I assume that equates to "ease of use" as in, load up the library, make your calls, and watch it all go. There is an awful lot of foundation work now done for Propellers that makes this possible, without the interrupts and the many constraints that come with them. Perhaps some effort to congeal those things into more accessible packages would help things.
All in all, gaining some share is necessary, just to establish the chip. Once that's done, value adding to maintain margins is just as effective of a strategy as is competing on sheer cost is, particularly if there is repeat business seeing real benefit from the design trade-offs made in the Propeller. IMHO a big part of this is getting people to make the investments necessary to see the value.
Apple just took over Microsoft's top revenue position, and did so with a modest market share, and little to no debt. User loyalty remains high, and they've been careful to keep value perception high while expanding on the product offerings in multiple ways. Parallax could do similar things to build on the Propeller. They have control over the entire design process, up to and including add on sub-system type products. That's a powerful position to be in, as Apple computer clearly shows.
I see a lot of parallels between that dynamic and how micros are used.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 6/21/2010 5:57:12 AM GMT
The price is not so very bad in the US, but 52.35 OMG! Something just has to be done!
IMO, Parallax is making a mistake by not taking CatalinaC and PropBASIC under
their wing and building support into a new IDE for these languages. It's a blunder
of epic proportion. These 2 projects are just awesome. They should be paying you
guys something to keep you plugging away fixing bugs and adding features.
And why after more than 4 years is there no PASM book!?!? it's mind boggling.
An epic fail :-(
Make something like an arduino but using a prop instead of an AVR and advertise
it with a free BASIC and C. Make a point of the video hardware! Something like that
would sell at the right price.
And institute lower volume prices for the Prop. 5.99/1000 lot is pricey when you
remember that an .80 eeprom is also required. maybe have an option to let a
high volume buyer have the chips run off at a Tiawan fab and just pay a license
fee per chip. This would let people do COB which is sometimes nice.
I just love Chip's chip, I don't want it to fade away. Maybe the new prop will come
with improved language support and an asm book? And a new IDE? And a price equal
to or even lower than the current chip? I know I say this without any knowledge of
the price to manufacture the chips so I may be asking the impossible.
I said I would try and find a good example to illustrate Catalina's new ability to run C concurrently on every cog - well, here is the classic 'Dining Philosophers' problem written in C for Catalina. Each diner is simulated using a cog. Each fork is simulated using a lock. For more details on the problem, and why it is used as a classic example of concurrency, see http://en.wikipedia.org/wiki/Dining_philosophers_problem.
The attached binary will run on a Hydra. No XMM or SD card required. It uses the TV output and the keyboard.
/***************************************************************************\ * * * Dining Philosophers * * * * This progran simulates the "Dining Philosophers" dilemma on the Propeller * * using a cog to represent each philosopher, and a lock to represent each * * fork. * * * * For more details on this classic problem in concurrency, see: * * * * http://en.wikipedia.org/wiki/Dining_philosophers_problem * * * \***************************************************************************/ /* * include the definitions of some useful multi-cog utility functions: */ #include "utilities.h" #define MAX_COGS 8 #define MAX_SEATS 5 #define MAX_COURSES 20 struct Customer { char *name; // customer's name int left; // customer's left fork int right; // customer's right fork }; static struct Customer Philosopher[MAX_SEATS] = { {"Aristotle", 0, 1}, {"Kant", 1, 2}, {"Spinoza", 2, 3}, {"Marx", 3, 4}, {"Russell", 4, 0}, }; static int Seat[MAX_COGS]; // maps cogs to seats static int Lock[MAX_SEATS]; // maps forks to locks static int HMI_Lock = 0; // lock to prevent HMI contention static int Dinner_Bell = 0; // set to 1 to start dinner /* * Pick_Up - pick up a fork */ void Pick_Up(int fork) { do { } while (_lockset(Lock[fork])); } /* * Put_Down - put down a fork */ void Put_Down(int fork) { _lockclr(Lock[fork]); } /* * Diner - function to run on a cog to simulate a philosopher */ void Diner(void) { int me; int course; // wait till dinner is served do { } while (!Dinner_Bell); // get our identity me = Seat[_cogid()]; // be seated cogsafe_print_str(HMI_Lock, "%s has been seated\n", Philosopher[me].name); // have dinner for (course = 1; course <= MAX_COURSES; course++) { cogsafe_print_str(HMI_Lock, "%s is thinking\n", Philosopher[me].name); wait(random(2000)); cogsafe_print_str(HMI_Lock, "%s is hungry\n", Philosopher[me].name); Pick_Up(Philosopher[me].left); Pick_Up(Philosopher[me].right); cogsafe_print_str(HMI_Lock, "%s is eating\n", Philosopher[me].name); wait(random(2000)); Put_Down(Philosopher[me].right); Put_Down(Philosopher[me].left); } // leave cogsafe_print_str(HMI_Lock, "%s is leaving\n", Philosopher[me].name); wait(100); _cogstop(_cogid()); } /* * main - set up the diners and then start dinner */ void main() { int i = 0; int fork = 0; int seat = 0; int num_seats = 0; unsigned long stacks[STACK_SIZE*MAX_SEATS]; cogsafe_print(HMI_Lock, "Dining Philosophers\n\n"); cogsafe_print(HMI_Lock, "Press a key to begin ...\n\n"); k_wait(); randomize(); // kill the keyboard (so we have 5 cogs spare) _cogstop(_cogid() + 1); // kbd is the first driver started after this cog // assign a lock to be used by all cogs (to avoid HMI plugin contention) HMI_Lock = _locknew(); // set up seats and forks until we reach the maximum or // there are no cogs (seats) or locks (forks) left do { seat = C_coginit(&Diner, &stacks[STACK_SIZE*(num_seats + 1)]); if (seat >= 0) { Seat[seat] = num_seats; fork = _locknew(); if (fork < 8) { Lock[num_seats] = fork; num_seats++; } } } while ((num_seats < MAX_SEATS) && (seat >= 0) && (fork >= 0)); if (num_seats >= 2) { cogsafe_print_int(HMI_Lock, "There are %d seats\n\n", num_seats); // set up forks (in case there are less than MAX_SEATS seats) Philosopher[num_seats - 1].right = 0; // now start dinner Dinner_Bell = 1; } else { cogsafe_print(HMI_Lock, "There are not enough seats!\n"); } while (1) { // loop forever } }The following is an example of output of this program:That was my point in developing the Propeller Platform; it helped me with my column ("Spin Zone" in Nuts & Volts) and it would provide a platform that could easily be expanded. Brad Campbell did us a huge favor by incorporating PropBASIC into BST. If Catalina could be incorporated into BST then we really have it made and, perhaps, those considering the Arduino because it programs in C (on the platform of their choice) might give the Propeller a second look.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA
It would of course make C programmers feel good that there is some effort by Parallax to cater to the crowd. Honestly though, officially "mentioning" the different C programing environments is much better than gluing something else to BST which would get further bloated.
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
It took me about a half hour to get it installed on my Windows 7 PC and run a "Hello World" program.· First I had to figure out where to download·Catalina.· I went straight to the big Catalina thread, but then I had to figure out which zip files I needed.· I like using the DOS command line, so I didn't need CodeBlocks.· I downloaded the docs zip file and skimmed through the Catalina PDF to figure out which zip files were needed.· Catalina is split up into two zip files, presumably because of size limitations on forum attachments.· Windows 7 supports WinZip archives, but not the split kind, so I had to download WinZip to handle the split zip files.
The PDF does a good job of describing where to load the Catalina files, and how to run the BAT file to set up the path and other environmental variables.· I created a hello world program and compiled it.· It pulled in mouse, keyboard and video drivers, which I didn't need.· I just wanted to use the Prop terminal as my I/O device.· So I went back to the PDF and found the description of targets.· I tried the "-D PC" flag, and that did the trick.· It just happen to run at 57600 baud, which is what I normally use, so I didn't even have to change the baud rate.
I am looking forward to trying out Catalina on various applications.· It's nice to have an alternative to Spin -- especially one that most professional programmers can program in immediately.· I do have a few suggestion:
-·A Catalina webpage would be useful.· It should give a basic description of Cataline, and have various options for downloading.
- A single-page quick-start document would be good.· This would save time for first-timers in installing Catalina.
- It would be good to include the PC target in the list of other targets, such as HYDRA, Demo board, etc.
- It's not clear to me how the baud rate is set for the PC target
- I would like to see a "cog" target.· I.e., code that runs entirely within a cog with register variables and hub ram access.
Ross, Catalina looks very impressive, and I am looking forward to trying out lots of stuff with it.
Dave
·
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
I'd be happy to pay for the multi-cog version of Catalina C.
BTW: will the Blackcat and Blackbox debuggers remain useable in the multi-cog C environment?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I intend to put up a Catalina web page when I get some time. I've also reserved a sourceforge name to hold the code and will no longer be posting source and binaries on these forums - as Dave Hein points out, the forum limitations on the size and number of zip files are too restrictive.
@Steve,
I have no problem with you hosting a Catalina page. Your page will probably be up way sooner than mine will! Just point back to these forums (currently) or sourceforge (eventually) for source code and binaries.
My next piece of documentation for Catalina will be a FAQ, which I willl use to address some of the niggling little issues (like installation and rebuilding) that tend to get buried in the larger documents. This would be good fodder for a web page.
Ross.
P.S. I notice no-one has said they would be willing to pay anything for a commercial version of Catalina, so release 2.6 will be going on the backburner (a shame, I think - the latest version has a better code generator that generates smaller, faster code and also some really cool features - such as those described in this thread). However, while working on 2.6 I noticed a small issue with release 2.5 (locks are broken) so I will probably release a small patch shortly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
A paying customer! Step right up, sir!
Unfortunately, since you contributed so much, I'd feel downright mean charging you
I have made allowance in the new kernel for debugger support - I think it will be possible to debug programs that use multiple cogs, but probably only one cog at a time - and we will need to figure out how to switch cogs.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina