Waitpeq

g3cwi

I am using waitpeq to detect a change of state from one cog to another. Thus one cog has a process running (timer) that sets a pin. The other cog sits waiting to see the pin set before starting work. This means that one cog uses the pin as an output and the other as an input - at the same time. Is this allowed? Is there a better way to signal an event from one cog to another?

Cheers

Richard

Heater.

Yes, you can have one COG set the pin as output and another set the same pin as input.
I did this when testing the execution speed of my Z80 emulator, the emulator toggled a pin after every emulated Z80 opcode and another cog acted as a frequency counter with that pin as input.

Normally we signal events from COG to COG via a variable in HUB RAM. For example a LONG might be set to a non-zero value to indicated some event or command. The responding COG would loop until it sees that command in the LONG, do the work required and then set the LONG back to zero. At which point the first COG can issue another command.

This is of course much slower than signalling via a pin and using waitpxx but saves a pin and is very flexible.

Mark_T

waitpeq and waitpne have the advantage that they save power as the cog pauses execution, and can synchronize to (I think) the system clock resolution.

If you want to signal from one cog to several others and prevent more than one getting through then locks are the best option.

cavelamb

I need to see a code snippet for this one...

Process A sets pin as output and writes a 1 to that output pin.
Process B is waiting fro that 1 to show up.

Does B have to set the pin as input to read it?
Or is it reading from the output register that drives the pin?
without having to turn the pin to input?

Recall that the 8255 and Z80 PIO pins work the latter way.

Phil Pilgrim (PhiPi)

cavelamb wrote:

Does B have to set the pin as input to read it?

All pins are inputs all the time. To read the physical state of a pin, just read ina. Some pins can also be outputs, when their dira bit is set to 1. You can read outa to determine what your cog wants the output to be if the pin has been set to output from that cog. But that's not necessarily what will exist on the pin. That's because other cogs may also have the pin set as an output, and their outputs are ORed together to set the pin state. So, as a rule, to check a pin's state use ina. It always works.

-Phil

cavelamb

Fascinating.
Thanks Phil.

The more I learn about this chip the more impressive it is.

Ya done good, Chip!

frank freedman

g3cwi wrote: »

I am using waitpeq to detect a change of state from one cog to another. Thus one cog has a process running (timer) that sets a pin. The other cog sits waiting to see the pin set before starting work. This means that one cog uses the pin as an output and the other as an input - at the same time. Is this allowed? Is there a better way to signal an event from one cog to another?

Cheers

Richard

I posted an ADC object a while back that uses one cog for timing generation to control multiple parallel ADC devices. One master control cog, one cog for master timing generation and one additional cog for each MCP3201 ADC. The adc cogs all monitor the pins from the timing cog to perform capture and serial transfer of the result into the cog. It does need a few improvements, but that was the fastest way to do it as no memory to memory timing gets in the way. All cogs have access to all pins and can read their states, instant availability that way. Thinking about this if you wanted to waste a few pins, you could transfer bytes or words between cogs by setting the data on the pins from one and signaling data valid to one or more other cogs for non memory transfer of data between cogs. How much faster or slower remains to be tested, this possibility just occurred to me as I was thinking about this very reply.

FF