Intergrating SPIN/PASM into a C program(number of cogs used)

DvIant-01

Ok, I'm new to SimpleIDE and to posting in forums. I usually just read them to see if anyone else is having the same issues. But I figured why not go ahead and give it a try.

After looking at a post from I believe is was mindrobots, I believe I understand how to use PASM code with a SimpleIDE C program. exp:

***IMPORTANT*** The filename you use is VERY IMPORTANT to linking the PASM and C together. In you .c wrapper file, you will create something looking like this:
Code:

extern unsigned int *binary_keyboard_dat_start;
the external label will always be binary_filename_dat_start where filename must match EXACTLY to the filename you used for filename.spin


I get that part.

With the examples that I have seen you have to use 'cognew' in C that calls your start function in SPIN which contains 'cognew' that points to your PASM code.

My question is: how many cogs does this utilize exactly? Do you have to sacrifice 2 cogs any time you want to call PASM code from your C code.?

Thanks in advance!

jac_goudsmit

You have complete control over how many cogs you want to use. Well, almost: sometimes you may need a driver that starts its own cog.

When you use cognew from C or C++, it works the same as when you call it from Spin (or PASM for that matter): it starts one cog. The cognew itself doesn't take up a cog.

If you use cognew to launch a cog that's written in a DAT section of a Spin program, that will use up one cog. You would only use two cogs if you would launch the Spin executor to run the Spin code AND that Spin code would launch an additional cog for the PASM code in the DAT section. It sounds like that's not what you're doing: you're just launching the PASM code so the Spin code won't run at all and the PASM code will take up one cog (not two). As long as the Spin code is not somehow essential to run the PASM code (or as long as you have C/C++ code that does what the Spin code would normaly do), that's fine.

By the way, keep in mind that unlike Spin, the C/C++ compiler doesn't obligate you to run PASM programs in separate cogs. If there's just some thing you want to do with Assembly, you can use inline assembly to do it in the same cog as where your C/C++ program runs. In my opinion, this is one of the most important features of PropGCC. But of course, if you're using existing code from a Spin module that's intended to run as a separate cog, you will have to modify that code (probably re-write it) to be useful as inline code. And some code simply can't be modified that way; for example a serial driver simply has to listen to incoming traffic all the time (even when your program has other things to do) so it's better to keep it running in a separate cog.

===Jac

DvIant-01

Thanks Jac!

I was under the assumption that when you use 'cognew(&binary_filename_dat_start ,0);' in C that it started code beginning at the start of the .spin file. i.e. the first SPIN method if it contains one.

I realize now that it actually starts the DAT section of the spin file. Hence the: 'dat_start' portion. (feeling some what dumb right now lol).

Thanks again for the help!

mindrobots

Hi Dvlant-01,

Welcome to the Forums (as a poster)!

Most of the SPIN/PASM examples that I recall coming across being ported to C kept the PASM code (maybe modified to use a C structure as a mailbox) and redid the SPIN wrappers in C code. From your C program, the new wrapper code would set up the mailbox and initialize any data the PASM needed and then do the cognew. This process was used to wrap a few OBEX PASM examples to show how to leverage the existing PASM objects in a C world. It's been a while since I've really done anything with PropGCC so I don't have any current examples to cite.

It sounds like you are on the right track now with Jac's help and your revelation about what you were seeing.