Unwanted pulse on PortC.1 on 16F876

[Muttley]

I have scanned the posts for similar problems to the one I am detailling below but to be honest I'm not exactly sure what to look for.
I am using a 16F876 (4Mhz) to drive two DS1267 digital pots on Port C. The two RST (chip select lines) of the Ds1267's are connected to RC0 and RC1 respectively. The clock (CLK) and data (DQ) lines are paralleled and connect to RC2 and RC3.
The program selects the appropriate DS1267 by sending either RC0 or RC1 high then uses SHIFTOUT to write the data.
When RC0 goes high a pulse appears on RC1 that is sufficiently long enough to confuse the hell out of the other DS1267. However, the reverse is not true, i.e. when RC1 goes high no pulse appears on RC0 so it works fine.
This extra pulse is driving me nuts!
I suspect it has something to do with Timer1 or even CCP2 that are multiplexed on these two ports. I must admit that even after reading the datasheet for the 876 I am not proficient enough to understand how to ensure these functions are off. Of course there's a very real chance it has nothing to do with these functions and I'm barking up the wrong proverbial tree.
There must be someone who knows where these extra pulses come from and how I can stop them.
Thanks.

[Acetronics2]

Hi, Muttley

a small relevant piece of code and the PortC to DSs scheme are really welcome ...

too much solutions without those two things !!!

Alain

[Muttley]

Hi Acetronics,
Does this help?

Pinout:
1 ]
6 ]RC0 (pin11) >>>> DS1267(1) RST (pin5)
F ]RC1 (pin12) >>>> DS1267(2) RST (pin5)
8 ]RC2 (pin13) >>>> DS1267(both) CLK (pin6)
7 ]RC3 (pin14) >>>> DS1267(both) DQ (pin8)
6 ]

Code

DEFINE OSC 4
DEFINE SHIFT_PAUSEUS 100
DEFINE CHAR_PACING 100 'add 100 uSec extra stop bit

rst1 var PORTC.0 'DS1267 POT1 chip select port
rst2 var PORTC.1 'DS1267 POT2 chip select port
clk var PORTC.2 'DS1267 POTS clock port
dq var PORTC.3 'DS1267 POTS Data port
ampwiper var byte 'DS1267 pot wiper positions
sparewiper var byte
pwwiper var byte
freqwiper var byte

OUTPUT rst1: OUTPUT rst2: OUTPUT clk: OUTPUT dq

high rst1
SHIFTOUT dq,clk,1,[%0\1,ampwiper,sparewiper] 'Code required to write to DS1267
low rst1

The last three lines seem to put the unwanted pulse on PORTC.1
However,

high rst2
SHIFTOUT dq,clk,1,[%0\1,freqwiper,pwwiper]
low rst2

Does not put a pulse on PORTC.0

Cheers
Muttley

[Acetronics2]

Ok for the code,

But scheme ( are there pullup or pulldown resistors ....) etc, etc
Would be great ...

Alain

[Darrel Taylor]

Hi Muttley,

It's hard to tell if it's a single pass program, or if the statements were extracted from other subroutines. but, assuming it's single pass (as shown).

When a PIC first powers up, the state of the output latches are undefined. So when you set a pin to output, without setting it's state first, it could go either high or low. Leaving RC1 in the wrong state during the shiftout to the first DPOT.

After both of the shiftout's execute, things would get back "in sync" again. But then the programs finished at that point. (still assuming single pass)

Maybe try setting the pins LOW instead of OUTPUT at the beginning.<br><br>

[Muttley]

Darrel
It seems my efforts to keep the information as brief as possible while containing the relevant parts has lead to some confusion. The three lines of code that cause the problem are in fact part of a subroutine that is called whenever the user presses a button (monitored elsewhere in the prog). It is not just a single pass, sorry.
At the start of the program code I use the statement TRISC=%11110000 that I hope is setting the ports I am using for the DS1267's to outputs.
The devilish pulse occurs at EVERY pass of the subroutine.
Hope this clarifies.
Muttley

[Darrel Taylor]

Maybe you can clarify something else.

You say that...
When RC0 goes high a pulse appears on RC1 that is sufficiently long enough ...

Are we talking a few nanoseconds, or several hundred microseconds? Are you looking at a scope?

I'm also a bit confused with this part

The last three lines seem to put the unwanted pulse on PORTC.1
However,

high rst2
SHIFTOUT dq,clk,1,[%0\1,freqwiper,pwwiper]
low rst2

Since "rst2" is PORTC.1, you will obviously get a pulse there on every pass. But the original question mentioned that When RC0 goes high a pulse appears on RC1. Is it the exact same time?<br><br>

[Acetronics2]

My question reaches Darrel's idea ...

could it be a capacitive coupling between your lines ( Pcb, test board ??? ), or is it a software problem ???

one thing to try is to turn RST1 low when turning RST2 high ( at the same time ...) and the opposite.

and one further step, one !!!

Alain

[Muttley]

Thanks guys so far.
It's not a capacive coupling problem, pretty sure of that
The pulses on the 2nd DS1267 (RC1) are around 1mS long and the desired pulse on RC0 is about 3mS long. The pulse on RC1 occurs during the last third of the RC0 pulse, which is really weird.
As if that wasn't enough, when I deliberately try to address the 2nd DS1267, i.e make RC1 go high the pulse is only 1mS long in contrast to the 3mS when I am addressing RC0. Yet the two subroutines do exactly the same thing??
I've attached the entire relevant code for you experts. It's not that long and as I'm not that experienced, isn't very heavy.
It's got to be a stupid coding error but I'm damned if I can spot it.
BTW, whoever asked, no there are no pull-up resistors on the lines between PIC and DS1267. All the literature I've read suggests I don't need it and the PIC ports I'm using are TTL compatable, I think.

[Bruce]

How does this version work?

[Muttley]

Hi Bruce,
I think I can see what you're thinking
I'll give it a go and might even add a PAUSEUS in the other subroutines if it doesn't work as they are repeated over and over, compared to the setpotszero subroutine that is only called at start up.
Won't be for a day or so as a tad busy earning a crust.
Thanks for advice and I'll report back.
If there are any other suggestions, I'll still be happy to read them.
Muttley

[Darrel Taylor]

That would be interesting if that works. But I can't imagine it causing an output to go high in the middle of a shiftout command.

I've spent several hours now pouring through your code, and I can't see anything that would cause the described problem.

So I have one more question for you. Are you using a bootloader to program the chip, or a regular programmer?<br><br>

[Muttley]

Bruce,
You're a genius! Your code worked.
Now, you know what I'm going to ask you, why?
Like the previous post, I can't see why that should put an extra pulse on the other port. I left out all the DEFINE's that you remarked out and it worked exactly as you had written it, no changes. The pots are now incrementing and decrementing fine. The pulse out of RC0 is now only 1ms long instead of the 3mS each time the upamplitude/downamplitude subroutines are called so that's doubly weird.
To answer the other post (sorry didn't make a note of the name) I'm using a regular programmer (epic) and not a bootloader.
I really appreciate the help. No doubt I'll come across another stumbler as the code grows so in the words of Arnie, "I'll be back"
Much appreciation - but WHY DID IT WORK - ARGGGHHHH, I have to know!
Muttley

[Darrel Taylor]

Yeahh Bruce,

I was stumped. Good save!

Darrel

[Bruce]

Several assumptions on my part. Your code actually looked fine except where you initially used the high & low commands in the setpotszero sub.

Setting port latches followed by tris in the beginning reduces the possibility of read-modify-write when initializing both pots in the setpotszero routine. Using high & low together like that with the port latches in random states will normally cause headaches.

Why high RC0 created the pulse on RC1..? The only thing I could see (short of capacitive coupling) that may cause this was using the high & low commands so close together.

With low rst1 immediately followed by high rst2 it seemed to be showing high on RC1 before RC0 had settled.

Dropping the short delay in there just allows the RC0 logic to settle back to 0 before RC1 is taken high. Successive operations on a port, pin-by-pin, can cause odd things to happen depending on the load on each pin. So the brief delay sometimes helps.

Just a guess, but I'm glad it worked for you.

Once in a while I get someting right....;o}