Here are some demos for the LED Matrix board, written in Spin, BASIC, and C. I think I may have posted earlier versions of them a long time ago, but I can't remember.
Here are some demos for the LED Matrix board, written in Spin, BASIC, and C. I think I may have posted earlier versions of them a long time ago, but I can't remember.
Sorry for being critical but I see that the C code just calls the Spin object. Are we going to start seeing all low-level driver code written in Spin and called from C? I guess I'd prefer to see the driver code in C with a Spin interface if required.
Here are some demos for the LED Matrix board, written in Spin, BASIC, and C. I think I may have posted earlier versions of them a long time ago, but I can't remember.
Sorry for being critical but I see that the C code just calls the Spin object. Are we going to start seeing all low-level driver code written in Spin and called from C? I guess I'd prefer to see the driver code in C with a Spin interface if required.
Sure, driver code can be written in C, or it can be written in Spin. The point is not to write it twice -- I already had some Spin code for the matrix, so I just used it in C rather than having to re-write it. If you really want a C only version you can convert it with spin2cpp . But you can also do it the other way around, Spin code can call C (at least within the fastspin framework).
So if you're writing a driver from scratch pick whatever language you prefer or already have code for. Some of the (fastspin) Spin library routines are written in C, and vice-versa.
Here are some demos for the LED Matrix board, written in Spin, BASIC, and C. I think I may have posted earlier versions of them a long time ago, but I can't remember.
Sorry for being critical but I see that the C code just calls the Spin object. Are we going to start seeing all low-level driver code written in Spin and called from C? I guess I'd prefer to see the driver code in C with a Spin interface if required.
Sure, driver code can be written in C, or it can be written in Spin. The point is not to write it twice -- I already had some Spin code for the matrix, so I just used it in C rather than having to re-write it. If you really want a C only version you can convert it with spin2cpp . But you can also do it the other way around, Spin code can call C (at least within the fastspin framework).
So if you're writing a driver from scratch pick whatever language you prefer or already have code for. Some of the (fastspin) Spin library routines are written in C, and vice-versa.
Sure, I know I can write in whatever language I want. I guess I'm just hoping that the vast majority of user written drivers won't be only in Spin with a C interface. I think one of the main ways new people learn a new processor is by looking at example code and if most of the example code is in a language they don't understand it may be a barrier. It's not so much that *I* can't read Spin. I can. I just wonder if it's a good idea for potential customers looking through the P2 version of OBEX.
Eric: I notice that your C wrapper for your led_matrix_demo uses the Spin object as if it were a C++ class instance. Do you support class definitions in your C compiler?
Sure, I know I can write in whatever language I want. I guess I'm just hoping that the vast majority of user written drivers won't be only in Spin with a C interface. I think one of the main ways new people learn a new processor is by looking at example code and if most of the example code is in a language they don't understand it may be a barrier. It's not so much that *I* can't read Spin. I can. I just wonder if it's a good idea for potential customers looking through the P2 version of OBEX.
Ah, I see. That's a good point, availability of good C examples is important, and I agree with you that it would be nice to see some C drivers.
Unfortunately unless Parallax gets behind something it's hard to see how anything other than Spin will gain traction. At the moment Chip's Spin interpreter is the only "official" development tool announced (although it isn't available yet). I hope Chip will provide some way to call C code from his interpreter, that would make it feasible to write portable drivers in C. Otherwise Spin drivers will be the de facto standard, since they'll be the most portable (we can call Spin from C, but not vice-versa).
Eric: I notice that your C wrapper for your led_matrix_demo uses the Spin object as if it were a C++ class instance. Do you support class definitions in your C compiler?
Very limited class declarations, with the functions "inline" in the struct, like:
#include <stdio.h>
struct point {
int x, y;
void offset(int a, int b) {
x += a; y += b;
}
int getx() { return x; }
int gety() { return y; }
} p;
int main() {
p.x = 1;
p.y = 2;
p.offset(10, 100);
printf("p=(%d, %d)\n", p.getx(), p.gety());
}
Comments
http://forums.parallax.com/discussion/169706/accessory-boards/p1
dgately
Sure, driver code can be written in C, or it can be written in Spin. The point is not to write it twice -- I already had some Spin code for the matrix, so I just used it in C rather than having to re-write it. If you really want a C only version you can convert it with spin2cpp
So if you're writing a driver from scratch pick whatever language you prefer or already have code for. Some of the (fastspin) Spin library routines are written in C, and vice-versa.
EDIT: Looking at it now ... it's quite handy for learning the interface between C and spin.
Ah, I see. That's a good point, availability of good C examples is important, and I agree with you that it would be nice to see some C drivers.
Unfortunately unless Parallax gets behind something it's hard to see how anything other than Spin will gain traction. At the moment Chip's Spin interpreter is the only "official" development tool announced (although it isn't available yet). I hope Chip will provide some way to call C code from his interpreter, that would make it feasible to write portable drivers in C. Otherwise Spin drivers will be the de facto standard, since they'll be the most portable (we can call Spin from C, but not vice-versa).
Very limited class declarations, with the functions "inline" in the struct, like: