serialport / bindings-cpp Goto Github PK
View Code? Open in Web Editor NEWThe C++ bindings for the node serialport project.
License: MIT License
The C++ bindings for the node serialport project.
License: MIT License
We can't seem to build from source with the default github runner anymore on windows-latest
. We've pinned back to windows-2019
references
10.8.0
v16.14.2
No response
Darwin 18.5.0 /RELEASE_X86_64 x86_64
No response
No response
I tried to build my own build of bindings cpp with:
npm run rebuild
Fatal error during build fatal error: too many errors emitted, stopping now
gyp info spawn args [ 'BUILDTYPE=Release', '-C', 'build' ]
CXX(target) Release/obj.target/bindings/src/serialport.o
In file included from ../src/serialport.cpp:1:
In file included from ../src/./serialport.h:11:
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/stdio.h:108:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/stdio.h:64:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/_stdio.h:68:
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/sys/cdefs.h:784:2: error:
Unsupported architecture
#error Unsupported architecture
/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/sys/cdefs.h:784:2 :
/*
* Architecture validation for current SDK
*/
#if !defined(__sys_cdefs_arch_unknown__) && defined(__i386__)
#elif !defined(__sys_cdefs_arch_unknown__) && defined(__x86_64__)
#else
#error Unsupported architecture // <=== line 784
#endif
It seems that miss some flag.
Build should be done
I was able to fix it and correctly build, when I change 'OTHER_CFLAGS' to 'CFLAGS' and I do the same for OTHER_LDFLAGS
. I was asking my self it is really 'OTHER_CFLAGS' that you want to do ?
Lines 36 to 45 in abba894
v10.5.0/v11.0.1
v12.22.12/v14.15.4/v18.14.2
No response
Linux 5.10.0-22-amd64 #1 SMP Debian 5.10.178-3 (2023-04-22) x86_64 GNU/Linux
x64
Arduino
SerialPort = require('serialport').SerialPort;
SerialPort.binding.list().then(console.log)
[
{
path: '/dev/ttyACM1',
manufacturer: undefined,
serialNumber: undefined,
pnpId: undefined,
locationId: undefined,
vendorId: '8086',
productId: 'a12f'
},
{
path: '/dev/ttyACM0',
manufacturer: undefined,
serialNumber: undefined,
pnpId: undefined,
locationId: undefined,
vendorId: '8086',
productId: 'a12f'
}
]
[
{
path: '/dev/ttyACM0',
manufacturer: 'Arduino\x20\x28www.arduino.cc\x29',
serialNumber: '952383433343518101E1',
pnpId: '/dev/serial/by-path/pci-0000:00:14.0-usb-0:2:1.0',
locationId: undefined,
vendorId: '8086',
productId: 'a12f'
},
{
path: '/dev/ttyACM1',
manufacturer: 'Arduino\x20\x28www.arduino.cc\x29',
serialNumber: '751313138323515011A0',
pnpId: '/dev/serial/by-path/pci-0000:00:14.0-usb-0:11:1.0',
locationId: undefined,
vendorId: '8086',
productId: 'a12f'
}
]
$ udevadm info -n /dev/ttyACM1
P: /devices/pci0000:00/0000:00:14.0/usb1/1-11/1-11:1.0/tty/ttyACM1
N: ttyACM1
L: 0
S: serial/by-path/pci-0000:00:14.0-usb-0:11:1.0
E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-11/1-11:1.0/tty/ttyACM1
E: DEVNAME=/dev/ttyACM1
E: MAJOR=166
E: MINOR=1
E: SUBSYSTEM=tty
E: USEC_INITIALIZED=437935568319
E: ID_BUS=pci
E: ID_VENDOR_ID=0x8086
E: ID_MODEL_ID=0xa12f
E: ID_PCI_CLASS_FROM_DATABASE=Serial bus controller
E: ID_PCI_SUBCLASS_FROM_DATABASE=USB controller
E: ID_PCI_INTERFACE_FROM_DATABASE=XHCI
E: ID_VENDOR_FROM_DATABASE=Intel Corporation
E: ID_MODEL_FROM_DATABASE=100 Series/C230 Series Chipset Family USB 3.0 xHCI Controller
E: ID_PATH=pci-0000:00:14.0-usb-0:11:1.0
E: ID_PATH_TAG=pci-0000_00_14_0-usb-0_11_1_0
E: ID_USB_MODEL=0043
E: ID_USB_MODEL_ENC=0043
E: ID_USB_MODEL_ID=0043
E: ID_USB_SERIAL=Arduino__www.arduino.cc__0043_751313138323515011A0
E: ID_USB_SERIAL_SHORT=751313138323515011A0
E: ID_USB_VENDOR=Arduino__www.arduino.cc_
E: ID_USB_VENDOR_ENC=Arduino\x20\x28www.arduino.cc\x29
E: ID_USB_VENDOR_ID=2341
E: ID_USB_REVISION=0001
E: ID_USB_TYPE=generic
E: ID_USB_INTERFACES=:020201:0a0000:
E: ID_USB_INTERFACE_NUM=00
E: ID_USB_DRIVER=cdc_acm
E: ID_MM_CANDIDATE=1
E: ID_FOR_SEAT=tty-pci-0000_00_14_0-usb-0_11_1_0
E: DEVLINKS=/dev/serial/by-path/pci-0000:00:14.0-usb-0:11:1.0
E: TAGS=:systemd:seat:uaccess:
E: CURRENT_TAGS=:systemd:seat:uaccess:
$ udevadm info -n /dev/ttyACM0
P: /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/tty/ttyACM0
N: ttyACM0
L: 0
S: serial/by-path/pci-0000:00:14.0-usb-0:2:1.0
E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/tty/ttyACM0
E: DEVNAME=/dev/ttyACM0
E: MAJOR=166
E: MINOR=0
E: SUBSYSTEM=tty
E: USEC_INITIALIZED=17488184319
E: ID_BUS=pci
E: ID_VENDOR_ID=0x8086
E: ID_MODEL_ID=0xa12f
E: ID_PCI_CLASS_FROM_DATABASE=Serial bus controller
E: ID_PCI_SUBCLASS_FROM_DATABASE=USB controller
E: ID_PCI_INTERFACE_FROM_DATABASE=XHCI
E: ID_VENDOR_FROM_DATABASE=Intel Corporation
E: ID_MODEL_FROM_DATABASE=100 Series/C230 Series Chipset Family USB 3.0 xHCI Controller
E: ID_PATH=pci-0000:00:14.0-usb-0:2:1.0
E: ID_PATH_TAG=pci-0000_00_14_0-usb-0_2_1_0
E: ID_USB_MODEL=0043
E: ID_USB_MODEL_ENC=0043
E: ID_USB_MODEL_ID=0043
E: ID_USB_SERIAL=Arduino__www.arduino.cc__0043_952383433343518101E1
E: ID_USB_SERIAL_SHORT=952383433343518101E1
E: ID_USB_VENDOR=Arduino__www.arduino.cc_
E: ID_USB_VENDOR_ENC=Arduino\x20\x28www.arduino.cc\x29
E: ID_USB_VENDOR_ID=2341
E: ID_USB_REVISION=0001
E: ID_USB_TYPE=generic
E: ID_USB_INTERFACES=:020201:0a0000:
E: ID_USB_INTERFACE_NUM=00
E: ID_USB_DRIVER=cdc_acm
E: ID_MM_CANDIDATE=1
E: ID_FOR_SEAT=tty-pci-0000_00_14_0-usb-0_2_1_0
E: DEVLINKS=/dev/serial/by-path/pci-0000:00:14.0-usb-0:2:1.0
E: TAGS=:seat:uaccess:systemd:
E: CURRENT_TAGS=:seat:uaccess:systemd:
The first reply here is quite useful: https://www.reddit.com/r/debian/comments/1331wlr/devserialbyid_suddenly_missing/
12.0.1
18.20.2
Microsoft Windows NT 10.0.22631.0 x64
x64
$Env:npm_config_arch="arm" ; $Env:npm_config_platform="linux" ; yarn install --inline-builds
sqlite3 or canvas in package.json
node:internal/child_process:414
throw errnoException(err, 'spawn');
^
Error: spawn EINVAL
at ChildProcess.spawn (node:internal/child_process:414:11)
at Object.spawn (node:child_process:761:9)
at build (G:\Roboqbo\qbo-5\server\node_modules\@serialport\bindings-cpp\node_modules\node-gyp-build\bin.js:29:8)
at preinstall (G:\Roboqbo\qbo-5\server\node_modules\@serialport\bindings-cpp\node_modules\node-gyp-build\bin.js:38:32)
at G:\Roboqbo\qbo-5\server\node_modules\@serialport\bindings-cpp\node_modules\node-gyp-build\bin.js:11:7
at ChildProcess.exithandler (node:child_process:430:5)
at ChildProcess.emit (node:events:517:28)
at maybeClose (node:internal/child_process:1098:16)
at Socket.<anonymous> (node:internal/child_process:450:11)
at Socket.emit (node:events:517:28) {
errno: -4071,
code: 'EINVAL',
syscall: 'spawn'
}
Node.js v18.20.2
Look at this: nodejs/node#52681
Is it possible to change the Node dependency from 12.17.0
to 12.14.1
?
Currently we can't get the bindings to work in Atom because Atom bundles with 12.14.1
. We can get it working by running npm install
manually in the package folder, but that's not something we can ask our users to do.
10.7.0
16.5.0
No response
Microsoft Windows NT 10.0.22000.0 x64
No response
No response
Simply running SerialPort.list()
on a Windows system with the language set to one that has accents (diacritics). The list of ports will contain ๏ฟฝ
characters in ports' properties instead of the accents.
Ports' list parameters encoding is broken for Unicode accents:
The ports list should properly encode all port parameters:
Seems like the serialport_win
implementation uses char
s, which do not encode Unicode characters on Windows. Instead, the implementation should use wchar_t
s, which is the preferred way to store such data on Windows, substitute std::string
with std::wstring
and use the Napi::String::New(Env, const char16_t*)
(since wchar_t
is essentially a 16-bit wide Unicode character) signature over Napi::String::New(Env, const char*)
when passing these values to interpreted code.
12.0.1
v21.2.0
No response
Linux opi5b 5.10.110-rockchip-rk3588 #1.0.2 SMP Thu Apr 13 16:55:55 CST 2023 aarch64 GNU/Linux
arm64
16550A
Simply opening /dev/ttyS9 on this hardware using the code below:
const debug=require('debug')
debug.enable('*')
const { SerialPort } = require('serialport')
const port = new SerialPort({
path: '/dev/ttyS9',
baudRate: 57600,
})
port.on('data', function (data) {
console.log('Data:', data)
})
initial unixRead()
that is called on port open is trapped into recursive call to itself, because readAsync()
always returns { bytesRead:0 }
, see https://github.com/serialport/bindings-cpp/blob/39fd4be0904434a0ec72ee88e04d54bfa1645667/lib/unix-read.ts#L41C1-L44C1
The debug log confirms the said:
2023-11-26T14:55:04.624Z serialport/bindings-cpp loading LinuxBinding
2023-11-26T14:55:04.626Z serialport/stream opening path: /dev/ttyS9
2023-11-26T14:55:04.626Z serialport/bindings-cpp open
2023-11-26T14:55:04.628Z serialport/stream _read queueing _read for after open
2023-11-26T14:55:04.629Z serialport/bindings-cpp/poller Creating poller
2023-11-26T14:55:04.629Z serialport/stream opened path: /dev/ttyS9
2023-11-26T14:55:04.629Z serialport/stream _read reading { start: 0, toRead: 65536 }
2023-11-26T14:55:04.631Z serialport/bindings-cpp read
2023-11-26T14:55:04.631Z serialport/bindings-cpp/unixRead Starting read
2023-11-26T14:55:04.632Z serialport/bindings-cpp/unixRead Starting read
2023-11-26T14:55:04.632Z serialport/bindings-cpp/unixRead Starting read
2023-11-26T14:55:04.632Z serialport/bindings-cpp/unixRead Starting read
2023-11-26T14:55:04.632Z serialport/bindings-cpp/unixRead Starting read
2023-11-26T14:55:04.633Z serialport/bindings-cpp/unixRead Starting read
2023-11-26T14:55:04.633Z serialport/bindings-cpp/unixRead Starting read
2023-11-26T14:55:04.633Z serialport/bindings-cpp/unixRead Starting read
2023-11-26T14:55:04.633Z serialport/bindings-cpp/unixRead Starting read
2023-11-26T14:55:04.633Z serialport/bindings-cpp/unixRead Starting read
2023-11-26T14:55:04.634Z serialport/bindings-cpp/unixRead Starting read
2023-11-26T14:55:04.634Z serialport/bindings-cpp/unixRead Starting read
2023-11-26T14:55:04.634Z serialport/bindings-cpp/unixRead Starting read
2023-11-26T14:55:04.634Z serialport/bindings-cpp/unixRead Starting read
2023-11-26T14:55:04.634Z serialport/bindings-cpp/unixRead Starting read
... and continues indefinitely
unixRead() should return normally or throw
I realize this is probably buggy hardware, but is it possible to work around this by implementing a simple recursion counter and throw if recursion deph exceeds 10 or so, for example?
Half of the prebuildify-cross images use python 2 prebuild/docker-images#15 so we can't build on them. I'm not sure why however.
latest
No response
No response
No response
No response
No response
N/A
N/A
N/A
This module is not correctly node version safe. While it does use Node-API, it is also including uv.h
which is listed as not being included in the stability guarantees https://nodejs.org/api/n-api.html#implications-of-abi-stability.
This is likely not a problem for a while, but there is some risk of builds not being compatible depending on the libuv changes between node versions
I need to control dcb.fOutxCtsFlow (https://github.com/serialport/bindings-cpp/blob/main/src/serialport_win.cpp#L160) value with flag from serial port configuration. Now it's linked directly to rtscts configuration, so it can't be set to false
in any way.
I have some kind of very exotic serial device that requires dcb.fOutxCtsFlow to be set to false
while dcb.fRtsControl is set to RTS_CONTROL_ENABLE
. There are the only DCB parameters that works with my device:
dcb.BaudRate = CBR_9600;
dcb.ByteSize = 8;
dcb.StopBits = TWOSTOPBITS;
dcb.Parity = EVENPARITY;
dcb.fDtrControl = DTR_CONTROL_ENABLE;
dcb.fRtsControl = RTS_CONTROL_ENABLE;
dcb.EofChar = 0x0;
dcb.ErrorChar = 0x0;
dcb.fErrorChar = 0x0;
dcb.EvtChar = 0x0;
dcb.XonChar = 0x11;
dcb.XoffChar = 0x13;
dcb.fOutxCtsFlow = FALSE; // Can't be set to FALSE using serialport library
dcb.fOutX = FALSE;
dcb.XonLim = 2048;
dcb.XoffLim = 512;
So I'm getting the following packet when setting up serial communication:
IOCTL_SERIAL_SET_HANDFLOW: Set handshake information
ControlHandShake=1
FlowReplace=64
XonLimit=2048
XoffLimit=512
11.0.3 & 12.0.1
16.20.1
No response
Alpine Docker container on Rasperry Pi Buster
ARM
NA
docker build -t node-serial-docker-test
sudo socat -d -d pty,rawer,echo=0,link=/dev/ttyUSB0 pty,rawer,echo=0,link=/dev/ttyUSB1
docker run -v /dev:/dev -it --entrypoint /bin/sh --ulimit core=-1 --privileged node-serial-docker-test
node index.js
will generate core fileSample core file provided
Crashes on startup
Not crash trying to open a port
running npm run rebuild
in the node_modules/@serialport/bindings-cpp
fixes the problem which implies it's the pre-built binaries that are the problem.
re: node-red/node-red-nodes#1027
We need to run on 11.0.x as we need to maintain NodeJS 14 support (for a little while longer)
I couldn't find any info if this is compatible with the Memory Cage of Electron 21+. Is it? I just don't want to risk that it works on my machine and users of my application are doing something differently and it crashes for them.
By the way, when searching for "electron" in the Docs, it redirects to the 9.x.x versions of the documentation, which is a bit confusing. I just don't have time right now to open a separate issue for that.
Yes
This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.
These updates are currently rate-limited. Click on a checkbox below to force their creation now.
actions/download-artifact
, actions/upload-artifact
)@typescript-eslint/eslint-plugin
, @typescript-eslint/parser
)These updates have all been created already. Click a checkbox below to force a retry/rebase of any.
debug
, @types/debug
)chai
, @types/chai
)mocha
, @types/mocha
)node
, @types/node
)@typescript-eslint/eslint-plugin
, @typescript-eslint/parser
)node
, @types/node
).github/workflows/build.yml
actions/setup-node v3
actions/checkout v3
actions/upload-artifact v3
actions/checkout v3
actions/download-artifact v3
actions/setup-node v3
.github/workflows/test.yml
actions/checkout v3
actions/setup-node v3
actions/checkout v3
actions/setup-node v3
codecov/codecov-action v3
.node-version
node 18.17.1
package.json
@serialport/bindings-interface 1.2.2
@serialport/parser-readline 11.0.0
debug 4.3.4
node-addon-api 7.0.0
node-gyp-build 4.6.0
@semantic-release/exec 6.0.3
@serialport/binding-mock 10.2.2
@types/chai 4.3.9
@types/chai-subset 1.3.4
@types/debug 4.1.10
@types/mocha 10.0.3
@types/node 18.17.17
@typescript-eslint/eslint-plugin 6.9.0
@typescript-eslint/parser 6.9.0
cc 3.0.1
chai 4.3.10
chai-subset 1.6.0
esbuild 0.19.5
esbuild-register 3.5.0
eslint 8.52.0
mocha 10.2.0
node-abi 3.45.0
node-gyp 9.4.0
nyc 15.1.0
prebuildify 5.0.1
prebuildify-cross 5.0.0
semantic-release 21.1.0
shx 0.3.4
sinon 17.0.1
typescript 5.1.6
node >=16.0.0
10.7.0
16.15.0
19.0.12
Linux raspberrypi 5.15.61-v7l+ #1579 SMP Fri Aug 26 11:13:03 BST 2022 armv7l GNU/Linux
ARM
Etc
Run a VSCode extension with serialport on a raspberry pi with the 32-bit Raspberry Pi OS.
At runtime node-gyp-build gets "default" as the value for "armv". But actually the armv on a 32-bit Raspberry Pi 4b is 7. So the result is that it compares 6 and 7 (the two prebuild arm version) agains "default" which will of course fail! The reason for that is following line https://github.com/prebuild/node-gyp-build/blob/0078d7884dfeb0e708477b3e20bfc4f520c1e2f8/index.js#L16
var vars = (process.config && process.config.variables) || {}
.
.
.
var armv = process.env.ARM_VERSION || (arch === 'arm64' ? '8' : vars.arm_version) || ''
That the arm version is correctly detected so it can detect which prebuild is the right.
You either have to set process.env.ARM_VERSION
or ensure that process.config.variables.arm_version get overwritten to "default".
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.