Do you dynamically start and stop cogs?

Cluso99

Do you dynamically start and stop cogs? If so, would you be so kind to give some details please.

I dynamically start and stop cogs in my PropOS. For example each OS command (such as DIR, COPY, etc) all load/start a new cog which starts _cmd.cmd and stops itself.
The spin/pasm compiler (Originally Sphinx by Michael Park) also starts and stops cogs. If you run a program either under the OS it gets started and may in turn start other cogs. If you "run" a binary, it loads/runs the binary after stopping all cogs, and that binary may start other cogs.

I don't recall any other programs of mine that dynamically start and stop cogs.

Heater.

Yes.

My FFT can can use 1, 2, 4 cogs to spread the load for a bit of a performance boost. It's written in C and uses OpenMP to to the parallelization. I'm not totally sure but as a far as I know does not pre-allocate the max required COGs to do this. I see no reason why it should. Code is here: https://github.com/ZiCog/fftbench

I posted a Spin version of the JKISS32 pseudo random number generator. Which produces much better and vastly longer period sequences of random numbers than most languages implement. When you want something more random but don't want to waste a COG on Chips Real Random object it has a seed function that fires up a COG to get a random number from Real Random to use as a seed. That COG is then released.

Jonny Mac used that code for some stage effects so Limp Bizkit may well have used dynamic COGs on stage!

Bill Henning

I dynamically start and stop cogs in the latest RoboPi (Prop1) firmware, and need that functionality for a future Prop2 version.

Cluso99

FYI, I am just after instances of how often dynamic cogs are started and stopped.

i have no intention in wanting it removed - it's a fantastic feature, perhaps way under used.

Cluso99

Thanks Bill. I thought you and Drac would be doing it.

heater,
I am particularly interested where multiple cogs are started and stopped. Programs that start objects that then start more cogs are not what I am after as they don't stop cogs for restarting.
Yes, possibly Jon might start and stop cogs, perhaps running on time sequences.

Electrodude

I have a game that I never finished that while inside the level editor runs the 4 cog VGA_1280x1024_Tile_Driver_With_Cursor.spin, and when actually playing runs the secondary game engine cog and a modified version of the 1 cog VGA.spin. I loaded most cog images off of an SD card into the space that originally held the SD card driver in order to save space, and had modified versions of each object that didn't come with cog images and instead had modified start methods that took an additional pointer to where they should find their cog image. I also had normal versions of each object that had a method to get a pointer to the cog image; these were used in the installer program that wrote all necessary files to the SD card.

It used cognew everywhere. I just checked, and the only coginit in the whole thing is inside Kye's SD card driver in the program loader.

Heater.

Clusso,

I am particularly interested where multiple cogs are started and stopped.

That is exactly the case with my examples.

The FFT will only fire up 3 new COGs to split the processing over 4 COGs when you call on it to do an FFT. When it's done those 3 COGs are stopped.

Similarly the JKISS32 only fires up a Real Random COG when you call the "init" or "seed" function (I forget what I called it now), which you can do at any time.

Which is interesting now that I think about it. If you were using both of those in a program you would have to be sure there there is enough free COGs to run them both at the same time. Or you would have to be sure you never run them at the same time if you are short of COGs to do so.

Cluso99

Thanks for the explanation heater. I didn't realise the FFT was doing a "dynamic" calculation. I understood the random number generator would run each time a number was required.

jmg

Heater. wrote: »

Which is interesting now that I think about it. If you were using both of those in a program you would have to be sure there there is enough free COGs to run them both at the same time. Or you would have to be sure you never run them at the same time if you are short of COGs to do so.

Yes, nicely put.
There is no 'completely free' COG allocate, you do have to make sure you never try to ask for 9 in P1, or 17 in P2.

Heater.

Yeah, the FFT will fire up COGs only at the time you want it to do work. Then release them.

The pseudo random number generator is actually only a method that when called runs in the calling COG. But it has this random seeding method that fires up a COG briefly to get a real random number.

rjo__

Not exactly on topic, but:

I have never stopped a cog... but that is only because all of my work has been experimental for prototyping.
I can't imagine writing a systems-type application for actual use that didn't dynamically allocate resources.

As the system gets smarter, resource allocation is going to be increasingly more important.

The robots we build next will have more sensors than are needed at any one moment.
It would be a waste of batteries not to shut them down until needed.

twm47099

Not sure if this is what you mean, but in Prop C I will start functions in new cogs that call functions in the simple ide library that in turn start new cogs. Once that function has done it's work, both cogs are stopped, and I start different functions (sensors or actuators) in cogs that start other cogs, etc.

Which functions run depends on what a sensor may detect/measure and what action needs to be taken. My functions and library functions may start and stop cogs multiple times depending on the situation, and I can't predict which ones will be open at the same time, or what cog they will start. I try to program so that worst case, no more than 8 cogs try to be running at the same time.

Tom

Cluso99

Yes Tom. Thanks..

Dave Hein

Yes, I dynamically start and stop cogs in spinix. Some spinix programs also start up additional cogs and stop them.

Cluso99

But Dave,
We keep getting reminded that the P1 & P2 are not for running an OS

potatohead

Actually, we get reminded we aren't gonna break some basic ideas to improve on how an OS might run.

...which means a Prop OS will look a bit different from the usual stuff out there.

dMajo

No, I only reload already started cogs with suitable code. Eg 4 channel dimmer each cog handles one channel that can dimmer from 24VDC to 240VAC nearly every light/motor/blind/curtain ... depending on selected function the suitable code is loaded/reloaded