[PD-dev] comport and arduino stalls

[B. Bogart]

Hey Hans,

Actually my test system is not using a circut!!! That is I'm just
connecting the arduino to the USB port, and reading the noise of the A2D
for testing.

I started running a test this morning on a different USB port on the
machine, and so far that is not showing the same behaviour. I'll leave
it run overnight to make sure.

Seems there are some issues with one of my USB ports. I don't really get
why it works for a while, and I don't get any other errors! Actually
Hans, remember I was getting some weird "unknown command" errors from
[arduino] well, on this USB port I'm not getting them!!! Seems something
is wrong with some USB ports.

So for the archives, if anyone sees this kind of issue, try a different
USB port!

No idea how I would have messed em up. Now that I think of it I did see
some strange pan/tilt behaviour last installation of Dreaming Machine....

At least I can use the "unknown command" messages to test the USB ports
and mark em as unusable.

Anyone know if this kind of thing could be caused by a software glitch?
It's a shuttle SN27P2.

Thanks Hans,
.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/
> 
> 
>