Specifically solves usage of ii.<module>.help() for modules with a lot of commands (kria, jf, txo, disting etc).
Previously, only the first 1024 bytes would be sent, after which the USB TX buffer would be full & discard the rest of a message. This PR adds a queue system so that longer blocks of chars will be broken up across multiple USB frames.
Note, this solution only works with const char* strings as we don't need to copy the data anywhere. It cannot be applied to scripts that generate giant strings.
//
While fixing this i discovered that the code that marks the TX buffer as empty doesn't guarantee that the buffer has been fully consumed. In practice I was able to trample the last dozen characters or so, when spamming the USB port. Making a note here so it can be searched, but not opening an issue as i don't think it's pertinent to fix for crow's usage.
If someone needs to fix it, look at the new USB_tx_is_ready() fn in usbd/usbd_cdc_interface.c for how to check if the buffer should be released.
Fixes #264
Specifically solves usage of
ii.<module>.help()for modules with a lot of commands (kria, jf, txo, disting etc).Previously, only the first 1024 bytes would be sent, after which the USB TX buffer would be full & discard the rest of a message. This PR adds a queue system so that longer blocks of chars will be broken up across multiple USB frames.
Note, this solution only works with
const char*strings as we don't need to copy the data anywhere. It cannot be applied to scripts that generate giant strings.//
While fixing this i discovered that the code that marks the TX buffer as empty doesn't guarantee that the buffer has been fully consumed. In practice I was able to trample the last dozen characters or so, when spamming the USB port. Making a note here so it can be searched, but not opening an issue as i don't think it's pertinent to fix for crow's usage.
If someone needs to fix it, look at the new
USB_tx_is_ready()fn inusbd/usbd_cdc_interface.cfor how to check if the buffer should be released.