Confused about serial port generators

[MitchBradley]

Checklist

• Checked the issue tracker for similar issues to ensure this is not a duplicate.
• Provided a clear description of your suggestion.
• Included any relevant context or examples.

Issue or Suggestion Description

I am tracking down some tricky issues around serial port management in the face of the ESP32 continually rebooting. That situation tends to cause buffer overruns that make it hard to maintain a coherent serial reader state.

I am confused by this line of code and a few similar ones: const { value: p } = await this.transport.read(timeout).next(); . this.transport.read(timeout) creates a new instance of a generator function, then .next() waits for the function to yield. That generator function is never used again. Every use of .next() is in the context of a new generator function instance, so what is the point of using a generator that only generates one value? Isn't that effectively the same as an ordinary function, but with added complexity?

There is a similar situation with readLoop() in newRead().

I am not a JavaScript expert so I could be missing something. Please help me understand the rationale.

[brianignacio5]

Hi @MitchBradley you are right !

I've been experimenting with a new approach which is to keep the readLoop as continuously reading from port and parsing command and results from a buffer. Seems to provide a more stable solution but feel free to test using the #228 branch.

I need to find a way to push some live demos for PR testing but unfortunately I don't have a way for the moment.

[MitchBradley]

I will test 228 tomorrow. Meanwhile I have a custom version of the serial code in a fork, which seems to be solid on devices that were troublesome before.