Le 14/10/2014 20:59, Martin Peach a écrit :
Ah I see...
In your code you're calling gettimeofday() repeatedly while the pulse is arriving. This will freeze Pd for the duration of the pulse. Maybe that's what causes the segfault?

That looks like a good explanation.

You could use a clock callback in Pd to check for the echo, but then your resolution is down to Pd's event loop period.

I've no clue if it's enough or not, for me the only way to be accurate is about using wall clock instead of cpu clock,

Alternatively start a new thread to measure the pulse and use a clock to check for the thread result. That way you'll get the most accurate time.

I don't know if I can do that, but will give a try by looking at other externals using threads.

thanks again

pc


Martin

On Tue, Oct 14, 2014 at 2:21 PM, Colet Patrice <colet.patrice@free.fr> wrote:
Le 14/10/2014 19:51, Martin Peach a écrit :
Oh sorry, I thought you were using an arduino.


 I'm using an emulated arduino, it's called pcduino and it's the most powerfull miniPC we can actually find.
PureData is running so fine on it even through ssh there is no latency like I've encountered on raspberry,
and Multitrack USB soundcards runs greatly on it.


Martin

On Tue, Oct 14, 2014 at 1:16 PM, Colet Patrice <colet.patrice@free.fr> wrote:
Le 14/10/2014 15:06, Martin Peach a écrit :
Not sure why it segfaults, just want to say that that method is really bad. Because of Pd's control rate as well as the serial interface latency, your timing will be really sketchy. The way to do what you want is to implement the ranging entirely on the arduino and send the values back to Pd via [comport]. So a Pd [pulseIn] object shoud simply send a request to the arduino to start a pulse and return the time. It could be implemented as an abstraction containing [comport].


 I'm not using serial to read gpio state but fopen() (may be fopen() is not fast enough), like in a raspberry (but it's not on raspberry), I will try to do this with python and use pdsend for retrieving value into puredata.
thank you for the advice.
pc


Martin

On Mon, Oct 13, 2014 at 9:29 PM, Colet Patrice <colet.patrice@free.fr> wrote:
Hello, I'm trying to implement the pulseIn() function we can find in arduino libraries into an external.

I couldn't make it work because some part doesn't seem to behave like I expect so I'm wondering if it's caused by puredata process,
so maybe someone in the list could enlight me about that.

The purpose of the external is about using an ultrasound sensor connected on gpio that require a microsecond timer for getting distance like this:


//here is a custom timer using a struct provided by pcduino headers:
#include core.h
unsigned long pat_micros() {
    struct timeval tv;
    gettimeofday(&tv,NULL);
    return tv.tv_sec*(uint64_t)1000000+tv.tv_usec;
}

//here is the custom pulseIn() function:
unsigned long pat_pulseIn(t_pdpcduino *x, int pin)
{
    unsigned long timeout = 100000;
    unsigned long start = pat_micros();

    while( pdpcduino_gpio_read2 (x, pin) == 1 )
        if( pat_micros() - start > timeout )
            return 0;

// this is where I'm getting a segmentation fault:

    while ( pdpcduino_gpio_read2 (x, pin) == 0 )
        if( pat_micros() - start > timeout )
        return 0;

//...
    unsigned long value = pat_micros();

    while( pdpcduino_gpio_read2 (x, pin) == 1 )
        if( pat_micros() - start > timeout )
            return 0;

    return pat_micros() - value;

}

//...


If I reduce the timeout number, segfault comes randomly after this function has been triggered, so I'm wondering if this method is really appropriate,
is there an exemple of external (containing such while loops) I could get inspired from to write this pulseIn() function?






_______________________________________________
Pd-dev mailing list
Pd-dev@lists.iem.at
http://lists.puredata.info/listinfo/pd-dev