Software for serial communications without speed limit
Clash Royale CLAN TAG#URR8PPP
I have a serial to USB device which supports speeds of 8Mbaud and 12Mbaud (based on FT232H IC). I have tested it under Windows using HTerm, works just fine, but I had to resort to HTerm with hacked config to enable support for speeds I use. During tests I noticed, that quite a few applications meant for serial comms silently limit baudrates to either 115200 or 1Mbaud (measured with an oscilloscope), if baudrate param exceeds whatever maximum they have set internally.
Now I'm trying to achieve this connection with a Linux machine (Debian in my case). Tried stty, that does not accept non-standard speed parameters. Screen seems to cap baudrate internally, since I receive nothing above 1Mbaud.
At the moment I have no space left on root to install Qt5 and cannot try out HTerm linux branch, but is there any other tool that would be able to communicate with serial devices outside normal baudrate range?
terminal tty
asked Jan 10 at 11:19
stiebrsstiebrs
1061
add a comment |
I have a serial to USB device which supports speeds of 8Mbaud and 12Mbaud (based on FT232H IC). I have tested it under Windows using HTerm, works just fine, but I had to resort to HTerm with hacked config to enable support for speeds I use. During tests I noticed, that quite a few applications meant for serial comms silently limit baudrates to either 115200 or 1Mbaud (measured with an oscilloscope), if baudrate param exceeds whatever maximum they have set internally.
Now I'm trying to achieve this connection with a Linux machine (Debian in my case). Tried stty, that does not accept non-standard speed parameters. Screen seems to cap baudrate internally, since I receive nothing above 1Mbaud.
At the moment I have no space left on root to install Qt5 and cannot try out HTerm linux branch, but is there any other tool that would be able to communicate with serial devices outside normal baudrate range?
terminal tty
asked Jan 10 at 11:19
stiebrsstiebrs
1061
1
linux has the TCSETS2 ioctl which allow you to set any speed you want (supported by the hw) viac_ispeedandc_ospeed. That's not used by thetcsetattr(3)library func or bystty. If there isn't any std utility taking advantage of it, we may hack something withLD_PRELOAD.
– mosvy
Jan 10 at 12:58
Thank you very much for the hint. A search on TCSETS2 led me to this SE question: unix.stackexchange.com/questions/327188/…. I'll try it out and report back
– stiebrs
Jan 10 at 13:37
I tried out solution proposed in question 327188 and it works, now I can even directly echo to and cat /dev/ttyUSB0. If you want reputation for this, feel free to format it as an answer and I'll accept it :) Otherwise I'll do it myself in a day or two, if no other solutions are proposed
– stiebrs
Jan 10 at 13:49
add a comment |
I have a serial to USB device which supports speeds of 8Mbaud and 12Mbaud (based on FT232H IC). I have tested it under Windows using HTerm, works just fine, but I had to resort to HTerm with hacked config to enable support for speeds I use. During tests I noticed, that quite a few applications meant for serial comms silently limit baudrates to either 115200 or 1Mbaud (measured with an oscilloscope), if baudrate param exceeds whatever maximum they have set internally.
Now I'm trying to achieve this connection with a Linux machine (Debian in my case). Tried stty, that does not accept non-standard speed parameters. Screen seems to cap baudrate internally, since I receive nothing above 1Mbaud.
At the moment I have no space left on root to install Qt5 and cannot try out HTerm linux branch, but is there any other tool that would be able to communicate with serial devices outside normal baudrate range?
terminal tty
asked Jan 10 at 11:19
stiebrsstiebrs
1061
I have a serial to USB device which supports speeds of 8Mbaud and 12Mbaud (based on FT232H IC). I have tested it under Windows using HTerm, works just fine, but I had to resort to HTerm with hacked config to enable support for speeds I use. During tests I noticed, that quite a few applications meant for serial comms silently limit baudrates to either 115200 or 1Mbaud (measured with an oscilloscope), if baudrate param exceeds whatever maximum they have set internally.
Now I'm trying to achieve this connection with a Linux machine (Debian in my case). Tried stty, that does not accept non-standard speed parameters. Screen seems to cap baudrate internally, since I receive nothing above 1Mbaud.
At the moment I have no space left on root to install Qt5 and cannot try out HTerm linux branch, but is there any other tool that would be able to communicate with serial devices outside normal baudrate range?
terminal tty
terminal tty
asked Jan 10 at 11:19
stiebrsstiebrs
1061
asked Jan 10 at 11:19
stiebrsstiebrs
1061
asked Jan 10 at 11:19
stiebrsstiebrs
1061
asked Jan 10 at 11:19
stiebrsstiebrs
1061
asked Jan 10 at 11:19
stiebrsstiebrs
1061
1061
1
linux has the TCSETS2 ioctl which allow you to set any speed you want (supported by the hw) viac_ispeedandc_ospeed. That's not used by thetcsetattr(3)library func or bystty. If there isn't any std utility taking advantage of it, we may hack something withLD_PRELOAD.
– mosvy
Jan 10 at 12:58
Thank you very much for the hint. A search on TCSETS2 led me to this SE question: unix.stackexchange.com/questions/327188/…. I'll try it out and report back
– stiebrs
Jan 10 at 13:37
I tried out solution proposed in question 327188 and it works, now I can even directly echo to and cat /dev/ttyUSB0. If you want reputation for this, feel free to format it as an answer and I'll accept it :) Otherwise I'll do it myself in a day or two, if no other solutions are proposed
– stiebrs
Jan 10 at 13:49
add a comment |
1
linux has the TCSETS2 ioctl which allow you to set any speed you want (supported by the hw) viac_ispeedandc_ospeed. That's not used by thetcsetattr(3)library func or bystty. If there isn't any std utility taking advantage of it, we may hack something withLD_PRELOAD.
– mosvy
Jan 10 at 12:58
Thank you very much for the hint. A search on TCSETS2 led me to this SE question: unix.stackexchange.com/questions/327188/…. I'll try it out and report back
– stiebrs
Jan 10 at 13:37
I tried out solution proposed in question 327188 and it works, now I can even directly echo to and cat /dev/ttyUSB0. If you want reputation for this, feel free to format it as an answer and I'll accept it :) Otherwise I'll do it myself in a day or two, if no other solutions are proposed
– stiebrs
Jan 10 at 13:49
1
1
linux has the TCSETS2 ioctl which allow you to set any speed you want (supported by the hw) via
c_ispeed and c_ospeed. That's not used by the tcsetattr(3) library func or by stty. If there isn't any std utility taking advantage of it, we may hack something with LD_PRELOAD.– mosvy
Jan 10 at 12:58
linux has the TCSETS2 ioctl which allow you to set any speed you want (supported by the hw) via
c_ispeed and c_ospeed. That's not used by the tcsetattr(3) library func or by stty. If there isn't any std utility taking advantage of it, we may hack something with LD_PRELOAD.– mosvy
Jan 10 at 12:58
Thank you very much for the hint. A search on TCSETS2 led me to this SE question: unix.stackexchange.com/questions/327188/…. I'll try it out and report back
– stiebrs
Jan 10 at 13:37
Thank you very much for the hint. A search on TCSETS2 led me to this SE question: unix.stackexchange.com/questions/327188/…. I'll try it out and report back
– stiebrs
Jan 10 at 13:37
I tried out solution proposed in question 327188 and it works, now I can even directly echo to and cat /dev/ttyUSB0. If you want reputation for this, feel free to format it as an answer and I'll accept it :) Otherwise I'll do it myself in a day or two, if no other solutions are proposed
– stiebrs
Jan 10 at 13:49
I tried out solution proposed in question 327188 and it works, now I can even directly echo to and cat /dev/ttyUSB0. If you want reputation for this, feel free to format it as an answer and I'll accept it :) Otherwise I'll do it myself in a day or two, if no other solutions are proposed
– stiebrs
Jan 10 at 13:49
add a comment |
1 Answer
1
active
oldest
votes
The Linux Documentation Project has a section on serial communication, section 12 covers the problem you are experiencing. It basically says 115.2k (sometimes 230.4k) are the usual max speed settings, in bits/sec, but goes on to describe a work-a-round by just setting the max speed and if your hardware supports higher, you'll get a higher speed. This all seems a bit archaic and crewd.
Now there are faster serial hardware options around eg RS485, I2C, SPI even I2S, ... but they usually dedicated hardware and communicate over small distances. (Apart from RS485).
I'm wondering if you are going about this the wrong way (using usb). Here's an interesting discussion regarding Raspberry pi communicating with an Arduino.
Edit after I had a coffee and read your excellent comments below.
@mosvy Durh! Yes, you are absolutely correct, LDP describes setting internal UART and nothing about external serial-> usb adapters.
@stiebrs, I wish I hadn't put RS485 into that list, it's not short distance. But speed and distance are inversely proportional. Re ftdi virual ports, yes I also was surprised, that those Speed constants hadn't moved on in the last 20 years since I looked at them, but the 2nd link I gave, they found that it wasn't baud rate per se that failed debian/ubuntu, but rather rate of delivery. Also they used their own C program, that didn't rely on standard utility. Great to hear you've solved it, with python program.
answered Jan 10 at 12:52
X TianX Tian
7,62711936
1
setting the divisor is for the standard PC serial ports -- not for USB serial adapters.
– mosvy
Jan 10 at 13:07
1
RS485 is also a serial and can be viewed as just an extension of RS232 in a sense that it provides different physical layer, but data can be (and often is) in exactly the same format, as viewed from software point of view (start/stop bits, data bits, parity, etc). As I stated in the question - I DO have hardware, that supports these speeds (as a matter of fact, it is USB-RS232-RS485 converter) and it works just fine under Windows.
– stiebrs
Jan 10 at 13:09
1
Damn comment length limitations. FTDI provides both win and *nix drivers. I had an impression, that bundled VCP drivers (ftdi_sio) should be capable of handling their devices, but I'll try to use the drivers provided by them directly. I'm more concerned about artificial limitations introduced by software developers in available serial terminal applications. Also - I wouldn't say that RS485 distance of 1.6km is small
– stiebrs
Jan 10 at 13:09
1
Just did it with python, works like a charm with bundled drivers. ser = serial.Serial(port='/dev/ttyUSB0', baudrate=12000000). I'm just too lazy to write a python application to test whether communications work or not, hence the question on SE :)
– stiebrs
Jan 10 at 13:35
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f493675%2fsoftware-for-serial-communications-without-speed-limit%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The Linux Documentation Project has a section on serial communication, section 12 covers the problem you are experiencing. It basically says 115.2k (sometimes 230.4k) are the usual max speed settings, in bits/sec, but goes on to describe a work-a-round by just setting the max speed and if your hardware supports higher, you'll get a higher speed. This all seems a bit archaic and crewd.
Now there are faster serial hardware options around eg RS485, I2C, SPI even I2S, ... but they usually dedicated hardware and communicate over small distances. (Apart from RS485).
I'm wondering if you are going about this the wrong way (using usb). Here's an interesting discussion regarding Raspberry pi communicating with an Arduino.
Edit after I had a coffee and read your excellent comments below.
@mosvy Durh! Yes, you are absolutely correct, LDP describes setting internal UART and nothing about external serial-> usb adapters.
@stiebrs, I wish I hadn't put RS485 into that list, it's not short distance. But speed and distance are inversely proportional. Re ftdi virual ports, yes I also was surprised, that those Speed constants hadn't moved on in the last 20 years since I looked at them, but the 2nd link I gave, they found that it wasn't baud rate per se that failed debian/ubuntu, but rather rate of delivery. Also they used their own C program, that didn't rely on standard utility. Great to hear you've solved it, with python program.
answered Jan 10 at 12:52
X TianX Tian
7,62711936
1
setting the divisor is for the standard PC serial ports -- not for USB serial adapters.
– mosvy
Jan 10 at 13:07
1
RS485 is also a serial and can be viewed as just an extension of RS232 in a sense that it provides different physical layer, but data can be (and often is) in exactly the same format, as viewed from software point of view (start/stop bits, data bits, parity, etc). As I stated in the question - I DO have hardware, that supports these speeds (as a matter of fact, it is USB-RS232-RS485 converter) and it works just fine under Windows.
– stiebrs
Jan 10 at 13:09
1
Damn comment length limitations. FTDI provides both win and *nix drivers. I had an impression, that bundled VCP drivers (ftdi_sio) should be capable of handling their devices, but I'll try to use the drivers provided by them directly. I'm more concerned about artificial limitations introduced by software developers in available serial terminal applications. Also - I wouldn't say that RS485 distance of 1.6km is small
– stiebrs
Jan 10 at 13:09
1
Just did it with python, works like a charm with bundled drivers. ser = serial.Serial(port='/dev/ttyUSB0', baudrate=12000000). I'm just too lazy to write a python application to test whether communications work or not, hence the question on SE :)
– stiebrs
Jan 10 at 13:35
add a comment |
The Linux Documentation Project has a section on serial communication, section 12 covers the problem you are experiencing. It basically says 115.2k (sometimes 230.4k) are the usual max speed settings, in bits/sec, but goes on to describe a work-a-round by just setting the max speed and if your hardware supports higher, you'll get a higher speed. This all seems a bit archaic and crewd.
Now there are faster serial hardware options around eg RS485, I2C, SPI even I2S, ... but they usually dedicated hardware and communicate over small distances. (Apart from RS485).
I'm wondering if you are going about this the wrong way (using usb). Here's an interesting discussion regarding Raspberry pi communicating with an Arduino.
Edit after I had a coffee and read your excellent comments below.
@mosvy Durh! Yes, you are absolutely correct, LDP describes setting internal UART and nothing about external serial-> usb adapters.
@stiebrs, I wish I hadn't put RS485 into that list, it's not short distance. But speed and distance are inversely proportional. Re ftdi virual ports, yes I also was surprised, that those Speed constants hadn't moved on in the last 20 years since I looked at them, but the 2nd link I gave, they found that it wasn't baud rate per se that failed debian/ubuntu, but rather rate of delivery. Also they used their own C program, that didn't rely on standard utility. Great to hear you've solved it, with python program.
answered Jan 10 at 12:52
X TianX Tian
7,62711936
1
setting the divisor is for the standard PC serial ports -- not for USB serial adapters.
– mosvy
Jan 10 at 13:07
1
RS485 is also a serial and can be viewed as just an extension of RS232 in a sense that it provides different physical layer, but data can be (and often is) in exactly the same format, as viewed from software point of view (start/stop bits, data bits, parity, etc). As I stated in the question - I DO have hardware, that supports these speeds (as a matter of fact, it is USB-RS232-RS485 converter) and it works just fine under Windows.
– stiebrs
Jan 10 at 13:09
1
Damn comment length limitations. FTDI provides both win and *nix drivers. I had an impression, that bundled VCP drivers (ftdi_sio) should be capable of handling their devices, but I'll try to use the drivers provided by them directly. I'm more concerned about artificial limitations introduced by software developers in available serial terminal applications. Also - I wouldn't say that RS485 distance of 1.6km is small
– stiebrs
Jan 10 at 13:09
1
Just did it with python, works like a charm with bundled drivers. ser = serial.Serial(port='/dev/ttyUSB0', baudrate=12000000). I'm just too lazy to write a python application to test whether communications work or not, hence the question on SE :)
– stiebrs
Jan 10 at 13:35
add a comment |
The Linux Documentation Project has a section on serial communication, section 12 covers the problem you are experiencing. It basically says 115.2k (sometimes 230.4k) are the usual max speed settings, in bits/sec, but goes on to describe a work-a-round by just setting the max speed and if your hardware supports higher, you'll get a higher speed. This all seems a bit archaic and crewd.
Now there are faster serial hardware options around eg RS485, I2C, SPI even I2S, ... but they usually dedicated hardware and communicate over small distances. (Apart from RS485).
I'm wondering if you are going about this the wrong way (using usb). Here's an interesting discussion regarding Raspberry pi communicating with an Arduino.
Edit after I had a coffee and read your excellent comments below.
@mosvy Durh! Yes, you are absolutely correct, LDP describes setting internal UART and nothing about external serial-> usb adapters.
@stiebrs, I wish I hadn't put RS485 into that list, it's not short distance. But speed and distance are inversely proportional. Re ftdi virual ports, yes I also was surprised, that those Speed constants hadn't moved on in the last 20 years since I looked at them, but the 2nd link I gave, they found that it wasn't baud rate per se that failed debian/ubuntu, but rather rate of delivery. Also they used their own C program, that didn't rely on standard utility. Great to hear you've solved it, with python program.
answered Jan 10 at 12:52
X TianX Tian
7,62711936
The Linux Documentation Project has a section on serial communication, section 12 covers the problem you are experiencing. It basically says 115.2k (sometimes 230.4k) are the usual max speed settings, in bits/sec, but goes on to describe a work-a-round by just setting the max speed and if your hardware supports higher, you'll get a higher speed. This all seems a bit archaic and crewd.
Now there are faster serial hardware options around eg RS485, I2C, SPI even I2S, ... but they usually dedicated hardware and communicate over small distances. (Apart from RS485).
I'm wondering if you are going about this the wrong way (using usb). Here's an interesting discussion regarding Raspberry pi communicating with an Arduino.
Edit after I had a coffee and read your excellent comments below.
@mosvy Durh! Yes, you are absolutely correct, LDP describes setting internal UART and nothing about external serial-> usb adapters.
@stiebrs, I wish I hadn't put RS485 into that list, it's not short distance. But speed and distance are inversely proportional. Re ftdi virual ports, yes I also was surprised, that those Speed constants hadn't moved on in the last 20 years since I looked at them, but the 2nd link I gave, they found that it wasn't baud rate per se that failed debian/ubuntu, but rather rate of delivery. Also they used their own C program, that didn't rely on standard utility. Great to hear you've solved it, with python program.
answered Jan 10 at 12:52
X TianX Tian
7,62711936
edited Jan 10 at 13:42
answered Jan 10 at 12:52
X TianX Tian
7,62711936
answered Jan 10 at 12:52
X TianX Tian
7,62711936
answered Jan 10 at 12:52
X TianX Tian
7,62711936
7,62711936
1
setting the divisor is for the standard PC serial ports -- not for USB serial adapters.
– mosvy
Jan 10 at 13:07
1
RS485 is also a serial and can be viewed as just an extension of RS232 in a sense that it provides different physical layer, but data can be (and often is) in exactly the same format, as viewed from software point of view (start/stop bits, data bits, parity, etc). As I stated in the question - I DO have hardware, that supports these speeds (as a matter of fact, it is USB-RS232-RS485 converter) and it works just fine under Windows.
– stiebrs
Jan 10 at 13:09
1
Damn comment length limitations. FTDI provides both win and *nix drivers. I had an impression, that bundled VCP drivers (ftdi_sio) should be capable of handling their devices, but I'll try to use the drivers provided by them directly. I'm more concerned about artificial limitations introduced by software developers in available serial terminal applications. Also - I wouldn't say that RS485 distance of 1.6km is small
– stiebrs
Jan 10 at 13:09
1
Just did it with python, works like a charm with bundled drivers. ser = serial.Serial(port='/dev/ttyUSB0', baudrate=12000000). I'm just too lazy to write a python application to test whether communications work or not, hence the question on SE :)
– stiebrs
Jan 10 at 13:35
add a comment |
1
setting the divisor is for the standard PC serial ports -- not for USB serial adapters.
– mosvy
Jan 10 at 13:07
1
RS485 is also a serial and can be viewed as just an extension of RS232 in a sense that it provides different physical layer, but data can be (and often is) in exactly the same format, as viewed from software point of view (start/stop bits, data bits, parity, etc). As I stated in the question - I DO have hardware, that supports these speeds (as a matter of fact, it is USB-RS232-RS485 converter) and it works just fine under Windows.
– stiebrs
Jan 10 at 13:09
1
Damn comment length limitations. FTDI provides both win and *nix drivers. I had an impression, that bundled VCP drivers (ftdi_sio) should be capable of handling their devices, but I'll try to use the drivers provided by them directly. I'm more concerned about artificial limitations introduced by software developers in available serial terminal applications. Also - I wouldn't say that RS485 distance of 1.6km is small
– stiebrs
Jan 10 at 13:09
1
Just did it with python, works like a charm with bundled drivers. ser = serial.Serial(port='/dev/ttyUSB0', baudrate=12000000). I'm just too lazy to write a python application to test whether communications work or not, hence the question on SE :)
– stiebrs
Jan 10 at 13:35
1
1
setting the divisor is for the standard PC serial ports -- not for USB serial adapters.
– mosvy
Jan 10 at 13:07
setting the divisor is for the standard PC serial ports -- not for USB serial adapters.
– mosvy
Jan 10 at 13:07
1
1
RS485 is also a serial and can be viewed as just an extension of RS232 in a sense that it provides different physical layer, but data can be (and often is) in exactly the same format, as viewed from software point of view (start/stop bits, data bits, parity, etc). As I stated in the question - I DO have hardware, that supports these speeds (as a matter of fact, it is USB-RS232-RS485 converter) and it works just fine under Windows.
– stiebrs
Jan 10 at 13:09
RS485 is also a serial and can be viewed as just an extension of RS232 in a sense that it provides different physical layer, but data can be (and often is) in exactly the same format, as viewed from software point of view (start/stop bits, data bits, parity, etc). As I stated in the question - I DO have hardware, that supports these speeds (as a matter of fact, it is USB-RS232-RS485 converter) and it works just fine under Windows.
– stiebrs
Jan 10 at 13:09
1
1
Damn comment length limitations. FTDI provides both win and *nix drivers. I had an impression, that bundled VCP drivers (ftdi_sio) should be capable of handling their devices, but I'll try to use the drivers provided by them directly. I'm more concerned about artificial limitations introduced by software developers in available serial terminal applications. Also - I wouldn't say that RS485 distance of 1.6km is small
– stiebrs
Jan 10 at 13:09
Damn comment length limitations. FTDI provides both win and *nix drivers. I had an impression, that bundled VCP drivers (ftdi_sio) should be capable of handling their devices, but I'll try to use the drivers provided by them directly. I'm more concerned about artificial limitations introduced by software developers in available serial terminal applications. Also - I wouldn't say that RS485 distance of 1.6km is small
– stiebrs
Jan 10 at 13:09
1
1
Just did it with python, works like a charm with bundled drivers. ser = serial.Serial(port='/dev/ttyUSB0', baudrate=12000000). I'm just too lazy to write a python application to test whether communications work or not, hence the question on SE :)
– stiebrs
Jan 10 at 13:35
Just did it with python, works like a charm with bundled drivers. ser = serial.Serial(port='/dev/ttyUSB0', baudrate=12000000). I'm just too lazy to write a python application to test whether communications work or not, hence the question on SE :)
– stiebrs
Jan 10 at 13:35
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f493675%2fsoftware-for-serial-communications-without-speed-limit%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
linux has the TCSETS2 ioctl which allow you to set any speed you want (supported by the hw) via
c_ispeedandc_ospeed. That's not used by thetcsetattr(3)library func or bystty. If there isn't any std utility taking advantage of it, we may hack something withLD_PRELOAD.– mosvy
Jan 10 at 12:58
Thank you very much for the hint. A search on TCSETS2 led me to this SE question: unix.stackexchange.com/questions/327188/…. I'll try it out and report back
– stiebrs
Jan 10 at 13:37
I tried out solution proposed in question 327188 and it works, now I can even directly echo to and cat /dev/ttyUSB0. If you want reputation for this, feel free to format it as an answer and I'll accept it :) Otherwise I'll do it myself in a day or two, if no other solutions are proposed
– stiebrs
Jan 10 at 13:49