cog access to mutually exclusive resources

Woodwise

It seems that there are several threads here addressing cog access to mutually exclusive resources and the overhead of it. I am new to the PP1, reading up on SPIN and C for the PP, and wondered about this myself. I understand that cogs can run internally at full speed, meaning that a cog clock cycle is the same as a system clock cycle, but the 16-cycle limit for access to exclusive resources seems too small for many apps. It might be useful to have that user-programmable up to, say, 256, or better yet, 64K cycles. It would be nice to have hub task switching controllable, so that I could have, say, cog switches every 65 us, rather than every 16 System Clock cycles, which (I gather) is 16 cycles @ 100 MHz w a 6.25 MHz crystal = 16 ns. In fact, for many apps that I can imagine (I am experienced with embedded controls), I'd be happy with, say, 100 us context-switching times, and this is ~6000 times longer than currently available, // if I understand this correctly //. With that sort of control of the IO and exclusive resources, I might not have to resort to clever coordination of several cogs.

Is this currently available, or is the 16-cycle context switch hard wired?

JonnyMac

The Propeller 1 is what it is -- no changes. You might want to have a look at the Propeller 2 thread (I've only spent a little time there) as it seems like the P2 is designed for better cog/hub access.

Heater.

There is no "context switch".

There are 8 COGs. Basically processors all running completely independently.

If they never access HUB memory they run at full speed, 4 clocks per instruction.

If a COG reads or writes to main, shared, memory then it has to wait for it's allotted time slot to do so. The HUB mechanism is allocating those time slots on a "round robin" basis. The Read/Write instruction stalls until that time. There is no context switch. When the time slot arrives the access is made and the COG continues on it's way.

In this way all COGs can get access to the shared memory without tripping over each other, the HUB is coordinating things.

There is no way to change the round robin cycle of the HUB.

Is there any reason this would cause problems for you? What is this "clever coordination of several cogs" you think you might need?

The code running in different COGs usually coordinates by simple flags in HUB memory locations. Hardly anything difficult or unusual there.

When sharing large data structures between COGs one might want to use the Propeller locks, this is rarely necessary.

Or one can exchange data via a FIFO, without locks. Have a look at the FullDuplexSerial object to see how that is done.