Max data transfer size/rate via USART?

@Gordon: Ah - wait. It has nothing to do with the Serial connection after all - it's something to do with passing a variable through JSON.stringify() and then concatenating to it.

The simplest/most convenient test-code that replicates it is as follows - flash it to the Pico chip and run go() - it just sets sets up a serial connection on B6/B7, kicks a chunk of data down it and waits for the transmission to finish, setting the LEDs at each stage to indicate status.

var setBusy = function(busy) {
  digitalWrite(LED1, 0+busy);  // Red = busy
  digitalWrite(LED2, 0+(!busy));  // Green = waiting
};

var blockData = "f3+AgICAgICAgICBgYGBgYGBgoKBgoGBgY... any huge chunk of text data here";

function go() {
  USB.setConsole();

  setBusy(true);

  console.log(blockData.length);

  JSON.stringify(blockData) + 'a';

  setBusy(false);
}

setBusy(false);

The important factors here seem to be the following:

The fact that the JSON.stringified() string is concatenated with another string afterwards

If omit the concatenation I can send an arbitrarily large (20k+) messages without any problems. If I concatenate it with another string as per the code above, anything over 3680 characters causes the REPL to become unresponsive.

That naively suggests to me it's not "just" an OOM problem in the JS code, as surely reserving/sending one 20k string is going to use more memory than even two or three implicit copies of a 3.6k one?

The length of blockData in chars

Assuming the concatenation as per the code above, the following boundaries seem to apply on the length of blockData:

4029 or more = REPL unresponsive, LED stays red (indicating JS processing is stopping immediately after JSON.stringify()?)

3681 - 4028 = REPL unresponsive, LED turns green after transmission finishes (so somethings killing the REPL, but the rest of the JS is executing correctly?)

3680 or fewer = LED turns green after transmission ends, REPL remains responsive after code finished executing

I'm assuming that this is some sort of bug because from what you're saying I should be seeing errors thrown for OOM, and the REPL shouldn't stop responding under any circumstances.

Is that any help?