Hi Manuel,

On 01/17/2013 02:29 PM, wesen wrote:
> In libmaple/usb/stm32f1/usb_cdcacm.c:
>
>> @@ -428,6 +407,11 @@ uint32 usb_cdcacm_tx(const uint8* buf, uint32 len) {
>>          usb_set_ep_tx_count(USB_CDCACM_TX_ENDP, len);
>>          n_unsent_bytes = len;
>>          usb_set_ep_tx_stat(USB_CDCACM_TX_ENDP, USB_EP_STAT_TX_VALID);
>> +    } else {
>> +      usb_set_ep_tx_count(USB_CDCACM_TX_ENDP, 0);
>> +      usb_set_ep_tx_stat(USB_CDCACM_TX_ENDP, USB_EP_STAT_TX_VALID);
>> +      // actually block here waiting for interrupt, even though we sent 0 bytes
>> +      n_unsent_bytes = 1;
>
> Yes this is the correct behaviour, we need to wait for the 0 byte packet
> to have been sent before going on. I don't know about the BTABLE entry,
> although I remember (but couldn't find it in the reference manual)
> reading somewhere that once a transfer is going on, these BTABLE entries
> are taboo.

I see; thanks. I don't understand the USB peripheral well at all, so 
these explanations are very useful.


> Also I would not do the sending of the 0 byte packet in the
> interrupt (I tried that at first), because it would send a 0 byte packet
> after each 64 bytes packet, instead of waiting for the end of the long
> string of 64 byte packets (in case I send 2kB for example).

Good point.

> I did some
> eclipse magic, I had the project nested inside our main project, and it
> would take over the 2 byte indenting. sorry about that (and the
> sign-offs), I was a bit caught up in the whole coding. Regards, Manuel

No problem! Thanks again for taking the time to send the patch.

> … <#>
> On Jan 17, 2013, at 8:08 PM, Marti Bolivar <notifications@github.com>
> wrote: In libmaple/usb/stm32f1/usb_cdcacm.c: > @@ -428,6 +407,11 @@
> uint32 usb_cdcacm_tx(const uint8* buf, uint32 len) { >
> usb_set_ep_tx_count(USB_CDCACM_TX_ENDP, len); > n_unsent_bytes = len; >
> usb_set_ep_tx_stat(USB_CDCACM_TX_ENDP, USB_EP_STAT_TX_VALID); > + } else
> { > + usb_set_ep_tx_count(USB_CDCACM_TX_ENDP, 0); > +
> usb_set_ep_tx_stat(USB_CDCACM_TX_ENDP, USB_EP_STAT_TX_VALID); > + //
> actually block here waiting for interrupt, even though we sent 0 bytes >
> + n_unsent_bytes = 1; This introduces another bug -- until the interrupt
> occurs, usb_cdcacm_get_pending() will falsely return 1, instead of 0.
> Probably what we want is to have usb_cdcacm_tx() check a new bit of
> state to see if a flush is still waiting, rather than overload the
> meaning of n_unsent_bytes in this way. Incidentally, I don't know if you
> saw my source code comment in vcomDataTxCb() -- I tried to read the TX
> count from the appropriate BTABLE entry for the TX endpoint, rather than
> assuming that all bytes were flushed. But this broke the device: I
> couldn't send bytes. Do you know why? Also, please use 4 space indents.
> — Reply to this email directly or view it on GitHub.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/leaflabs/libmaple/pull/67/files#r2686174>.
>