Forum > General

[FOUND A SOLUTION] TLazSerial component has a major bug

(1/3) > >>

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,

--- Quote from: Awesome Programmer on December 14, 2021, 08:53:12 pm --- :'(
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.

--- End quote ---
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.  :o


--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} --- ... procedure TForm1.ApplyComm();begin  case TypeDXCard.ItemIndex of     0:      begin        DXProtocol := tDxTwo;        msglen := 6;        rmsglen := 5;      end;     1:      begin        DXProtocol := tDxExpress;        msglen:=0;        rmsglen:=0;      end;     else      begin        DXProtocol := tDxTwo;        msglen := 6;        rmsglen := 5;      end;  end;        if (MComport.Active=false) then        begin         if (uscheck.ItemIndex=0) then        begin             case Commport.ItemIndex of             1:MComport.Device:='/dev/ttyS0';             2:MComport.Device:='/dev/ttyS1';             3:MComport.Device:='/dev/ttyS2';             4:MComport.Device:='/dev/ttyS3';             5:MComport.Device:='/dev/ttyS4';             end;        end        else if (uscheck.ItemIndex=1) then        begin             case Commport.ItemIndex of             1: MComport.Device:='/dev/ttyUSB0';             2: MComport.Device:='/dev/ttyUSB1';             3: MComport.Device:='/dev/ttyUSB2';             4: MComport.Device:='/dev/ttyUSB3';             5: MComport.Device:='/dev/ttyUSB4';             end;        end;                     case BaudRate.ItemIndex of             0:MComport.BaudRate:=br___300;//tmpbaud:=300;             1:MComport.BaudRate:=br__1200;//tmpbaud:=1200;             2:MComport.BaudRate:=br__2400;//tmpbaud:=2400;             3:MComport.BaudRate:=br__4800;//tmpbaud:=4800;             4:MComport.BaudRate:=br__9600;//tmpbaud:=9600;             5:MComport.BaudRate:=br_19200;//tmpbaud:=19200;             6:MComport.BaudRate:=br_38400;//tmpbaud:=38400;             7:MComport.BaudRate:=br_57600;//tmpbaud:=57600;             8:MComport.BaudRate:=br115200;//tmpbaud:=115200;             end;                     case paritygroup.ItemIndex of             0:MComport.Parity:=pEven;             1:MComport.Parity:=pNone;             end;              MComport.StopBits:=sbOne;             MComport.FlowControl:=fcNone;             MComport.DataBits:=db8bits;             MComport.RcvLineCRLF:=false;              MComport.SynSer.EnableRTSToggle(true);             MComPort.Open;        end;end;                                        ... procedure Form1.Timer1Timer(sender:TObject);var RxMsg[20] : Byte;begin            Timer1.enabled :=false;              MComport.SynSer.RecvBuffer(@RxMsg,5);              Timer1.enabled := true;end; ...  
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,

--- Quote from: Awesome Programmer on December 15, 2021, 06:52:08 pm ---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.  :o
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.

--- End quote ---
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,  :)

Navigation

[0] Message Index

[#] Next page

Go to full version