search

jputcu / serialport

Cross platform haskell library for using the serial port
Other
43 stars 36 forks source link

Characters following byte 0x0c are dropped #12

Closed bgamari closed 10 years ago

bgamari commented 12 years ago

It seems that recv drops any byte directly following byte 0x0c. I haven't had a chance to put together a test case yet. Early indications make it seem as though the problem might be in fdRead, however, as an empty string is returned in place of the missing byte.

bgamari commented 12 years ago

Indeed it does appear the System.Posix.IO.fdRead chokes on control characters. This isn't all that unexpected as it returns a String where here we really want a ByteString. I thought that System.Posix.IO.ByteString might hold some promise but sadly it seems that these return Strings as well. Is this a bug?

Regardless, I've put up a hacked fix to prove to myself that this is in fact the problem. It can be found in my fix-bytestring branch. My hack is clearly not merge-worthy and depends upon the posix-bytestring package. Without knowing the intended nature of System.Posix.IO.ByteString from unix, it's unclear how we should proceed.

jputcu commented 12 years ago

I've tried to recreate this problems by having my Arduino echo the characters I send it. Going from 0x00 to 0xff, and everything is fine. I'm running Linux. 0x0c is apparently "NP form feed, new page".

bgamari commented 12 years ago

Not really sure what to say beyond that I have observed the problem and have been able to reproduce it on two different machines running Ubuntu 12.04. Given this is a binary protocol, I think common sense would conclude that using String is a bad idea. This sort of thing is the exact reason ByteString exists.

jputcu commented 10 years ago

Bytestrings are used now