Device Names, Special Fields and Blocking

Device Names and Numbers

The FTDI driver must cope with different devices and interfaces. Eg. you will have serial or parallel interfaces but also complete devices as OBD-adapters. It is not predictionable which devices you will attach. If you are connecting a serial to USB interface it makes sense to use "Serial" as device name perhaps followed by a port number. For FTDI devices the device name shall start with "FTDI." followed by interface type (eg "SERIAL.") and then followed by a device identification (eg. "OBD"). At the end of the name you should place a number which acts as minor device number in the device claim protocol. The major device number for FTDI devices is hexadecimal 101D. Note that if you are emulating eg. a serial port you must use the major device number of a serial port (2). Inclusion of the minor number into the device name allows applications to cope with individual configurations and using the device claim protocol. They only have to look at the end of the name for a number. So a FTDI device name may look as follows:

FTDI.SERIAL.OBD2

Special Fields

In general a FDTI device is configured by the configuration file. This file defines the allowed settings and the default with which the device is initialized. However you can set some values in accordance to RISC OS serial port as special field when opening a stream. But note that you can only choose values which have been allowed inside the configuration file else you will get an error and the opening of the stream will fail.

Group Term Value
Baud rate baud Baud rate
Data Bits data Number of data Bits
Stop Bits stop Number of stop Bits
Parity noparity -
even -
odd -
Handshake nohandshake -
rts -
dtr -
xon -
Buffer size size Buffer size in Bytes
Threshold thres Threshold in Bytes

Blocking behaviour

Sleeping for taskwindows is handled by DeviceFS (Special field "sleep"). The driver also supports non blocking. However it is designed to never block on input because it will always return EOF in case that no data is pending on input side.

If using OS_BGET open the input stream in a classical way. If no data is avaible then you will obtain a set C flag pre EOF indicator. You must reset this before next read eg. using OS_Args 3 setting an extension of 0.

OS_GBPB is handled in then same way so "noblock" has no influence because the EOF evaluation operates before noblock activity.