[PD-dev] comport and arduino stalls

[Hans-Christoph Steiner]

Sounds like the USB/serial connection is getting reset, often caused  
by short circuits, brownouts, or overcurrent protection.  I think your  
problem is most likely in the circuit.

.hc

On Sep 12, 2009, at 1:01 PM, B. Bogart wrote:

> Hey all,
>
> I've been using the same version of comport in my installations (to
> control a pan/tilt unit) for some time. These have been stable for  
> weeks.
>
> Now I'm working on an arduino installation, and I've been unable to  
> make
> comport behave for more than a few hours.
>
> I'm using the original arduino USB w/ an ATMEGA8, with Firmata2.1
> "SimpleAnalogFirmata".
>
> And using the latest stable [arduino] object.
>
> The patch starts running normally, I see the TX light on the arduino
> stays solid.
>
> after running for a while, from 20min to hours, eventually PD will  
> stall
> (the patch is no longer responsive, no console messages),  and the TX
> light on the arduino will turn off.
>
> Often this sets off the watchdog, and PD starts using up lots of  
> memory
> (more the longer it's running).
>
> If I manually kill the pd process in GDB, here is the backtrace:
>
> Program received signal SIGINT, Interrupt.
> [Switching to Thread 0xf7c816b0 (LWP 21173)]
> 0x081025d0 in alist_list (x=0xa1a7884, s=0x8128fb0, argc=112220,
> argv=0xf365f008) at x_list.c:111
> 111	x_list.c: No such file or directory.
> 	in x_list.c
> (gdb) bt
> #0  0x081025d0 in alist_list (x=0xa1a7884, s=0x8128fb0, argc=112220,
> argv=0xf365f008) at x_list.c:111
> #1  0x080b232f in outlet_list (x=0xa1a7810, s=0x8128fb0, argc=112220,
> argv=0xf365f008) at m_obj.c:428
> #2  0x08101753 in list_append_list (x=0xa1a77d0, s=0x8128fb0,
> argc=112220, argv=0xf3b83008) at x_list.c:200
> #3  0x080b232f in outlet_list (x=0xa1a7948, s=0x8128fb0, argc=112220,
> argv=0xf3b83008) at m_obj.c:428
> #4  0x08101ce9 in list_prepend_list (x=0xa1a7908, s=0x0, argc=1,
> argv=0xff8353c4) at x_list.c:260
> #5  0x080af290 in pd_defaultfloat (x=0xf373b008, f=0) at m_class.c:73
> #6  0x080b2527 in outlet_float (x=0xa1a7610, f=0) at m_obj.c:394
> #7  0x080b2527 in outlet_float (x=0xa1a74d8, f=0) at m_obj.c:394
> #8  0x080f4f83 in trigger_list (x=0xa1a7480, s=0x0, argc=1,
> argv=0xff835464) at x_connective.c:979
> #9  0x080f50e7 in trigger_float (x=0xa1a7480, f=0) at x_connective.c: 
> 1025
> #10 0x080b2527 in outlet_float (x=0xa1a6168, f=0) at m_obj.c:394
> #11 0x080b2527 in outlet_float (x=0xa1a6018, f=0) at m_obj.c:394
> #12 0x080b2527 in outlet_float (x=0xa1949f8, f=0) at m_obj.c:394
> #13 0xf66af389 in comport_tick () from /usr/lib/pd/extra/ 
> comport.pd_linux
> #14 0x080bd7d4 in m_scheduler () at m_sched.c:357
> #15 0x080c0805 in sys_main (argc=3, argv=0xff835774) at s_main.c:318
> #16 0x080cc0df in main (argc=1, argv=0x0) at s_entry.c:31
>
> Which looks to me like comport is the culprit. A test of simulating  
> the
> comport output (when attached to arduino) replacing the comport in the
> arduino.pd patch is rock solid, so it does appear comport is the  
> problem.
>
> I'll keep doing some testing.
>
> I'm running debian lenny (stable) with a 2.6.26-1-amd64 kernel  
> (32bit).
>
> I've tried many different versions of comport from SVN, all seem to
> cause the same trouble.
>
> So what revision of comport is known to work stable (on linux) over  
> long
> periods of simple analog input from arduino?
>
> I'll keep testing, but wanted to see what people have already tested  
> and
> is known to work.
>
> Thanks,
> B. Bogart
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev



----------------------------------------------------------------------------

                                               http://at.or.at/hans/