Output latch?

kenmac · 2007-07-16 04:59

Hi,
I'm still feeling my way with Propeller Spin.
Outputs are described as "latching" when set.
When a pin is set by code in a particular Cog, should it retain the current state (latch) when that Cog completes and closes?
I have found that following code by itself doesn't appear to do anything.

pub start
            dira[noparse][[/noparse]16]~~
            outa[noparse][[/noparse]16]~~

However, if included in a repeat loop it activates the pin, probably indicating that the Cog closes before the effect can be seen (on a LED)
So, is it necessary to maintain a Cog's operation to retain the relevant Pin's status?
I'm using a Propstick, but that's probably not relevant info.

kenmac

Mike Green · 2007-07-16 05:19

When a cog is stopped, either by "running off the end" of the main method or by being explicitly stopped using COGSTOP, all of the special registers associated with the cog are cleared to zero including the DIRA/B registers. This changes the cog's I/O direction to input mode.

Note that the outputs are still "latching". It's just that the latches (including the direction latches) are zeroed when the cog is stopped.

The "running off the end" thing is done by the Spin interpreter pushing a dummy return address on the return stack before starting your cog. This returns to a COGSTOP instruction for the cog.

Beau Schwabe · 2007-07-16 05:19

kenmac,

"When a pin is set by code in a particular Cog, should it retain the current state (latch) when that Cog completes and closes?"

No, when the Cog completes, it will release Output control and the logic state will return to LOW.

If you look at a scope, you can "see" that your code is actually doing something, although it's too fast for you to perceive if you are just using an LED. Edit - You can actually see it as a very brief "blip".

Instead of including the code within a repeat loop, try this code to confirm that if the Cog is kept "alive", you will see your expected result.

pub start
            dira[noparse][[/noparse]16]~~
            outa[noparse][[/noparse]16]~~             repeat

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

Post Edited (Beau Schwabe (Parallax)) : 7/16/2007 5:29:12 AM GMT

kenmac · 2007-07-16 08:22

Thanks for that info. guys.
What is happening in the following situation:
Two objects .
test_2.spin

obj
  x : "test_3"
  
pub main
  x.start 
  start 
  
pub start
  dira[noparse][[/noparse]16]~~
   outa[noparse][[/noparse]16]~~
    repeat

Note: above should say X but the code button wouldn't show it

test_3.spin

pub start
  dira[noparse][[/noparse]20]~~
  outa[noparse][[/noparse]20]~~

When test_3 is run by itself, there is no latch on P20.
However, when called from test_2 the pin actually latches!
Both P16 and P20 latch.
From the previous discussion I would have expected the P20 not to latch

????

kenmac

kenmac · 2007-07-16 08:25

The first object should say obj :
The code button wouldn't show it.

kenmac

kenmac · 2007-07-16 08:29

I was attempting to show square brackets, but it won't do it - sorry.

kenmac

mirror · 2007-07-16 08:54

kenmac said...
Thanks for that info. guys.
What is happening in the following situation:
Two objects .
test_2.spin
obj
  x : "test_3"
  
pub main
  x.start 
  start 
  
pub start
  dira[noparse][[/noparse]16]~~
   outa[noparse][[/noparse]16]~~
    repeat
Note: above should say X but the code button wouldn't show it

test_3.spin
pub start
  dira[noparse][[/noparse]20]~~
  outa[noparse][[/noparse]20]~~
When test_3 is run by itself, there is no latch on P20.
However, when called from test_2 the pin actually latches!
Both P16 and P20 latch.
From the previous discussion I would have expected the P20 not to latch

????

kenmac

kenmac,

The call to x.start is a function call within the same cog as main, just as start is also a function with in the same cog. So what happens is the following:

o· The propeller starts a single cog (id = 1), and calls function main in test_2.spin.
o··main calls x.start which sets the direction and state of pin 20 - which is still within cog 1
o· main calls start which sets the·direction and state of pin 16 - which is still within cog 1
o· start never returns, so the values assigned to·the I/O pins belonging to cog 1 are retained until time passes by.

Now if you has called x.start as follows:

var
  long x_stack[noparse][[/noparse]20]
 
pub main
  cognew(x.start, @x_stack)
  start

then, when main calls x.start it would be run in a new cog (id = 2). The direction and state of pin 20 would be set - within cog 2. But then x.start would end, and so·would its cog. The result is that the I/O state of cog number 2 return to the reset condition.

·

kenmac · 2007-07-16 10:15

OK, I had assumed that x.start began a new Cog.
I think I have been confused by the Tutorial Ex 8 where there is a list of objects being started - it stated that several cogs were opened.
Perhaps that only happened because the same Object was being called multiple times?
It's a bit unclear how a Cog is started except for COGNEW and COGINT.

kenmac

mirror · 2007-07-16 22:53

kenmac said...

It's a bit unclear how a Cog is started except for COGNEW and COGINT.

Actually, aside from reset (which starts the first cog) those functions are the ONLY way a new cog may be started. So, that should make it a little less unclear.

Mike Green · 2007-07-16 23:40

kenmac,
Keep the concepts of cogs and objects distinct. You can have a program consisting of several objects that all runs on one cog. You can also have a program with no objects (other than the main program) that uses all 8 cogs.

An object is an abstraction, a collection of variables, constants, and methods that implement this abstraction. By keeping the variables and some of the methods private, some of the internal implementation of the abstraction is hidden from the user.

A cog is a processor and its memory. It is initialized by using a COGNEW or COGINIT that references a copy of the initial instructions to be used with the copy in shared (hub) memory.

kenmac · 2007-07-17 02:08

Mike,
In the Tutorial Exercise 8 (in the Manual) they show an object list:

Obj
    x.start
    x.start
    x.start
    x.start

etc.

According to the text, this starts multiple Cogs, but Mirror says you can only start a Cog with COGNEW or COGINT?
Of course, the program does work, with several LED's flashing independantly (parallel) which should mean that several Cogs are operating.

kenmac

mirror · 2007-07-17 03:05

kenmac said...
Mike,
In the Tutorial Exercise 8 (in the Manual) they show an object list:
Obj
    x.start
    x.start
    x.start
    x.start
etc.

According to the text, this starts multiple Cogs, but Mirror says you can only start a Cog with COGNEW or COGINT?
Of course, the program does work, with several LED's flashing independantly (parallel) which should mean that several Cogs are operating.

kenmac

Almost, but not quite:
What they show in the manual is:

x[noparse][[/noparse]1].start
x[noparse][[/noparse]2].start
x[noparse][[/noparse]3].start
x[noparse][[/noparse]4].start

If you look at the definition of x.start, then you'll see it reads as:

PUB Start : Success
  Stop
  Success := (Cog := cognew(blah blah))

Do exercise 7 and 8 again. Read·the text carefully.
·

kenmac · 2007-07-17 04:25

Oops - you're right.
The Cog's are actually being started by the object Output.spin each time it is started.
I had actually been thru the exercises sometime before but referred back to them when contemplating how to fire up Cogs.
I lost the context and made an incorrect assumption.
Thanks for your help.

kenmac

Output latch?

Comments