Question about outa

jim N8RHQ · 2011-12-22 14:59

Could someone help me understand the difference between sequences

outa[leftLED..rightLED] := %001

and

outa[leftLED..rightLED] := %000
outa[leftLED..rightLED] := %001

or

outa[leftLED..rightLED]~
outa[leftLED..rightLED] := %001

well, I mean besides the obvious of explicity setting leftLED..rightLED to 000 before setting rightLED high?
I thought the first line would clear any previous settings of leftLED..rightLED in favor of the new value. I've
had to add one or the other extra lines to make this work on my MSR1 and I dont understand why. I do
have a seperate cog running and have dira[leftLED..rightLED]~~ and outa[leftLED..rightLED]~ as the first
two lines, which from reading the manual I didnt think was necessary, but seems to be.

pedward · 2011-12-22 15:25

The output lines are ORed together, so if another COG is holding an output high, you will not be able to set it low. If the other COG isn't doing anything with those outputs, just remove an reference to them.

jim N8RHQ · 2011-12-22 15:40

pedward wrote: »

The output lines are ORed together, so if another COG is holding an output high, you will not be able to set it low. If the other COG isn't doing anything with those outputs, just remove an reference to them.

I read the manual the same way, but if I take the outa[leftLED..rightLED]~ out of the seperate cog, or any where else for that matter, I end up with led's lit that shouldnt be. dira[leftLED..rightLED]~~ and outa[leftLED..rightLED]~ are the only
two references in the cog.

pedward · 2011-12-22 15:44

How are your LEDs configured, active high or active low? If only one cog issues dira[3..0]~~ then outa[3..0]~, the outputs will be low. The other thing you need to remember is that the order in the brackets [0..3] or [3..0] will change the order of the applied binary value. You need to have [3..0] for MSB, since you are using MSB 1 to write to the port.

Yeah, your problem is that you are reversing the bit order. Since Right is 5 and Left is 3, you need to enumerate Right..Left for the literal value to match the order of the array reference.

A simpler way to do this, without error, is OUTA[LeftLED]~ or OUTA[RightLED]~

jim N8RHQ · 2011-12-22 16:14

LEDs are wired active high.

I've been very consistant with my bit order, but ordering from highest pin to lowest pin to match MSB I was not aware of. Thank you!

I have reversed the bit order as you suggested, and removed the extra outa[rightLED..leftLED]~ lines, and I'm back to having more than one led on at a time.

I understand your simpler way, but outa[rightLED..leftLED] := 001 or 010 or 100 helps me visualize which LEDs I'm turning on and trying to turn off a little better.

new code attached

Phil Pilgrim (PhiPi) · 2011-12-22 16:36

Jim,

You can use either order. For example, both of these turn on the left LED:

outa[LeftLED .. RightLED] := %100
outa[RightLED .. LeftLED] := %001

-Phil

jim N8RHQ · 2011-12-22 16:41

Phil Pilgrim (PhiPi) wrote: »

Jim,

You can use either order: outa[LeftLED .. RightLED] := %100 and outa[RightLED .. LeftLED] := %001 both turn on the left LED.

-Phil

Thanks, Phil. Turning on seems to work great, but it's the turning off that's not working so great

Phil Pilgrim (PhiPi) · 2011-12-22 16:48

Jim,

Are you certain that more than one LED is on at a time? Or could they be alternating so fast that they just look like they're on simultaneously?

-Phil

jim N8RHQ · 2011-12-22 16:56

I am very certain they are staying on and not flashing. By running through static tests, once an LED is on, it's on to stay.

Phil Pilgrim (PhiPi) · 2011-12-22 17:04

Jim,

Please try this program by itself, and report what happens:

CON

  _clkmode      = xtal1 + pll16x
  _xinfreq      = 5_000_000


  LeftLED       = 3
  CenterLED     = 4
  RightLED      = 5

PUB start

  dira[LeftLED .. RightLED]~~
  repeat
    outa[LeftLED .. RightLED] := %100
    waitcnt(cnt + clkfreq)
    outa[LeftLED .. RightLED] := %010
    waitcnt(cnt + clkfreq)
    outa[LeftLED .. RightLED] := %001
    waitcnt(cnt + clkfreq)

-Phil

Phil Pilgrim (PhiPi) · 2011-12-22 17:08

One other thing to try: Change your stack size to 100. Fifteen is probably too small.

-Phil

MagIO2 · 2011-12-22 17:17

I'm not sure whether the LEDs are the real problem. To check that out you could first try to understand the LED-stuff with a small test-program!
(PS: like already posted by PhiPi in the meanwhile;o)
What can happen is, that you change the LEDs to fast which would be recognized as having two LEDs on at the same time but in reality the LEDs are never on at the same time! So, in your program this means that several if-cases are true at the same time or at least to fast to see the different LED-states on their own.

What puzzles me for example is your ping-function! If I want to compare r and l, I'd make sure that both values have been measured at points in time as close together as possible! So, I would do all 3 measurements straight after another and then wait for 10ms. Otherwise in case your motors are on, you would compare values which do not really belong together.
As you measure 3 values it would also be good to write all 3 bytes in one instruction from local storage to the global variables and then from global variables back to some other local variables in your main-program. Otherwise you'll have the same problem - comparing a set of values which do not belong together.

MagIO2 · 2011-12-22 17:26

Stacksize could be fine I guess. I'm not sure about the real overhead per function-call, but I counted 1 long for return address, 1 for return value, 1 per parameter and 1 per local variable. From that point of view 15 should be fine ... well maybe try it with 20, but 100 if far to much.

Phil Pilgrim (PhiPi) · 2011-12-22 17:38

MaglO2 wrote:

but 100 if far to much.

No doubt. But I wanted to err far on the side of too much as a test to see if stack size was the issue. If it is, reducing it from 100, can be a refinement.

Also, don't forget: any methods in external objects called from that cog use the same stack.

-Phil

jim N8RHQ · 2011-12-22 17:43

ok this is weird
red on blue off green off
red on blue on green dim
red on blue dim green on
red on blue dim green dim
red on blue on green dim
red on blue dim green on
red on blue dim green dim
red dim blue on green dim
red dim blue dim green on
red on blue dim green dim
red off blue on green dim
red dim blue dim green on etc.

Anticipating the question, P3 is wired 330 ohm to red led to ground , P4 is wired to blue led to 470 ohm to ground, P5 is wired to 470 ohm to green led to ground.

Phil Pilgrim (PhiPi) · 2011-12-22 18:23

Jim,

You didn't specify it: which program shows that behavior? Yours or mine?

-Phil

jim N8RHQ · 2011-12-22 18:30

Phil Pilgrim (PhiPi) wrote: »

Jim,

You didn't specify it: which program shows that behavior? Yours or mine?

-Phil

yours

Phil Pilgrim (PhiPi) · 2011-12-22 18:55

To which side of the MSR-1's level converters have you connected the LEDs?

-Phil

jim N8RHQ · 2011-12-22 19:08

Phil Pilgrim (PhiPi) wrote: »

To which side of the MSR-1's level converters have you connected the LEDs?

-Phil

I'm on the 5v side, I've made no changes to the board.

Phil Pilgrim (PhiPi) · 2011-12-22 19:23

Jim,

Have you looked at the datasheet for the TXB0108 level shifters used on the MSR1 board? Based on my reading of it, I have to conclude that they are neither designed for, nor capable of, driving LEDs directly. I would recommend adding either transistor drivers or a logic buffer between the level translator and the LEDs to isolate their current requirements from the translator. I can't say for sure that this is the root of the behavior you're seeing. But I can say that it has nothing to do with the software. It's definitely a hardware issue.

-Phil

jim N8RHQ · 2011-12-22 20:05

Phil Pilgrim (PhiPi) wrote: »

Jim,

Have you looked at the datasheet for the TXB0108 level shifters used on the MSR1 board? Based on my reading of it, I have to conclude that they are neither designed for, nor capable of, driving LEDs directly. I would recommend adding either transistor drivers or a logic buffer between the level translator and the LEDs to isolate their current requirements from the translator. I can't say for sure that this is the root of the behavior you're seeing. But I can say that it has nothing to do with the software. It's definitely a hardware issue.

-Phil

I must admit I have not read the datasheet for the TXB0108. I'm not real sure I got the idea I could drive an led. I will see about wiring up some transistors. I've been planning to do that anyway because I want to drive some ir leds as bright as possible.

Thank you for your help.

I really wanted to solve this before moving on with more enhancements and I just couldnt understand or accept that I had to add the extra lines to make it work. How can I move forward if I dont understand outa? It was driving me just a little nuts.
I'm not type A, I'm not type A, I might be OCD, but I'm not type A :-)

It will take me a day or two to scare up some transistors and suitable resistors, I'll post back then. Thanks again!

Merry Christmas

jim

jim N8RHQ · 2011-12-29 20:43

Hey Phil,

I tried driving some transistors with the level shifters. It works great now.

LEDs now turn off when they should, and now even brighter with the increased current.

Big big thanks for the help.

RTFM, what a concept!

Phil Pilgrim (PhiPi) · 2011-12-29 21:37

Jim,

I'm glad you got it working! Bidirectional level shifters are some of the most misunderstood ICs out there -- including by those who design them into a circuit. They're certainly not the panacea that they might appear to be at first blush and, IMO, they seldom meet their design objectives without severe compromise.

-Phil

Question about outa

Comments