Thank you, that might be.. Actually I tested it again and appears I was not exact. When device starts everything is ok. Then Linux app opens "/dev/serial/by-id/mydevice" (which with lsof somehow shows that /dev/ttyACM0 was opened instead) and sends few bytes: "t 6\n\r", device sends back some data starting with 0xCE, but my application does not receive it, instead some from some unknown place I see that cdc-acm itself in response to device data sends like this:
0x5e 0x43 0x5e 0x42 0x33 0xFF 0xD3 0x5E 0x45 0x31 0x53 0x38 0x30 0x40 0x59 0x25 0x43, then 4 first bytes that device sent and 0x5E 0x41 0x5E 0x40 0x5E 0x40 - repeats few times 0x5e 0x40 then lot of 0x08 0x20.. Which looks like ^C^B3 0xFF 0xD3 ^E1S80@Y%C does not make sense to me.. Checked udev, shat down ifplugd and dbus-daemon, no effect. On Dec 2, 2014, at 7:02 AM, Matthias Urlichs <matth...@urlichs.de> wrote: > Hi, > > Dmitriy Fitisov: >>> lsof /dev/ttyACM0 >> >> That I also tried last week. Nothing is open. > > The next target of interest would be udev. > Which rules fire, and do they start anything? > (udevadmin monitor …) > > -- > -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/d6d9c13d-ce60-4b4b-a443-1044926b9...@radier.ca
