First, I am not sure that the existing semaphore made the memory access completely atomic. I made some changes there and in the thread code to ensure that when a packet arrives, the threads cannot interrupt the data copying until the UDP callback releases the semaphore. This will add some jitter, but I'm not sure this is avoidable. I also disabled interrupts during the data copy for the same reason. As things evolve I'll try to take some jitter measurements
SPI frequency was pretty low. PicoBOB is fairly tight and I have had no issues running the SPI at 50 MHz. This really helps the ping times.
I found that oversampling the servo thread on the PRU really helps. I am not completely clear on why this is, but I think it is because of clock drift. As there is no synchronization mechanism between the two boards, it seemed to me that they would go in and out of sync with following errors worsening and improving with nothing else changing. Oversampling the servo thread seems to have fixed this in my testing and it makes sense to me as there will no longer be points where the servo thread on the PRU will 'miss' a packet from the host.
Not sure if this all makes sense to you, but it is night and day different on my bench. These settings are stable with even 1-2 ms servo thread in LinuxCNC in my testing with a pi400. I am still getting up to speed on LinuxCNC so maybe I am missing something on that side.
Few things I have found:
First, I am not sure that the existing semaphore made the memory access completely atomic. I made some changes there and in the thread code to ensure that when a packet arrives, the threads cannot interrupt the data copying until the UDP callback releases the semaphore. This will add some jitter, but I'm not sure this is avoidable. I also disabled interrupts during the data copy for the same reason. As things evolve I'll try to take some jitter measurements
SPI frequency was pretty low. PicoBOB is fairly tight and I have had no issues running the SPI at 50 MHz. This really helps the ping times.
I found that oversampling the servo thread on the PRU really helps. I am not completely clear on why this is, but I think it is because of clock drift. As there is no synchronization mechanism between the two boards, it seemed to me that they would go in and out of sync with following errors worsening and improving with nothing else changing. Oversampling the servo thread seems to have fixed this in my testing and it makes sense to me as there will no longer be points where the servo thread on the PRU will 'miss' a packet from the host.
Not sure if this all makes sense to you, but it is night and day different on my bench. These settings are stable with even 1-2 ms servo thread in LinuxCNC in my testing with a pi400. I am still getting up to speed on LinuxCNC so maybe I am missing something on that side.