Run the ChunkedReaderT given an initial state.

The initial state represents excess bytes carried over from a previous run. When invoking runChunkedReaderT for the first time you can safely pass the empty bytestring as the initial state.

A contrived example showing how you can manually thread the excess bytes through subsequent invocations of runChunkedReaderT:

  example ∷ InterfaceHandle → IO ()
  example ifHnd = do
    (packets1, rest1) ← runChunkedReaderT (readData ifHnd 400) empty
    print $ BS.concat packets1
    (packets2, rest2) ← runChunkedReaderT (readData ifHnd 200) rest1
    print $ BS.concat packets2

However, it is much easier to let ChunkedReaderTs monad instance handle the plumbing:

  example ∷ InterfaceHandle → IO ()
  example ifHnd =
    let reader = do packets1 ← readData ifHnd 400
                    liftIO $ print $ BS.concat packets1
                    packets2 ← readData ifHnd 200
                    liftIO $ print $ BS.concat packets1
    in runChunkedReaderT reader empty

Reads data from the given FTDI interface by performing bulk reads.

This function produces an action in the ChunkedReaderT monad that, when executed, will read exactly the requested number of bytes. Executing the readData action will block until all data is read. The result value is a list of chunks, represented as ByteStrings. This representation was choosen for efficiency reasons.

Data is read in packets. The function may choose to request more than needed in order to get the highest possible bandwidth. The excess of bytes is kept as the state of the ChunkedReaderT monad. A subsequent invocation of readData will first return bytes from the stored state before requesting more from the device itself. A consequence of this behaviour is that even when you request 100 bytes the function will actually request 512 bytes (depending on the packet size) and block until all 512 bytes are read! There is no workaround since requesting less bytes than the packet size is an error.

USB timeouts will not interrupt readData. In case of a timeout readData will simply resume reading data. A small USB timeout can degrade performance.

The FTDI latency timer can cause poor performance. If the FTDI chip can't fill a packet before the latency timer fires it is forced to send an incomplete packet. This will cause a stream of tiny packets instead of a few large packets. Performance will suffer horribly, but the request will still be completed.

If you need to make a lot of small requests then a small latency can actually improve performance.

Modem status bytes are filtered from the result. Every packet send by the FTDI chip contains 2 modem status bytes. They are not part of the data and do not count for the number of bytes read. They will not appear in the result.

Example:

  -- Read 100 data bytes from ifHnd
  (packets, rest) ← runChunkedReaderT (readData ifHnd 100) empty

These are low-level functions and as such they ignores things like:

• Max packet size
• Latency timer
• Modem status bytes

USB timeouts are not ignored, but they will prevent the request from being completed.