Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

can anyone tell me whats wrong with this program

Status
Not open for further replies.
According to the datasheet.... (115uS) 8.6khz minimum distance.... (18.5mS) 58hz maximum distance..

So 80hz was just in then...

When simulated if I set the pulse to 8.6khz you receive a count of 12 not 36.

If I set the prescaler to 1:4, 8.6khz gives a count of 25 and 58hz yields 5421 (nearer the value you need)

The pulse output doesn't appear linear...

I bought this sensor https://proto-pic.co.uk/4-20ma-current-loop-ultrasonic-range-finder/ 4.20ma out... it was much easier to use..
 
According to the datasheet.... (115uS) 8.6khz minimum distance.... (18.5mS) 58hz maximum distance..

So 80hz was just in then...

When simulated if I set the pulse to 8.6khz you receive a count of 12 not 36.

If I set the prescaler to 1:4, 8.6khz gives a count of 25 and 58hz yields 5421 (nearer the value you need)

The pulse output doesn't appear linear...

I bought this sensor https://proto-pic.co.uk/4-20ma-current-loop-ultrasonic-range-finder/ 4.20ma out... it was much easier to use..

Output here "12" in cm is the distance value ? if so according to the datasheet the min distance is 2cm
 
Yes... But when I checked 8.6khz (115.uS / 200mm and a count of 25 )... and 58hz (18.5mS / 3000mm and a count of 5421 )

I assumed that 1.5M would be somewhere in the middle... a count of 2732 should be obtained... guess what only 98!!

Therefore the input is not linear. (WITH MY INPUT, the actual sensor may be different ).

As I cant simulate the sensor, you will have to just print out the TMR1 count at different lengths.
 
Yes... But when I checked 8.6khz (115.uS / 200mm and a count of 25 )... and 58hz (18.5mS / 3000mm and a count of 5421 )

I assumed that 1.5M would be somewhere in the middle... a count of 2732 should be obtained... guess what only 98!!


Therefore the input is not linear. (WITH MY INPUT, the actual sensor may be different ).

As I cant simulate the sensor, you will have to just print out the TMR1 count at different lengths.

but what i always get is a RB2 high and RB1 low output for whatever obstacle i keep no matter whatever distance

(sensor is in working condition as it shows distance in Atmega16 :confused: )
 
Can you please post your current code, with all the little changes made? It would help to see where you're at.
 
Code:
#include <htc.h>


__CONFIG(LVPDIS & BORDIS & PWRTEN & WDTDIS & HS);

#define _XTAL_FREQ 10000000    //10MHz xtal speed


  
unsigned int sensorRead()
{
  
	unsigned int SENSOR = 0;//variable used to combine two 8 bit variables into 1 16 bit variable

	TRISC2 = 0;    //RC2 output
	RC2 = 1;    //set RC2 high
  	__delay_us(5);    //for 5uS
 	RC2 = 0;   //RC2 low
  	__delay_us(200);     //200uS delay
  	TRISC2 = 1;    //RC2 input
  	TMR1H = 0;    //clear timer 1
  	TMR1L = 0;    
  	T1CON = 0b00110000;  //init timer 1

 	while(!RC2);    //wait until RC2 goes high via echo pulse
 	TMR1ON = 1;    //start timer 1
 	CCP1CON = 0x04;    //enable capture module, capture every falling edge of RC2/CCP1
 	while(!CCP1IF);    //wait for falling edge on RC2
 	CCP1CON = 0x00;    //CCP module off
 	CCP1IF = 0;    //clear CCP interrupt flag
 	TMR1ON = 0;    //stop timer 1


 	SENSOR = ((int)(CCPR1H) << 8)+ CCPR1L; // 1:8 prescaler ie 3.2uS so minimum value 115uS/3.2uS = 36 (approx)
  	return SENSOR;
}

void main(void)

{
	PORTB=0;         //clear portB
	TRISB=0;        //PORTB as output
	unsigned int my_Time;    //variable for storing the time to calculate distance
	unsigned int my_Distance;
	while(1) 
	{ 
		my_Time=sensorRead();
 
		__delay_ms(500);
  
		my_Distance= my_Time/58;

		if((my_Distance > 30) && (my_Distance < 50))  
		{
			RB4 = 1;
			RB5 = 0;
		}
		else 
		{
			RB4 = 0;
			RB5 = 1;
		}
	}
}
 
Why are you turning on the timer but only reading the CCP1 module? You're not reading the timer at all....?
 
sir the capture would read the timer1 value i guess

I haven't used the capture module, but are you sure it reads the timer? Have you read that part of the datasheet? That could make all the difference.
 
I notice that you stop the timer after you have the capture module read it. Perhaps you need to stop it before?

I'm actually hoping someone else who has experience with CCP1 can jump in here. I'm not really sure how it works....
 
I notice that you stop the timer after you have the capture module read it. Perhaps you need to stop it before?

I'm actually hoping someone else who has experience with CCP1 can jump in here. I'm not really sure how it works....

ohhh is it so ? even i am not sure about it
 
Last edited:
ohhh is it so ? even i am not sure about it

hi San,
In Oshonsoft, the hex file, shows the Ping Pulse and when the RC2 is clicked high for a short time, the CCP regs/Timer1 show a count, BUT the RB1 or RB2 never go high.

E.
 
In ISIS this program works ok... RB2 goes high when the distance is outside the values... and RB1 when its between 30 and 50.

CCP1 module functions as it should the timer counts ok.... its just not linear.... Like I said i don't have a sensor model... so it may work with a real device.

Even the new code swaps between RB4 / 5.
 
Last edited:
Exactly eric thats my problem too :(

hi San,
This is quick test program for your project.

Load the Ping1.hex into your 16F877A, it should display on PORTB, [CCPR1H] and on PORTD [CCPR1L] register contents. [NOT the actual range, there is no processing of the CCPR1 count]

The update/refresh Rate is 10/second

The Oshonsoft Basic is for reference ONLY, to show the sequence of the program.

Code:
PORTB = 0
TRISB = 0
PORTD = 0
TRISD = 0

main:
TRISC.2 = 0
PORTC.2 = 1
WaitUs 5
PORTC.2 = 0
WaitUs 750

TRISC.2 = 1

TMR1H = 0
TMR1L = 0
T1CON = 0x30

While PORTC.2 = 0
Wend

T1CON.TMR1ON = 1
CCP1CON = 0x04

While PIR1.CCP1IF = 0
Wend

CCP1CON = 0
PIR1.CCP1IF = 0
T1CON.TMR1ON = 0

PORTB = CCPR1H
PORTD = CCPR1L

WaitMs 100

Goto main
 
Last edited:
hi San,
This is quick test program for your project.

Load the Ping1.hex into your 16F877A, it should display on PORTB, [CCPR1H] and on PORTD [CCPR1L] register contents. [NOT the actual range, there is no processing of the CCPR1 count]

The update/refresh Rate is 10/second

The Oshonsoft Basic is for reference ONLY, to show the sequence of the program.

Code:
PORTB = 0
TRISB = 0
PORTD = 0
TRISD = 0

main:
TRISC.2 = 0
PORTC.2 = 1
WaitUs 5
PORTC.2 = 0
WaitUs 750

TRISC.2 = 1

TMR1H = 0
TMR1L = 0
T1CON = 0x30

While PORTC.2 = 0
Wend

T1CON.TMR1ON = 1
CCP1CON = 0x04

While PIR1.CCP1IF = 0
Wend

CCP1CON = 0
PIR1.CCP1IF = 0
T1CON.TMR1ON = 0

PORTB = CCPR1H
PORTD = CCPR1L

WaitMs 100

Goto main

Eric thatnks a lot will check it asap and come up with the results
Thanks again
 
hi San,
IIRC you said you used a JDM prommer.??

If the quick test program doesn't work, I would check out the JDM and your hardware for problems.

Some JDM's rely on the PC serial port providing the PGM voltage, some PC's and Laptops do not have a Serial output voltage sufficient to to provide the required PGM voltage
 
hi San,
IIRC you said you used a JDM prommer.??

If the quick test program doesn't work, I would check out the JDM and your hardware for problems.

Some JDM's rely on the PC serial port providing the PGM voltage, some PC's and Laptops do not have a Serial output voltage sufficient to to provide the required PGM voltage

hello Eric,

Even i had that doubt so i just made few test programs to check whether programmer is burning the PIC properly and yes it dose it work perfectly
Regarding the sensor well its working exceedingly well with ATMEGA 16 :confused:
but not with my PIC :(
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top