jcurl / RJCP.DLL.SerialPortStream

SerialPortStream is an independent implementation of System.IO.Ports.SerialPort and SerialStream for better reliability and maintainability. Default branch is 2.x and now has support for Mono with help of a C library.
Microsoft Public License
624 stars 197 forks source link

Reading same barcode returns different amount of bytes on Linux #52

Closed SovRedBit closed 6 years ago

SovRedBit commented 6 years ago

Hello, using this library with ReadAsync() i get first time a good byte array and if i continue to scan the same barcode, it will start to give me different bytes array, some of them good but mostly bad, is there any solution for this? Using Windows i can't see the problem there, the problem just on Linux, i am using Kubuntu 16.04.

jcurl commented 6 years ago

There is no support for Async in the library, it uses the .Net 4.0 BeginXXX amd EndXXX methods. That suggests the problem is in the framework wrapping this functionality as I can tell.

jcurl commented 6 years ago

Also please note that the Read methids only guarantee reading at least one byte like all other streams. If you're assuming a Read will wait for 2 bytes or more this is an error.

SovRedBit commented 6 years ago

Yes, ReadAsync comes from System.IO.Stream, and i tried to use the Read() method and it give me random byte array to, i am not really sure, but maybe the problem in libnserial? Because it working very good on Win10, the problem just on Linux.

SovRedBit commented 6 years ago

And i forget to mention that i am using netcoreapp 2.0

jcurl commented 6 years ago

You might want to provide some logs, or a test case that I can use to recreate the problem. See the "build.sh" script

#Enable this line instead of the other to build with logging
#CFLAGS="-O0 -g -Wall" cmake -DCMAKE_BUILD_TYPE=Debug -DNSLOG_ENABLED=ON .. && make
CFLAGS="-O0 -g -Wall" cmake -DCMAKE_BUILD_TYPE=Debug -DNSLOG_ENABLED=OFF .. && make

Logs are placed in text in /tmp.

Also please refer to the Wiki for enabling .NET logs.

It would be helpful if you indicate how you installed libnserial.so (compile yourself, install the provided debian package, etc.) and which version of serialportstream you're using.

jcurl commented 6 years ago

I might also state that there are test cases for BeginRead and in GoogleTest framework for libnserial which no errors have been identified. What serial driver are you using?

SovRedBit commented 6 years ago

Yes of course, the nserial.log: LogFile .Net logs show nothing interesting First time i installed "libnserial" by using deb package, but now i compiled it to get logs in tmp folder. the version of serialportstream is 2.1.2 from nuget. an example of the problem: I scan the barcode and it will show me for example "0A-0A-0A-0A-00-00-00-00-0A-0A-0A-0A" then if i scan the same barcode for the second time, it will show me: "0A-0A-0A-0A-00-00-00-00-00-00-00-00" and again it can randomly be "0A-0A-0A-0A-00-00-00-00-0A-0A-0A-0A"or something else

SovRedBit commented 6 years ago

About the driver, do you mean cdc_acm 1-9:1.0 for ttyACM0?

jcurl commented 6 years ago

I'm not too sure what's going on. The logs show you're opening and closing the port. Nothing terribly interesting. Did you see the README.md file for the issues I've seen regarding "Garbage Data on Open"? Here I would get a bunch of zero's on opening. No matter what I flush, it would remain. This would occur on USB chipsets, but not on 16550A on board chips (hard to find these days).

I generally keep a record of my own testing at https://github.com/jcurl/SerialPortStream/wiki/Driver-Compatibility-with-SerialPortStream#Linux.

jcurl commented 6 years ago

The only thing I see in the nserial.logs is that the file is being opened and closed. The problem description sounds very much like on the Wiki Driver-Compatibility-with-SerialPortStream#garbage-data-on-start.

You could try not closing the serial port between opening and closing if this helps. You could try flushing the serial port. I'm not familiar enough with the actual device drivers themselves in the kernel to say what is going wrong.

If you obtain more information, please feel free to reopen this ticket.