9 Cable components

In the physical world, a cable is simply a device used to propagate signals from one place to another. Some cables also transmit power. In CEF terms, the propagation of power is irrelevant and it is simply assumed that power is available to all components. Signals, on the other hand, indicate information that is transmitted. There are cases where a signal can be carried on a power "carrier". In such cases, the signal would be important to CEF, but the power itself is not.

Signals can be anything from timing to data to addresses. Timing is generally handled by the master clock and so such signals can usually be ignored. Other signals can be discrete, such as CTS (Clear to Send) indications, or they may be data. In the case of data, the signals are abstracted into a single data transference call, for performance and ease of implementation.

Thus, a CEF cable component is simply a virtual device that propagates signals. It is assumed to be connected to other components who send and receive signals from each other. In the physical world, a cable connects to a connector on a hardware device (such as a video terminal), where the connector transfers signals between the cable and the device. In CEF terms, the connector itself is a cable component. Thus, CEF allows devices with such interfaces to connect directly to each other without having to have a cable component in-between - there is an assumed cable connecting the connectors to each other. Each end of a cable has a connector which likewise serves to propagate signals from the cable to whatever the connector is connected to. The simplest "cable" is an adapter which is simply two connectors. Thus, the connector itself is a CEF cable component, which is why a standalone cable component is not necessary. This is why devices such as video terminals and printers are considered to be cable components in CEF. Their connection to the outside world is simply a connection for propagating signals. To be a little more clear, they are often referred to as "cable ends".

Could not a bus inside a computer be considered a cable as well, since its purpose is to transmit signals between components? Yes it could. And it might make sense to implement a bus that way in some cases. But generally, it is more efficient (and easier) to use the standard signal and data calls between components that are connected together. CEF cable components are the virtual analog to sending data over long distances where the sender and receiver are more decoupled and have to negotiate transmission details (such as baud rate), which are not usually needed on a system bus.

Henceforth, the term "cable" will be used to mean a CEF cable component (a "cable end"). For a cable that transmits data in a parallel manner, the interface is easiest because there is usually a strobe signal that indicates when new data is being transmitted, and a given value is transmitted all at once. The physical strobe is inherent in the sending of the data in CEF. For serial data (RS232C and ethernet, for instance), the timing of each bit is important and the speed of the data transfer can be vital. For ease of use and implementation, CEF allows a speed (corresponding to bits per second in most cases, or baud rate for RS232 emulation) to be set to 0 indicating that the sender and receiver will automatically match up the data rate. However, if emulating the negotiation of speed between components is needed, the speed can be set to a specific value so that the components will act accordingly. Also, to support some serial communication protocols, the cable can propagate data with stop bits. If speed is 0, stop bits are ignored as well, otherwise they should be treated as significant by the receiving component. Note that start bits are not considered, since they are implied.

Some cables (such as SCSI) have addresses and the normal Write operations should be used to supply an address in these cases. These cables are typically connected to multiple components, addressed via those addresses. Functions unique to cables are accessed via the TCable object, provided via the TComponent.Cable method.

The TCable class has the following methods:

Boolean Serial()

Returns true if this is a serial cable. False if parallel.

String Protocol()

Returns name of the protocol supported by this cable. Returns empty string if generic.

TUEC Transmit( int64 Speed, integer Value, integer Data_Size, integer Stop_Bits )

Calling this method transmits Value to the component. Speed is the transfer rate in bits/second. A speed of 0 indicates automatic speed matching between both ends of the cable. Data_Size is the number of bits in Value to write (0=default for component) and may be 0 to 32, inclusive. Stop bits indicate the number of stop bits for serial transfers. This calls Receive on connected cable components.

TUEC Transmit_String( int64 Speed, string Value, integer Data_Size, integer Stop_Bits )

This is the same as calling Transmit once for each byte in the string. It is provided to allow more efficient means of transmitting large amounts of data. Speed is the transfer rate in bits/second. A speed of 0 indicates automatic speed matching between both ends of the cable. Size is the number of bits in Value for each transmission (0=default for component). Stop_Bits indicates the number of stop bits for each transmit on serial transfers.

void Receive( TComponent Source, int64 Speed, integer Value, integer Data_Size, integer Stop_Bits )

Called by a Transmit from a connected cable component. Speed is the transfer rate in bits/second. A speed of 0 indicates automatic speed matching between both ends of the cable. Data_Size is the number of bits in Value to write (0=default for component) and may be 0 to 32, inclusive. Stop bits indicate the number of stop bits for serial transfers. THe component that the transmission is received from is passed in Source.

boolean Get_Data( int64 &Speed, integer &Value, integer &Data_Size, integer &Stop_Bits )

Returns the data last received. The function returns False if no data has been received since the last call to Get_Data. The parameters are ignored on call. On a successful return the parameters are filled with the data from the last Receive call.