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 <[email protected]> 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 <[email protected]> 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
>> [email protected]
>> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/libopencm3-devel