O.K. i have to go out. I had the same code, and i didn't have any problem...
when i'll be back, i'll use a lower voltage AND use HighBrightness LEDs.
Wish i could see the same thing....
Still thinking there's an hardware problem...
O.K. i have to go out. I had the same code, and i didn't have any problem...
when i'll be back, i'll use a lower voltage AND use HighBrightness LEDs.
Wish i could see the same thing....
Still thinking there's an hardware problem...
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
Pablo,
Good new, Bad news.
I finally found my 12F683 and gave it a go.
I've completely duplicated your problem. Blinking and all.
For some reason it only does it on the 683.
Every other chip I tried seems to work fine.
And the bad news is, I haven't found out why yet. (Operative word, Yet)
It appears to be with the A/D, the readings are all over the place at low voltage input.
I still have many things to try, but just wanted you to know you're not crazy.
And, I WILL find it. (unless somebody beats me to it)
<br>
DT
An EE friend of mine (Thanks Doug) told me a new possibility about the cause of the problem:
What if reading the ADC so often does not give it enough time to handle the low voltage values?
(more discussions via chat with my friend)
He points out something interesting, the test program initializes the ADC using:
DEFINE ADC_BITS 10 ' ADCIN resolution (Bits)
DEFINE ADC_CLOCK 1 ' ADC clock source (Fosc/8)
DEFINE ADC_SAMPLEUS 11 ' ADC sampling time (uSec)
But reading the pic basic manual we have:
and the PAUSEUS section says:ADC_SAMPLEUS is the number of microseconds the program waits
between setting the Channel and starting the analog to digital
conversion. This is the sampling time. The minimum number of
microseconds usable is determined by the minimum time for PAUSEUS.
See it’s section for this information.
So, the initial theory appears to be right, I don't have the protoboard here now, but I will check this tomorrow.For 4mhz Minimum Delay is 24us
Pablo
I tried every AD oscillator / Sample time possible, and it made no difference.
Even with the A/D input tied directly to ground, it was getting crazy readings between 0 and 20.
After I tried it with a 12F675 (without the CCP) and got the same results,
I finally figured out that I had removed the big cap on the power lines on this protoboard.
Probably needed it for something else. Doh!
After putting a 100uf cap across the power supply, everything calmed down again.
It's still not perfect, but I think that has alot to do with the breadboard.
So then to really stabilize things I added an averaging routine, and I think that's about as close as we're going to get.
First make sure you have enough capacitance on your power lines (I think mister_e already suggested that).
Then add this to the bottom of the programAnd also, just after the ADCIN statement, add thisCode:' -=-=-=-=-=-= Average Analog values -=-=-=-=-=-=-=-=-=-= Avg VAR WORD AvgCount CON 16 spread CON 20 Average: ' Smooth data IF ABS (pote - Avg) > spread then Avg = pote else Avg = (Avg*(AvgCount-1)+pote)/AvgCount pote = Avg endif ReturnHTH,Code:gosub Average
DT
it's getting interesting... i have everything on hand, will do some test here.
Sorry, i was suppose to do it yesterday![]()
![]()
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
well I hope you find something because I tried adding a 100uF capacitor in the power lines or in parallel with the wiper and my problems remain, even after adding the averaging routine provided by Darrel.
I even started looking for other pic alternativesin case this can't be solved...
Thanks again
Bookmarks