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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
http://lists.puredata.info/listinfo/pd-dev
_______________________________________________
Pd-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
