Depending upon which port you are using . . . some Schmidt trigger inputs there.
Depending upon which port you are using . . . some Schmidt trigger inputs there.
If you do not believe in MAGIC, Consider how currency has value simply by printing it, and is then traded for real assets.
.
Gold is the money of kings, silver is the money of gentlemen, barter is the money of peasants - but debt is the money of slaves
.
There simply is no "Happy Spam" If you do it you will disappear from this forum.
...Never mind.....
Last edited by mister_e; - 12th June 2011 at 11:35.
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
As the code shows I'm using PortA.0. Schmidt trigger or not why would that make a difference in this case, care to elaborate a bit? Same pin, same signal, same voltage on input. One program sees the input it, the other doesn't.
I'm still pretty much stumped on this one.
By any chance... is there still any ADC or Comparator enabled on those specific pins...
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
Hi,
Aahrgh, sorry can't read my own code...The input pin in question is PortB.3 not PortA.0, sorry about that - and it IS set to an input.
No, the 18F2431 doesn't have any comparators and all pins are set to digital with ANSEL0 = 0.
Here's what the hardware looks like (again, that should read PortB.3, not A.0):
As I've said, the hardware has been this way "for ever" and it has been working just fine "for ever". I changed the code and all of a sudden it didn't see the input. I could go back and forth between working and not working by basically changing where in the code I polled the input.
Again, the voltage at the pin WAS indeed outside the electrical specs but I still don't understand how it can see the input in one version of the code and not the other. The diode in series with the opto-isolator is NOW a shotky type and it's back up and running with the new code. I'm still looking for an explanation though.
Does the code modification also add/modify what happen to the adjacent "offending" input pins?!?
Or you've been lucky OR...well... let's apply this rule
Sometimes, you don't wanna know why... and stay happy
Keep it simple... Look forward![]()
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
Have you looked at the transitions with a scope?
Is there any undershoot?
The non-filtered version would be more likely to catch short lived pulses just under the threshold.
DT
No I have not scoped it but it's got to be something like that. I'm just a bit surprised that it "never" (that I know of) missed it before and now it didn't see it at all. I spent quite some time staring at the code before I even bothered to put the meter on it since I "was sure" that the hardware was OK.
I'll scope it next time I work on that project.
Thanks!
/Henrik.
Hello Henrik,
Here is my thoughts, for better or worse . . . Schmidt Trigger is more particular as to threshold voltage as to when it switches, both high and low. TTL switches around 1/2 way between VSS - VDD, if your diodes are different in terms of their switching voltage, as I see it, 1 will work and the other will not, and your VOM might not be high enough impedance to see the difference.
In any event, as I said, those are my thoughts . . .
If you do not believe in MAGIC, Consider how currency has value simply by printing it, and is then traded for real assets.
.
Gold is the money of kings, silver is the money of gentlemen, barter is the money of peasants - but debt is the money of slaves
.
There simply is no "Happy Spam" If you do it you will disappear from this forum.
Yes, but I didn't switch inputs or diodes or did anything else to the hardware. It was working just fine with the old code but stopped working with the new code. I took a working board and downloaded the revised code. Nothing changed hardware wise, just the code. Reverted to the old version - everything OK. New code, nope.
It's got to be something in line with Darell's thinking. Previously it checked the input in a very tight loop except when it ran the servo loop which is around 350us 1500 times per second. Now it checks it a single time each time it enters the servo loop.
But if this is the case I would expect it to have missed it on ocations even with the old code. After all, it's busy ~50% of the time thus not checking the input so if an undershoot event on the signal was what caused it to work I must have been seriosult lucky since I haven't had it miss a single time.
Thanks!
/Henrik.
Bookmarks