using F32 in multiple objects, then multiple interpreter cogs

PaulRowntree

Hi! It has been several years since I last worked with the prop, but some home and work projects have come up that have brought me back. But oh so rusty!
I am working on an I2C interfaced IMU board from Pololu, using Mike Green's I2C drivers. Everything is working well. Now I want to add the trig bits, using floating point.
First off, is F32 v1.6 the current code that people are using?
Second, if I want to use floating point in the top level spin code and in the IMU object that I have written (both running on the same SPIN interpreter cog), do I just declare that they both use F32, but only start it from the top level code?
Almost Lastly, if/when I want the IMU code to run autonomously in the background, do I need 2 F32 cogs, one for each interpreter?
Lastly, can I run a background cog code that interfaces the I2C, but in the same IMU object have spin code that gets called from the top level SPIN, and therefore only uses a single instance of F32?

It's taking some doing to clear the cobwebs from under these grey hairs ... it is still a pretty cool chip.
Cheers, and thanks in advance for your help !
pr

Lawson

1) yes I think that's the most up to date.

2) I think you'll need to pass some address between the two F32 objects to get both hooked to the same F32 assembly cog. (i.e. you'd start one, and make an init() function for the other)

3) Yes, you'll need two F32 cogs, or a lock to arbitrate sharing. Another approach would be to modify the F32 command interpreter so it can accept commands from two sources as I'm pretty sure the Spin wrapper is the biggest bottle-neck for F32 right now.

4) if the top-level spin code doesn't care about speed, use FME.spin for it's floating point. Has all the functions of F32, but all in Spin. (link in my sig)

JasonDorie

If you use the "stream processor", F32 will do a LOT more math than you can call from spin, because you lose about 1500 cycles of overhead per call (or more).

PaulRowntree

Thanks Lawson! I thought that there was a direct way for a single SPIN interpreter to use a single floating point cog across all of the objects that it was running, but it looks like that isn't the case. There are two calls that return pointers to the dispatch table & command flag, so I may play with this if I run short of cogs.

JasonDorie, I don't know what the 'stream processor' is; no ref to it in F32_1_6, nothing that I can see in Obex. it sounds useful ... can you give any details on what it is and how to find it?

Thanks!

JasonDorie

I didn't realize you were using F32 - there's one in Float32, and it's possible to add one to F32. The end result is that you pass a pointer to an array of (operation, arg1, arg2, result) where the arg and result values are hub addresses. The Float32 or F32 object processes all the commands in series until the whole stream is done, so there's no Spin overhead per operation.

The F32 object in the Elev8-FC github implements a stream processor, but you have to lose a couple commands to create space for it. I believe the Float32 object has it built in already.

PaulRowntree

Got it . Thanks JasonDorie!