|
|
|
|
|
|
Synopsis |
|
|
|
|
Devices
|
|
|
A representation of an FTDI device.
|
|
|
|
The type of FTDI chip in a Device. The capabilities of a device
depend on its chip type.
| Constructors | ChipType_AM | | ChipType_BM | | ChipType_2232C | | ChipType_R | | ChipType_2232H | | ChipType_4232H | |
| Instances | |
|
|
|
|
|
|
|
:: Device | USB device
| -> ChipType | | -> Device | FTDI device
| Promote a USB device to an FTDI device. You are responsible for
supplying the correct USB device and specifying the correct chip
type. There is no failsafe way to automatically determine whether a
random USB device is an actual FTDI device.
|
|
|
|
Tries to guess the type of the FTDI chip by looking at the USB
device release number of a device's descriptor. Each FTDI chip uses
a specific release number to indicate its type.
|
|
Interfaces
|
|
|
A device interface. You can imagine an interface as a port or a
communication channel. Some devices support communication over
multiple interfaces at the same time.
| Constructors | Interface_A | | Interface_B | | Interface_C | | Interface_D | |
| Instances | |
|
|
Device handles
|
|
|
You need a handle in order to communicate with a Device.
|
|
|
|
Perform a USB device reset.
|
|
|
Returns the USB timeout associated with a handle.
|
|
|
Modifies the USB timeout associated with a handle.
|
|
|
Open a device handle to enable communication. Only use this if you
can't use withDeviceHandle for some reason.
|
|
|
Release a device handle.
|
|
|
The recommended way to acquire a handle. Ensures that the handles
is released when the monadic computation is completed. Even, or
especially, when an exception is thrown.
|
|
Interface handles
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Data transfer
|
|
data ChunkedReaderT m α | Source |
|
Instances | |
|
|
|
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
|
|
Low level bulk transfers
|
|
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.
|
|
|
:: InterfaceHandle | | -> Int | Number of bytes to read
| -> IO (ByteString, Bool) | | Perform a bulk read.
Returns the data that was read (in the form of a ByteString) and a flag
which indicates whether a timeout occured during the request.
|
|
|
|
:: InterfaceHandle | | -> ByteString | Data to be written
| -> IO (Int, Bool) | | Perform a bulk write.
Returns the number of bytes that where written and a flag which indicates
whether a timeout occured during the request.
|
|
|
Control requests
|
|
|
Reset the FTDI device.
|
|
|
Clear the on-chip read buffer.
|
|
|
Clear the on-chip write buffer.
|
|
|
Returns the current value of the FTDI latency timer.
|
|
|
Set the FTDI latency timer. The latency is the amount of
milliseconds after which the FTDI chip will send a packet
regardless of the number of bytes in the packet.
|
|
|
MPSSE bitbang modes
| Constructors | BitMode_Reset | Switch off bitbang mode, back to regular serial/FIFO.
| BitMode_BitBang | Classical asynchronous bitbang mode, introduced with B-type
chips.
| BitMode_MPSSE | Multi-Protocol Synchronous Serial Engine, available on 2232x
chips.
| BitMode_SyncBitBang | Synchronous Bit-Bang Mode, available on 2232x and R-type
chips.
| BitMode_MCU | MCU Host Bus Emulation Mode, available on 2232x
chips. CPU-style fifo mode gets set via EEPROM.
| BitMode_Opto | Fast Opto-Isolated Serial Interface Mode, available on 2232x
chips.
| BitMode_CBus | Bit-Bang on CBus pins of R-type chips, configure in EEPROM
before use.
| BitMode_SyncFIFO | Single Channel Synchronous FIFO Mode, available on 2232H
chips.
|
| Instances | |
|
|
|
The bitmode controls the method of communication.
|
|
Line properties
|
|
|
Constructors | Parity_Odd | The parity bit is set to one if the number of ones in a given
set of bits is even (making the total number of ones, including
the parity bit, odd).
| Parity_Even | The parity bit is set to one if the number of ones in a given
set of bits is odd (making the total number of ones, including
the parity bit, even).
| Parity_Mark | The parity bit is always 1.
| Parity_Space | The parity bit is always 0.
|
| Instances | |
|
|
|
|
|
|
Constructors | StopBit_1 | | StopBit_15 | | StopBit_2 | |
| Instances | |
|
|
|
|
|
|
Representation of a baud rate. The most interesting part is the
instance for Bounded.
| Constructors | | Instances | |
|
|
|
Calculates the nearest representable baud rate.
|
|
|
Sets the baud rate. Internally the baud rate is represented as a
fraction. The maximum baudrate is the numerator and a special
divisor is used as the denominator. The maximum baud rate is
given by the BaudRate instance for Bounded. The divisor
consists of an integral part and a fractional part. Both parts are
limited in range. As a result not all baud rates can be accurately
represented. This function returns the nearest representable baud
rate relative to the requested baud rate. According to FTDI
documentation the maximum allowed error is 3%. The nearest
representable baud rate can be calculated with the
nearestBaudRate function.
|
|
Modem status
|
|
|
Modem status information. The modem status is send as a header for
each read access. In the absence of data the FTDI chip will
generate the status every 40 ms.
The modem status can be explicitely requested with the
pollModemStatus function.
| Constructors | ModemStatus | | msClearToSend :: Bool | Clear to send (CTS)
| msDataSetReady :: Bool | Data set ready (DTS)
| msRingIndicator :: Bool | Ring indicator (RI)
| msReceiveLineSignalDetect :: Bool | Receive line signal detect (RLSD)
| msDataReady :: Bool | Data ready (DR)
| msOverrunError :: Bool | Overrun error (OE)
| msParityError :: Bool | Parity error (PE)
| msFramingError :: Bool | Framing error (FE)
| msBreakInterrupt :: Bool | Break interrupt (BI)
| msTransmitterHoldingRegister :: Bool | Transmitter holding register (THRE)
| msTransmitterEmpty :: Bool | Transmitter empty (TEMT)
| msErrorInReceiverFIFO :: Bool | Error in RCVR FIFO
|
|
| Instances | |
|
|
|
Manually request the modem status.
|
|
Flow control
|
|
|
Constructors | RTS_CTS | Request-To-Send / Clear-To-Send
| DTR_DSR | Data-Terminal-Ready / Data-Set-Ready
| XOnXOff | Transmitter on / Transmitter off
|
|
|
|
|
Set the flow control for the FTDI chip. Use Nothing to disable flow
control.
|
|
|
Set DTR line.
|
|
|
Set RTS line.
|
|
|
Set the special event character. Use Nothing to disable the event
character.
|
|
|
Set the error character. Use Nothing to disable the error character.
|
|
Defaults
|
|
|
Default USB timeout. The timeout can be set per device handle with
the setTimeout function.
|
|
Produced by Haddock version 2.6.0 |