New User Question about Propeller Programming in C
rvaughn
Posts: 2
Hi all,
I come from the assembly and C programming background (30+ years) using embedded controllers. It looks like the Propeller chip may be a very good migration path for some of my customers aging designs (using the Intel 8032 and MicroChip PIC designs). Many of my designs are fairly complex, and I have concerns about using the SPIN language "interprerter" due to speed of execution. Assembly is nice if needed, but you should not be forced to write your entire application in it. Here are a few of my basic questions:
(1) Is there a good C compiler available for the Propeller and has anyone used it for their applications (applications that you sell to clients or the public).
(2) Of the C compilers available, do they have a complete set of extensions to access all the unique features of the propeller chip?
(3) My main concern is a software "hang" after sending out hundreds of units. Is there a "watchdog" feature in the Propeller? With the 80C32 and PIC chips, I have total control of all operations of the chip. It seems like I am giving up some of this control with the Propeller, is this true? any comments?
(4) It seems many people use code from the Object exchange. It makes me very nervous to use another person's code if it is doing a critical operation in my application (serial port, mouse, keyboard, etc..). Please remember, I am "new"! Are the object modules fully documented, and is all the source code available? Please remember, I create units for a company that ships world-wide. The units MUST be rock solid, without a doubt 100% of the time, or I am out of a job.
(5) If someone has used the Propeller to develop or migrate a product line, I would really appreciate a few minutes of your time, and would like to hear your opinions.
Thanks in advance! Sorry for the long note!
Rick
I come from the assembly and C programming background (30+ years) using embedded controllers. It looks like the Propeller chip may be a very good migration path for some of my customers aging designs (using the Intel 8032 and MicroChip PIC designs). Many of my designs are fairly complex, and I have concerns about using the SPIN language "interprerter" due to speed of execution. Assembly is nice if needed, but you should not be forced to write your entire application in it. Here are a few of my basic questions:
(1) Is there a good C compiler available for the Propeller and has anyone used it for their applications (applications that you sell to clients or the public).
(2) Of the C compilers available, do they have a complete set of extensions to access all the unique features of the propeller chip?
(3) My main concern is a software "hang" after sending out hundreds of units. Is there a "watchdog" feature in the Propeller? With the 80C32 and PIC chips, I have total control of all operations of the chip. It seems like I am giving up some of this control with the Propeller, is this true? any comments?
(4) It seems many people use code from the Object exchange. It makes me very nervous to use another person's code if it is doing a critical operation in my application (serial port, mouse, keyboard, etc..). Please remember, I am "new"! Are the object modules fully documented, and is all the source code available? Please remember, I create units for a company that ships world-wide. The units MUST be rock solid, without a doubt 100% of the time, or I am out of a job.
(5) If someone has used the Propeller to develop or migrate a product line, I would really appreciate a few minutes of your time, and would like to hear your opinions.
Thanks in advance! Sorry for the long note!
Rick
Comments
There is a good C compiler called Catalina for the Propeller, you will want to ask RossH for more detail on this. Catalina C does seem to have a good set of libraries for using various peripherals.
Everything in the OBEX is fully open source, and released under the very permissive MIT license.
Hopefully some one that has already done some commercial products with the Propeller can help with the rest of your questions.
Parallax Inc is ramping up to support customers like yourself that are eyeing the Propeller Chip as a potential candidate. They have plans to also put in place a tested OBEX for users such as yourself. Look for Parallax Semiconductor soon.
About C - I have not used it on the propeller chip. The translation from being a good C programmer to a good SPIN programmer is really, really, really, easy. A week at tops of just playing with the chip will give you the expierence you need to learn how to use it. SPIN is very much like C. Unless you are planning on using a heavy amount of dynamic data structures not having C is not horrible.
About hanging - The propeller chip literally has 8 seperate processors in it that can all restart the chip if they want to. You can dedicate on processor to resart the chip like a watch dog timmer if you want. The whole idea of the propeller chip is not to use the 8 processors to do parallel algorithmic programming but instead to have 7 processors act as soft hardware devices while one main core runs your code.
You have much more control than you have with the propeller than you will have with other chips. With the propeller chip the programmer can touch pretty much everything.
Please check the forum regularly as posts like yours generate a huge number of responces from members. You may wish to enable email notification. I am sure members of the forum who make a living off of selling the propeller chip in equipement will have alot to talk to you about. You also may wish to look into talking to Mike Lord.
Thanks (please forgive any spelling errors
Catalina is a good C compiler based on the lcc tool chain, a stable, multiplatform C compiler. The Propeller-specific changes were made by RossH and he's actively maintaining and extending its features. It compiles partially interpreted code (known as LMM or Large Memory Model code) while allows for programs up to about 32K in size which are stored in the shared (hub) memory and copied for execution into a cog by an efficient interpreter which directly executes most instructions and essentially interprets flow of control instructions. Catalina can also compile XMM code (or eXtended Memory Model) which resides in external SRAM and is copied to a cog for execution using a cache manager. XMM code can be effectively unlimited in size and programs of several megabytes in size have been compiled and run.
Catalina allows access to the same Propeller functions as Spin. Most of the objects in the Object Exchange are written in and for Spin. To use them with C would require some modification. Often these objects consist of an assembly portion that does most of the work in a cog and a Spin portion that acts as the interface to the assembly cog. The assembly portion can be used with minimal changes with Catalina, but the Spin interface has to be rewritten in C. This has already been done for several core I/O objects like asynchronous serial I/O, video output, and SD card / FAT file system I/O.
Others have already posted answers to most of the questions you asked. Just to expand on a couple of points: Yes, Catalina is being used in commercial applications. Catalina comes with a rich set of libraries that give easy access to just about all the Propeller's special features, including the ability to run C code on all 8 cogs concurrently. You can also call assembly language functions from C, or also run assembly or SPIN on some cogs in parallel with your C code if you need to. It would be very easy to dedicate a cog to running a software watchdog that resets the Propeller if it thinks the software running on the other cogs has hung - but most critical applications use an external hardware watchdog circuit that has to be reset regularly or it times out and resets the prop using the external hardware reset line. The propeller is no different in this respect to any other micro. Most of the OBEX code is actively maintained, and any issues are known by people in these forums. The source is always available, but the level of documentation varies.
Ross.
Welcome to the fourum,
I'm fairly sure you will have no issues with using the Catalina C compiler for serious commercial development. No more so than any commercially supported tool chain. For sure all issues I have ever seen come up here have been handled by RossH very promptly.
There may be one potential fly in the ointment. That being the fact that the code generated by Catalina is a little larger than similar functionality written in Spin. That is something you won't know is a problem until your project is done.
Be aware that Catalina C is faster than Spin (by a factor of 4 or more ?) but is still not running at the 20 MIPs you might expect of the Propeller. Perhaps more like 5 MIPS. That is really a consequence of the Prop architecture rather than any failing of the Catalina compiler.
A couple of little quibbles Kye,
Being free or not does nor make it any more or less reliable than paid for software. Plenty of commercial libraries turn out to be buggy with poor support. You only find out after you have paid.
You do not have to "reverse engineer" the code in the OBEX as you might have to for a closed source library. You have the source code. With that in hand you can verify it's correctness by reading it and/or use the source as a basis for a thorough test harness.
Some objects are better than others. Some are better documented than others. When you find an object you like, or a function you require, make sure you ask here. You will receive a lot of frank advice, and once again some better than others, but you will get a lot of help.
I am using the prop in a professional design (in fact 3 props). Unfortunately I cannot disclose details. One of the props has 512KB of SRAM and a microSD and we are using Catalina. I saw Dr_Acula last night and he has Catalina dynamically loading and unloading pasm objects into cogs. There is also another commercial C compiler ICC? (it is on the website)
There are a few things you should be aware of...
You can dedicate one cog to doing a watchdog function, should you wish. In fact, it can be programmed to watch all other 7 cogs. It can also kill/load any cog.
All cogs can access the 32KB hub sram without contention, and the 32KB rom.
There are no interrupts on the prop. This is a huge advantage, but it does require a little rethinking. At first, many cannot understand this and want interrupts. Believe me, you do not need them and in fact are much better off without them.
PASM is the assembler. It is a 32 bit RISC instruction set. It is SIMPLE to learn. There are no registers as such because each instruction has a source and destination which is any address in the cog. The cog has 496 longs of instructions and 16 special registers, making the total 2KB per cog.
Each cog is identical and has counters and video generators. All cogs can access all 32 I/O pins.
Spin is easy and quite similar in many ways to C, basic, etc. However, indentation is enforced, which can be difficult if you were not disciplined to indenting code. Otherwise, it is easy. It compiles to 8bit bytecodes. Sometimes there are more than 1 byte to a bytecode. The spin code is stored in hub and a pasm code runs in the cog to interpret the bytecode. As such, it is not very fast, but it is efficient code. Since you can split your code without using interrupts, often the main program is not time critical and spin will surfice, and it is easy to use.
You then use pasm in a cog for the time critical tasks. Note that we can make all kinds of peripheral interfaces with cog(s) using exactly the one chip. A classic use that you mention is the PS2 keyboard driver. We can place quite intelligent code within the cog to aid the soft peripheral interface which relieves the main code from this.
One of the "toy" apps we have done on the prop (see heaters post above and his icon for the clue) is a Z80 emulation of the prop. We have CPM2.2 running on the prop faster than the old 4MHz Z80 and use the microSD as 8 x 8MB hard disk drives. IIRC one of those was extended to 32MB.
Sometimes we find the cog space is limited. We have overcome this in varying ways such as LMM where the instructions are copied from hub to cog and then executed. We also can copy routines from hub to cog for execuation (overlaying - see my overlay object when you want to use this). If you get to this problem, just ask.
Just for reference, I have been designing and coding commercial micro based products, including some released under Apple's brand name, since 1976 when the MC6800 was released. I am not related to Parallax. However, they are a fantastic company, unlike any other I have come across, and provide lots of help and input to this forum and its members.
The prop is my choice of micro
Just a thought as the whole point of the thread was about C for the propeller.
With respect to a 'software hang', this would be a nightmare for any commercial developer. Dedicating a cog to a watchdog is one solution. Also, if you get really stuck, devote 4 pins on the propeller to an SD card, and then you can always distribute updates via an SD card.
Having used Catalina for nearly a year now, I can attest to it being "rock solid". If something works the first time, it will keep working.
Just a few more follow-up questions:
(1) "Single-Source" is always a hard sell to my clients. Does anyone have concerns about the long-term support and production of the Propeller chip? By long term, I mean 10+ years?
(2) Is there a Propeller "2" version on the drawing board? And if so, what is the migration path from the Version "1" - will it be backward compatible? If the Version "2" comes out, will Parallax stop production of the version "1", and will the version "2" be a "drop-in" replacement? Does Parallax typically give some type of advanced notice for end-of-life (for one-time buy opportunities).
(3) In your experience, do the Parallax support tools change quickly to match any new features or design changes in the Propeller?
Thanks again for your quick and candid responses!
Rick
1) I wouldn't be too concerned about Parallax long term support for Propeller.
2) It's coming. Not as fast as some of us would like, but Parallax keeps us up to date.
3) Support for Parallax tools is good. They definitely fix bugs and respond to show-stopper needs.
Catalina is fine. It's not officially supported by Parallax, but RossH does a good job keeping it current.
I would like to add that you should make sure you investigate thoroughly whether or not Propeller has enough memory for your task. You've probably been thinking about it already judging by question 2. Your experience with microcontrollers will probably lead you to the right conclusion, but the only path to more memory with Propeller today is with external solutions which are quite slow compared to purely on chip solutions.
First of all welcome to the world of Propeller. In a word, yes. Last year they were forced to discontinue the SX microcontroller by the owner of the Intelectual Property for the SX. They made much noise about the necessity for the discontinuence and offered users much advance notice and ordering opportunity to stock up before the product became unavailable.
Even though the Prop II is in the works, I personally don't think that the Prop I will go away anytime soon after the release of Prop II. There will be applications that run on Prop I for which Prop II will be overkill, so I think the the I will be around for a long time to come. You can do a thread search on the forums for info about Prop II, and there is a blog on the progress of its development. Something you will not likely ever see from anyother manufacture!
Jim
But you can pick up spin very quickly if you are a C
coder. I just made notes in a small notebook about
the quirks and differences of spin and in a few days
it became very easy to use. And PASM is also easily
picked up if you have coded in any other asm dialect.
It is especially powerful and is actually a joy to work
with. The creator of the prop did a superb job with both
the interpreter and the assembly language.
It took awhile to get used to interruptless methods. I'm
so used to worrying over the speed of interrupt code that
it soon started to feel like I was cheating when coding
on the prop! :-)
edit: Oh, the fact that there is no code protection ability
for the prop is not really very important when you remember
that there are several unscrupulous outfits in Asia that will
get the code out of any other type of controller for a fee.
There is a sneaky way to protect your code though, it involves
destroying a few bytes of memory in the eeprom chip...the eeprom
is where your code goes since the prop does not have internal
flash memory. Even so, if your adversary is not an idiot s/he will
figure out any protection scheme.
Only "pretty decent", Holly? - you're off my Christmas Card list!
Did you / can post your notes someplace? It seems this would be useful to other folks as well.
Or do you feel that the execeise of creating the notebook is of greater benefit to a user?
Also, this thread has many key points in a small space. Should it be made sticky?
Hello Rick, I'll address a few of the questions that should be answered by Parallax. The community answered the technical questions really well, as usual, and there's little I could add except to say "thanks" to every single one of them.
Regarding #4 about the Object Exchange, in May Parallax is launching a new division specifically for our commercial customers named Parallax Semiconductor. For several months many of us have been very quiet as we prepare this company. It's required a significant change to the way we operate internally and externally, but we're just about there. Of importance to you is our Gold Standard Object program. Beyond OBEX, Parallax Semiconductor will now certify certain objects under our Gold Standard Object guidelines. These objects will be available as their own zip file from www.parallaxsemiconductor.com (it's not live until May 2nd or shortly thereafter).
About #5, I would be pleased to ask other developers if they would be willing to speak with you about their experiences porting product lines to the Propeller. Please contact me offline at kgracey@parallax.com if that is of interest to you. Some of these customers never frequent our forums.
At the moment you may be uncomfortable buying chips from a company that serves education and hobby markets so well, but isn't properly configured for commercial customers. Parallax Semiconductor has the characteristics of what you'll be looking for in a chip supplier. At first glance it will look like we've just created a new web site, but there's much more that will become evident through as we get the chance to serve you under our new name:
- a staff of field application engineers (FAEs) are available at your demand, here there or anywhere
- application notes will be released which have been in development for many months
- the internal structure of the company has focused our engineers on your needs
- support ticket software enables quick problem resolution
- Gold Standard Object guidelines and approval process
- a design consultant program with commission
- Propeller 2 early release notes
There's no reason for us to hide the history of Parallax - we're taking all the best attributes of our past and applying them in Parallax Semiconductor. You'll see a comfortable mix of a conservative business but with the openness for which we are known.
As for the longevity of the Propeller, since we own the design it will always be available. The design we are using is high-throughput meat and potatoes process for the foundry and it is available at multiple locations. Parallax has a history of long-term support; the BASIC Stamp 1 has been available since 1992 with no retirement in sight. If you need a second source for Propellers - or if the Purchasing Manager or company leaders do - you have Mouser and Digi-Key. In addition to our technology, Parallax and Parallax Semiconductor are built on the same principles that you need to be successful with your product: long term supply, stability and the best service. We derive all revenue from sales - I would also argue from a business standpoint that it's more important to partner with a supplier with this background than one which is funded as a spin-off, think-tank, or via government grants. I guess you could say we grow our own food.
Please let me know if I can send you some development hardware.
Sincerely,
Ken Gracey
So, will I have to wait until may to get an answer to this? http://forums.parallax.com/showthread.php?131196-C3-Protoboard-Engineering-Drawings