It turned out that the problem with non-receiving data before launching the terminal was caused by "cocked" mode of the serial port, by adding a \n to the data stream made the problem disappear, the terminal SW simply selected "raw" mode and it sticks even after exiting the terminal.
Still looking into the other problem.
Giovanni
USB CDC ACM and 64 bytes transaction Topic is solved
- Giovanni
- Site Admin
- Posts: 14563
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1111 times
- Been thanked: 937 times
- Contact:
Re: USB CDC ACM and 64 bytes transaction
Hi Giovanni,
Thanks for looking into this. Let me know if I can help.
We have merged my workaround into RusEFI master and as far a I know our problem is not longer reproducible.
Thanks for looking into this. Let me know if I can help.
We have merged my workaround into RusEFI master and as far a I know our problem is not longer reproducible.
- Giovanni
- Site Admin
- Posts: 14563
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1111 times
- Been thanked: 937 times
- Contact:
Re: USB CDC ACM and 64 bytes transaction
hi,
Fixed another problem with the number of bytes returned by usbReceive(), it was higher than the real value under certain conditions.
About the frames exactly 64 bytes, the driver does not notify for data because the host sends no zero packet, the driver assumes that more frames follows as specified by the USB protocol, there is nothing that can be done on the device side, it is the host.
Other issue specific of this OTG peripherals, it has an unified RX FIFO, if there are multiple OUT endpoints the application needs to greedly read data or one unread frame can keep in queue frames of other endpoints indefinitely, again, this is not something that can be fixed in the driver unless we adopt a policy of dropping unread frames.
Please report about the current driver state in your use case if possible. I still need to make other standby-related changes but I wish to have a stable state 1st.
Giovanni
Fixed another problem with the number of bytes returned by usbReceive(), it was higher than the real value under certain conditions.
About the frames exactly 64 bytes, the driver does not notify for data because the host sends no zero packet, the driver assumes that more frames follows as specified by the USB protocol, there is nothing that can be done on the device side, it is the host.
Other issue specific of this OTG peripherals, it has an unified RX FIFO, if there are multiple OUT endpoints the application needs to greedly read data or one unread frame can keep in queue frames of other endpoints indefinitely, again, this is not something that can be fixed in the driver unless we adopt a policy of dropping unread frames.
Please report about the current driver state in your use case if possible. I still need to make other standby-related changes but I wish to have a stable state 1st.
Giovanni
Re: USB CDC ACM and 64 bytes transaction
Hi Giovanni,
Few months have passed, no more communication stuck reported from users. So I can confirm that setting SERIAL_USB_BUFFERS_SIZE equal to EP size fixes/workarounds the problem.
I agree that driver does not sends ZLP and this looks correct to me. As it is serial device and there is no actual "end of block".
Andrey.
Few months have passed, no more communication stuck reported from users. So I can confirm that setting SERIAL_USB_BUFFERS_SIZE equal to EP size fixes/workarounds the problem.
I agree that driver does not sends ZLP and this looks correct to me. As it is serial device and there is no actual "end of block".
Andrey.
Who is online
Users browsing this forum: No registered users and 7 guests