-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
serialport/bindings-cpp/unixRead read error [Error: EAGAIN: resource temporarily unavailable, read] #2787
Comments
I have the same issue, with similar scenario. I'm running archlinux with electron 26.2.1 serialport v12 dev mode output:
With debug enabled
Any clue? Thanks |
Same problem MAC M1.... checking console.log(port) : the buffer is full but not readable with port.on("data", (data)=>console.log(data)) Here the buffer : |
SerialPort Version
Tested 10-12
Node Version
Electron main
Electron Version
Tested 26-30
Platform
Sonoma 14.14.1 - Darwin Kernel Version 23.4.0 macOS
Architecture
ARM
Hardware or chipset of serialport
FTDI FT232R USB UART (PID: 0x6001)
What steps will reproduce the bug?
I have a weight scale that responds to a simple "W\r\n". This works fine using
screen /dev/tty.usbserial-AI04V9SR 9600
, here's the expected output:I'm no stranger to USB devices, Electron, native modules, TypeScript, etc. I'm unable to get serialport to work as I'd expect.
What happens?
Here's the output from electron 26.6.9 main when DEBUG=*
My calling code is fairly vanilla. I've tried with autoOpen:true/false, with/without a parser. Here's a code sample:
My writing looks like:
My goal is to keep targeting Electron 26 due to macOS 10.13/10.14, along with other native module compatibility.
Here's the DEBUG repl using node v18.17.1.
Immediately after this I can type
screen /dev/tty.usbserial-AI04V9SR 9600
and press W and receive a response from the scale.Oh, and here's the stty/permission settings.
What should have happened?
I'd just like to see the output of the weight scale.
Additional information
I've unplug/replugged the USB device multiple times to ensure it's a clean/fresh interface. No difference, unfortunately.
The text was updated successfully, but these errors were encountered: