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? 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. 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.
Martin On Tue, Oct 14, 2014 at 2:21 PM, Colet Patrice <[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]> > 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]> >> 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] >>> http://lists.puredata.info/listinfo/pd-dev >>> >> >> >> > >
_______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
