ByteString serialport interface

[acowley]

Added ByteString send/recv functions to the SerialPort library. I've only tested this on a Mac; I added similar interfaces to the Windows code, but it needs to be tested.

[jputcu]

I was eventually planning to add bytestring support. I don't know if I'll pull in everything, but thank you for the patches.

[metametaclass]

Windows code has some issues in "recv" function: 1) packCStringLen without qualifying BS, should be BS.packCStringLen

2) win32_ReadFile doesn`t pass type checking:

System\Hardware\Serialport\Windows.hs:39:24: Couldn't match expected type GHC.Word.Word32' with actual typeInt' Expected type: DWORD Actual type: Int In the third argument of win32_ReadFile', namelyn' In the first argument of (>>=)', namely win32_ReadFile h p n Nothing'

[metametaclass]

possible fix for Windows version of recv: recv (SerialPort h _) n = allocaBytes (fromIntegral n) $ \p -> do
recv_cnt <- win32_ReadFile h p (fromIntegral n) Nothing
liftM Just $ BS.packCStringLen (p, fromIntegral recv_cnt)

also, with this implementation extensions (ViewPatterns,TupleSections) are not needed

[acowley]

Thank you metametaclass for taking the time to fix the Windows parts. I was not happy about the state I left it in (not even compiled), but the POSIX side I was using seemed useful enough to put some pressure on the issue. Let me know if I can help with merging the patches or just getting things to match up better stylistically.

The choice to add the "String" suffix to the original functions proved very helpful as the names for the ByteString API fit in rather well, imo, so kudos on the thoughtful design.

[metametaclass]

I am already using your version of serialport with my windows fixes both on windows and posix(linux), so maybe all that remains is to merge changes into main branch.

I am also thinking about async versions of send/recv, but it requires more knownledge on internal IO workings of GHC and differences between windows and posix versions than I have.

[basvandijk]

I am also thinking about async versions of send/recv, but it requires more knownledge on internal IO workings of GHC and > differences between windows and posix versions than I have.

Let me know if you need some advice on async IO. I've recently added asynchronous implementations for the I/O functions in my usb library. They use the GHC event manager for handling events.

The Windows implementation is not working yet. I could use some help there.

[mitar]

I have made a NXT Haskell library some time ago. And it worked well on Mac OS X. I have implemented my own serial port communication (for Linux and Mac OS X). You can check it here:

https://bitbucket.org/mitar/nxt/

I am now in progress of changing it to use this package, but I am seeing that it does not set everything correctly. You can see my past code here:

https://bitbucket.org/mitar/nxt/src/1ebcede761e9/ffi/initserial.c

It took quite some time to find all the proper flags and settings for everything to work on Mac OS X an Linux. ;-) Baud is also set higher than it is possible through serialport package. ;-)

Also, Haskell part is different:

https://bitbucket.org/mitar/nxt/src/1ebcede761e9/lib/Robotics/NXT/Protocol.hs#cl-154

I use more parameters to openFd and handle should be unbuffered for Mac OS X (but it works correctly also on Linux).

[jputcu]

Hello

Serial programming is very complex and for what I was using, basic serial settings were enough. That said, I have ambitions to make it more complete and correct, so your tips are very welcome.

Greetings

Joris

On Wed, 11 Jan 2012 03:51:52 -0800 Mitar reply@reply.github.com wrote:

I have made a NXT Haskell library some time ago. And it worked well on Mac OS X. I have implemented my own serial port communication (for Linux and Mac OS X). You can check it here:

https://bitbucket.org/mitar/nxt/

I am now in progress of changing it to use this package, but I am seeing that it does not set everything correctly. You can see my past code here:

https://bitbucket.org/mitar/nxt/src/1ebcede761e9/ffi/initserial.c

It took quite some time to find all the proper flags and settings for everything to work on Mac OS X an Linux. ;-) Baud is also set higher than it is possible through serialport package. ;-)

Also, Haskell part is different:

https://bitbucket.org/mitar/nxt/src/1ebcede761e9/lib/Robotics/NXT/Protocol.hs#cl-154

I use more parameters to openFd and handle should be unbuffered for Mac OS X (but it works correctly also on Linux).

---

Reply to this email directly or view it on GitHub: https://github.com/jputcu/serialport/pull/6#issuecomment-3445431

[mitar]

Version bump?

[mitar]

BTW, send is really a too generic function name. Maybe serialSend? serialReceive?

[mitar]

Please release this.

[jputcu]

Version 0.4.3 was released two days ago.

[mitar]

Aha, because there was no change in the version, I thought that it has not yet been released. Great then!

[jputcu]

I had updated the development version some time ago. About your comment on the naming of "send" and "recv", I agree, but this is a matter of taste. You still have the "import qualified" and naming everything with the package name prefixed could lead to long names.