Thanks Johan!
TL;DR: I'm delighted to report that it *does* work with 4.12.0-rc7
Below I've tried to answer your questions best as I could, probably moot
now but it's the least I can do for wasting your time on something that
was already fixed. And if you think it could be useful, I'd be more
then happy to send you one of my little boards (for testing or
whatever), they're intended as an alternative for FTDI cables.
Cheers,
Zaerc.
On 2017-06-26 10:31, Johan Hovold wrote:
On Sun, Jun 25, 2017 at 08:44:02PM +0200, Zaerc wrote:
Hello everyone,
Sorry to bother you, I'll try to keep it brief. I am making an
USB-serial adapter using an Atmel (Microchip) ATMega16u2 with a LUFA
based firmware, which gives me a nice working ttyACM0 device.
However I am running into some trouble implementing DSR/DTR hardware
flow control. The DTR signal (output) can be set and cleared, no
problem there. The DSR signal (input) however does not seem to get
reported back eventhough with usbmon I can see the device sending it
to
the host.
Please provide the relevant bits from such a trace (e.g. an interrupt
message with some context).
I hope this is what you mean:
DSR ready (going low):
ffff98e6cfd6e900 435591757 C Ii:4:003:2 0:128 8 = a1200000 00000200
ffff98e6cfd6e900 435591786 S Ii:4:003:2 -115:128 8 <
ffff98e6cfd6e900 435623754 C Ii:4:003:2 0:128 2 = 0200
ffff98e6cfd6e900 435623776 S Ii:4:003:2 -115:128 8 <
DSR not ready (going high):
ffff98e6cfd6e900 444007755 C Ii:4:003:2 0:128 8 = a1200000 00000200
ffff98e6cfd6e900 444007778 S Ii:4:003:2 -115:128 8 <
ffff98e6cfd6e900 444039758 C Ii:4:003:2 0:128 2 = 0000
ffff98e6cfd6e900 444039779 S Ii:4:003:2 -115:128 8 <
I have mainly tested with gtkterm on a few different (more or less)
recent linux kernels. To add insult to injury (just kidding) it works
on windows (7 tested with RealTerm), so it seems my device should
behave
like it is supposed to. I have also tried it with a real serial port
(ttS0, DSR/DTR and RTS/CTS) and an FTDI cable (ttyUSB0, RTS/CTS only)
and gtkterm can see the signals just fine with those.
Which is the most recent kernel you've tried? Some changes in this area
went into 4.12 (adding support for fragmented notifications), but I
guess you haven't tried that yet?
The most recent version I tried (before sending this message) was the
current Debian Sid kernel:
Linux Behemoth 4.11.0-1-amd64 #1 SMP Debian 4.11.6-1 (2017-06-19) x86_64
GNU/Linux
And you guessed right, but after your reply I got off my lazy behind
(haven't had to compile my own for over a decade) and now I have tried:
Linux Behemoth 4.12.0-rc7 #1 SMP Tue Jun 27 00:37:46 CEST 2017 x86_64
GNU/Linux
With that gtkterm and sct (Serial Com Tester) do see the DSR line
changing, problem solved! I didn't reckon there was active development
going on in this area, which just goes to show: assumption is the mother
of all fsckups...
Also what is the lsusb -v output for your device?
zaerc@Behemoth:~$ lsusb -v
...
Bus 004 Device 002: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter
Project
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x03eb Atmel Corp.
idProduct 0x204b LUFA USB to Serial Adapter Project
bcdDevice 0.01
iManufacturer 1
iProduct 2
iSerial 220
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 62
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 0
CDC Header:
bcdCDC 1.10
CDC ACM:
bmCapabilities 0x06
sends break
line coding and serial state
CDC Union:
bMasterInterface 0
bSlaveInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 255
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 5
...
Any advice, pointers or help you could give me would be greatly
appreciated. And I'd be happy to provide more specific details as it
will be open hard/soft-ware anyway (designed to be made in a fablab by
anyone actually).
You should also try enabling debugging for the cdc-acm driver, which
may
provide a hint about why this isn't working.
echo module cdc_acm +p > /sys/kernel/debug/dynamic_debug/control
I never got around to trying this, but it looks interesting, thanks for
the suggestion.
Thanks,
Johan
No way, thank you and all the other developers for your hard work!
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
