P2 - Sharing COG Resources
ctwardell
Posts: 1,716
In another thread rwgast_logicdesign mentioned "borrowing" counters from another cog:
http://forums.parallax.com/showthread.php/145032-Need-help-determining-just-how-much-mCU-power-I-need-for-4-Quad-Encoders?p=1154876&highlight=basically+borrow+cogs+counters#post1154876
Although this can't be done directly Duane Degn mentioned that you could potentially "share" the counter by having another cog poll a hub location and use that to update the counter.
On the P2 one could use multitasking to simplify adding this functionality to an existing object without manually "weaving it in" to the primary task on the cog.
I'm thinking we could formalize an approach where a cog would run a lightweight overlay reader / execution task that would allow making use of unused resources.
The general idea is that a cog wanting to use "inter-cog" resources would provide a setup overlay that would execute on the "host" cog to configure the counter or other resource to be borrowed.
After the setup overlay executes another "server" overlay would be loaded that takes care of polling the hub for values and updates the borrowed resource.
The advantage here is that configuration is handled by the borrower, not the host.
For something like rwgast_logicdesign's PWM usage, the motor drivers would likely update at some rate in the tens to hundreds of times a second so the "server" thread would be able to loaf along using just 1 of 16 time slots.
Some things to work out would be:
- How to signal the overlay loader / execution task that a new overlay is ready, possibly interrupting a running task.
- How the overlay loader / execution task signals that it is idle (for example the setup overlay is done).
This could of course expand to having a "registry" allowing discovery of available resources, but let's handle one task at a time.
I know Clusso is one of our overlay experts, any thoughts Clusso?
C.W.
http://forums.parallax.com/showthread.php/145032-Need-help-determining-just-how-much-mCU-power-I-need-for-4-Quad-Encoders?p=1154876&highlight=basically+borrow+cogs+counters#post1154876
Although this can't be done directly Duane Degn mentioned that you could potentially "share" the counter by having another cog poll a hub location and use that to update the counter.
On the P2 one could use multitasking to simplify adding this functionality to an existing object without manually "weaving it in" to the primary task on the cog.
I'm thinking we could formalize an approach where a cog would run a lightweight overlay reader / execution task that would allow making use of unused resources.
The general idea is that a cog wanting to use "inter-cog" resources would provide a setup overlay that would execute on the "host" cog to configure the counter or other resource to be borrowed.
After the setup overlay executes another "server" overlay would be loaded that takes care of polling the hub for values and updates the borrowed resource.
The advantage here is that configuration is handled by the borrower, not the host.
For something like rwgast_logicdesign's PWM usage, the motor drivers would likely update at some rate in the tens to hundreds of times a second so the "server" thread would be able to loaf along using just 1 of 16 time slots.
Some things to work out would be:
- How to signal the overlay loader / execution task that a new overlay is ready, possibly interrupting a running task.
- How the overlay loader / execution task signals that it is idle (for example the setup overlay is done).
This could of course expand to having a "registry" allowing discovery of available resources, but let's handle one task at a time.
I know Clusso is one of our overlay experts, any thoughts Clusso?
C.W.
Comments
In P2 You not need go trough HUB.
You can use Internal IO port to that
Sapieha,
You are correct that you could make use the internal port in some cases.
Cases like the mentioned PWM usage are such low speed updates that the hub isn't really a bottle neck.
For a case where high speed updates are needed and a single 32 bit value is sufficient for data transfer the internal port would be ideal.
I really wish we had some locations where a flag was set upon write and cleared on read so we could have easy handshaking on simple data transfers.
C.W.
The key to multitasking!!
This sounds like a good idea and is certainly doable and made easier with the internal IO port. The trick will be an agreed upon structure.... we don't always do well with "agreed upon".
I only have a single emulated COG at this point, all I can do is help bicker toward agreement!
Yeah, I only have a DE0-Nano as well, really can't afford the DE2-115 right now.
We can "cheat" and use a third task to stand in as the "borrower" to do some simple testing.
C.W.