How does this version work?
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
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>
DT
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
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}
Bookmarks