[FOUND A SOLUTION] TLazSerial component has a major bug

[Awesome Programmer]

 :'(
I am writing a program on Lazarus using TLazserial. This program is suppose to just LISTEN for incoming serial data. My program does not send any requests out. So, when I set my program to just listen and make the serial connection, CPU load exponentially goes up to 35% and stays there drags my program down. This is even before receiving a byte from the serial port. CPU Load won't come down until I disconnect from the serial port. However, if I set up my program for normal communication (Send Request and wait to receive Response), then it doesn't effect my CPU Load at all. It hangs around 0% to 1% while communicating through my serial port.

Can anyone tell me what is going on TLazSerial?

Thanks,

[Jurassic Pork]

hello,

I am writing a program on Lazarus using TLazserial. This program is suppose to just LISTEN for incoming serial data. My program does not send any requests out. So, when I set my program to just listen and make the serial connection, CPU load exponentially goes up to 35% and stays there drags my program down.

Before to say that a component has a major bug wait to be confirmed by other people.
1 - TLazSerial is a driven event component so to receive data , you haven't to do a waiting loop (to have a heavy cpu load, i suspect that you use a loop)
2 - If you program is a console program don't use TLazserial , use synaser.
3 - Show me your code

Friendly, J.P

[Awesome Programmer]

I initially used TLazSerial's serialRXData event. It caused cpu overload. Then, I decided not to use the event. Instead, I setup a Ttimer and within Ttimer's Timer Event I call read serial port command as follows. It works... However, it too causes spike in CPU LOAD. 

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

1.  
2. ...
3.  
4. procedure TForm1.ApplyComm();
5. begin
6.   case TypeDXCard.ItemIndex of
7.  
8.     0:
9.       begin
10.         DXProtocol := tDxTwo;
11.         msglen := 6;
12.         rmsglen := 5;
13.       end;
14.  
15.     1:
16.       begin
17.         DXProtocol := tDxExpress;
18.         msglen:=0;
19.         rmsglen:=0;
20.       end;
21.  
22.     else
23.       begin
24.         DXProtocol := tDxTwo;
25.         msglen := 6;
26.         rmsglen := 5;
27.       end;
28.   end;
29.         if (MComport.Active=false) then
30.         begin
31.  
32.         if (uscheck.ItemIndex=0) then
33.         begin
34.              case Commport.ItemIndex of
35.              1:MComport.Device:='/dev/ttyS0';
36.              2:MComport.Device:='/dev/ttyS1';
37.              3:MComport.Device:='/dev/ttyS2';
38.              4:MComport.Device:='/dev/ttyS3';
39.              5:MComport.Device:='/dev/ttyS4';
40.              end;
41.         end
42.         else if (uscheck.ItemIndex=1) then
43.         begin
44.              case Commport.ItemIndex of
45.              1: MComport.Device:='/dev/ttyUSB0';
46.              2: MComport.Device:='/dev/ttyUSB1';
47.              3: MComport.Device:='/dev/ttyUSB2';
48.              4: MComport.Device:='/dev/ttyUSB3';
49.              5: MComport.Device:='/dev/ttyUSB4';
50.              end;
51.         end;
52.        
53.              case BaudRate.ItemIndex of
54.              0:MComport.BaudRate:=br___300;//tmpbaud:=300;
55.              1:MComport.BaudRate:=br__1200;//tmpbaud:=1200;
56.              2:MComport.BaudRate:=br__2400;//tmpbaud:=2400;
57.              3:MComport.BaudRate:=br__4800;//tmpbaud:=4800;
58.              4:MComport.BaudRate:=br__9600;//tmpbaud:=9600;
59.              5:MComport.BaudRate:=br_19200;//tmpbaud:=19200;
60.              6:MComport.BaudRate:=br_38400;//tmpbaud:=38400;
61.              7:MComport.BaudRate:=br_57600;//tmpbaud:=57600;
62.              8:MComport.BaudRate:=br115200;//tmpbaud:=115200;
63.              end;
64.        
65.              case paritygroup.ItemIndex of
66.              0:MComport.Parity:=pEven;
67.              1:MComport.Parity:=pNone;
68.              end;
69.  
70.              MComport.StopBits:=sbOne;
71.              MComport.FlowControl:=fcNone;
72.              MComport.DataBits:=db8bits;
73.              MComport.RcvLineCRLF:=false;
74.  
75.              MComport.SynSer.EnableRTSToggle(true);
76.              MComPort.Open;
77.         end;
78. end;                      
79.                  
80. ...
81.  
82. procedure Form1.Timer1Timer(sender:TObject);
83. var RxMsg[20] : Byte;
84. begin
85.             Timer1.enabled :=false;
86.  
87.              MComport.SynSer.RecvBuffer(@RxMsg,5);
88.  
89.              Timer1.enabled := true;
90. end;
91.  
92. ...
93.  
94.  

How can that simple code cause CPU LOAD? Besides, Timer1Timer event is in it of itself a THREAD. I have done extensive test and CPU LOAD spikes to around 33% to 35% as soon as I make the serial port connection as I said above EVEN BEFORE RECEIVING anything through the serial port.

Any hints or clues will be greatly appreciated. Thanks.

[Jurassic Pork]

hello,

I initially used TLazSerial's serialRXData event. It caused cpu overload. Then, I decided not to use the event. Instead, I setup a Ttimer and within Ttimer's Timer Event I call read serial port command as follows. It works... However, it too causes spike in CPU LOAD. 
How can that simple code cause CPU LOAD? Besides, Timer1Timer event is in it of itself a THREAD. I have done extensive test and CPU LOAD spikes to around 33% to 35% as soon as I make the serial port connection as I said above EVEN BEFORE RECEIVING anything through the serial port.

it is strange ! what is your O.S ? Can you put all your code in attachment ? can you show me the first code with serialRXData event ?
Friendly, J.P

[Awesome Programmer]

Hi there. Jurassic Pork,

Your TLazSerial is awesome. I've been using your component for quiet sometime and I love it.

After much researching and poking around in your code, I have a question.

In the Synaser file, there is a comment that says, not drain CPU on large download within RecvPacket function.

What exactly do you mean by that?

That's what is going on with my program. My program is only supposed to listen for incoming serial data NOT SEND ANYTHING back on the port.

If my program is only going to listen, then it will be considered as a LARGE DOWNLOAD. My CPU usage does spike UP based on the rate of serial data is received; faster the serial data is received at the port the higher CPU usage (25% to 30%). Slower the serial Data received at the port the lower the CPU usage (7% to 1%). However, I don't see any issue with my CPU usage whenever I communicate normally through TLazSerial; Sending request and Receiving response serial data.

What would be the simple work around to fix this issue, if you understand what I am talking about? Thanks, 

[Jurassic Pork]

Hello,

it is strange ! what is your O.S ? Can you put all your code in attachment ? can you show me the first code with serialRXData event ?
Friendly, J.P

     If you don't answer to my questions or requests, i can't help you !

Friendly, J.P

[Awesome Programmer]

Hello,

it is strange ! what is your O.S ? Can you put all your code in attachment ? can you show me the first code with serialRXData event ?
Friendly, J.P

     If you don't answer to my questions or requests, i can't help you !

Friendly, J.P

My OS is Linux or Raspbian. I really can't put all of my code in an attachment. Besides, after my extensive research into my issue, I learned that Before my program even starts to process the incoming Serial Data, CPU usage goes up just by constantly receiving serial data at the port. So, the issue is within either TLazSerial or Synser.pas. All you have in your component is a THREAD just listening for Incoming Serial Data and waits for 100 million every time. That shouldn't cause this CPU usage spike.

I can show you SerialRXData code.

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

1. procedure TDxCommDlg.MComportRxData(Sender: TObject);
2. begin
3.        if (ActiveUnit<>nil) then
4.        begin
5.               MComport.Synser.RecvBuffer(@RxMsg, 5);
6.               ActiveUnit.Retreive;
7.        end;
8. end;
9.  

This code is called constantly that my program within few seconds FREEZES and all the control is lost. At which point, I had to reboot my machine.

Remember, my program is only suppose to listen for incoming Serial Data. There are no Outgoing Serial Data.
Thanks, Pork.

[Jurassic Pork]

hello,
have you try another software like cutecom to see if you have the same kind of problem ?  are you sure of your serial port ?

[tetrastes]

I can show you SerialRXData code.

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

1. procedure TDxCommDlg.MComportRxData(Sender: TObject);
2. begin
3.        if (ActiveUnit<>nil) then
4.        begin
5.               MComport.Synser.RecvBuffer(@RxMsg, 5);
6.               ActiveUnit.Retreive;
7.        end;
8. end;
9.  

This code is called constantly that my program within few seconds FREEZES and all the control is lost. At which point, I had to reboot my machine.

Have you tried RecvBufferEx instead of RecvBuffer? From my experience (though I never used TLazSerial, but synaser directly), your usage of RecvBuffer is improper. At minimum your code, as it "is called constantly", will freeze your app when there is no data at port. I would recommended you to check the code of function RecvPacket at synaser.pas, after the line

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

1. //not drain CPU on large downloads...

Oh, sorry, you have already. So you know how to use RecvBuffer properly...

[BosseB]

If all you want to do is receive serial data, then why don't you use the serial unit that ships with FreePascal and can do exactly what you need without all the extraneous fluff?
About a year or more ago I struggled with the serial port too and wrestled with TLazSerial, which brings in Synapse and if used in a console program won't even compile properly...

Look here in the official documentation.

[Awesome Programmer]

 

Thank you all for your inputs and suggestions including Jurassic Pork.

Well, I took your advice BosseB. I skipped TLazSerial and went straight to Synaser. My program actually communicates without SPIKING up the CPU USAGE. While communication (READING INCOMING SERIAL DATA ONLY), CPU usage hovering around 0% to 4% not like before 25% to 30% I am in SHOCK... I've been at this for couple of days since last week.

Well, if this is the case, I may have to do a major modification to my program. I was under the impression it was my program or Synaser was having an issue. However, this is a special case scenario. For Normal Serial Communication (Sending Request and Receiving Response), TLazSerial does work as expected and there is no CPU SPIKE.

Thanks again guys,
Have a great day.

[Thaddy]

For non-gui components are BAD. for gui they are GOOD.
I never, ever use non-visual components.