Pssst.... Look in post #22.....
Dave Purola,
N8NTA
skimask is right.
If your LEDs are referenced to V+ and your scope is referenced to Vcommon
the scope will show a logic high when the LEDs are off.
If you “invert” a channel on your scope it should show you what the LED is doing...
I have not tried it but this code should work:
‘ with both LEDs referenced to V+
high GPIO.0 ' OFF INITIAL CONDITIONS
high GPIO.1 ' OFF INITIAL CONDITIONS
START:
PAUSEUS 2074 ' before pulse
LOW GPIO.1 ‘ON = pulse
PAUSEUS 4168 ' ON TIME - GPIO.1 only
HIGH GPIO.1 ‘both pins OFF
PAUSEUS 2074 ' after pulse
PAUSEUS 20 ' anti-overlap time
‘should add to 8.336 milliseconds
PAUSEUS 2074 ' before pulse
LOW GPIO.0 ‘ON = pulse
PAUSEUS 4168 ' ON TIME - GPIO.0 only
HIGH GPIO.0 ‘both pins OFF
PAUSEUS 2074 ' after pulse
PAUSEUS 20 ' anti-overlap time
‘should add to 8.336 milliseconds
GOTO START '60 HZ FREQUENCY
END
I agree with Malcolm on all three points he made.
The idea about slowing the duty cycle down to visible speeds to test LEDs is good....
But, because, your board is made:
You should be able to use a single (LED) supply resistor in this circuit because you NEVER want the LEDs to be on at the same time.
You can leave the LEDs referenced to V+ as long as you remember any Vcommon referenced measurements are inverted to the LEDs.
Also:
Do you have your optocouplers on the board? If so:
You can temporarily feed them with +/-12V (instead of the 150V) and a series resistor in each leg to protect them (in case both on)...
Measure the output referenced to common.
Aside:
The programmable guard time (anti-overlap time) between polarity switching is handy, I know you have done that in your analog work with deliberate propagation delays. Keeps the smoke to a minimum.
The programmable “before / after pulse” time would help “push” the wave shape to what you want.
-Adam-
Ohm it's not just a good idea... it's the LAW !
I hate to tell you this, Adam, but your program makes the outputs high for 4 ms and low for 12 ms, just like mine. And, I am refrencing the scope to VSS.
Are you sure you don't have a inverted probe type??? or scope setting.
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
Aarrrggghh, I hate hearing that, too!![]()
Mister-e’s suggestion on the other tread sounds plausible (“Where's the CMCON setting?”).
The other idea is: you may not be really re-programming the PIC.
Try changing the times to 100 times longer. Just to check.
or
Try erasing the PIC, reading it, look at the hex to make sure it is erased. Then, program it with the new code compiled from MCS and PBP. Then read the device again to see it has really been re-programmed.
I seem to remember some forum postings about forgetting to re-compile before re-burning.
So they just kept burning the original (Version 1 of their code) ASM into HEX, not the new PBP (Version 2 of their code).
-Adam-
Good suggestions, Adam. But, I have done all those things (except make the time longer). Look at post#15, why is that waveform the same as post#1?
I'm thinking the problem overall is the fact that you've got one resistor for current limiting for 2 LEDs. If you pull either pin low and you're measuring your signal on the LED side of the resistor, it won't matter which pin gets pulled low, they will probably both read low at back side of the LED (the connection nearest to the resistor).
What do you get if you 'scope the actual pins themselves, right at the PIC with nothing else connected?
Bookmarks