One component I have depended on for serial port programming over the years is TComPort, originally by Dejan Crnila.
My own private fork of it is located on BitBucket now. Known issues with my last version (5.0, last touched in 2010) include that the Packet component doesn't work properly.
Some of those bugs are fixed in the latest version on SourceForge, which Brian Gochnauer has taken over maintaining. The reason for me wanting to maintain my own version is that I believe there will be two possible schools of thought out there.
Brian's thinking, and perhaps others may agree, is that a "regular String" should be used for String read/write methods. My thinking is that AnsiString should be used in both ansi and unicode Delphi versions, because serial port protocols are either binary (8 bit) or ascii (7 bit or 8 bit) and there are NO 16 bit serial port protocols that I know of.
So that means maybe you have to cast here and there to avoid implicit cast warnings, and I say, so be it.
Anyways, the other thing that I think is weird about the latest sourceforge version is that the Async read/write method appears to do things which might cause memory corruption or crashes depending on your luck. My code used GetMem and FreeMem and allocated and copied information into distinct non-delphi-string-heap areas before they were involved in any Win32 Async API operations, to avoid unpleasantness. That appears not to be the case anymore. So I am publically disavowing that codebase, and leaving it to whoever wants to maintain it to maintain it. I am no longer formally involved in that code.
I will retain sourceforge project membership so that in the event that Brian does not resume development and someone wants to repair the current UnicodeString based codebase, I can add them as a comitter. I bear no ill will to Brian, and thank him for fixing and maintaining the project on sourceforge when I had no time to do it. But I also feel that since I was publically associated with the project for many years, I need to say, I'm not happy with the code, and I think it stinks, but I'm not going to fix it either.
I'm going back to my last version, and I'll re-add any patches that seem necessary to add that have been contributed since I stopped maintaining the project actively. Really, if I'm blaming anyone here, I'm blaming myself for not reviewing the changes as they happened to AsyncPro, for sanity and correctness. My bad.
Anyways, carry on programming serial ports with AsyncPro or with TComPort, use whatever you like, but be aware that I think there are some serious issues with the latest SourceForge version of TComPort.
My own private fork of it is located on BitBucket now. Known issues with my last version (5.0, last touched in 2010) include that the Packet component doesn't work properly.
Some of those bugs are fixed in the latest version on SourceForge, which Brian Gochnauer has taken over maintaining. The reason for me wanting to maintain my own version is that I believe there will be two possible schools of thought out there.
Brian's thinking, and perhaps others may agree, is that a "regular String" should be used for String read/write methods. My thinking is that AnsiString should be used in both ansi and unicode Delphi versions, because serial port protocols are either binary (8 bit) or ascii (7 bit or 8 bit) and there are NO 16 bit serial port protocols that I know of.
So that means maybe you have to cast here and there to avoid implicit cast warnings, and I say, so be it.
Anyways, the other thing that I think is weird about the latest sourceforge version is that the Async read/write method appears to do things which might cause memory corruption or crashes depending on your luck. My code used GetMem and FreeMem and allocated and copied information into distinct non-delphi-string-heap areas before they were involved in any Win32 Async API operations, to avoid unpleasantness. That appears not to be the case anymore. So I am publically disavowing that codebase, and leaving it to whoever wants to maintain it to maintain it. I am no longer formally involved in that code.
I will retain sourceforge project membership so that in the event that Brian does not resume development and someone wants to repair the current UnicodeString based codebase, I can add them as a comitter. I bear no ill will to Brian, and thank him for fixing and maintaining the project on sourceforge when I had no time to do it. But I also feel that since I was publically associated with the project for many years, I need to say, I'm not happy with the code, and I think it stinks, but I'm not going to fix it either.
I'm going back to my last version, and I'll re-add any patches that seem necessary to add that have been contributed since I stopped maintaining the project actively. Really, if I'm blaming anyone here, I'm blaming myself for not reviewing the changes as they happened to AsyncPro, for sanity and correctness. My bad.
Anyways, carry on programming serial ports with AsyncPro or with TComPort, use whatever you like, but be aware that I think there are some serious issues with the latest SourceForge version of TComPort.
I agree that the AnsiString should be used. There was a discussion a few weeks back in the newsgroups about the possible immutability of strings, and not to raise that topic in particular, it was clear that many of those commenting have no idea of a UART.
ReplyDeleteUntil four years ago, my work with Delphi had almost always included COM port access. OK, serial port, for those who think COM is an MS interface technology. ;)
Like you, I know of no 16-bit UART, but further, I can conceive of no reason for one to exist. Foreign languages are a non-issue. Most of the protocols with with I have worked use bit-fields, and hex values, not alphabetic messages. Where letters are used, they are most often in mnemonics, not recognizable words.
Any effort spent adapting a COM port component to wide strings default strings, or even to UTF-8 awareness is misguided at best.
It's good to know there be dragons out there. Might be time to dust off TSerial (my own longtime fave), just in case I need to connect to a UART anytime soon...
UTF8 is unicode and 8 bit. No reason why internally, the engine can not decide to convert 16 bit unicode to raw bytes, ansi or indeed utf8 based on what the receiver is expecting. Yes, most devices expect raw/ansi - but if you linked 2 pcs, utf8 is a perfect reasonable transport encoding.
ReplyDeleteThis comment has been removed by the author.
ReplyDeleteWarren, Et. al,
ReplyDeleteI (after being away for several years) thank you for working to maintain Crnila’s TComport. I have used it on most of my projects needing serial com.
I agree with you and Bill insofar that it makes good sense to keep the multi-byte symbol aspects out of the basic communication port design. Further, as one who has added his own custom features for special applications on top of the basic functions of TComport, I always wished that the essential features of the basic communication would be removed from TComport into a basic ancestor (named like TComportBasic?) of TComport.
And what about UsbSer.exe and Windows.Devices.SerialCommunication namespace? Do these allow any simplification? I agree with MS, for a change, that accessing, even old, RS232 hardware through USB seems reasonable.
See http://blogs.msdn.com/b/usbcoreblog/archive/2015/07/29/what-is-new-with-serial-in-windows-10.aspx
and https://msdn.microsoft.com/en-us/library/windows/hardware/dn707976(v=vs.85).aspx
and https://msdn.microsoft.com/en-us/library/windows/hardware/windows.devices.serialcommunication.aspx
I do not remember much about calling Windows API functions and setting up callbacks, but I wonder how complicated it would be and if it makes sense to switch over to using the Windows.Devices.SerialCommunication functions. And do the Windows.Devices.SerialCommunication functions fuss with multi-byte symbols?
Warren, Does your https://bitbucket.org/wpostma/tcomport2010 code work in Win10/Delphi 10 w/o problem?
Best regards to all, JohnH