[PD-dev] while loop segfault

Colet Patrice colet.patrice at free.fr
Tue Oct 14 20:21:28 CEST 2014


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 at free.fr 
> <mailto:colet.patrice at 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 at free.fr <mailto:colet.patrice at 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 at lists.iem.at <mailto:Pd-dev at lists.iem.at>
>>         http://lists.puredata.info/listinfo/pd-dev
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20141014/45d6dd1a/attachment.html>


More information about the Pd-dev mailing list