[PD-dev] comport and arduino stalls

Tue Sep 29 22:50:53 CEST 2009

Hey Hans,

After it was working for 24 hours at home, it bailed again the next day.

Indeed it turns out to me a usb disconnect:

Sep 29 11:17:16 micro kernel: [  438.172628] usb 1-10: USB disconnect,
address 4
Sep 29 11:17:16 micro kernel: [  438.359266] usb 1-9: USB disconnect,
address 3
Sep 29 11:30:27 micro -- MARK --
Sep 29 11:44:56 micro kernel: [ 2099.167777] usb 1-3: USB disconnect,
address 2
Sep 29 11:44:56 micro kernel: [ 2099.168822] ftdi_sio 1-3:1.0: device
disconnected
Sep 29 11:44:56 micro kernel: [ 2099.345225] usb 1-3: new full speed USB
device using ohci_hcd and address 5
Sep 29 11:44:56 micro kernel: [ 2099.557819] usb 1-3: configuration #1
chosen from 1 choice
Sep 29 11:44:56 micro kernel: [ 2099.560815] ftdi_sio 1-3:1.0: FTDI USB
Serial Device converter detected
Sep 29 11:44:56 micro kernel: [ 2099.560840] ftdi_sio: Detected FT232BM
Sep 29 11:44:56 micro kernel: [ 2099.560869] usb 1-3: FTDI USB Serial
Device converter now attached to ttyUSB1
Sep 29 11:44:56 micro kernel: [ 2099.564489] usb 1-3: New USB device
found, idVendor=0403, idProduct=6001
Sep 29 11:44:56 micro kernel: [ 2099.564489] usb 1-3: New USB device
strings: Mfr=1, Product=2, SerialNumber=0
Sep 29 11:44:56 micro kernel: [ 2099.564489] usb 1-3: Product: USB <->
Serial
Sep 29 11:44:56 micro kernel: [ 2099.564489] usb 1-3: Manufacturer: FTDI

Seems once it disconnected then it reconnects as a different device
name. No surprise that comport is freezing.

I heard people have been trouble with ehci, so I tried disabling ehci
and switching to ohci and disabling usb2.0 in the bios. All I have tried
leads to an eventual freeze. Remember there is no circuit attached to
the arduino in my testing.

The school has USB (not clear which one, mine is a first generation) and
Diecimila boards. I'll borrow a couple and see if they show the same
behaviour.

Also this appears to only happen on one machine, so I'm thinking its
unlikely to be the arduino board itself.

I spoke to one of the arduino guys around here who said he did have
trouble with the USB board in Max when receiving lots of data.

No one else has had trouble reading analog inputs under linux for long
periods?

Thanks,
B.

Hans-Christoph Steiner wrote:
> 
> 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/
> 
> 
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
> 