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
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@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
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@iem.at http://lists.puredata.info/listinfo/pd-dev
http://at.or.at/hans/
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@iem.at http://lists.puredata.info/listinfo/pd-dev
http://at.or.at/hans/
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-
B. Bogart -
Hans-Christoph Steiner