-2

I'm not sure if this is an obvious question, but I am somewhat new to serial communication (at least never thought about it in this depth) and extremely new to Python. I have a Raspberry Pi and a linear actuator. The linear actuator has an API that provides functions that use PySerial to read and write to the hardware, and these are what I use to try and talk to the actuator.

I have implemented a more involved code that receives request data via DDS, but ultimately the purpose of the code is to write the position value extracted from that request data to the linear actuator, and in return receive the linear actuator's position value. It can write to the hardware OK, and the linear actuator extends/retracts as needed, but reading position feedback from the hardware results to a timeout & if I increase timeout value or change serial.read() to serial.read(1) (by changing the code in the API directly), it reads b'' instead. I noticed that my code, when being run, uses 100.7% CPU. By the time I read, it goes up to 101%.

There is another more basic code that I have with only a few lines that simply reads and writes to the linear actuator without the DDS stuff. Instead the position value that gets passed down to the actuator is hard-coded. This one uses the same read/write functions from the API as is without changes like I had to do for the other code. When testing with this very basic code, it only shows 5% CPU usage and reads position feedback just fine.

I couldn't understand why it would work for the basic code and not for other, especially since the sequence of actions are the same when writing/reading, and the same exact functions and parameters are used. I was beginning to wonder if somehow the high CPU usage for the more involved code affects reading of serial data.

Do any of you know whether high CPU usage would affect PySerial's ability to read data or not? Is there a correlation between the two?

sometimesLazy
  • 54
  • 8
  • 1
    Can. Depends on the code (which you didn't show). – Klaus D. Mar 22 '22 at 22:21
  • @Klaus D That's because I am not trying to ask for a specific solution for my code. It's a concept I never knew about and was asking for confirmation and a bit of explanation about it since Icouldn't find anything that explicitly said that it does affect it – sometimesLazy Mar 22 '22 at 22:22
  • It's surprising that code reading from a serial port would use 100% CPU. I would guess that somewhere in your code is something that immediately retries a failed read in an infinite loop. – Nick ODell Mar 22 '22 at 22:26
  • @NickODell There is other stuff in my code that involves threads prior to writing/reading to the hardware. I think maybe I've misused the threads causing my cpu usage to go up to 100%. I wasn't sure if I should focus on that first or something else to resolve the reading issue and that's why I asked this to see if its worth digging into the usage problem first before anything else – sometimesLazy Mar 22 '22 at 22:29
  • This kind of theoretical question is not a good fit for Stack Overflow. We prefer to see a minimal reproducible example we can base our answers on. – Klaus D. Mar 22 '22 at 22:30
  • @KlausD. Right, except I was asking about something conceptual so I know what I should set my sights on so I can resolve things myself. NOT someone to reproduce my errors and tell me what to fix. I thought Stack Overflow was a place to find some clarity may it be conceptual or directly code-related. It's ridiculous a question like mine is not allowed. Clearly people like pcamach2 didn't have a problem enlightening me about something I wasn't sure about. – sometimesLazy Mar 22 '22 at 22:36

1 Answers1

2

If you are hitting the ceiling of your CPU usage, it is possible that the PySerial process that is reading the data is not able to complete each cycle before the next sampling window (e.g. your code wants a sample per second, but the cycle takes two seconds to complete). Adding too many processes or CPU-heavy processes will eventually lead to the CPU being a bottleneck.

pcamach2
  • 443
  • 2
  • 13