12f675_fuse_about_to_blow!

**LEDave** · - 13th July 2010, 00:54

Sounds like a weak battery or the transmitter was stuck on transmit.

I'm hoping the former.The battery I used was unopened but had been my draw for a long, long time.

Can you check the amps when "not in use" ?

Tricky and I guess I'll need a new battery which I don't have right now. I guess try a new battery.

I read in the TX pdf that the TX output power can be set and adjusted via different resistor values set on a pin. This might be a way of increasing the transmit range (at the cost of battery power/life I guess).

Here's (another) project I'd like to do next Spring (gives me time to learn how to do this). Most Years we have birds use a nesting box in our apple tree. When the young hatch, the parents are really busy bringing in food. I'd like to:

1/ Have a beam set across the entrance whole to the nest box.

2/ When the beam is broken (parent bring in food) a counter is incremented and stored.

3/ Set a Light_Dependant_Resistor up so that when night falls the days DATA is rfpic'ed back to the RX module and displayed on the Serial Communicator.

LEDave, so many projects, too little knowledge.

**mackrackit** · - 13th July 2010, 01:09

Cool project!!!
Two beams so you only count one way? Or just divide by two?

**LEDave** · - 13th July 2010, 01:44

Two beams so you only count one way? Or just divide by two?

Mmm, I hadn't thought of that. I guess divide by two would be easiest, all depends on space I guess.

Looking at the TX / RX demo code in.ASM it looks really difficult and Bruce's code not much easier, although I can understand some of that, would be good to try and figure and learn over the Winter.

To my mind, sending data through the air has something mystical / magical even about it. I'd like to crack rf.

Right, I'm off to me bed.

Night, night mackrackit.

Dave

**mackrackit** · - 13th July 2010, 15:02

Looking at the TX / RX demo code in.ASM it looks really difficult and Bruce's code not much easier, although I can understand some of that, would be good to try and figure and learn over the Winter.

You will get it.. Plenty of resources here.
But you may want to start a new thread specific to the project. This one has gotten all over the place...

**LEDave** · - 13th July 2010, 16:00

You will get it.. Plenty of resources here.

Would be go if I could. Like I said when I first joined the Forum: I may not be that brightest but I am a trier

But you may want to start a new thread specific to the project. This one has gotten all over the place...

Fair comment mackrackit. I'll do my background research into rf and try and pick up as much as I can then later in the year I'll start a 'Project Specific' thread.

In the meantime what next here?

Dave

**mackrackit** · - 13th July 2010, 16:12

Originally Posted by LEDave

Would be go if I could. Like I said when I first joined the Forum: I may not be that brightest but I am a trier

Same here, I just add more voltage though...

In the meantime what next here?

While you are getting the RF modules figured out you could start on the project using wires.
Then all you will have to do is add the RF stuff later on.

**LEDave** · - 13th July 2010, 16:22

While you are getting the RF modules figured out you could start on the project using wires.Then all you will have to do is add the RF stuff later on.

Good shout, I like it and I'm on it Boss

I'm thinking two 16F684's SEROUT from one into SERIN on the other to LCD / or Communicator. With a push_button on SEROUT PIC to simulate the beam at this stage with an LDR / potential divider to trigger the 'SEND DATA' at night fall.

How does that sound?

Dave

**mackrackit** · - 13th July 2010, 16:45

SEROUT is very limited.

Use SEROUT2/SERIN2 .
Then when you get a PIC with hardware serial the syntax will be the same.

**LEDave** · - 13th July 2010, 16:57

Use SEROUT2/SERIN2 . Then when you get a PIC with hardware serial the syntax will be the same.

SERIN / OUT2 it is. Cheers mackrackit.

I nearly missed that one

Same here, I just add more voltage though...

Dave

**LEDave** · - 14th July 2010, 23:21

I've been GQQGLING around looking for rfpic info and on several sites I've found articles from people all saying that the rfpic battery had gone flat after only about a week.Has anyone here found this to be the case?

I guess for the project the rfpic will need to be in sleep mode as much as possible to save the battery power.

Dave

**LEDave** · - 25th July 2010, 19:10

Quick question:

When does an INPUT voltage level on a pin become an INPUT? What I'm clumsily trying to say is that when I use my potential divider (fixed resistor and an LDR) the voltage level will gradually rise until the PIC reads that voltage as a logic 1, will that be exactly five volts or less?

Dave

**mackrackit** · - 25th July 2010, 19:26

If you are still using the 684 take a look at table 15.5 in the data sheet.
There are two types of inputs, schmit and TTL. One is 0.8 and the other is 2.

How is everything going with the project?

**LEDave** · - 25th July 2010, 20:02

Hi mackrackit,

If you are still using the 684 take a look at table 15.5 in the data sheet.
There are two types of inputs, schmit and TTL. One is 0.8 and the other is 2.

Yes still on the 684, I'll have a read of the data sheet tonight.

The Project is coming along, I love these PIC's and what they can do (still frustrated at what I can't do mind

) When you start a project it's amazing where things lead and what has to be taken into account, example:

The parent birds fly into the box bringing in food and each time they do so they break the beam and a counter (divide by two as we said earlier) gets incremented. Then as night falls the voltage level on the P0T_Divider rises and when it's dark a pin reads voltage 1 and that days data gets rfpic'ed across. However simple little things to consider, how dark is dark? Is a passing cloud 'dark' enough to make the data be sent prematurely etc...? Things like that.

I've been spending time analysing Bruce's rfpic program to try and figure out just what is going on and how it all works. Plus I've been dabbling with some basic assembler...oh dear

It's a good job I've got until next Spring to get this up and running

Also learning to program is a great thing to go over the Winter Months too.

So, slow progress, still loving it.

Dave

**LEDave** · - 27th July 2010, 15:12

I'm probably way of beam here but when I read the data sheet for the 684 and then read about the 'Schmitt Trigger' it seemed to me that this worked on a pre defined voltage level (the voltage can vary up to the set value). Maybe this could be the way to ensure that any data sent only gets sent at a 'set' light / voltage level.

Am I reading this right?

I know I could also just use the potential divider set to a voltage / light level and even add in a time delay routine (say an hour) to make sure the data only gets sent once and when it is dark.

Interesting though.

Dave

**mackrackit** · - 28th July 2010, 00:11

I hope this makes sense..

At around 5 vdd.

A TTL input pin will go "HIGH" around 1.1 volts. 1.1 volts is the ON?OFF threshold.

A Schmitt input will go "HIGH" around 3 volts but stay high until it drops below 1.6 or so.

Your meter may vary a bit. Mine does

Personally in an application I will not call an input high before 3.6 volts and LOW has to be 1.5 or less. This is dealing with limit switches and such. Basically I figure it is either on or off, Dirty contacts, bouncy switches and such adds to the problem.

If I need to split hairs (volts) I do not like to rely on TTL or ST for the threshold. I set up an ADC.

**LEDave** · - 28th July 2010, 11:08

Interesting,

If I need to split hairs (volts) I do not like to rely on TTL or ST for the threshold. I set up an ADC.

Well I've never done ADC, it does look an ideal application for the project and new learning for me.

When you have some spare time (spare time, as rare as hen's teeth he says) could we do some ADC stuff? No rush, as and when, as ever.

Dave

**mackrackit** · - 28th July 2010, 11:27

When you have some spare time (spare time, as rare as hen's teeth he says) could we do some ADC stuff?

Sure, I have been planning to write some some basic ADC stuff for the wiki so I will use the 684 as one of the example chips.

But in the mean time you can not beat this foe an explanation. Different chip but most still applies.
http://rentron.com/PIC12C67XAD.htm

**LEDave** · - 28th July 2010, 12:20

Sure, I have been planning to write some some basic ADC stuff for the wiki so I will use the 684 as one of the example chips.

Brilliant

I've had a quick look at the link, looks very good. I'll have a read / study this evening and try and get a grasp of what's going on.

Thanks for that mackrackit.

Dave

**mackrackit** · - 29th July 2010, 23:04

I am feeling lazy so I will do an article later. For now here is some stuff to play with. I found that I am out of 684s so I did this with a 676. Should work with the 684.

For now we will look at 8 bit ADC. Using 8 bit the signal is divided into 256 steps, 0 - 255.
The ADC will return 0 - 255. If you use this to read a voltage and you are using 5 volts for the VDD/reference, 1 volt will return 51, 2 volts will return 102, 3 volts.....

You will not find this way of doing the ADC in the manual, but if you follow along with the data sheet you will see what is happening with the registers.

I wrote the examples for the PicKit1 test board. Using the on-board POT and LEDs.
Example #1

Code:

'FL PIC16F676                                                                                                    
'16F676 ADC ON PICKIT_1   
  DEFINE OSC 4
  @ __config _INTRC_OSC_NOCLKOUT &amp; _WDT_ON &amp; _MCLRE_OFF &amp; _CP_OFF     
  ANSEL = %00000001 'CHANNEL AN0  
  ADCON1 = %00010000 'FOSC/8 
  TRISA = %00000001 
  CMCON = %00000111
  CHAN0  VAR BYTE   'VAR TO HOLD ADC0 READING 
    
    CHECK: 
    GOSUB ADC_0 
    IF CHAN0 > 128 THEN   
    GOSUB BLINK 
    ELSE   
    PORTA = %00000000 
    ENDIF   
    GOTO CHECK 
           
    BLINK:  
    D0_HIGH: 
    TRISA = %11001111
    PORTA = %00010000
    PAUSE 500
    D1_HIGH: 
    TRISA = %11001111
    PORTA = %00100000
    PAUSE 500
    D2_HIGH: 
    TRISA = %11101011
    PORTA = %00010000
    PAUSE 500
    D3_HIGH: 
    TRISA = %11101011 
    PORTA = %00000100 
    PAUSE 500   
    RETURN 
    
    ADC_0:       'READ AN0  
    ADCON0 = %00000001      'TURNS ADC ON, SET FOR 8 BIT  
    GOSUB   READ_AD
    CHAN0 = ADRESH   
    RETURN

    READ_AD:   'DOES THE ADC CONVERSION 
    PAUSE 50  
    ADCON0.1=1  
    WHILE ADCON0.1=1:WEND  
    RETURN

Example #2

Code:

'FL PIC16F676               
'16F676 ADC ON PICKIT_1  WITH CASE SELECT 
  DEFINE OSC 4
  @ __config _INTRC_OSC_NOCLKOUT &amp; _WDT_ON &amp; _MCLRE_OFF &amp; _CP_OFF 
  ANSEL = %00000001 'CHANNEL AN0 
  ADCON1 = %00010000 'FOSC/8
  TRISA = %00000001
  CMCON = %00000111
  CHAN0  VAR BYTE   'VAR TO HOLD ADC0 READING

    CHECK:
    GOSUB ADC_0 
    GOSUB BLINK       
    GOTO CHECK  

    BLINK:
    SELECT CASE CHAN0  
           CASE IS > 254    
                TRISA = %11001111 
                PORTA = %00010000  
           CASE IS > 192  
                TRISA = %11001111 
                PORTA = %00100000 
           CASE IS > 128  
                TRISA = %11101011 
                PORTA = %00010000 
           CASE IS > 64  
                TRISA = %11101011 
                PORTA = %00000100 
           CASE ELSE 
                PORTA = %00000000 
    END SELECT 
    RETURN

    ADC_0:       'READ AN0
    ADCON0 = %00000001      'TURNS ADC ON, SET FOR 8 BIT
    GOSUB   READ_AD
    CHAN0 = ADRESH
    RETURN

    READ_AD:   'DOES THE ADC CONVERSION
    PAUSE 50
    ADCON0.1=1
    WHILE ADCON0.1=1:WEND
    RETURN

**LEDave** · - 29th July 2010, 23:59

Hi mackrackit,

Thanks for your post and program.

Right then. I need to print off your program and the relevant parts of the 684 data sheet and work it through.

Very interesting stuff this, let me see how far I can get and see how much I can figure out before I ask my first question.

Dave

**mackrackit** · - 1st August 2010, 09:13

Hey Dave,
Did my code work on your PicKit1 board?
I did find a couple 684s in the bottom of a drawer. Once the pins were straightned out they worked in the test board. But I had to program them with a PicKit2 The PicKit1 kept giving an error?

**LEDave** · - 1st August 2010, 19:18

Hi mackrackit,

Sorry for the late reply, Sunday is 'family' day

(say no more!).

Did my code work on your PicKit1 board?
I did find a couple 684s in the bottom of a drawer. Once the pins were straightned out they worked in the test board. But I had to program them with a PicKit2 The PicKit1 kept giving an error?

I had some errors on Compiling the first program, so had a hunt around looking for Configuration_Fuse info (found this page:http://www.picbasic.co.uk/forum/showthread.php?t=543)

So changed your code to this for the 684:

Code:

 DEFINE OSC 4

CMCON0 - from CMON
 
  @DEVICE_INTRC_OSC_NOCLKOUT 
  @DEVICE_WDT_ON
  @DEVICE_MCLRE_OFF 
  @DEVICE_CP_OFF

The program compiled and ran a treat. What happens is that when a Voltage of 2.5V appears on PORTA.0 (pin13 on the 684) the LED's on D0-D3 light in turn on after the other. If the Voltage drops below 2.5V they turn off. How does that sound.

Dave

**mackrackit** · - 1st August 2010, 19:36

Yup, family come first!!!

I use MPASM in place of PM for the assembler. If you are using Micro Code Studio you can change that in compiler options. PM is OK though, until you get to using 18F parts.

Yes, on the first code the analog break point is at the halfway point.
When you get a chance to run the second code you will see how it is split even more. Lots of things can be done with this, like the code shows, one input can effectively become many, sort of.

Now take all this back to the LDR thing and you can have light, dark, and options for something in between.

**LEDave** · - 1st August 2010, 19:46

For the second program I made the same Config changes, the program worked a treat two:

When the pot is turned LED D3 lights at approx:1.25V (pin13), D2 lights at 2.5V (D3 goes out). At 3.75V D1 lights (D2 goes out). And at 4.95V D0 lights up and D1 goes out.

I must say mackrackit, this is very clever stuff.

I'm thinking for the project, the LDR set against a pre-defined ADC voltage trigger level would be spot on to send the data at a set light night time light level.

I'm still doing loads of reading / studying, I've got a few things I'm not sure of so may have to get back to you on those, bear with me.

Dave

**LEDave** · - 1st August 2010, 19:54

Ah, I see you posted while I was still composing.....

Now take all this back to the LDR thing and you can have light, dark, and options for something in between.

Yes this would work a dream.

I think this project will contain nearly everything we've covered so far in one program

RF.ADC,SEROUT2,EEPROM data storage, Serial Communicator - LCD......!

Loving it: Dave

**mackrackit** · - 1st August 2010, 20:11

I'm still doing loads of reading / studying, I've got a few things I'm not sure of so may have to get back to you on those, bear with me.

No problem. If only all students worked as hard as you have...

I think this project will contain nearly everything we've covered so far in one program RF.ADC,SEROUT2,EEPROM data storage, Serial Communicator - LCD......!

And all since February... COOL!!!!

**LEDave** · - 1st August 2010, 22:13

No problem. If only all students worked as hard as you have...

Like I said way back when mackrackit, I'm not naturally bright but I am a trier....

And all since February... COOL!!!!

Yes it's amazing really. As we all know I couldn't blink an LED when I first came here...! As much to do with the Teacher as the pupil me thinks / knows...!

Dave

**mackrackit** · - 2nd August 2010, 21:04

Hey Dave..

What happens if the order of CASE IS is switched around? Why?

Code:

 SELECT CASE CHAN0  
           CASE IS > 254    
                TRISA = %11001111 
                PORTA = %00010000  
           CASE IS > 192  
                TRISA = %11001111 
                PORTA = %00100000 
           CASE IS > 128  
                TRISA = %11101011 
                PORTA = %00010000 
           CASE IS > 64  
                TRISA = %11101011 
                PORTA = %00000100 
           CASE ELSE 
                PORTA = %00000000 
    END SELECT

**LEDave** · - 3rd August 2010, 01:30

Hi mackrackit,

I changed the program SELECT CASE to this:

Code:

SELECT CASE CHAN0  
           CASE IS > 192  
                TRISA = %11001111 
                PORTA = %00100000
           CASE IS > 254    
                TRISA = %11001111 
                PORTA = %00010000       
           CASE IS > 128  
                TRISA = %11101011 
                PORTA = %00010000 
           CASE IS > 64  
                TRISA = %11101011 
                PORTA = %00000100 
           CASE ELSE 
                PORTA = %00000000 
    END SELECT

With this D0 didn't light, D1 lit at 5V, D2 at 3.65V, D3 at 2.45V. Mmm.

So your question was:

What happens if the order of CASE IS is switched around? Why?

My answer is: I don't know for sure

But, is it because for an 8bit ADC the conversion started at 192 (not 255 2_to_the_power_eight) therefore 192 became 5V. 255 would then be greater than the 5V supply reference voltage so wouldn't be read and was missed out. The other readings were all lower so were all calculated and there LED's lit.

I'm suspecting I'm North of the North pole.......Again

Dave

**mackrackit** · - 3rd August 2010, 02:41

I'm suspecting I'm North of the North pole

Then you are heading South.... Maybe.

The ADC creates a moving target. Try hard coding the value for "CHAN0".
Then.
Try reversing the values from the original but use < with the ADC active.

**LEDave** · - 3rd August 2010, 17:57

Hi mackrackit,

I could be going North again..........

Try hard coding the value for "CHAN0".

From your second example:

Code:

CHAN0 = ADRESH

To my understanding ADRESH_high_byte contains the value of the ADC conversion, so to hard code the value for CHAN0 it would simply be: CHAN0=%10101010 as an example, is this right?

I think I'm confusing myself here (correction I am confusing myself here...lol) But from your examples if we're doing an 8 bit ADC I thought we would be using ADRESL_low_byte and ADRESH&L for a 10 bit conversion (8+2) or does using ADRESH make the conversion more accurate?

Dave

**mackrackit** · - 3rd August 2010, 18:20

CHAN0 = 193
Would also work.

Take a look at this from the data sheet.
Name: ADRESH.jpg
Views: 572
Size: 38.0 KB

When using 8 bit ADC we are after the MSB from ADRESH.
If we want 10 bit ADC we would grab a couple extra bits from ADRESL.

So you are on the right track.

Here is a snippet from something doing 10 bit.
TC is a WORD size VAR

Code:

getT2:
	ADCON0= %00000101   '$5  '%00000101 AN1
ADCON2.7 = 1
	gosub getAD
	TC.highbyte = ADRESH
	TC.lowbyte = ADRESL
	return

getAD:
	pause 50
	WHILE ADCON0.1=1:WEND 
	return

**LEDave** · - 3rd August 2010, 18:41

When using 8 bit ADC we are after the MSB from ADRESH.
If we want 10 bit ADC we would grab a couple extra bits from ADRESL.

Ok..... Heading South again (albeit walking backwards...

)

Then.Try reversing the values from the original but use < with the ADC active.

I'll do this when I get back in later tonight (I'm off keyboard playing).......ah.

Dave

**LEDave** · - 4th August 2010, 00:37

Hi mackrackit,

Try hard coding the value for "CHAN0".

With CHAN0 = ADRESH all LED's lit in sequence.
With CHAN0 = 255 D0 lits.
With CHAN0 = 193 D1 lits.
with CHAN0 = 129 D2 lits.
with CHAN0 = 65 D3 lits.

So using greater than> the sequence still followed!

Try reversing the values from the original but use < with the ADC active.

Then using <than and ADRESH D0 lit.
With CHAN0 = 253 D0 lit.
With CHAN0 = 191 D0 lit.
With CHAN0 = 127 D0 lit.
With CHAN0 = 63 D0 lit.

So using less <than only D0 lit! across all settings. I wasn't expecting that I must admit, I thought it would work the same as > only in reverse.

mackrackit,is the reason only led0 lights because the ADC isn't using the MSB's when doing the conversion, or something like that. Or have I simply made a mistake here.

Dave

**mackrackit** · - 4th August 2010, 11:44

Think of SELECT CASE as a series of IF/THENS.
The first time a condition is met the code jumps to END SELECT.

If a "random" value is being tested IF/THEN is probably the better option.
In the example we have been working with when the value is predictable SELECT CASE is nice.
But that also means the order that SELECT CASE uses matches the "predictable" value.

Give this a shot

Code:

SELECT CASE CHAN0
           CASE IS < 64  
                TRISA = %11001111   'D0  
                PORTA = %00010000
           CASE IS < 128  
                TRISA = %11001111   'D1  
                PORTA = %00100000
           CASE IS < 192  
                TRISA = %11101011   'D2  
                PORTA = %00010000
           CASE IS < 254  
                TRISA = %11101011   'D3 
                PORTA = %00000100
           CASE ELSE
                PORTA = %00000000
    END SELECT

BTW. I will have limited to none internet till Monday so I may not be around here much in the mean time.

Have fun!!!

**LEDave** · - 4th August 2010, 13:54

Give this a shot

Yep, spot on.

BTW. I will have limited to none internet till Monday so I may not be around here much in the mean time.

Ok. Watch out for IWS though (Internet_withdrawl_Syndrom).It starts after about three hours with me, symptoms:Anxiety(have I any emails?)...This news paper isn't in PDF format(worse still it's non tech related)....etc. If left untreated this is a serious condition, only known cures:WIFI mobile phone or a broadband connection, so check you route!

Have fun!!!

You too, plenty of reading for me on ADC over the next few days.

Dave

**LEDave** · - 10th August 2010, 20:25

I bet you thought I'd left the Country the time this one has taken me. I must admit I really confused myself at times and went around in circles a little (ok, a lot).

Anyway I think I've managed to convert mackrackit's 8bit ADC to a 10bit for the 16F684. I would be very interested to hear how I've done on this one. Seems to work, or have I just 'lucked in'?

Code:

DEFINE OSC 4
  
  @DEVICE_INTRC_OSC_NOCLKOUT
  @DEVICE_WDT_ON 
  @DEVICE_MCLRE_OFF
  @DEVICE_CP_OFF 
  
  ANSEL = %00000001 'CHANNEL AN0 
  ADCON1 = %01010000 'FOSC/16
  TRISA = %00000001  'AN0_Input Pin
  CMCON0 = %00000111 'COMPARATORS OFF. 
  CHAN0  VAR word   'VAR TO HOLD ADC0N READING (10-BIT)

    CHECK:
    GOSUB ADC_0 
    GOSUB BLINK       
    GOTO CHECK  
    
    BLINK:
    SELECT CASE CHAN0  
           
           CASE IS > 64    
                TRISA = %11001111 
                PORTA = %00010000       
           CASE ELSE 
                PORTA = %00000000 
    END SELECT 
    RETURN

    ADC_0:       'READ AN0
    ADCON0 = %10000001      'BIT0=ADC ENABLE: BIT1=A/D CONVERSION STATUS BIT
                            'BITS2-4=AN0 CHANNEL SELECT BIT(CHS0): ADFM BIT1= right justified
    GOSUB   READ_AD
    CHAN0.highbyte = ADRESH  'A/D HIGHBYTE
    CHAN0.LOWBYTE  = ADRESL  'A/D LOWBYTE
    RETURN

    READ_AD:   'START THE ADC CONVERSION
    PAUSE 50
    ADCON0.1=1 '1 = A/D conversion cycle in progress.
               'Setting this bit starts an A/D conversion cycle.
    WHILE ADCON0.1=1:WEND 'Do WHILE condition is TRUE (I like WEND!).
    RETURN

Dave

**mackrackit** · - 11th August 2010, 03:34

(I like WEND!)

Looks like you got it!!!

Now change the select case to use the ten bit values. 0 to 1023.
And for you project you may want to play with some averaging. Analog will tend to drift with a temperature flux (resistors) or more so for your application how sensitive you want the LDR (stray car lights?).

**LEDave** · - 11th August 2010, 10:54

I changed the value to 1022 and the led lit and occasionally flicked off then back on, so right at the end of the 10bit conversion / pot sensitivity. At a value of 1 the led lit with some pot 'travel' still left. So pretty spot on I'd say:

And for you project you may want to play with some averaging. Analog will tend to drift with a temperature flux (resistors) or more so for your application how sensitive you want the LDR (stray car lights?).

Mmm, interesting. I want to transmit the data (days total count) when it's dark and the parents have stopped feeding the young for the day. Like you say though, I don't want say the garden PIR light (when the Badger arrives) to effect things so some averaging and tweaking / testing needed here.

As ever a big thank you for the 8bit ADC program pointer mackrackit. When it came to doing the 10bit conversion I've learned a lot about setting REGISTER bits, I'm still painfully slow but I guess that will improve with time / practise really interesting learning though.

Code:

ADFM BIT1= right justified

Just spotted that this should read ADFM BIT7=1= right justified

And as for WEND, I suppose elegant would be the word.

Dave

**mackrackit** · - 11th August 2010, 11:56

Just spotted that this should read ADFM BIT7=1= right justified

But your code was correct....

Have you done a FOR/NEXT loop yet?
Here is a snip from an 8 bit averaging. Pretty simple. Some like to throw out the first and last readings and only use the middle values. I guess it depends on the app..

Code:

GET_T:
  ADC_TEMP = 0
  FOR X_TEMP = 1 TO 20
  ADCON0=00000001
  GOSUB READ_AD
  S_TEMP = ADRESH
  ADC_TEMP = ADC_TEMP + S_TEMP
  PAUSE 250
  NEXT X_TEMP
  OUT_TEMP = ADC_TEMP / 20

Thread: 12f675_fuse_about_to_blow!

Thread Tools

Search Thread

Display

Members who have read this thread : 0

Bookmarks

Bookmarks

Posting Permissions