Reading the output state of a pin in one cog that has been set by a different c

GenRev

I've written code where the output state of some pins are controlled by one cog.· In a different cog I would like to read the states of these pins in order to do some conditional processing.· However, it appears that pins' states that have been set by one cog cannot be read by another cog using simple conditional commands (see below code for a simple·example).· Is there a way for a cog to determine if the state of an output pin is high or low that has been set by a different cog?· Thanks!

-genrev



VAR
· long stack[noparse][[/noparse]100]
·
···
PUB Main
· coginit(2, Start, @stack[noparse][[/noparse]0])··
·
·
PRI Start
· dira[noparse][[/noparse]9] := 0
· repeat until ina[noparse][[/noparse]9] == 1········ 'Wait until Start button is pushed.
· coginit(3, LightLED, @stack[noparse][[/noparse]30])······
· coginit(6, TestResult, @stack[noparse][[/noparse]60])··························
·
···························
PRI LightLED········
· waitcnt(clkfreq + cnt)··········· 'One-second delay before pin 7 goes high.
· dira[noparse][[/noparse]7] := 1
· outa[noparse][[/noparse]7] := 1
· repeat
·
·······
PRI TestResult
· dira[noparse][[/noparse]7] := 1
· dira[noparse][[/noparse]22] := 1
· repeat until outa[noparse][[/noparse]7] == 1· 'QUESTION:· What's wrong with the third-to-last step that prevents
· outa[noparse][[/noparse]22] := 1················· 'the second-to-last step from being executed when pin 7 goes high?·····················
· repeat··························· 'If the second-to-last step is indented, it gets executed, but it
······································ 'gets executed before pin 7 goes high, as expected.
······································ 'Basically, I would like to know how to execute the second-to-last
······································ 'step only when the condition in the third-to-last step is met using
········································'a different cog for each method.

Jeff Martin

Hi GenRev,

What you're trying to do is certainly possible, but you have a slight, but critical, misconception here.

THE SHORT ANSWER:

change your third-to-last step to: repeat until ina[noparse][[/noparse]7] == 1


THE LONG ANSWER:

Every cog can read the state of any pin, at any time, regardless of the direction of that pin as set by the·cog collective. Regardless of the direction, or which cog set a pin's direction or state, reading ina[noparse][[/noparse]x] actually reads the state of the actual pin. The ina register can be thought of as one that is shared among all cogs; it is really a pseudo-register that doesn't really exist (in typical form) in each cog, but rather, access to ina from any cog results in reading the current state of the Propeller's I/O pins.

The dira and outa registers, however, do exist in each cog... ie: each cog has its own dira and outa register, and any changes to a cog's dira and outa register can not be seen by any other cog.· See page 26 of the Propeller Manual for a deeper·explanation of this part of the architecture.

So, the cog (6) that executes the third-to-last step, repeat until outa[noparse][[/noparse]7] == 1, is reading it's own outa register, bit 7, which can only be affected by that cog, so it remains unchanged from its original state of 0.

What you really need to do is read the global ina[noparse][[/noparse]7] bit to get the actual state of the pin, ie: repeat until ina[noparse][[/noparse]7] == 1


Also, it's important to keep in mind that the reads of ina return the state that is "sensed" on that/those pin(s), which, under most circumstances, is either the state of the outside influence (for pins set to input by the Propeller), or is the state of the output influence (for pins set to output by the Propeller). However, even if a pin is set to output a high or low, reads of ina can effectively read a different state if an outside connection is also driving the pin to a different voltage; where an output pin is accidentally connected to a voltage source, producing a short-circuit.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Jeff Martin

· Sr. Software Engineer
· Parallax, Inc.

Post Edited (Jeff Martin (Parallax)) : 1/24/2008 2:17:45 PM GMT

GenRev

Cool!· It actually crossed my mind to use the ina[noparse][[/noparse]x] command, but at the time it seemed counter-intuitive.· It makes sense now thanks to your detailed explanation.· Much appreciative.

-GenRev