Fix 128 Character Max Paste Into REPL#698
Conversation
|
tried this on a metro_mr_express_revb: so it seems to work in Paste Mode but still truncates in "normal" REPL -- Is this expected? |
|
Thanks for testing @jerryneedell!! I'll go sniffing... |
|
Just for fun - here is a nice example of it working in "Paste Mode" |
|
So, my previous testing was only with continuous strings...testing fail on my part. Using multiple lines would cause the @jerryneedell you are the ULTIMATE tester. Don't know what we'd do without you... Please give this another thorough run-through. |
|
nailed it ! -- almost -- see all three examples also with Paste Mode but - sometimes paste mode fails with a syntax error -- I'm not sure why. |
|
Note - the occasional paste mode failures are not new to the latest commit. They occurred in the previous one as well. I thought it was user error but now it looks like a possible issue. |
|
the syntax errors I was thinking about were from #124 |
tannewt
left a comment
There was a problem hiding this comment.
Amazing work! Thank you for figuring this out and improving it.
| return true; | ||
| } | ||
| } | ||
| }*/ |
| bool usb_bytes_available(void) { | ||
| // Check if the buffer has data, but not enough | ||
| // space to hold another read. | ||
| if (usb_rx_count > 64) { |
There was a problem hiding this comment.
Want to use USB_RX_BUF_SIZE here so this changes with it?
There was a problem hiding this comment.
Can do. Or, we can use the EP max packet size constant; any future use of USB HS is what would be the determination of going above 64 bytes per EP buffer. Yes?
| /*if (!pending_read && usb_rx_count == USB_RX_BUF_SIZE - 1) { | ||
| start_read(); | ||
| } | ||
| }*/ |
There was a problem hiding this comment.
Go ahead and delete this too. Git has it in its history.
| if (mp_interrupt_char != -1 && cdc_enabled() && !pending_read) { | ||
| start_read(); | ||
| // Make sure we have space in the buffer | ||
| if (usb_rx_count < 64) { |
There was a problem hiding this comment.
Use USB_RX_BUF_SIZE here too and merge the condition with the outside if statement. No need to have two.
|
The only change I see so far from the fix to #124 is the addition of VFS gc collection. Could have reintroduced the previous problem. Will keep looking, unless wiser minds chime in... |
|
Lets get this in and we can chase the syntax error down separately if we want. |
|
You know better than I do. :-)
…On Fri, Mar 23, 2018 at 2:34 PM sommersoft ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In ports/atmel-samd/usb.c
<#698 (comment)>
:
> @@ -243,9 +245,16 @@ static bool cdc_enabled(void) {
}
bool usb_bytes_available(void) {
+ // Check if the buffer has data, but not enough
+ // space to hold another read.
+ if (usb_rx_count > 64) {
Can do. Or, we can use the EP max packet size constant; any future use of
USB HS is what would be the determination of going above 64 bytes per EP
buffer. Yes?
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<#698 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AADNqXYMD8J7GUQwvoby9dCFi96FS1VXks5thWpTgaJpZM4S4_xe>
.
|
|
No objection from me! Great work on this. I think it will be good for others to use it and see how often the syntax error occurs. For me it is about 25% to 50% of the time but there was a lot of flailing around. |
|
So, I pulled back on all of the "futurization" I mentioned earlier in discord. The only SAM chips that run High Speed USB are M7s; no real reason to put that in for now. |
tannewt
left a comment
There was a problem hiding this comment.
Thanks! I really appreciate you tackling this.
| // Check if the buffer has data, but not enough | ||
| // space to hold another read. | ||
| if (usb_rx_count > 64) { | ||
| if (usb_rx_count > CDC_BULKOUT_SIZE) { |
There was a problem hiding this comment.
You've been awesome with feedback so I'll nitpick just a smidge more. This should be USB_RX_BUF_SIZE - usb_rx_count > CDC_BULKOUT_SIZE here and below. This works now because USB_RX_BUF_SIZE is 128. This will break if we make that buffer bigger.
There was a problem hiding this comment.
USB_RX_BUF_SIZE - usb_rx_count > CDC_BULKOUT_SIZE caused REPL to be non-responsive. Puzzled me until I thought about the truth table.
usb_rx_count = 0 # REPL will always start at zero
USB_RX_BUF_SIZE = 128
CDC_BULKOUT_SIZE = 64
if ((128 - 0) > 64) { return > 0;}
All that was needed was flipping the buffer to the other side of the eval. Tests successfully.
tannewt
left a comment
There was a problem hiding this comment.
Yup, good catch on the flip. One more nitpicky thing for clarity. Great work!
| // space to hold another read. | ||
| if (usb_rx_count > CDC_BULKOUT_SIZE) { | ||
| if (usb_rx_count > USB_RX_BUF_SIZE - CDC_BULKOUT_SIZE) { | ||
| return usb_rx_count > 0; |
There was a problem hiding this comment.
One last thing. This will always be true because USB_RX_BUF_SIZE - CDC_BULKOUT_SIZE is always more than zero. So, just return true;.
See Issue #417.
After all that digging through the USB read functions and ASF4, turns out we were just reading to often, before clearing the local USB buffer.
usb_bytes_availablenow checks if the local USB buffer 1) has data perusb_rx_count, and 2) if we have space for a new USB read (64 bytes max).I also commented out the recurring calls to
start_readin bothusb_readandread_complete. I don't think we need them, sinceusb_bytes_availableandusb_cdc_backgroundwill always call it. Makes it easier to debug in the future, and keeps from having too many hands in the cookie jar. If anyone has objections, easy enough to uncomment. Likewise, if we want to delete them...just as easy.