12f675_fuse_about_to_blow!

[LEDave]

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]

Hey Dave..

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

 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]

Hi mackrackit,

I changed the program SELECT CASE to this:

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]

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]

Hi mackrackit,

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

Try hard coding the value for "CHAN0".

From your second example:

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]

CHAN0 = 193
Would also work.

Take a look at this from the data sheet.

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

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]

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