This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM62L: AM62L: Codesys with SPI

Part Number: AM62L

In that post, the issues encountered during standalone SPI testing were addressed by applying a patch, which resulted in stable ioctl execution time, a jitter of approximately 300 µs, and low CPU usage. Now, the SPI test program has been integrated into CODESYS as a child thread to emulate the actual usage scenario. The SPI test program is reconfigured to execute at a 1 ms period, and spi_mcu_output_test() transmits 200 bytes of data per cycle. Core 1 is dedicated solely to EtherCAT, running a 1 ms cycle with 4 axes, and the program includes only MC_Power and MC_MoveVelocity. All other programs are executed on Core 0.

When the SPI test thread is not present, Core 0 usage is 20 %–45 %, Core 1 usage is 36 %, and the EtherCAT task jitter is approximately 80 µs.

When the SPI test thread is present, Core 0 usage rises to 85 %, Core 1 usage to 45 %, the EtherCAT task jitter increases to about 260 µs, and the SPI test thread jitter reaches as high as 4 ms.

When the SPI test thread is present but EtherCAT is removed, Core 0 usage drops to 66 %, Core 1 usage to 2 %, and the SPI test thread jitter is 400 µs.

The CPU usage statistics reported by htop and CODESYS are in close agreement, and the kernel has been built with CONFIG_VIRT_CPU_ACCOUNTING_GEN enabled. After the program has run stably, the jitter statistics are manually cleared.

In summary, it can be observed that SPI and EtherCAT interfere with each other, even though they are not assigned to the same core, and that CPU usage is excessively high. Please assist in analysing the underlying issues.

  • Hello,

    May I ask how was the SPI test program was integrated into CODESYS as a child thread? Any details on steps taken to perform this integration? What is unclear to me is that my understanding is that once codesyscontrol starts in Linux, the list of child threads cannot be added to or removed as it is written in the CODESYS source code, which is not available for users (both commericial and developmental).

    It was mentioned that SPI test program was integrated as a child thread to emulate the actual usage scenario. What usage scenario is it meant to emulate and is the final goal/deployment to have this SPI program integrated or is it simply meant to simulate the scenario you are describing?

    Can you also describe what the purpose of the SPI test program is and what exactly is the SPI test program doing. Does the function the SPI program performs have any dependencies on EtherCAT communication? If so, please describe how the SPI program works. 

    -Daolin