Do I want to C?
Erlend
Posts: 612
It was love at first glance when I met Spin a few years ago. By now I have learnt to know her fairly well, but for sure I do not know all her secrets yet. We go along well. There are many other - more or less strange - inhabitants in Propeller town, running back and Forth, doing things real quick, and that is fine, it makes life interesting, but I am not likely to leave Spin for any of them. Unless-... Lately the one they call C have gained both popularity and power, and I fear that one day C will chase Spin out of town.
Am I only being overly nervous? I remember how in earlier days how the C Clan gained almost world dominance. Will it happen in Propeller? Must I again read K&R?
Erlend
Am I only being overly nervous? I remember how in earlier days how the C Clan gained almost world dominance. Will it happen in Propeller? Must I again read K&R?
Erlend
Comments
Stay with Spin in your case. C follows Spin at Parallax in many ways. Almost all of our commercial customers are using Spin/ASM.
You'll get more from the Propeller with Spin and ASM, first. C proved necessary for Parallax business in Education, which pays the way for so many other efforts in our company. I don't know why you'd need to fear that C would kick Spin out of town. Do what you like and do it well. Chip's heart lies with Spin and ASM, so that'll ensure that our first demos, programming tools and examples will use Spin 2. However, please count on the C compiler team working concurrently to deliver the same.
Ken Gracey
I agree with Ken though, that if you've already learned Spin, it's perfectly fine to stay with Spin.
C is more standard and has more options, but it's also a hair more complicated.
The Spin language was specifically designed for the Propeller.
Also, the ROM contains the Spin interpreter. So, C programs will generally be larger than Spin programs.
But, if you need to run super big programs, have direct code compatibility with other micro controllers, or need faster speed. It's worth trying out C.
C will probably be the language of choice for Prop2 also.
BTW: If you do want to try C or C++, the Spin2Cpp tool is a really amazing way to convert your existing Spin code to C or C++
That's a great idea, as you can learn much faster if you already KNOW what the code does.
Another option for the toolbox to consider is Spin for main code, and if PASM is too big a jump, you can do Spin2Cpp -> then C into COG, for small blocks, that you need more PASM-like speed on.
Spin is in ROM, so is rather literally cast in stone.
thanks
Sounds like I can safely stay faithful to Spin, but I like the idea to put some C into a COG for when I need speed, but don't want to assembly. I could code the object in Spin, then Spin2Cpp it. It wouldn't be much of a craftmanship, but would save me a lot of time.
Erlend
My first language was BBC Basic (for the Acorn micro) where GOTOs were banished and Procedures encouraged. So, I am not a BASIC-hating fundamentalist at all. Do you mind sharing the quadenc code you mention with me? - I'm curious.
Erlend
Those that use spin should use spin until it doesn't do whats required.
Those that have no prior preference and want to work quickly and have fun should talk to me.
There are significant number of people with this opinion, but be aware that any bad experiences may have been from the way the project was handled, rather than the tool itself.
Not reading too far into the statement, but I'm curious what you mean, Doug. The compiler and tools were developed very much in the open, in the community, fairly loosely managed by Parallax. If it's worth clarifying please do so since we're always trying to do the best we can given the allotted resources available to the project.
Thanks,
Ken Gracey
? I read #11 as talking about the 'back in time' experience, not any Prop C experience.
Prop C seems to be percolating nicely.
GCC also gives users access to a Macro Assembler, which matters to some.
Sorry, I was not clear. I was not refering to the project developing Prop C.
I was refering to various projects at various organizations, where C selected as the programming tool, due to the commodity nature of C programmers. More often than not, "fast paced, dynamic environoment" meant little chance of success due to poor requirements, insufficent resources for testing, unrealistic goals and deadlines, moving targets; poor management in general. Many bad experiences using C on development projects. Because of this, I know to avoid non-regulated industries.
This is not an issue with any particular tool, its an issue of management. Software deveopment using C and non regulated industry are indicators of these risks.
Parallax is an example of the "good way" to do it. But Parallax is still pretty rare.
Seems everybody seems to have a horror story about large-scale C programming projects, accentuated by the various points Doug brought up (insufficient testing resources, unrealistic goals, poorly defined needs, etc.). Having worked in small environments for my whole existence I lack the experience of large-scale challenges. And I think I might be thankful for not having this kind of experience.
I don't want to sidetrack the discussion too much but I wasn't able to find a working quadrature encoder object in the OBEX.
Wildatheart recently found a bug in Kye's QE object.
The QE object in the Propeller Tool Library seems to work correctly. I didn't see a demo for the object so I posted a couple in post #7 of my quadrature encoder thread. While the my main effort is to write an object to both read encoders and provide PWM to motors, is did post some encoder only code to post #2 of the thread. Kye also posted some additional encoder/PWM code to the thread.
I'm still on the fence about C. I like Spin but I have several large projects which require me to load only a portion of the program in the the Propeller at a time. Most of this segmented program is stored on a SD card. I think C would probably make these type of programs easier to manage.
That's the one I tried to find in the OBEX. I knew I had used it before. It took me a while to realize it was in the Propeller Tool Library. I'm pretty sure it has been there a long time.
Erlend
Here's a link to an earlier thread. It's a different approach and only good for one encoder (as-is). It doesn't include writing the updated count to the hub but that would happen just prior to GOTOing (JMPing) to a different label after a change of state of either ChA or ChB.
The generated PASM code uses very few instructions and I bet it could be further optimized.
Erlend
BASIC looks like this:
Other people peddle languages that look like this:
Public Class StarsProgram Public Shared Sub Main() Dim UserName, Answer, stars As String, NumStars As Integer Console.Write("What is your name: ") UserName = Console.ReadLine() Console.WriteLine("Hello {0}", UserName) Do Console.Write("How many stars do you want: ") NumStars = CInt(Console.ReadLine()) stars = New String("*", NumStars) Console.WriteLine(stars) Do Console.Write("Do you want more stars? ") Answer = Console.ReadLine() Loop Until Answer <> "" Answer = Answer.Substring(0, 1) Loop While Answer.ToUpper() = "Y" Console.WriteLine("Goodbye {0}", UserName) End Sub End ClassHow do they have the nerve to use the same name for these things?
BASICS supporters will counter such arguments by pointing out that BASIC does not look like that any more. They point to VB or whatever and say "See it's just like a modern language".
Sometimes I think it's just awful both ways round. The original BASIC was too rude and crude. The modern BASICs because, well because they have no reason to exist, we have many other standardized and cross-platform languages.
On the other hand if you want a language that is small enough to work on your device and is a soft start for beginners then BASIC is fine.
It's been a while since I checked the PropBasic documentation but I do believe that you can use an inline ASM directive which would allow one to substitute JMP for GOTO. Would that make things more palatable? After all, there's no getting away from JMP in ASM.
JMPRET in PASM is even more "interesting" :-)
A screw driver can be used to turn screws or stir paint. If you don't have the habit of putting down the screw driver and picking up the paint stirrer, you may end up with a mess. GOTO ends up in a mess often enough to remove it from the tool box.
Erlend
JMPRET reminds me a bit of the IBM System 360's BALR instruction. Except that BALR used a register to hold the return address and the Propeller uses storage in the instruction sequence. But other than that it's a way of doing a JSR when your processor doesn't have a stack.