Unwanted pulse on PortC.1 on 16F876

[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}