Comments (12)
What route should I take for debugging this further?
Hi @skmagiik, as data you're receiving with the Prolific device looks just garbled and the setup seems to work at least with the FTDI adapter: are you using the same cable for connecting to the device? Not that we are dealing with a connection issue here.
Another issue could be baud rate setup. At which baud rate are you communicating with the external device? There might be an issue with setting some/non-standard baud rates with the Prolific adapter.
Do both adapters work when you are communicating between them in a cross-over configuration with our example hardware_check
? Like for example:
$ cargo run --release --example hardware_check -- --loopback-port /dev/tty.usbserial-X /dev/tty.usbserial-Y
What does hardware_check
say?
In case you have an oscilloscope at hand, you might look at the actual data on the wire between your device and the adapter.
from serialport-rs.
Hey @sirhcel I will run that hardware check. I didn't know that existed. For the connection / baud rate etc:
The target device is the same. If i open it with tio or minicom with the same baudrate parameters I don't have any issue.
I'll report back with hardware check results soon.
from serialport-rs.
Here is the result each time I run it:
RUST_BACKTRACE=full cargo run --release --example hardware_check -- --loopback-port /dev/tty.usbserial-3240 /dev/tty.usbserial-FTBHOLDE
Finished `release` profile [optimized] target(s) in 0.02s
Running `target/release/examples/hardware_check --loopback-port /dev/tty.usbserial-3240 /dev/tty.usbserial-FTBHOLDE`
Testing '/dev/tty.usbserial-FTBHOLDE':
Testing baud rates...
9600: success
38400: success
115200: success
Testing non-standard baud rates...
10000: success
600000: success
1800000: success
Testing data bits...
Five: success
Six: success
Seven: success
Eight: success
Testing flow control...
Software: FAILED (flow control None does not match set flow control Software)
Hardware: FAILED (flow control None does not match set flow control Hardware)
None: success
Testing parity...
Odd: success
Even: success
None: success
Testing stop bits...
Two: success
One: success
Testing bytes to read and write...
SerialPort::bytes_to_write: success
SerialPort::bytes_to_read: success
Test clearing software buffers...
Input: success
Output: success
All: success
Testing data transmission...success
Testing '/dev/tty.usbserial-3240':
Testing baud rates...
9600: success
38400: success
115200: success
Testing non-standard baud rates...
10000: success
600000: success
1800000: success
Testing data bits...
Five: success
Six: success
Seven: success
Eight: success
Testing flow control...
Software: FAILED (flow control None does not match set flow control Software)
Hardware: FAILED (flow control None does not match set flow control Hardware)
None: success
Testing parity...
Odd: success
Even: success
None: success
Testing stop bits...
Two: success
One: success
Testing bytes to read and write...
SerialPort::bytes_to_write: success
SerialPort::bytes_to_read: success
Test clearing software buffers...
Input: success
Output: success
All: success
Testing data transmission...success
Testing paired ports '/dev/tty.usbserial-FTBHOLDE' and '/dev/tty.usbserial-3240':
Transmitting from /dev/tty.usbserial-FTBHOLDE to /dev/tty.usbserial-3240...
At 2000000,8,n,1,noflow...
FAILED: Custom { kind: TimedOut, error: "Operation timed out" }
thread 'main' panicked at examples/hardware_check.rs:284:13:
assertion `left == right` failed: Received message does not match sent
left: [
0x0,
0x0,
0x0,
0x0,
0x0,
0x0,
0x0,
0x0,
0x0,
0x0,
0x0,
0x0,
]
right: [
0x54,
0x65,
0x73,
0x74,
0x20,
0x4d,
0x65,
0x73,
0x73,
0x61,
0x67,
0x65,
]
stack backtrace:
0: 0x102eab400 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h01b2beffade888b2
1: 0x102ec24cc - core::fmt::write::hbadb443a71b75f23
2: 0x102ea9238 - std::io::Write::write_fmt::hc09d7755e3ead5f0
3: 0x102eab258 - std::sys_common::backtrace::print::h28349e5c25acbac7
4: 0x102eac588 - std::panicking::default_hook::{{closure}}::hd24b6196784d991e
5: 0x102eac26c - std::panicking::default_hook::hfcec80a2720c8c73
6: 0x102eace7c - std::panicking::rust_panic_with_hook::h84760468187ddc85
7: 0x102eac868 - std::panicking::begin_panic_handler::{{closure}}::he666a5eb600a7203
8: 0x102eab884 - std::sys_common::backtrace::__rust_end_short_backtrace::h592f44d2bf9f843f
9: 0x102eac5e0 - _rust_begin_unwind
10: 0x102ecc2f4 - core::panicking::panic_fmt::h98bbf7bdf4994454
11: 0x102e466b4 - hardware_check::check_test_message::h1f6f45a25f320ef3
12: 0x102e434a0 - hardware_check::main::h13a7110e26878ca3
13: 0x102e47dd8 - std::sys_common::backtrace::__rust_begin_short_backtrace::h39af040a4a38b474
14: 0x102e47df0 - std::rt::lang_start::{{closure}}::hb79ded03dedd80ed
15: 0x102ea60f0 - std::rt::lang_start_internal::h39923ab4c3913741
16: 0x102e46998 - _main
from serialport-rs.
Running with devices in the reverse order gives similar stack trace results:
thread 'main' panicked at examples/hardware_check.rs:284:13:
assertion `left == right` failed: Received message does not match sent
left: [
0x0,
0x0,
0x0,
0x0,
0x0,
0x0,
0x0,
0x0,
0x0,
0x0,
0x0,
0x0,
]
right: [
0x54,
0x65,
0x73,
0x74,
0x20,
0x4d,
0x65,
0x73,
0x73,
0x61,
0x67,
0x65,
]
stack backtrace:
0: 0x100e8b400 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h01b2beffade888b2
1: 0x100ea24cc - core::fmt::write::hbadb443a71b75f23
2: 0x100e89238 - std::io::Write::write_fmt::hc09d7755e3ead5f0
3: 0x100e8b258 - std::sys_common::backtrace::print::h28349e5c25acbac7
4: 0x100e8c588 - std::panicking::default_hook::{{closure}}::hd24b6196784d991e
5: 0x100e8c26c - std::panicking::default_hook::hfcec80a2720c8c73
6: 0x100e8ce7c - std::panicking::rust_panic_with_hook::h84760468187ddc85
7: 0x100e8c868 - std::panicking::begin_panic_handler::{{closure}}::he666a5eb600a7203
8: 0x100e8b884 - std::sys_common::backtrace::__rust_end_short_backtrace::h592f44d2bf9f843f
9: 0x100e8c5e0 - _rust_begin_unwind
10: 0x100eac2f4 - core::panicking::panic_fmt::h98bbf7bdf4994454
11: 0x100e266b4 - hardware_check::check_test_message::h1f6f45a25f320ef3
12: 0x100e2348c - hardware_check::main::h13a7110e26878ca3
13: 0x100e27dd8 - std::sys_common::backtrace::__rust_begin_short_backtrace::h39af040a4a38b474
14: 0x100e27df0 - std::rt::lang_start::{{closure}}::hb79ded03dedd80ed
15: 0x100e860f0 - std::rt::lang_start_internal::h39923ab4c3913741
16: 0x100e26998 - _main
from serialport-rs.
This result does not look like what I would have expected in the first place: the received data is all zeroes where I would have expected some garbled data from what you reported in the description.
Well. As you told, that the Prolific adapter works in combination with Minicom - could you please give this combo a spin? May be the initialization sequence of Minicom makes a difference here and we can investigate this further. Like before, with both adapters connected in a cross-over fashion. We have two more examples for this scenario:
-
receive_data
to just print the received data to stdout. I've fixed this with #191, as I did not see any output on macOS in the first place. Please use the revision from the PR for testing. You could read the data you type into Minicom as shown below. Please cross-check that flow control is disabled and be aware that linebreaks will not work (as Minicom just sends them as\r
).$ cargo run --example receive_data -- /dev/tty.usbserial-X 115200
-
transmit
just sends some string at a regular interval. To send some data to Minicom, you could use this as follows:$ cargo run --example transmit -- --string 'ping ' /dev/tty.usbserial-X 115200
Does this get you some data to be transmitted or received as expected with the Prolific adapter?
from serialport-rs.
Alright, I was incorrect. Minicom is also having some issues reading the serial device:
Minicom shows the '.' char as a ? when transmitting from the known working to the Prolific adapter. Trying to transmit from either minicom or tio via the working adapter doesn't succeed with the receive_data.
However, tio (https://github.com/tio/tio) is not having any issues receiving
On the receive test, no matter which solution I tested we don't receive any data here:
from serialport-rs.
For future reference. I modified the tio source code to print the termios struct and it did look significantly different than the termios struct that this library tried to write to the tty. Even replicating this struct exactly across to the serialport-rs library and running the example did not resolve. I'm not sure what else could be the culprit.
from serialport-rs.
Thank you for pursuing the topic! This sounds strange indeed. Have you looked at ioctl::iossiospeed
in this context as well? Just using the termios struct is likely not enough.
And by the way, thank you for the pointer to tio! This is a neat tool I did not know beforehand.
from serialport-rs.
I have tried getting that to work, but I was getting an error result (-1) with an errno value of 14 Invalid file descriptor.
I tried submitting fd.0 as well as fd.into_raw() without success.
from serialport-rs.
If you could publish this to a fork, I will have a look into it the next days. The fd should be valid and a small number. What fd do you actually get?
from serialport-rs.
Looks like i'm getting fd.0 == 3
I'll create a fork for it :)
from serialport-rs.
@sirhcel I did discover a solution, though I'm not sure if there is a better way to resolve. Please see my pull request:
Resolve Mac OS setting Prolific Technology adapter #194
from serialport-rs.
Related Issues (20)
- Unplug serial device cause system shutdown on windows HOT 8
- Fast receive missing beginning of packet HOT 3
- Tracking issue for WebSerial support. HOT 1
- Can Add Mark and Space to Parity? HOT 1
- Configurable buffer size HOT 1
- Update dependency on nix to 0.28 HOT 3
- Potentially confusing read_exact timeout semantics HOT 1
- wrong serial number for FTDI modules ? HOT 1
- Timeout reading SerialUSB from Arduino DUE or GIGA HOT 3
- Outdated documentation for TTYPort HOT 2
- Opening a COM port on Windows fails HOT 5
- Cannot list virtual serial ports on Windows 10 HOT 3
- Serial port operation has different performance in (windows10 \ MacOS) HOT 3
- Wrong serial number and missing interface number for FTDI multi-port device on Windows HOT 4
- Serial port doesn't properly open on Windows 11 HOT 5
- How to close the open port? HOT 3
- SerialPortBuilder.timeout(Duration::MAX) gives "Invalid argument" HOT 3
- Please add build instructions HOT 2
- macos and Windows disagree on interface numbering for Black Magic Probe HOT 12
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from serialport-rs.