Honeywell RS-232, Reference Manual

Page: 34 / 152

PC Communication Driver
24 RS232 Communications Reference Manual 8/99
3.6 Frequently Asked Questions ,
continued
“Can I recompile the source code with a 16-bit compiler?”
No. The AFX functions that deal with communications are completely different in the 32-bit world. Some
Win32 functions, such as Sleep, don’t exist at all in Win16. You would have to rewrite significant sections
of the physical layer.
“Why is some initialization in the constructor, while other initialization is in SetUpPort?”
The initialization that you are obligated to perform is in the constructor. The initialization, which you are
not necessarily obligated to perform, is in CElnApi::SetUpPort.
“What happens if the reply from the instrument is longer than the receive buffer whose pointer I have
passed to TransCeive?
The driver will truncate the incoming message to the length of the buffer and return an Rx overflow error.
The app should size the Rx buffer to the approximate length that you expect the reply to be. If the packet
footer is obliterated by a burst of noise, the driver will keep stuffing incoming bytes until a timeout occurs
or the end of the Rx buffer is reached, whichever happens first. If someone in the plant is running an arc
welder or a shop vacuum, the driver may very well continue happily stuffing bytes of noise until it runs out
of buffer space. Therefore, do not allocate an Rx buffer that is 65535 bytes long unless you really expect
that much data to come back.
“Why is this driver a LIB and not a DLL?”
There are two main reasons. One is because, if the interface to the driver is ever changed, it becomes a
maintenance problem for client apps to determine which version of the DLL the user has on his hard drive.
The second problem, however, has to do with memory management.
Suppose the driver is a DLL, and the app declares a new CElnApi object in the usual way (arguments to
constructor omitted for clarity):
CCommBase* pDriver = new CElnApi(…);
Even though the object was created by the app, the heap memory is nonetheless tagged as belonging to the
DLL because the implementation of CElnApi is in the DLL. This means that if the app tries to destroy the
driver in the usual way:
delete pDriver;
the system will throw an exception, because the app is trying to free memory which doesn’t belong to it.
The usual way around this problem is to disambiguate ownership of the memory by giving CElnApi a static
Factory function and a Destroy function. The app would then have to do this:
CcommBase* pDriver = CElnApi::Factory(…);
…
pDriver->Destroy();
continued next page