Unwanted pulse on PortC.1 on 16F876

[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