-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
SerialPorts Linux issues #27773
Comments
Moving this to future since I've addressed issues which I found useful to fix. Remainder is stuff which is very rarely used and we can address as we need. Please upvote/comment on issues if you find this and want to have something sooner so that we can prioritize accordingly. |
Setting SerialPort.ReadBufferSize property doesn't seem to affect the Linux tty buffer: _serialPort.ReadBufferSize = 3000000; // three megabytes, this works fine in windows and lets me read a massive chunk of data, but in Linux I can't seem to read anything past 4096 bytes. later if I use _serialPort.Read(dataBuffer, 0, dataBuffer.Length); then I miss anything outside of this 4K range. I like reading a large buffer rather than lots of small reads because I'm sending files and worried that the computer freezing up could make me lose a piece of the data in the middle of the transfer I know in the past the linux kernel had an internal buffer of 4096 bytes. Is this a problem that .NET can even fix if the kernel is limiting the buffer size? I'm not strong at Linux so I'm not sure. If this can't be fixed, should an exception be thrown? |
Hi @ss4adam, yes, this is fixable (assuming kernel allows you to do so) although we might not have cycles to fix this so any help would be appreciated (note: we will be doing repo move soon so might be better to wait until that's finished). I'll update the list shortly |
Hey @krwq, not sure what "might not have cycles to fix" means, but I would love to help. Just give me some direction so that I know where I'm looking to make the fix since I'm new to github (I'll probably need to brush up on com development). Another solution I was thinking about in the case that tty buffer might not be dynamically changeable (I looked at some linux source and saw it was hardcoded in a header file N_TTY_BUF_SIZE), maybe have it just read the 4k buffer in a looping/polling manner under the covers and update bigger buffer incrementing the index as it moves along, much like normal stream reading, but then .NET users will be able to use _serialPort.ReadBufferSize = 3000000 and never know the that the linux buffer was actually never changed. |
@ss4adam "no cycles" = no time Thanks for offering the help! Note corefx will not merge any PRs after tomorrow and new repo will show up which merges coreclr and corefx. I'd recommend to wait until then before making PRs. The fix will likely be here: but you can also backtrace from here: You'll likely need to add whatever syscall you need in one of those places: |
@ss4adam also, general contributing info here: https://github.com/dotnet/corefx/#contributing-guide Note, this repo will be merging into another one in a few days. Don't panic -- if you start your work against this one, it will be trivial to continue the work in the new one. |
Just out of curiosity, @ss4adam why do you need such a large buffer ? |
@valeriob Each machine I use is different, the highest is usually over 300K baud, but most are 115200 (which would never have a problem with 4k buffer). I am able to keep up using BaseStream.Read() in a polling manner, but on windows environments I'm able to make the buffer bigger, which is useful if the application freezes and I miss one of my polling iterations. |
Thanks for explaining @ss4adam, my 2c : if you need that reliabilty you should think about doing your own polling loop in a different thread, that's how i handle it, it works fine 😄 |
@valeriob I actually do it it's own thread, but I'm still seeing dropped data when the machine gets overloaded with other applications, not exactly sure why yet. |
I have a device with a baud rate of 14400. How can I use it under Linux with system.IO.Ports |
@skang0401 currently not supported. See note above about "Non-standard low baud rates" if you're interested in adding support |
@skang0401 if you need this quite fast, you can use a project I've been doing before the Linux System.IO.Ports which is perfectly working for low baud rates starting at 50. Check here: https://github.com/Ellerbach/serialapp/, there is an existing Nuget as well: https://www.nuget.org/packages/NetCoreSerial/ |
@Ellerbach I'm not seeing you using any custom dividers in your code, I wonder if we could just simply add this specific baud rate in order to get this supported (assuming it's available on all OSes) |
Correct, those are the official baud rates.
It needs to be tested. My guess regarding the various sources is that the final check of being or not a valid baud rate is done at the driver level. So if the hardware supports any baud rate and the driver will be ok with any value, it should just support it. Historically, those baud rates are what they are because of specific oscillators used and then frequencies were basically multiplied. In our days, most serial related hardware can support a larger range of rates based either on software serial either on precise high frequency dividers. |
@Ellerbach |
@skang0401 unfortunately that's GPL project which we can't reference here. As mentioned above I think this can be achieved with If you have some time doing the testing I can support you with the pull request |
@krwq has there been any progress on the non-standard low baud rates? This pyserial implementation seems to work for my application but now I'm trying to port it over to dotnet and would be nice if this were supported |
@gmkado unfortunately we're not currently doing any active work for serial ports in dotnet/runtime. There is an orthogonal effort going on in dotnet/iot though: dotnet/iot#1832 - you can mention your scenario in there. I'd be happy to review any contributions here... |
It doesn't support non-standard high bit rates on anything but Windows it seems either. I'm trying to set 111856, and it chokes on it. I'm sorry but the above deflection to the IoT team is subpar. This isn't some implementational difference of opinion, this is the behavior of straight broken software. |
Is it possible to add an ability to enable RS-485 support on Linux according to https://www.kernel.org/doc/Documentation/serial/serial-rs485.txt ? Thanks in advance. |
Would that need a new API @slyshykO ? |
@danmoseley I can help with tests on the proper device, but I have a little experience in C#. |
Collective issue for all issues while work is still happening.
Most of the issues were identified when working on async implementation: dotnet/corefx#33027
There are still lots of failures, all of them are marked with custom
[KnownFailure]
- most of the tests won't run on CI because it doesn't have physical port.Things known to still be broken on Linux:
The text was updated successfully, but these errors were encountered: