azure-iot-developer-kit icon indicating copy to clipboard operation
azure-iot-developer-kit copied to clipboard

Arduino Serial Monitor hangs after 384 characters

Open technoblogy opened this issue 5 years ago • 10 comments

I'm developing an application with the MXChip IoT DevKit using the Arduino IDE to interface with the board via the Serial Monitor.

However, after transferring 384 characters the Serial Monitor hangs up, and appears to crash the Arduino IDE, requiring a restart.

It can be demonstrated using the following program:

void setup() {
  Serial.begin(9600);
}

void loop (void) {
  if (Serial.available() > 0) Serial.print((char)Serial.read());
}

If you upload this program, then copy a block of text of more than 384 characters and paste it into the Serial Monitor input field, and press return, only the first 384 characters are displayed and the Serial Monitor hangs up, preventing any further input.

I'm using the Arduino IDE 1.8.7 on a MacBook Pro with High Sierra.

PS I'm not sure if this is the right place to report this issue, but I can't find an specifically Arduino-related forum.

technoblogy avatar Mar 19 '19 17:03 technoblogy

It works well in Windows with your sample code serial-port-win , will try to repro in macOS.

dooriya avatar Mar 20 '19 08:03 dooriya

Thank you, David

technoblogy avatar Mar 20 '19 09:03 technoblogy

The root cause is that the underlying serial port software (screen) we depends on in macOS has limited read buffer. So if you want to read a long string from serial port, you need to split it into chunks.

dooriya avatar Mar 22 '19 06:03 dooriya

Thank you for your reply. This is a bit of a showstopper for my application: I want to port my Lisp interpreter, uLisp, to the AZ3166. You interface to the Lisp REPL using the Arduino Serial Monitor:

http://www.ulisp.com/show?19XT

On other Arduino platforms this works fine; you can paste in Lisp programs and execute them. However, on the AZ3166 as soon as you try to paste in any significant program the Arduino IDE crashes or hangs up.

Why is this not a problem on other Arduino platforms?

Can I rewrite the serial interface to remove the restriction?

Any other suggestions? Thanks,David

technoblogy avatar Mar 22 '19 09:03 technoblogy

Any more suggestions about this issue?

technoblogy avatar Apr 12 '19 14:04 technoblogy

This issue has no recent activities, please take a look and provide updates for it.

github-actions[bot] avatar Nov 12 '19 06:11 github-actions[bot]

Is there any progress on this?

As I said in a previous post, this isn't a problem with most other platforms supported by the Arduino IDE (for example, ATSAMD21, ATSAMD51, ESP32, nRF52840). My test program works fine on those.

It therefore must be possible to implement Serial in a way that doesn't impose a 384-character limit. Is there some way I can contribute to fixing this?

technoblogy avatar Feb 29 '20 12:02 technoblogy

@dooriya any progress on this?

I tried increasing the buffer size by editing the line in BufferedSerial.h from:

BufferedSerial(PinName tx, PinName rx, uint32_t buf_size = 128, uint32_t tx_multiple = 4, const char* name=NULL, int sample_rate = 115200);

to:

BufferedSerial(PinName tx, PinName rx, uint32_t buf_size = 1024, uint32_t tx_multiple = 4, const char* name=NULL, int sample_rate = 115200);

but it didn't seem to help. Any other suggestions?

technoblogy avatar May 07 '20 18:05 technoblogy

Normally the input will be shorter than 384 characters. You may need to split long string to chunks and limit each input to 384 characters as a work-around.

hellyzh avatar May 15 '20 03:05 hellyzh

Thank you for the reply.

My input is not normally shorter than 384 characters, as I'm uploading Lisp programs, and I can't easily break them into chunks. One program may be more than 384 characters. So this essentially makes the MXChip IoT DevKit unusable for my application.

As I mentioned in an earlier message this isn't a problem with most other platforms supported by the Arduino IDE (for example, ATSAMD21, ATSAMD51, ESP32, nRF52840).

technoblogy avatar May 15 '20 06:05 technoblogy