The COM component is a hardware driver component for communication through asynchronous serial devices.
As of version 1.2.0 it is possible to suppress the generation of handshake line events introduced in version 1.1.13SR7. To achieve compatibility with previous versions of the COM component the new parameter LogHandshakeLines defaults to 0 (no generation of handshake line events) and will not be saved in a stack configuration when set to its default value.
As of version 1.1.13SR7 the COM component uses the AIDA_bDataFlags member of an AIDA data event to influence outgoing handshake lines not set to hardware handshake and to signal changes on incoming lines. As this feature currently is highly experimental and subject to change without notice it is not described in further detail here. The valid data flags are documented in the corresponding header file bsk_aida_com.h.
The Windows™ version of the COM component can use any serial port ("COMx:") known to the operating system. For proper operation at low bitrates or with echo suppression activated it is necessary to deactivate the fifo buffers of the uart chip. Otherwise the presence of the fifo buffers may cause inacceptable shifts in event generation when sending or receiving data. This will lead to malfunction not only with echo suppression activated, but also in combination with various upper level protocols relying on precise timings like KWP2000 (25ms fast WUP, 5Bd. WUP). As the Windows™ Operating system even in its latest versions still does not offer any means to legally modify the fifo settings from an application the correct settings must be selected manually. Please look at the Windows help for further details about activating/deactivating the fifo buffers.
The Windows™ operating system even in its latest versions lacks the possibility to read back the current state of outgoing handshake lines. So when going online the COM component sets the relevant lines to a defined state.
Due to deficiencies of the uart chips the operating system cannot notify the application when the last byte of send data has been shifted out of the output shift register. Furthermore there is no means to notify an application about the exact time when the start bit of a new byte is being received. The COM component tries to calculate the exact times. Nevertheless these deficiencies have some consequences: When waiting for data to be received the operating system has to wait for the given timeout plus an additional byte time to be shure that the received data is complete. This causes additional delays when receiving data that are noticeable especially at low bitrates. When sending data the TransmitDataDone event may be generated a few milliseconds too early or too late relative to the stop bit of the last byte sent. This becomes important when parameters shall be changed after sending data or when calculating the correct idle time for the next packet to be sent.
Using USB to serial communications adapters is not recommended. The USB bus is not capable of generating interrupts, data is therefor being polled. This prevents the echo suppression of the AIDA COM component from working. Furthermore drivers for certain hardware is known to be buggy, e. g. Prolific PL2302 based adapters do not signal a break. Worse, the adapter may not recover correctly from a long break. The PL2303 also has the severe hardware restriction of not supporting 10400bit/s. By now FTDI based adapters seem to work.
The COM component cannot be loaded under Windows 95™. The reason for this behaviour is not yet known. Please note that MS-DOS™ based Windows™ systems are in general unsupported by AIDA stack components.
One important API for serial communications is broken at least under Windows XP™. The effect on fast machines (P4@2600MHz+) is that the WaitCommEvent() function sometimes will not deliver the EV_TXEMPTY event on which the COM component relies when detecting the end of a transmission. As of version 1.3.13.3 (prerelease) and later the component uses another scheme for detecting the end of transmission which relies on undocumented behaviour of the operating system. Some testing has been done on Windows 98™, Windows NT 4.0™ and Windows 2000™ to assure that this method is compatible with older operating system versions. Nevertheless, BSK Datentechnik GmbH takes no responsibility for this component to work as expected on every operating system configuration. As soon as Microsoft has fixed the broken API the conventional component used documented behaviour shall be used again.
AIDA Overview, list of AIDA components