Remember to optimize debugging on a Linux platform

Author:drivermonkey

Mail:[email protected]

phone:13410905075

qq:196568501

Test platform:am335x

Pre-optimization Status: sampling speed 105 times/S

optimization Objectives : speed of 130 times/s (note: Based on the ADC's sample rate can theoretically reach 330 times/s)

Optimization steps:

1) Code framework can be divided into four modules (UI, business logic Management, device management, remote management) a total of 10 threads

There is a project dependency between the modules, you can not stop all of them, first remove some of the accessibility threads (such as: Key scan thread, remote command processing thread, etc.).

The next only UI, business logic processing, device management, remote management, four main thread. Compile run code to see if the sampling speed has changed. Run results

There is no noticeable change (still 105 times/s fluctuations)

2) Now suspect UI, device management, remote management These three modules are running too inefficient to cause the sampling speed to be brought up.

Each of these three threads is screened separately, and the sampling speed is checked for the same time, and there are no noticeable changes.

The result of the operation is no significant change (still 105 times/s fluctuation)

3) Now only the collection thread (all other threads stop) found the acquisition speed is also not going to go

Next block the sub-modules of the Business Processing module, and then compile and run separately to see the results of the operation, the sampling speed still no significant changes

4) To this step only the application layer code is read through the SPI bus the ADC this part of the code

Write a copy of the fake read ADC code to replace the original code, found to meet the current optimization requirements (fake read ADC code sampling rate of 280 times/S)

The current debug behavior is at least certain that the bottleneck of the ADC sample rate is not the application layer. Next debug ideas, from the application layer code to the drive layer, and the design of the hardware schematic diagram

5) Run a program with only the business logic layer code to read the ADC values and view the system status.

Discover the system process status through top view a kworker process has an exception, found that the process CPU utilization is 20%~30%.

Continue to find the data and discover that the kworker process is actually a kernel thread that handles queues in the kernel.

Seeing this kworker process gives me the first impression that the SPI read-write driver request is possible. Continue debugging the discovery call reads the ADC SPI interface sometimes it takes 5ms or even 10ms of time to return. In fact we send and receive only 4 bytes at a time. That could not be caused by the SPI driver, which could be caused by another driver, and the current run

The app only calls the SPI one driver.

Now start with the system state. By looking at the System state discovery, a drive interruption exception (103 interrupts per second) is interrupted, with significant interruptions too frequent. Actually this drives us

The system name is not used and the corresponding code is found to recompile the kernel. Rerun app capture speed directly to 258 times/S

Optimization results:

Sampling speed up to 258 times/S fully meets optimization objectives