You mentioned that there is no sharing, at least on I/O pins. But you have a cog controlling and reading the ADC position inputs. How are the positional values transferred from the ADC cog to the x, y, z, or FPU functions? It almost sounds like an intercog communications problem. Possibly the ADC cog may be stepping on the wrong areas of the hub stored code or variables. Or the functions are reading/writing to an incorrect area of hub ram. I have not had really anytime to play with C on the prop, but the memory model your are using LMM, CMM etc may have an impact on what is stored where. If a cog is not writing in the expected location, it may be that something is getting hammered in the stored code. It may not present immediately, but take as while before a value gets hit to cause the unit to fail. So it may be worth noting for Heater, or one of the other C conversant which memory model you are using for the project.
F
Looks like I may have overlapped on some points/checks made by earlier posters. Was a bit remiss reading the thread through before my last post. Sorry about any redundancy...........
Hi Frank,
I am getting a bit repetitious as well...but sometimes it helps.
The x, y, and z positions are not read by any ADC. The only use of the ADC is to read a single voltage sent by the plasma cutter. This voltage is a measure of the position between the cutter tip and the work piece. It ranges from o volts dc to 8 volts dc. My control board scales it to a range from o volts dc to 3 volts dc.
The cutter tip is moved to a starting zero point then all x and y positions are referenced from that zero point so there is no need to make position measurements.
I know little about how the SimpleIDE C compiler sets up the propeller but I do feel that something is amiss here.
Maybe Heater can look into the memory allocations and other associated functions and figure out what needs to be done to make the current design work.
As I mentioned earlier, if I change the z axis code to only output two slowly changing commands (UP and DOWN) to a BS2e where the four phase waveforms are generated for z axis control...everything works fine. But that requires a redesigned board...which I would like to avoid if at all possible.
Also, the ADC is the same chip used on the Propeller Activity Board so the same C code instruction is used and it works perfectly well.
Company policy does not permit product code and schematics to be disseminated.
Discovery, I suggest you get permission from your employer to post the code. Your problem could probably be quickly resolved if we could see the code. Try to reduce your code down to a minimal program that demonstrates the problem. Hopefully, the minimal code will not contain any proprietary features, and you will be able to post it.
Even if your code does contain proprietary features, your employer may be more interested in working code rather than any proprietary features that it may contain. Seek permission to post the code, and save some time in finding the problem
Hi Frank,
...
As I mentioned earlier, if I change the z axis code to only output two slowly changing commands (UP and DOWN) to a BS2e where the four phase waveforms are generated for z axis control...everything works fine
. ...
Just to make sure that it is not a pin conflict.
You said before that 2 of your 4 waveforms where missing, in case of failure.
I am pretty sure you took the working two pins to connect to your BS2. I would have.
Sadly neither I or anyone else here can do that. There is no code to look at. No schematics or layouts either. We cannot comment on anything concrete only suggest common, recurring issues that may or may not be your problem.
I certainly have no interest in exploring in the dark and falling down rabbit holes for a closed source commercial product. What do I get out of it?
Here is what I get out of it: We like to see Propeller based projects working and become successful. No matter if they are closed source and commercial or open source. If your product works and sells then you will be increasing the number of Propellers sold. That is good for Parallax and it is good for us as a result. Parallax remains in business, they get to produce the next gen Propeller 2, they get to do more of all that good stuff they do. We all win.
That is why we are all interested in helping you out. That and the terrible itch of curiosity, wanting to know what the mysterious issue is and how you ultimately resolve it. After all if there is a bug in the compiler or something weird like that we want to know what it is.
There must be a way that you can help us to help you. As suggested above you should be able to remove code until you have the smallest possible thing that demonstrates the Problem. You should be able to show us that code so that people can review it and test it.
I am now back in the shop and augmented the plasma cutter code to run on the Propeller Activity Board by putting the output stepper waveforms on pins 0, 1, 2, and 3 for the z axis motor; pins 5, 6, 7, and 8 for the x axis motor; and pins 10, 11,12, and 13 for the y axis motor. The adc_init instruction was changed to the set 21, 20, 19, and 18. All the inputs to the program were removed and the program ran without controlling elements. However, all the stepper motor outputs worked perfectly. Adjusting the pot voltage through the limit range clocked the z axis waveforms correctly. Everything in the smaller program worked properly.
This is very good news.
Next, I will perform the same scale down on the plasma cutter code to verify the same operation on the 40 pin propeller. If the small program works, the eliminated parts will be put back into the program one-by-one until the problem returns.
Here are my findings during exhaustive testing of the 40 pin propeller on the PC board and the operational code.
The code is written so that a while loop is executed immediately so that each axis can be slewed to a (0, 0, 0,) starting position. When the slewing is completed the START CUTTING button is depressed and the program exits the while loop and begins running the main code.
The slewing while loop is in the main program COG.
Movement in the x and y axes is performed from the main program COG.
Servoing the z axis motor is performed in the free running Z axis Servo COG. The actual code that performs the generation and phasing of the four waveforms that turn the motor is called from a subroutine.
So, when the z axis needs slewing the subroutine is called to perform the UP and Down movements. When the z axis needs servoing during cutting, the z axis COG calls the same routine for turning the z axis motor.
Here is the problem. If the z axis is not slewed then the START CUTTING button is depressed. All axes operate perfectly and the z axis tracks the simulated cutter hight voltage perfectly. However, if the z axis is slewed to a starting position then the START CUTTING button is depressed only one, two or sometimes three waveforms are generated for the z axis motor. This test was repeated numerous times with the same results. Why should this be so? It appears to me that when the z axis motor subroutine is first accessed from the main program slew loop, the motor control output pins are allocated to the main program COG and are fixed in position. When the z axis motor subroutine is first accessed from the z axis servo COG, a different allocation is established and fixed in position. And the pins don't match.
If I remove the z axis slewing call from the main program, the machine cuts perfectly but I cannot slew the cutting head to accommodate different thicknesses of metal in the cutter. This is unacceptable.
Discovery,
You have found your bug!
What is happening is as suspected by some. The main code is setting the z axis pins up when you call the z routine from the main code. Subsequently you start another cog to control the z axis and it sets the same output pins. Now what happens is that the same pins from the main code and the z cog will be "ORed" together. Any pins left at a "1" in the main program will be shut out by the OR from moving in the z cog.
What you need to do is start the z cog and then if you need to slew the z axis before start cutting, you need to pass a parameter(s) to the z cog for it to do the slewing.
Quite possibly the x & Y axis code should be in another 1 or two cogs too. This would likely simplify your code.
BTW It would have been far easier to post a cut down version of your code here and described it's operation as "pseudo" device such as a 3D printer. I understand your commercial dilemma, but you are asking for free help when someone is paying for the code to be done. When people help for free, they expect to see published code and/or circuits in return. I am amazed at the help you have obtained here under the circumstances. This reflects the enthusiasm of the prop fans here.
I found that process description rather hard to follow but I think Cluso has a valid point.
Put one and only one COG in charge of some particular I/O. In your case the Z axis seems to be a good example. That one thread in one COG should be in charge of any initialization, setting DIR for example, reading it's input pins and driving it's output pins.
If the main program wants to command those same I/Os, well basically it should not. It should have already started the COG that manages that subsystem and then send commands, through HUB memory, too tell the subsystem what to do.
Seems what we have here is a common or garden race condition between multiple processes.
I agree with Cluso's sensibilities. In instances where there are cogs to spare, where I'm not constrained to pinch every milliwatt, and where reliability is paramount, by all means simplify as much as possible!
There are few things in the world I like less than a call at 2 AM telling me that some customer somewhere has a problem. So with thousands of instances of my code operating in commercial vehicles around the country and medical offices around the world, I am absolutely neurotic about keeping things simple and straightforward.
In a canned application like yours, if there isn't a compelling need to stop and restart cogs, I wouldn't dream of doing so. Others may do differently, but my attitude is "why invite trouble?"
The reason is that the x and y movements are tightly bonded together during a cutting operation and no other operation of any kind is permitted to utilize any time slice in that operation.
It comes from the unique design of the cutting system.
The z axis function is completely different from the x and y functions and operates asynchronously from them. It is the function of the design.
The x and y movements are synchronous and the z is not.
For now, the plasma cutter machine will operate in two steps. The first step is to turn on the machine and perform a z axis position movement to place the cutting tip 1.5 mm from the metal work piece. The second step is to turn the machine off then turn it back on to perform any x and y axes slewing followed by a cutting operation.
This will be the mode of operation until I can find an upgrade to eliminate the two stage process. More laboratory work.
I would like to thank everyone who made contributions to identifying and solving this problem.
As an after thought...it would not be difficult at all to leave the z axis motor phases in an all 1s state or an all 0s state after performing the slewing so that when the z axis servo COG wants to use the phase pins they will be ORed or ANDed...whatever so that all four phases can be generated in the servo COG.
I will try that tomorrow on the Propeller Activity Board.
Why kibitz here on a commercial project? Can still learn something in the process and for me at any rate, it's all about the challenge. I fix imaging systems (big ones, CT and Card/angio systems) for a living. Good job, but the real payoff for me comes with beating the more difficult/obscure problems. Propeller is a hobby that once in a while I get time to play with. This was one of those, sorta like walking into a dark room and trying to first identify the overall function of the machine, then its design, and finally its faults. Like a moth to a flame......
Now that there is more to go with, I would guess that the cutter is fed a continuous stream of coordinates from the computer as the job progresses, with the assumption that the workpiece is a flat uniform surface. Since the x and y function seems to be working as it should, I would leave them alone for now; rather make the two step startup process into a single function. Use a separate cog to run the Z axis with a zero command or signal pin and a run command or pin. At initialization of the job, drive Z to max upward distance, slew to x=0, y=0 then on halt, have Z axis drive down slow until a micro-switch (or light barrier) trips the 1.5mm height limit and use that position voltage as the zero point and turn the Z axis loose in a closed loop servo fashion to maintain Z height across the workpiece (maybe in a future version, enable height tracking from the surface). Once the servo is locked on, signal the main cog to enable / signal the computer to start the job running. At end, have main signal Z to go to max height and move cutter out of way to a park position.
But that is the nice thing about the prop, all the separate cogs. which can all operate independently of each other. Well except the ability to stomp on each others toes, er I/O functions. Can always refine incrementally after the design proves out.
The reason is that the x and y movements are tightly bonded together during a cutting operation and no other operation of any kind is permitted to utilize any time slice in that operation.
It comes from the unique design of the cutting system.
The z axis function is completely different from the x and y functions and operates asynchronously from them. It is the function of the design.
The x and y movements are synchronous and the z is not.
For now, the plasma cutter machine will operate in two steps. The first step is to turn on the machine and perform a z axis position movement to place the cutting tip 1.5 mm from the metal work piece. The second step is to turn the machine off then turn it back on to perform any x and y axes slewing followed by a cutting operation.
This will be the mode of operation until I can find an upgrade to eliminate the two stage process. More laboratory work.
I would like to thank everyone who made contributions to identifying and solving this problem.
Code was added to the main program "while loop" to direct z axis Slew up and down commands to the Z axis COG. New code was added to the z axis COG to perform z axis slewing.
Everything works as originally designed. No double pass operation.
The machine was delivered to the client and put into operation.
The advantages of the prop is that you can use separate cogs to perform the tricky time critical functions, and then the typical main controlling cog can serve up the tasks to these cogs while not being time critical.
In your case here, the x and y axis cog could be one or two cogs. One cog would keep sync easier, but two cogs could maintain sync quite simply once you understand the prop better. The main cog could pass themaths to another cog(s) for calculating the next xy move while the xy cog(s) perform the current move. This is how to use the parallel cogs for best efficiency while kepping the software simple.
That's a very good point. I plan on doing some bench work with the Propeller Activity Board and become more familiar with propeller operations.
I learned to program C while developing the CNC Plasma Cutting Machine and found C to be a very nasty language to learn. I suspect that doing the timing you suggest will require learning SPIN...which doesn't look fun at all.
That's a very good point. I plan on doing some bench work with the Propeller Activity Board and become more familiar with propeller operations.
I learned to program C while developing the CNC Plasma Cutting Machine and found C to be a very nasty language to learn. I suspect that doing the timing you suggest will require learning SPIN...which doesn't look fun at all.
I could be wrong though.
Discovery
Spin is easy, pull down the softcopy of the propeller education book. You'll probably blow through it in no time. Then look into using that with PASM for when you really need that level of speed or detail.
I learned to program C while developing the CNC Plasma Cutting Machine and found C to be a very nasty language to learn. I suspect that doing the timing you suggest will require learning SPIN...which doesn't look fun at all.
How many languages do you know?
Spin is simply different from C although the operators are more complex ... and have different meanings. Spin indenting is easier than Python and good for people who don't like details. Spin syntax is heavily influenced by object Pascal Delphi stuff which is the favorite Parallax PC application language. PASM is a lot like ARM assembly (with limits), and easy to goof if you don't know what # does.
My own opinion is that SPIN/PASM (and Parallax by extension) unnecessarily redefine things from naivette, convenience, because they think something is silly, or just for cultish charm.
Added: Overall though Parallax tries very hard to enable learning by focusing on things they consider important. In this task they have generally done a great job.
...found C to be a very nasty language to learn...
That's rather a serious negative response. Could you perhaps elaborate on what was "nasty" about it?
I'm curious because thousands of people are learning C++ by means of the Arduino and seem to get along just fine with it. I'd like to think the C programming environment for the Propeller is at least as easy as the Arduinos. If it is not something is wrong.
I do it admit that C programming can get rather narly but for most MCU tasks it's can be very straight forward. The Arduino folks carefully don't talk about the complexities of C++ in their tutorial and reference materials, and their IDE does a good job of hiding it. In fact they never call the Arduino programming language C++. Presumably so as not to scare people away!
I suspect that doing the timing you suggest will require learning SPIN...which doesn't look fun at all.
As far as I know C executes faster than Spin. At least I don't expect Spin to be any better at this.
Again, perhaps you could say why Spin does not look fun?
Spin is a very simple and elegant language for most tasks on the Prop. It's string handling is a bit clumsy but still. The object system is nice. Easily launching code in other processors is nice.
By way of context it would be interesting to know what are the "nice" languages that you are judging C and Spin by.
Comments
You mentioned that there is no sharing, at least on I/O pins. But you have a cog controlling and reading the ADC position inputs. How are the positional values transferred from the ADC cog to the x, y, z, or FPU functions? It almost sounds like an intercog communications problem. Possibly the ADC cog may be stepping on the wrong areas of the hub stored code or variables. Or the functions are reading/writing to an incorrect area of hub ram. I have not had really anytime to play with C on the prop, but the memory model your are using LMM, CMM etc may have an impact on what is stored where. If a cog is not writing in the expected location, it may be that something is getting hammered in the stored code. It may not present immediately, but take as while before a value gets hit to cause the unit to fail. So it may be worth noting for Heater, or one of the other C conversant which memory model you are using for the project.
F
Looks like I may have overlapped on some points/checks made by earlier posters. Was a bit remiss reading the thread through before my last post. Sorry about any redundancy...........
I am getting a bit repetitious as well...but sometimes it helps.
The x, y, and z positions are not read by any ADC. The only use of the ADC is to read a single voltage sent by the plasma cutter. This voltage is a measure of the position between the cutter tip and the work piece. It ranges from o volts dc to 8 volts dc. My control board scales it to a range from o volts dc to 3 volts dc.
The cutter tip is moved to a starting zero point then all x and y positions are referenced from that zero point so there is no need to make position measurements.
I know little about how the SimpleIDE C compiler sets up the propeller but I do feel that something is amiss here.
Maybe Heater can look into the memory allocations and other associated functions and figure out what needs to be done to make the current design work.
As I mentioned earlier, if I change the z axis code to only output two slowly changing commands (UP and DOWN) to a BS2e where the four phase waveforms are generated for z axis control...everything works fine. But that requires a redesigned board...which I would like to avoid if at all possible.
Also, the ADC is the same chip used on the Propeller Activity Board so the same C code instruction is used and it works perfectly well.
Discovery
Even if your code does contain proprietary features, your employer may be more interested in working code rather than any proprietary features that it may contain. Seek permission to post the code, and save some time in finding the problem
Just to make sure that it is not a pin conflict.
You said before that 2 of your 4 waveforms where missing, in case of failure.
I am pretty sure you took the working two pins to connect to your BS2. I would have.
Ever tried the other two? Just to nail it down?
I am still curious as to where this comes from.
Enjoy!
Mike
I certainly have no interest in exploring in the dark and falling down rabbit holes for a closed source commercial product. What do I get out of it?
Here is what I get out of it: We like to see Propeller based projects working and become successful. No matter if they are closed source and commercial or open source. If your product works and sells then you will be increasing the number of Propellers sold. That is good for Parallax and it is good for us as a result. Parallax remains in business, they get to produce the next gen Propeller 2, they get to do more of all that good stuff they do. We all win.
That is why we are all interested in helping you out. That and the terrible itch of curiosity, wanting to know what the mysterious issue is and how you ultimately resolve it. After all if there is a bug in the compiler or something weird like that we want to know what it is.
There must be a way that you can help us to help you. As suggested above you should be able to remove code until you have the smallest possible thing that demonstrates the Problem. You should be able to show us that code so that people can review it and test it.
I am now back in the shop and augmented the plasma cutter code to run on the Propeller Activity Board by putting the output stepper waveforms on pins 0, 1, 2, and 3 for the z axis motor; pins 5, 6, 7, and 8 for the x axis motor; and pins 10, 11,12, and 13 for the y axis motor. The adc_init instruction was changed to the set 21, 20, 19, and 18. All the inputs to the program were removed and the program ran without controlling elements. However, all the stepper motor outputs worked perfectly. Adjusting the pot voltage through the limit range clocked the z axis waveforms correctly. Everything in the smaller program worked properly.
This is very good news.
Next, I will perform the same scale down on the plasma cutter code to verify the same operation on the 40 pin propeller. If the small program works, the eliminated parts will be put back into the program one-by-one until the problem returns.
Sincerely,
Discovery
Look forward to hearing what you come up with.
Next, the removed code will be put back into the program chunk by chunk and tested chunk by chunk.
This may take a while.
Sincerely,
Discovery
Here are my findings during exhaustive testing of the 40 pin propeller on the PC board and the operational code.
The code is written so that a while loop is executed immediately so that each axis can be slewed to a (0, 0, 0,) starting position. When the slewing is completed the START CUTTING button is depressed and the program exits the while loop and begins running the main code.
The slewing while loop is in the main program COG.
Movement in the x and y axes is performed from the main program COG.
Servoing the z axis motor is performed in the free running Z axis Servo COG. The actual code that performs the generation and phasing of the four waveforms that turn the motor is called from a subroutine.
So, when the z axis needs slewing the subroutine is called to perform the UP and Down movements. When the z axis needs servoing during cutting, the z axis COG calls the same routine for turning the z axis motor.
Here is the problem. If the z axis is not slewed then the START CUTTING button is depressed. All axes operate perfectly and the z axis tracks the simulated cutter hight voltage perfectly. However, if the z axis is slewed to a starting position then the START CUTTING button is depressed only one, two or sometimes three waveforms are generated for the z axis motor. This test was repeated numerous times with the same results. Why should this be so? It appears to me that when the z axis motor subroutine is first accessed from the main program slew loop, the motor control output pins are allocated to the main program COG and are fixed in position. When the z axis motor subroutine is first accessed from the z axis servo COG, a different allocation is established and fixed in position. And the pins don't match.
If I remove the z axis slewing call from the main program, the machine cuts perfectly but I cannot slew the cutting head to accommodate different thicknesses of metal in the cutter. This is unacceptable.
Any suggestions?
Discovery
You have found your bug!
What is happening is as suspected by some. The main code is setting the z axis pins up when you call the z routine from the main code. Subsequently you start another cog to control the z axis and it sets the same output pins. Now what happens is that the same pins from the main code and the z cog will be "ORed" together. Any pins left at a "1" in the main program will be shut out by the OR from moving in the z cog.
What you need to do is start the z cog and then if you need to slew the z axis before start cutting, you need to pass a parameter(s) to the z cog for it to do the slewing.
Quite possibly the x & Y axis code should be in another 1 or two cogs too. This would likely simplify your code.
BTW It would have been far easier to post a cut down version of your code here and described it's operation as "pseudo" device such as a 3D printer. I understand your commercial dilemma, but you are asking for free help when someone is paying for the code to be done. When people help for free, they expect to see published code and/or circuits in return. I am amazed at the help you have obtained here under the circumstances. This reflects the enthusiasm of the prop fans here.
Put one and only one COG in charge of some particular I/O. In your case the Z axis seems to be a good example. That one thread in one COG should be in charge of any initialization, setting DIR for example, reading it's input pins and driving it's output pins.
If the main program wants to command those same I/Os, well basically it should not. It should have already started the COG that manages that subsystem and then send commands, through HUB memory, too tell the subsystem what to do.
Seems what we have here is a common or garden race condition between multiple processes.
There are few things in the world I like less than a call at 2 AM telling me that some customer somewhere has a problem. So with thousands of instances of my code operating in commercial vehicles around the country and medical offices around the world, I am absolutely neurotic about keeping things simple and straightforward.
In a canned application like yours, if there isn't a compelling need to stop and restart cogs, I wouldn't dream of doing so. Others may do differently, but my attitude is "why invite trouble?"
Unless you have some compelling need to do otherwise start all your COGS running whatever services they should provide at start up time.
Then start the main program which will then make use of those services.
Basically a static COG configuration.
By the way, why do you treat the Z axis differently than X and Y? Why does it get it's own COG when the others do not?
What would be wrong with a symmetric system with X, Y and Z COGS?
It comes from the unique design of the cutting system.
The z axis function is completely different from the x and y functions and operates asynchronously from them. It is the function of the design.
The x and y movements are synchronous and the z is not.
For now, the plasma cutter machine will operate in two steps. The first step is to turn on the machine and perform a z axis position movement to place the cutting tip 1.5 mm from the metal work piece. The second step is to turn the machine off then turn it back on to perform any x and y axes slewing followed by a cutting operation.
This will be the mode of operation until I can find an upgrade to eliminate the two stage process. More laboratory work.
I would like to thank everyone who made contributions to identifying and solving this problem.
Sincerely,
Discovery
Happy New Year!
As an after thought...it would not be difficult at all to leave the z axis motor phases in an all 1s state or an all 0s state after performing the slewing so that when the z axis servo COG wants to use the phase pins they will be ORed or ANDed...whatever so that all four phases can be generated in the servo COG.
I will try that tomorrow on the Propeller Activity Board.
Have a Happy New Year!
Sincerely,
Discovery
Give control to the z axis servo COG. Give it a command to do the Z-axis slewing at start up.
Then there is no confusion over who owns/controls what.
Discovery
Now that there is more to go with, I would guess that the cutter is fed a continuous stream of coordinates from the computer as the job progresses, with the assumption that the workpiece is a flat uniform surface. Since the x and y function seems to be working as it should, I would leave them alone for now; rather make the two step startup process into a single function. Use a separate cog to run the Z axis with a zero command or signal pin and a run command or pin. At initialization of the job, drive Z to max upward distance, slew to x=0, y=0 then on halt, have Z axis drive down slow until a micro-switch (or light barrier) trips the 1.5mm height limit and use that position voltage as the zero point and turn the Z axis loose in a closed loop servo fashion to maintain Z height across the workpiece (maybe in a future version, enable height tracking from the surface). Once the servo is locked on, signal the main cog to enable / signal the computer to start the job running. At end, have main signal Z to go to max height and move cutter out of way to a park position.
But that is the nice thing about the prop, all the separate cogs. which can all operate independently of each other. Well except the ability to stomp on each others toes, er I/O functions. Can always refine incrementally after the design proves out.
Everything works as originally designed. No double pass operation.
The machine was delivered to the client and put into operation.
Q. E. D. Done
Discovery
Perhaps it's time to mark this thread as solved.
Any possibility of seeing a picture or video of this beast?
Picture or video ops...I will check with the client next week.
Sincerely,
Discovery
To do the same next time, just go back to the first post and edit it in advanced mode and use the pull downmenu to select "solved"
The advantages of the prop is that you can use separate cogs to perform the tricky time critical functions, and then the typical main controlling cog can serve up the tasks to these cogs while not being time critical.
In your case here, the x and y axis cog could be one or two cogs. One cog would keep sync easier, but two cogs could maintain sync quite simply once you understand the prop better. The main cog could pass themaths to another cog(s) for calculating the next xy move while the xy cog(s) perform the current move. This is how to use the parallel cogs for best efficiency while kepping the software simple.
I learned to program C while developing the CNC Plasma Cutting Machine and found C to be a very nasty language to learn. I suspect that doing the timing you suggest will require learning SPIN...which doesn't look fun at all.
I could be wrong though.
Discovery
Spin is easy, pull down the softcopy of the propeller education book. You'll probably blow through it in no time. Then look into using that with PASM for when you really need that level of speed or detail.
How many languages do you know?
Spin is simply different from C although the operators are more complex ... and have different meanings. Spin indenting is easier than Python and good for people who don't like details. Spin syntax is heavily influenced by object Pascal Delphi stuff which is the favorite Parallax PC application language. PASM is a lot like ARM assembly (with limits), and easy to goof if you don't know what # does.
My own opinion is that SPIN/PASM (and Parallax by extension) unnecessarily redefine things from naivette, convenience, because they think something is silly, or just for cultish charm.
Added: Overall though Parallax tries very hard to enable learning by focusing on things they consider important. In this task they have generally done a great job.
I think C is generally faster than Spin.
For high speed stuff, nothing beats PASM.
I'm curious because thousands of people are learning C++ by means of the Arduino and seem to get along just fine with it. I'd like to think the C programming environment for the Propeller is at least as easy as the Arduinos. If it is not something is wrong.
I do it admit that C programming can get rather narly but for most MCU tasks it's can be very straight forward. The Arduino folks carefully don't talk about the complexities of C++ in their tutorial and reference materials, and their IDE does a good job of hiding it. In fact they never call the Arduino programming language C++. Presumably so as not to scare people away! As far as I know C executes faster than Spin. At least I don't expect Spin to be any better at this.
Again, perhaps you could say why Spin does not look fun?
Spin is a very simple and elegant language for most tasks on the Prop. It's string handling is a bit clumsy but still. The object system is nice. Easily launching code in other processors is nice.
By way of context it would be interesting to know what are the "nice" languages that you are judging C and Spin by.