I ported support for DTR from the TI example, and it seems to work well
(at least for OSX, not tested on other OSes). The device runs fine with
or without USB enumeration, with or without terminal open on computer,
and no dropped lines when doing multiple calls in quick succession.
Changes, in case anyone is interested -
1. Change the ACM functional descriptor to indicate support -
.acm = {
.bFunctionLength = sizeof(struct usb_cdc_acm_descriptor),
.bDescriptorType = CS_INTERFACE,
.bDescriptorSubtype = USB_CDC_TYPE_ACM,
// we advertise support for Set_Line_Coding,
Set_Control_Line_State, and Get_Line_Coding
// we only really need Set_Control_Line_State, but that is not
available separately
.bmCapabilities = 0x2,
},
2. Add a handler to cdcacm_control_request -
case USB_CDC_REQ_SET_CONTROL_LINE_STATE: {
dtr = (req->wValue & (1 << 0)) ? 1 : 0;
rts = (req->wValue & (1 << 1)) ? 1 : 0;
return USBD_REQ_HANDLED;
}
3. Change your send routine to check dtr and rts. I am using &&, but
only checking one is probably sufficient. Retry sending packets if 0 is
returned.
int ret = 0;
do
{
ret = usbd_ep_write_packet(usbd_dev, 0x82, data, size);
}
while (ret == 0 && dtr && rts);
This is not technically compliant, because by setting the capability bit
we are also indicating support for Get_Line_Coding, which is not
implemented. It should be pretty trivial to implement however. I just
don't want to implement it now because I have no idea how to test it,
and I don't want to add untested code.
Matthew
On 2015-11-09 12:18 PM, Matthew Lai wrote:
> That is what I had as well. I found that if I don't retry
> usbd_ep_write_packet when it returns 0, I will sometimes have dropped
> characters/lines. Retrying solves that if USB is connected, but goes
> into infinite loop if it isn't.
>
> Using cdcacm_set_config may work, if OSes always start a transfer on the
> endpoint even if the terminal isn't open. I recall reading that at least
> some OSes do that.
>
> It seems to me like using DTR is the safest way, and it's actually only
> a few lines of code, too.
>
> Matthew
>
> On 2015-11-09 12:07 PM, Jason Kotzin wrote:
>> A bit of a hack, here is what I do.
>>
>> I usually put a static variable in the CDC file called usb_configured and
>> initialize it to 0. When cdcacm_set_config is called, I set it to one.
>>
>> Then my main loop calls pop char, looks like this:
>>
>> static void pop_usb_char(void)
>> {
>> if (!usb_configured)
>> return;
>>
>> if (!qempty(cdc->tx.head, cdc->tx.tail)) {
>> if (usbd_ep_write_packet(iface, 0x82,
>> &cdc->tx.buf[cdc->tx.tail], 1) ==
>> 0) {
>> return;
>> }
>> cdc->tx.tail = qinc(cdc->tx.tail, cdc->queuesize);
>> }
>>
>> }
>>
>> Works well, but wont work if the device is self powered, and you disconnect
>> the usb and plug it back in.
>>
>> Hope that helps.
>>
>> Sincerely,
>> Jason
>>
>>> On Nov 9, 2015, at 11:41 AM, Matthew Lai <m...@matthewlai.ca> wrote:
>>>
>>> Cool! That demo code does do that.
>>>
>>> I am not sure if it is completely compliant however.
>>>
>>> It implements SET_LINE_CODING and SET_CONTROL_LINE_STATE, but the
>>> capability bit (0x2) indicates that we support GET_LINE_CODING as well.
>>> The bit indicates support for these 3 requests (and a notification,
>>> which we don't care about).
>>>
>>> There is no way to indicate support for only SET_CONTROL_LINE_STATE.
>>>
>>> And it seems like the only symbol missing (for implementing this) in
>>> cdc.h is GET_LINE_CODING.
>>>
>>> I am not sure if GET_LINE_CODING is actually ever sent by Windows or
>>> Linux, and whether not supporting it (despite setting the capability
>>> bit) would actually be a problem.
>>>
>>> Thanks
>>> Matthew
>>>
>>> On 2015-11-09 4:41 AM, Karl Palsson wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Hrm, I thought the ti/lm4f cdc-acm demo code did this, but it
>>>> might have it locally. The definitions from the standard would be
>>>> certainly welcome in cdc.h
>>>>
>>>> Cheers,
>>>> Karl P
>>>>
>>>> Matthew Lai <m...@matthewlai.ca> wrote:
>>>>> Upon further research, I found that there is an optional "Set
>>>>> Control Line State" request that does exactly what I want. It
>>>>> is not yet implemented in cdc.h.
>>>>>
>>>>> I am going to implement it myself unless someone has done it
>>>>> already?
>>>>>
>>>>> Thanks
>>>>> Matthew
>>>>>
>>>>> On 2015-11-08 11:31 PM, Matthew Lai wrote:
>>>>>> Hello!
>>>>>>
>>>>>> I am using CDC ACM as a debug logging interface, so sometimes there is a
>>>>>> USB cable connected, and sometimes there isn't.
>>>>>>
>>>>>> My send routine looks like this -
>>>>>>
>>>>>> int ret = 0;
>>>>>>
>>>>>> do
>>>>>> {
>>>>>> ret = usbd_ep_write_packet(usbd_dev, 0x82, data, size);
>>>>>> }
>>>>>> while (ret == 0);
>>>>>>
>>>>>> However, if I call this function when either the USB cable isn't plugged
>>>>>> in or serial monitor is not opened on the computer, usbd_ep_write_packet
>>>>>> will just keep returning 0.
>>>>>>
>>>>>> Is there a way around this? Is there a way to tell whether the function
>>>>>> returned zero because there is no receiver, or if it returned zero
>>>>>> because it's busy and we should retry? Detecting whether the cable is
>>>>>> plugged in (or even whether the device is enumerated) is insufficient.
>>>>>>
>>>>>> Thanks!
>>>>>> Matthew
>>>>>>
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1.4.11 (GNU/Linux)
>>>>
>>>> iQIcBAEBAgAGBQJWQJSIAAoJEBmotQ/U1cr2iogP/iTCVCV1YYPSJ+5c2v0Ih0Xa
>>>> tphtjWIGQgGUUtLWRgGvUydZtJ10ec2gHybe7v+v3spqKhbLO3ydzmgxNdedg7AN
>>>> IfIo7axZt3A1LbUBOLSwqBBNS/Jr7MnZSw0V/56MBfnr2zL8+txuYmOAH/cwcbiq
>>>> c9GUwgK5QZTg/wQHaIqR9nPrEnejPAU/Tyelndmk5lkHH9/+QVr/F/HR/p6GZc3x
>>>> sWntENu30KvveQ2NZsCeE9tNa+9T1l5JTnDEfFch5Gt2PPjw31A87yDJEgeid1Yk
>>>> +hzmgZ+lf/3V/NL71JmNT8ky84ecejXX5xooqgFn9XJkHY4IidkTrUmPJiYnjytM
>>>> 7VjCzhVtiWSkqLMC3P70N6zAEZ/T4UCALriJz56rOL/AJebkdv2/pQXHEXBLKvVV
>>>> BxMFedV8JqL+fhMQlwOjPJ3hRAVM0N69BLGNIWfAeJoN+YhWZk8W/I01XrEof21r
>>>> 7qXiueGSqvzqj4GAMGcTEQTEn88utAUWb5MOjj0IdFEw4CsOVCGUlecvvkQFc6rC
>>>> nCxbQx6EyKR07ADDYoPDZBfrn6Q2JHbB3rpXQvfiH7Ky974sgIPouvYGuI6fP1mt
>>>> WCFfM9D9+Ewd3pfkHjDLIcddj2fU61fEvKh+ANyX1MVIqyJuVYnUgmJKjsbEAjWo
>>>> 1/87o6QolfPdFOZ7qlvD
>>>> =pxLy
>>>> -----END PGP SIGNATURE-----
>>> ------------------------------------------------------------------------------
>>> Presto, an open source distributed SQL query engine for big data, initially
>>> developed by Facebook, enables you to easily query your data on Hadoop in a
>>> more interactive manner. Teradata is also now providing full enterprise
>>> support for Presto. Download a free open source copy now.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=250295911&iu=/4140
>>> _______________________________________________
>>> libopencm3-devel mailing list
>>> libopencm3-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
>
> ------------------------------------------------------------------------------
> Presto, an open source distributed SQL query engine for big data, initially
> developed by Facebook, enables you to easily query your data on Hadoop in a
> more interactive manner. Teradata is also now providing full enterprise
> support for Presto. Download a free open source copy now.
> http://pubads.g.doubleclick.net/gampad/clk?id=250295911&iu=/4140
> _______________________________________________
> libopencm3-devel mailing list
> libopencm3-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
------------------------------------------------------------------------------
Presto, an open source distributed SQL query engine for big data, initially
developed by Facebook, enables you to easily query your data on Hadoop in a
more interactive manner. Teradata is also now providing full enterprise
support for Presto. Download a free open source copy now.
http://pubads.g.doubleclick.net/gampad/clk?id=250295911&iu=/4140
_______________________________________________
libopencm3-devel mailing list
libopencm3-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
