Objects in SPIN and ASM - Can use in C program?
John Kauffman
Posts: 653
C is standard for teaching. But OBEX is almost all non-C. I'm probably using wrong search terms, but can't find answers to below.
Is there a way to include a SPIN object in a C program?
Is there a way to include an ASM object in a C program?
Source of examples?
I'll look at David Betz spin wrapper this afternoon:
http://forums.parallax.com/showthread.php/153919-SpinWrap-a-tool-for-allowing-C-or-C-to-use-Spin-Objects?p=1243144&viewfull=1#post1243144
Thanks.
Is there a way to include a SPIN object in a C program?
Is there a way to include an ASM object in a C program?
Source of examples?
I'll look at David Betz spin wrapper this afternoon:
http://forums.parallax.com/showthread.php/153919-SpinWrap-a-tool-for-allowing-C-or-C-to-use-Spin-Objects?p=1243144&viewfull=1#post1243144
Thanks.
Comments
There must be other people with the same question: How to use objects written in Spin or ASM when using C.
Thanks.
Several Propeller-C libraries use the PASM from Spin files.
libfdserial uses pst.spin
libvgatext uses vga.spin
Generally however, C programs do not use Spin other than extracting PASM.
As you have found already, David's spinwrap program will allow using Spin as-is without converting files, etc....
We are not ready to incorporate that program into SimpleIDE just yet. Higher priorities exist.
The problem comes up when students see an interesting product in the Parallax catalog and want to buy it. But there is no C code example on the catalog page and only source of code is in OBEX is Spin/ASM. That cancels the sale.
They could write a C program from scratch but after just a 12 hour intro course for hobbyists, coding most devices is above their ability.
An alternate to the mixed language solution would be to include a C example with each product. For a person (intern?) comfortable with SPIN and C I think it would be quick to knock these out for the 30 or so best-selling devices in the catalog. It doesn't mean a full entry in the Learn system, just a sample like is already offered in BS2 or Spin.
Thanks.
It is of course up to Parallax.
It's my (not uncontested) opinion that Parallax erred in going the GCC route instead of concentrating on a simpler compiler that produes Spin bytecodes and links to Spin/PASM objects. Based upon my experience teaching a H.S. robotics course using C with the ActivityBot, I've come to the conclusion that a C compiler that produces fast, optimized code is unnecessary in this environment. The students are not going to be writing low-level drivers or wrestling with function pointers. It's quite enough of a challenge for them to write a while loop with a bunch of conditionals, inside which they make calls to library functions. And if those library functions already exist in Spin, they should be usable in C without having to rewrite them in C.
Fortunately, I think there may a solution coming in through the back door: Dave Hein's CSPIN C-to-Spin translator. Although it's a standalone command-line program now, I believe it could ultimately be integrated transparently into a development environment so that sudents would never have to know that their C programs were converted to Spin first before compiling. This would permit the current Spin library and OBEX objects to be used freely with C programs without having to recast them in C.
-Phil
As far as whether GCC was the right way to go -- I believe it was. GCC provides many important features that the proposed PMC compiler would not have had. In theory, the GCC code generator could be modified to produce Spin bytecodes. Even though the Spin VM is a stack machine there is at least one implementation of GCC for a stack-base machine (i.e., Zog) so it is proven that it can be done. One issue with the Spin VM is supporting global variables, but this could be done under the covers by using pointers that are initialized at link time.
(PM on your teaching to HS)
My comp sci knowledge is not deep enough to understand all you are saying, particularly if a path was a mistake. From applied experience, I'm getting good results from the Learn C tutorials on line and will welcome a version similar to a SIC text book. C seems to be accepted well by my students as many have done at least a little in C or Java.
The problem I have is very practical and at a business level: Students see a Parallax product that is cool and are ready to press the buy button but then realize they can't use it because there is no C example and the OBEX only has a SPIN object. Then I get an earful of junk that a similar-function board is available elsewhere for Arduino.
Easiest solution (I think) is to write an example in C before listing the product in the catalog. I think that would just require a policy change along the lines of maybe we have to wait another day to list, but we won't offer a device until there are examples in all of SPIN, C and PBASIC. But I'm in no position to understand all the factors that go into a business decision. I don't have the skills to write code in best practices, but am glad to test if someone does.
Longer term, it would be great to have a directive in C that instructs "Insert this SPIN object at top of this C program," similar to include an .h library. Then whatever functions are exposed in the SPIN/ASM are available in C.
I admit I have not tried Dave's tool; I'm a little worried it will be a half day to understand and test (no offense, Dave. I guess I am a slow learned). And I hope that C examples will emerge soon for the devices of my interest.
Parallax made a mistake going with GCC? You could argue that Parallax made a mistake putting the Spin VM in ROM in the first place thus locking everything into code that is now more than 8 years old with no opportunity to ever update it.
-Phil
-Phil
The more I think about it the more useful would be the option to have example code in C for each product rather then a generic wrapper for SPIN/ASM objects. With example programs students would see more code and it would be well-written C. From that I can point to how various problems were solved. A wrapper would just point to a black box (from their perspective) and not be useful for teaching.
But, anyway, we're getting off-track a bit from John's concerns. What we've got are two disjoint compilers, for Spin and GCC. Since Parallax made the decision to go with GCC, I guess the onus is on them to live with the consequences and to produce libraries and example programs written in GCC.
-Phil
-Phil
-Phil
I can understand the frustration of not having C code for this device or that device, but how do you think non C users feel?
I don't know what Parallax devices students are looking at but most of them are very easy to use.
I guess if Ken listed the 10 most popular devices then instructions on how to use them in C or actual C code for be written.
Also, couldn't Arduino code be ported to the Propeller?
It's really the latter, Phil, as you already know. There is no attempt in any of our material to try to teach students how to create low-level libraries along the ins and outs of C. The program is a high-level implementation of C and students can combine our different libraries to achieve their project. There is, however, a fairly light-duty explanation and use of multicore inherit in the design of the program, too. Students can learn some C just by taking a look at our syntax. In combination with any book about C they quickly become more capable.
There's no need to make this something deeper than it is, at this time. And it's pretty common to spend days and months with students and feel that you've not effectively imparted everything that you'd like them to know. Take your desired rate of teaching and divide it by two or more and you'll succeed. This is their first exposure - some students can carry their understanding and interest deeper but you've got to have a reasonable expectation about how much they will learn, especially in a group setting.
One thing that guys like you and I will have trouble grasping is how high-level everything has become. So much complexity is handled for us in libraries or objects, and to some extent we have to be comfortable not explaining all of this. You'll get glazed eyes, loss of interest and diversion to YouTube if you press these real programming concepts too early. Frustrating, I realize.
I understand I took a sideways trip in this reply to you.
Ken Gracey
In a way I feel like a total fraud. The only mandate I was given for the class was that the language used had to be C or C++; the rest of the curriculum was up to me. But given the light C exposure required to accomplish the robotics aspect, the same could have been accomplished in almost any language, given libraries similar to the extensive ones provided by the Learn curriculum. I guess my point is that even though the schools demand C, the students aren't really learning C to any skills-marketable extent, so it could just as well have been Spin. That's not to say that my class was a dud. Far from it. The students learned a lot about robotics and seemed to be totally engaged and having fun doing it. But lacking the C mandate, I think I could have accomplished even more with the class by using Spin instead.
But it is what it is. Convincing school admins that programming skills can be communicated regardless of the language chosen is probably an impossible uphill battle, so I can't really fault Parallax for choosing to cater to what the schools think they want rather than trying to sell them on something better.
-Phil
Now, I'd love to mirror the ActivityBot tutorials in Spin/ASM. The benefits of showing off the architecture and having better low-level control are big. We just need some capable people to write the code
Since we've arrived at what we agree on, maybe we can stop the banter about whether or not we should've made a translator, a compiler, or whatever. We aren't going back to repeat the process and in fact I expect to leverage all of our efforts to date for the P2, so there's not a lot of sense in digging up the bones. In fact, it might even discourage potential Parallax educators who are about to use our C tutorials but get confused and then discouraged by reading the forum posts.
Ken Gracey
I didn't really mean for my posts to come across as backward-looking or second-guessing. The OP raised a valid point, and I was just trying to sort out the decisions that led to where we are today and to explore options for how things could get better going forward. You're right: it's all about leveraging what you already have, i.e. getting the most bang for the bucks you've already spent. My objective, looking forward, was to find a way to leverage the current OBEX to make it usable from C, as an alternative to rewriting everything in C. With the help of Dave, David, John, and Steve, I think we had a productive discussion -- including both "can we?" and "should we?" -- with the conclusion that CSPIN is not quite ready for the task I had in mind, and maybe we shouldn't anyway if we want students to see library code written in C. So I'll leave it at that.
-Phil
It doesn't. It's just a function of how we've implemented C in our libraries. In order to make C simple to use, we've taken out some clock configuration, visibility of when we launch cores to run libraries, etc. I think it's fine for the intended audience because they get quick results without confusion. For our educational customers I think the approach we've used is correct.
When I took a college class on automation we used C on a 6811 and while some of the functions were in a library others required accessing the hardware directly.
In Andy's Simple Protocols, he briefly mentions using the AND and OR operators to set and reset hardware registers. Bit manipulation is a very useful skill especially when dealing with hardware.
I don't think it would be too difficult for students to change the bits in dira and outa, or use a mask on the ina register to see if a switch was pressed.
Counters are another thing that most microcontrollers have and NCO mode will generate pulses for LEDs, Servos, or music.
I don't think it would be too difficult for students to configure a counter, set it's frequency, and then start it running by accessing the Cog counter registers directly.
These hardware basics will prepare students for whatever language or hardware they eventually use plus teach the skill of reading datasheets and looking in reference manuals.
Learning by doing.
John's student might want to look at the same lesson since it explains Serial I/O and SPI. Andy might want to expand on the lesson to include I2C. That should cover most devices.
I went through the "Propeller C Library Studies" tutorial earlier today. It is quite good except for a type-o here and there.
I've provided a Keyboard library, but it hasn't made it through the scrubber yet. I'm sure Andy is adding devices as fast as he can, but he's also supporting sales channels. We are all in a crunch to have IDE software updates ready for Educators courses starting this month.
So much to do. So little time.