one can access output pins only in the method that declares them?

gio_rome · 2014-02-06 00:25

hello,

my program deals with the Propeller pins, some treated as outputs. They should be made accessible by different methods, of course providing the care that the different lines of codes do not interfere.

So, for instance:

PUB Main

dira[25]~~
outa[25]:=1 or 0
................

PUB DO_SOMTHNG

..............
outa[25]:=1 or 0

.....

PUB INITIALIZE

dira[25]~~
outa[25]:=1

and so on....

Well, I've found out that I cannot do it. I'd like to have a method to initialize the pins status, one that sets the pins in different configuration, etc. etc.

For now I had to put everything in the same method...and I don't like it.

For now it's like:

PUB Deal_w_pins

....initialize sequence....

repeat ' this method is to be run in a COG, so to be executed over and over in background, to regulate the pins according to what happens
1st setting sequence involving pins....
2nd setting sequence involving pins....

Now you see that I cannot parallel the 1st and the 2nd setting sequence, because in order to do that I'd have to have two different methods running in two different Cogs (that one I'd like), but I'd have to "declare" the pins in both methods, like initialize them twice...etc.

I would like to:

INITIALIZE
COGNEW(REGULATION1, @STACK1)
COGNEW(REGULATION2, @STACK2)

both regulation1 and 2 of course "talk to each other" by means of a common general variable.

Any idea? Maybe I have to change paradigm, because repeating the same lines of code or queue processes instead of parallel them does not seem very elegant, appropriate to me and what I'd like to actually do doesn't seem possible, maybe with good reasons. I have yet to develop any other ideas, though.

Thank you for any comment,

Giovanni

Phil Pilgrim (PhiPi) · 2014-02-06 00:44

I/O registers are common to multiple methods as long as those methods all operate from the same cog. But each cog has its own I/O registers and must set bits in its own DIRA in order to have output access to the physical pins. If multiple cogs write to the same output pin, the result on the pin is the OR of all the DIRA-enabled OUTA bits corresponding to that pin.

-Phil

Heater. · 2014-02-06 01:53

gio_rome,

As Phil says, if you want to use OUTA you have to set DIRA for every COG that the code runs in.

This is nothing to do with multiple declarations and such. One can imagine starting the same method in multiple COGs, that method had better set DIRA if it want's OUTA to work.

Do have a look at the Propeller architecture diagrams in the manual to se why this is so. Pages 20 and 21. There is also a written description in there somewhere.

gio_rome · 2014-02-06 02:33

I see. It does make sense afterall. Should've figured it out....

>As Phil says, if you want to use OUTA you have to set DIRA for every COG that the code runs in.

The thing is that DIRA actually resets the pin to its ground state, therefore changing it. I'd have liked to avoid having to do it twice.

I think the only way is to

cognew(regulation1, @stack1)
cognew(regulation2, @stack2)

and in the beginning of both those two methods I OUTA and DIRA in the correct order (for me), so that they can then both do things, of course with the correct precedence policies.

So

PUB REGULATION1
DIRA...
OUTA...

Repeat....
----
PUB REGULATION2
DIRA...
OUTA...

Repeat....

Now question is: REGULATION1 is launched, it DIRAs (and then OUTAs, to set the correct state for the pin) and then it cycles its regulation code.
THEN REGULATION2 is launched, it DIRA's again _WHILE_ REGULATION1 is doing it's things

Now for things of the machinery I cannot allow dangerous configurations of the pin states to occur. The only thing I can think of is a global checking variable, to set the precedence policy.

Like in REGULATION1 this global variable is set to 0 after the initiation is finished, and REGULATION1 doesn't start (*) its repeat code until this variable is set to 1 by REGULATION2, thing that happen at the end of _its_ initiation procedure. Well something like that anyway.

(*) it actually cycles the checking until it's satisfied so it cycles the actualy regulating code

I don't know any other way to make to different cog-run method talk to each other.

What do you think?

Giovanni

Heater. · 2014-02-06 03:31

gio_rome.

The thing is that DIRA actually resets the pin to its ground state, therefore changing it.

No it does not.

DIRA only enables or disables the output from the COG reaching the actual pins. The state that is driven to the pins depends on OUTA.

If you set a pin low with OUTA (Which is the default vase after reset anyway) then setting DIRA to output will drive the pin low (Perhaps the level on the actual pin will change if it has a pull up resistor for example).

Conversely if you set the pin high with OUTA and then set the direction to output with DIRA the pin will be driven high.

So, just initialize OUTA before you set the DIRA and no unwanted transitions will occur on the pin.

I cannot allow dangerous configurations of the pin states to occur.

Quite so. So don't do that.

If you have two or more COGS driving the same pins you will be in trouble. You would have to take care that the COGs cooperate some how an negotiate who has "ownership" or control of those pins at ant given time. This can be done in many ways. Perhaps by using locks, perhaps by passing flags between COGS though HUB variables and so on.

In general people do not access the same pins from different COGs and rarely have to. Life is much easier that way.

Phil Pilgrim (PhiPi) · 2014-02-06 08:28

Just to clarify, if two or more cogs output conflicting states to the same pin (i.e. one cog says "high"; the other, "low"), there will not be a physical conflict, since the states are ORed; so the pin will be "high."

-Phil

StefanL38 · 2014-02-08 14:12

Hi Giovanni,

if your project is not top secret please give us (the forum-members) an overview about your project.

You are asking for some programming details. I'm pretty sure if you give us an overview elegant solutions to the MAIN thing can be found.

It's a little bit like turning a screw through welding an iron onto the screw. Welding a second iron to the first in an angle of 90 degrees.
moving the second iron in circles. Then using sandpaper to disconnect the iron from the screw. If all you know is a welder and sandpaper
you will work with this tools. Now you are asking how do I have to adjust welding voltage to get a good welding-result on small irons?
If course a welding expert can tell you this.

If you would tell him the overview: "I want to turn a screw" She can suggest: "try an electric screwdriver with a suitable bit".

Of course my example is nonsens but it's suitable to show the difference between asking for details with and without giving an overview.

Switching IO-Pins is not a selfpurpose. So what is it you want to do IN THE END??

There are two main ways to get a project running:

1: Asking 150 details in postings each 10 lines long, doing try and error with them
which needs 1500 lines to write and half a year time.

2: Give an overview about your project with 150 lines. Asking 10 times in postings each 30 lines long finishing your project after 450 lines
within 4 weeks. Got it?

best regards
Stefan

gio_rome · 2014-02-11 01:21

Stefan,

maybe I've forgotten to thank in each thread I started, but I did receive precious help fundamental to the success of my programming. I'm new to SPIN so that's why I might seem so naive.

Sometimes I even write issues and, typing them down makes me figure it out by myself.

My project is having to handle INPUT pins and OUTPUT pins, this up to now in both the Main and some cog-method. I'm trying to clean up the code.
Having solved the issues with output pins, now a similar arises -I might have skipped it in the past. I will now mention it though I'll probably start an ad-hoc therad.

I've noticed that I can access INPUT pins in a different cog without having DIRAed them.

e.g.

PUB MAIN

' Set input pin
dira[n1]~
dira[n2]~
....
cognew(input, @stack0)

PUB input

if INA[n1]==0 .... 'if I push the first button...

IT WORKS!

Then again, I cannot easily post something more thorough just because I've yet to make full sense of it.It's a work in progress.

Vielen dank

Giovanni

kuroneko · 2014-02-11 01:24

gio_rome wrote: »

I've noticed that I can access INPUT pins in a different cog without having DIRAed them.

The default state for dira is 0, which means all pins are set to input.

gio_rome · 2014-02-11 06:42

so simple and I didn't see it

domo arigato kuroneko, tnx a lot!

G.

gio_rome · 2014-02-13 08:30

Phil Pilgrim (PhiPi) wrote: »

I/O registers are common to multiple methods as long as those methods all operate from the same cog. But each cog has its own I/O registers and must set bits in its own DIRA in order to have output access to the physical pins. If multiple cogs write to the same output pin, the result on the pin is the OR of all the DIRA-enabled OUTA bits corresponding to that pin.
-Phil

that leads to the question: if I start a cog in which I call a method that DIRAs~~ a pin, then will I be able to access the same output pin in the "Main" (regarding the above mentioned cog) too?

ie:

pub main

....
cognew(method#1, @stack1)
....

pub method#1

...
method#2
outa[I_1]:=0     ' will it work?
...

pub method#2

...
dira[I_1]~~
...

Will it work?

thank you

Giovanni

Phil Pilgrim (PhiPi) · 2014-02-13 08:45

For a cog to output to a pin, the dira bit for that pin must be set in that cog. Each cog has it's own dira register and its own outa register. The bits from the outas from all the cogs whose corresponding dira bits are set are ORed together before they reach the actual pin. Therfore, if one cog is outputting a 1 to a pin, another cog cannot lower the pin by outputting a 0 to its own outa register.

-Phil

one can access output pins only in the method that declares them?

Comments