Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: "P E Schoen" Newsgroups: comp.lang.pascal.delphi.misc Subject: Serial port component, ComDrv32 vs SerialNG Date: Sat, 26 May 2012 20:27:24 -0400 Organization: A noiseless patient Spider Lines: 2 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: quoted-printable Injection-Date: Sun, 27 May 2012 00:27:42 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="nGGXvXLL6GwyB23nJ4M9mQ"; logging-data="20154"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/CWN52XxnW2Ky2ra3uwMRxFnE/K1Yo9H0=" X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 X-Newsreader: Microsoft Windows Live Mail 15.4.3555.308 Importance: Normal Cancel-Lock: sha1:6XkKwKLCjZXPsnyqCqH8uSqllKA= X-Priority: 3 X-MSMail-Priority: Normal Xref: csiph.com comp.lang.pascal.delphi.misc:291 For a long time I have used the SerialNG component provided by Domis=20 (http://www.torry.net/authorsmore.php?id=3D3670), and I was able to get = it to=20 work well for my application, but I had to do some tricky coding, such = as=20 setting a critical section, and saving incoming data to a separate = buffer=20 which was then used for error checking and data processing. It is an=20 integral part of two of my products, and sometimes I still get errors, = but=20 they are more likely caused by the USB serial port driver. I'm using a=20 Silicon Labs CP2103 USB device. Now I am working on another project, and I'm just reading a string of=20 comma-separated text data with CRLF after each line. The line is about = 30=20 characters and I'm transmitting at 9600 baud, 1 stop bit, no parity, and = no=20 flow control. These lines are transmitted every 300 mSec. I was able to = use=20 Hyperterm to verify that the data can be received and displayed = accurately.=20 Hyperterm is a problem on Win7 because you can't reload the HT files and = must re-enter the communication parameters, but that's just an = annoyance. But when I made a simple terminal program using D4 and the SerialNG=20 component, I would get errors where it would miss characters and even = entire=20 sequences, and I was able to get some improvement (or break it = completely)=20 by fiddling with the cluster size and receive character timeouts. I was=20 parsing the incoming data and using the memo.strings.add method to = display=20 each line when I detected a CRLF. So I thought maybe it was unsafe to do = this from the receive cluster event processor. The demo seemed to work, = but=20 it is not a simple terminal and it also displays data as hex, with a=20 date-time stamp. So, I downloaded and installed ComDrv32=20 (http://www.torry.net/pages.php?id=3D198), and confirmed that its = terminal=20 demo received and displayed the data properly, and I incorporated it in = my=20 program and it works perfectly well, without any "fiddling". I had a few = problems installing the component and I had to restart D4, but then it=20 seemed to compile and run fine. Does anyone have experience with either of these components? Or = recommend=20 another? I may try a new version of my Ortmaster application with the=20 ComDrv32 component. If I can do it more simply, I will be happy. KISS is = wonderful! Thanks, Paul=20