Easy way to send / receive raw binary data bytes on a Serial / COM port?

[741]

Hi

Is there a package like AsyncFree or AsyncPro for Lazarus?

I had thought TLazSerial was the easiest solution - but I have to Tx/Rx raw binary data.

Regards
Stephen

[jamie]

You are after my heart "LM741" 

There are a couple of sources, SERIAL unit and or LazSerial component you can install.


What exactly is the issue here? You can't bit bang an IO pin so easy in windows, although you can do it via the standard method of control API but still, you won't get the response time if it needs to be critical.

[MarkMLl]

Is there a package like AsyncFree or AsyncPro for Lazarus?

I had thought TLazSerial was the easiest solution - but I have to Tx/Rx raw binary data.

Serial.pp is OK if you're happy managing your own threads etc., I use it routinely for bench equipment.

MarkMLl

[marcov]

I use tcomport.

[ccrause]

Is there a package like AsyncFree or AsyncPro for Lazarus?

Several options, some are listed here: https://wiki.freepascal.org/Hardware_Access#Serial_Communication

I had thought TLazSerial was the easiest solution - but I have to Tx/Rx raw binary data.

Yes, TLazSerial does not expose the ReadBuffer function of the underlying Synapse library.  You can always copy your binary data into and out of strings, but it will smell like a hack.  Or use SynaSer, but then you have to handle blocking reads in your code.

I usually work with the serial unit, but it may be a little too low level for some. Else try some of the other options.

[jamie]

If you don't checkmark the "RcvLineCRLF" property then the String contains RAW data which translates to a Dynamic Array at the end, since strings and hold anything, including #0 chars.

 If you do use the CRLF options then the data is split between those incoming line endings.

[avra]

If you are interested in file transfer over serial connection you need something like XMODEM, YMODEM or ZMODEM from ancient modem era.

I have not tested this one based on LazSerial:   
https://github.com/ivang78/xmodem

[Jurassic Pork]

Hello,

I had thought TLazSerial was the easiest solution - but I have to Tx/Rx raw binary data.

When you receive a packet of data how do you know that you have received the end of the packet ? size ? timeout ? end sequence ? other thing ?

Friendly, J.P

[CCRDude]

That's totally up to the protocol you use.
The serial connection on itself is just a stream.

It has already been mentioned that sometimes a CRLF is used as a separator, but since you mention raw binary data, it depends on whether you have control over the sender.

* You could send the length first, then the raw data, so on the receiving end, you will first read the length, then the according number of bytes.
* You could define a magic, but then you need to escape that magic if it appears within the actual data.
...

Or you don't have control, in which case the documentation of the sender will hopefully include some kind of protocol definition that helps you recognize the end.

[741]

Thanks for all the ideas.

Well, I might be tempted to use the fact that "the String contains RAW data which translates to a Dynamic Array at the end"

I'll need to re-read something on how that works first though - and I agree with the point "you can always copy your binary data into and out of strings, but it will smell like a hack.".

Basically it's partly down to convenience and expediency for now - I am converting an existing Delphi project which worked reasonably well. I'd need a way to invoke/populate a list of available COM ports, and that seems to be straightforward with LazSerial.


With 'AsyncFree" an event would occur when "some bytes" had arrived. I do not know what sets the way buffers are flushed etc, although there was a user-defined buffer size. For instance if the remote device sends 100 bytes, waits a second, then sends 100 more bytes, I never knew for sure how the data would be bunched by the USB/serial drivers.

The far side is a USB capable PIC. I'm reading and writing a protocol which is 'binary' - it is not ASCII.

It's ages since I used the project, but I think the protocol defines the packet length in the first 2 bytes.

[741]

Um... Just started some research on how to treat the 'ansistring' type as a byte array and it is not clear to me. This is what I've gathered so far -

In TLazSerial we find
{$H+}
...
   function ReadData: string;

According to Lazarus Help:
   "If the switch is on {$H+}, AND there is a maximum length (the size) specifier, the declaration is a short string declaration".
   "If no size and code page specifier are present, the above declaration can declare an ansistring OR a short string"
   
But - there is no length specifier. Here is ReadData:

Code: Pascal  [Select][+][-]

1.    function TLazSerial.ReadData: string;
2.    begin
3.      result:='';
4.      if FSynSer.Handle=INVALID_HANDLE_VALUE then
5.        ComException('can not read from a closed port.');
6.      if FRcvLineCRLF then
7.          result:=FSynSer.RecvString(0)
8.      else
9.          result:=FSynSer.RecvPacket(0);  //<---I'll be wanting this option
10.    end;

       
   
In LazSynaSer:   
   function Recvstring(timeout: integer): AnsiString; virtual;   
   function RecvPacket(Timeout: Integer): AnsiString; virtual; 
   
Back in Help:
   "Ansistrings are strings that have no length limit, and have a code page associated with them2. They are reference counted and are guaranteed to be null terminated.""
   "Internally, an ansistring is treated as a pointer"
   "The null-termination does not mean that null characters (char(0) or #0) cannot be used: the null-termination is not used internally, but is there for convenience when dealing with external routines that expect a null-terminated string"
   "When an ansistring is declared, the Free Pascal compiler initially allocates just memory for a pointer, not more."
   
   The Length function must be used to get the length of an ansistring: the length is not stored at character 0 of the ansistring. The construct
    L:=ord(S[0]);
   which was valid for Turbo Pascal shortstrings, is no longer correct for Ansistrings. The compiler will warn if such a construct is encountered.       

   Ansistrings can be typecast to PChar or Pointer types:

   Var P : Pointer; 
       PC : PChar; 
       S : AnsiString; 

   begin 
     S :='This is an ansistring'; 
     PC:=Pchar(S); 
     P :=Pointer(S);
     ...

[cdbc]

Hi
Well, look for a property "RcvLineCRLF" or "LineCRLF" in TLazSerial.
It determines, if to read a string terminated by crlf og just read the buffered data...
Q) There is no "TLazSerial.ReadPacket" ?!?
If not, can you surface such a method from protected?!?
Regards Benny

[jamie]

use a RawByteString to store the return.

The length of the string is marked outside of the characters within the string.

So using a Pchar(MyRawByteString) and a known length of the string will signal the end of the string.

#0 characters can exist within the string.

So the index value for Pchar needs to be one less than the Length(MyRawString);

of course, if Length returns 0 and you do subtract one in code you can simply test for <=0 etc.

[741]

OK thank you, I will look up "RawByteString", which is new to me.