I am using a pic16f690 on right justified counting upto 500 and displaying on a seven seg 3 digit, hundreds , tens , units , it works perfect from zero to 255, incrementing and rollover from 9 to 0, then it goes stupid,

at 256 the display shows 306, and continues to count up incrementing the units by one then the tens increment every rollover from 9 to 0 on the units, but the tens count upto 6 then increments the hundreds, then at 512 it goes back to normal again.

The part upto Check_256 works no problem, after it goes to over 255 it then goes daft, and then back to normal counting at 512

WHAT the hell is going wrong?
! am using left justified, and using the ADRESL file to get my input value.
is there some thing in the ADRESH file that is causing it to add 50 to the tens?

or is there a reason it wants to add 50?

 

I am using a pic16f690 on right justified counting upto 500 and displaying on a seven seg 3 digit, hundreds , tens , units , it works perfect from zero to 255, incrementing and rollover from 9 to 0, then it goes stupid,

at 256 the display shows 306, and continues to count up incrementing the units by one then the tens increment every rollover from 9 to 0 on the units, but the tens count upto 6 then increments the hundreds, then at 512 it goes back to normal again.

WHAT the hell is going wrong?
! am using left justified, and using the RESULTLO file to get my input value.
is there some thing in the RESULTHI file that is causing it to add 50 to the tens?

or is there a reason it wants to add 50?

i can add the asm file if you need it

First, is it left or right? If you are only using 8 bits, left justify and use ADRESH as your converted value. If using the full 10, right justify and use ADRESH:ADRESL as a 16 bit value.

Other than that, it looks like your binary ADC result ->BCD->7seg decoder routines are not properly converting more than 8 bits. EDIT: duh. But its a common problem depending on what method you are using for the conversion.. I guess that's what I was getting at.

The attached file has a BIN->BCD routine that works with up to 5 digits. 16 bit binary in, 5 packed BCD digits out. See how it compares to yours.

Have fun!

EDIT: Its always good to post your code from the get-go.

 

The part upto Check_256 works no problem, after it goes to over 255 it then goes daft, and then back to normal counting at 512

Maybe here. Your construct only checks the LSbit, not the 2 LSbits it should..

Check_256    
     
    btfss RESULTHI,0     ; is it over 255C ?
    return              ; no
;******** Should be ***
  movf RESULTHI,F ; check entire register for zero
  btfsc STATUS,Z   ; skip on NZ
  return
 ..

is there some thing in the ADRESH file that is causing it to add 50 to the tens?
or is there a reason it wants to add 50?

; yes do routine of adding extra 256C    
    movlw .2
    movwf huns          ; temp files for adding 2H, 5T, 6U , to extra temperature value
    movlw .5
    movwf tens
    movlw .6 
    movwf units

I haven't really run through your conversion arithmetic but aren't you adding 5*10 when you do this?

Some style issues:
Avoid $+x constructs, use labels. Its easier to read and less prone to error. More portable too..
Use a colon after the label - its way easier to read and identify i.e.
Label:
movf ...
What is movfw? built-in macro that does movf reg,W?

Consider putting your multiplexing routine in a periodic interrupt. Compute the segment patterns in the main program and store them where the interrupt routine can find them. Change digit patterns one per interrupt. It will make a better looking display.

Sorry I don't have more time to look at the whole thing.. these just jumped out.

Good luck!

 

Even if i put zero in the #256# files its the same, it always wants to add 50, and rolls the hundreds over at 60 tens. Also its an 8 bit register so i dont understand where 16 bit Bin to Bcd is going to help me?

 

Even if i put zero in the #256# files its the same, it always wants to add 50, and rolls the hundreds over at 60 tens. Also its an 8 bit register so i dont understand where 16 bit Bin to Bcd is going to help me?

The total ADC result is 10 bits. You can not squeeze a 10 bit result into a 8 bit register. So the full ADC result need to use two registers. That is why you need a 16 bit BIN to BCD function to decode the full ADC result. Over the full ADC range the ADRESL register will roll over four times

 

i know the result is split into 8 &2bits, i am using the lower 8 bits for counting, but cant get it to count over 255?

 

Huh...2^8=255. And what do you mean by this

i am using the lower 8 bits for counting, but cant get it to count over 255?

The ADC result registers has nothing to do with counter functions

 

i want to continue counting upto 500, but cant get any way to add the other 255 from start, so my counter stops at 255, have you got any way of counting from 256 upto 500 by adding the other 255 first then continue upto 500, that is what i am trying to get, but for some reason the counter jumps from 255 then goes to 306, 307, 308, etc???

 

I have a feeling you may have misunderstood the basics of ADC conversions in PICs. Then you start an ADC cycle in a PIC. You wait to the conversion flag say the conversion is done, and read the result. In the time between ADC start and and. I am not sure what the register content in ADRESL and ADRESH will be. But I would in any way consider it garbage. The result in the ADRESL and ADRESH registers are often referred to as number of counts. And perhaps it has been some misunderstanding from your side here.
Take a look at this link. I think section 1 and 2 may clear things for you
http://www.analog.com/library/analogDialogue/archives/39-06/data_conversion_handbook.html

 

Right lets start again, i am getting the result from the A2D in two files Adresh and Adresl, i am using right justified so i am looking at the lower 8 bits to get my value 0 to 255 in adresl, when it overflows adresh gets a 1 in bit0, the result in adresl is divided into 3files Huns Tens units. How do i add 2 to huns, 5 to tens, 6 to units, so my counter continues to count up? Have you got that!

 

Ri Have you got that!

No need to be nippy here. JohnInTX posted some assembler routines that will do the job. Many postings ago. So the problem is more that you refuse to take our advice. That is your problem not my. But you are free to have it your way anyway

 

if you have a solution then give it me, or show me how its done, i just want to get it cracked .