Other Parts Discussed in Thread: MSP430G2452
Hi I write a code. But it didnt work. Led is burning and burning out not with range.
Where is the problem
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Other Parts Discussed in Thread: MSP430G2452
Hi I write a code. But it didnt work. Led is burning and burning out not with range.
Where is the problem
Selim Erkan Oguz said:it didnt solve the problem
I did not say it will solve the problem! :D
Your "problem" is that whole concept of delay/range measurement is wrong. Try to THINK what actually happens, how your code executes, how you measure delay - if measure at all.
It's really the most important part.Ilmars said:Try to THINK what actually happens
Selim Erkan Oguz said:P1OUT^=tr; //Trigger is on for 10 us__delay_cycles(10);P1OUT^=tr;if(P1IN&ec){range++; //when echo coming range is increasing}
Hi, the problem come from measuring time, internal processor or logic measure time from burst to echo then raise the echo line for a the time needed to travel the distance.
so your code can be questionable but if you reset both range and out can work... The worst is never wait the rising edge of echo so:
Selim Erkan Oguz said:#include "msp430g2452.h"#define tr BIT0#define ec BIT1#define led BIT6int range=0;void main( void ){WDTCTL = WDTPW + WDTHOLD; //watchdog stopDCOCTL=CALDCO_1MHZ; //frequency setupBCSCTL1=CALBC1_1MHZ;P1DIR = tr+led;P1OUT=0x00; //all are zerofor(;;){P1OUT^=tr; //Trigger is on for 10 us__delay_cycles(10);P1OUT^=tr;
Selim Erkan Oguz said:if(P1IN&ec)
range=0;
}
}
Questionable Wrong Suggested
Hi Jens also 50 is under range so it cannot be measured with a secure trigger, again we don't know which compiler is using and how much cycle are involved on loop, assuming a 3 cycle total delay can be near 150uS.. A better approach can be forever use capture channel with a more higher resolution, IMHO is more better use MSP to send burst then measure echo from transducers.
Sure. Generating the 'trigger' with a tiemr PWM output and at the same tiem capturing the start (and maybe even end) of the echo by two capture units will be the best way to get reliable, repeatable, jitter-free results. Even for small distances. And independently of any code runtime.Roberto Romano said:A better approach can be forever use capture channel with a more higher resolution,
**Attention** This is a public forum