jlaitine commented on issue #16004: URL: https://github.com/apache/nuttx/issues/16004#issuecomment-2750195941
> > If you set bytes_to_read to something a bit bigger (like 5), you don't get anything out any more. Also the thing keeps crashing. > > In order to reduce the copying of data, the USB reqbuf is directly used as the serial port buf. When CONFIG_CDCACM_NRDREQS is 4, at most 4 packets of USB data are stored without reading. Minicom uses 1 byte as 1 packet of data, so it can only receive 4 bytes. More bytes can be received by expanding CONFIG_CDCACM_NRDREQS. > > If bytes_to_read is bigger than 5, it will cause a crash？ If I understand you correctly, this is completely unacceptable way of working. It doesn't work at all like other serial drivers! The data MUST be copied out from an endpoint to a separate buffer as soon as possible. You can't make assumptions on how often the ttyACM client reads out the data. There may be other class drivers running in parallel such as MSC, which need the endpoint buffers as well. It is a very common optimization technique for serial protocols to wait for n bytes to arrive before processing the serial data. Now this is not working - at all. First of all, the polling of amount of serial data in the buffer is heavy because of big kernel lock, and in addition you can't accumulate data in the buffers. See for example (close to my heart) PX4: https://github.com/PX4/PX4-Autopilot/blob/735777862d590ef8d428282ab2b26deacfd8c382/src/drivers/cdcacm_autostart/cdcacm_autostart.cpp#L237 I suggest that we revert the patches which cause these issues. Please comment @xiaoxiang781216 , @pussuw , @acassis , others? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
