SPI simultaneous transfers

[Fran89]

Dear all,

Pushing the hardware to the limits, I came up with a question about the architecture of the microcontroller itself: Can two different instances of SPIM start a transfer EXACTLY at the same time?
(Not just work simultaneously like in https://devzone.nordicsemi.com/f/nordic-q-a/29760/nrf52840-spi-simultaneous-connection).

Description:
I am using a single nRF52840-DK, running to instances of SPIM: SPIM 1 and SPIM 2 at the same time.
SPIM 1 is triggered by the compare event of TIMER 1 and a PPI channel connects them both.
SPIM 2 is triggered in the callback function of TIMER 2, no PPI channels involved.

When I trigger TIMER 1 and 2 at 100 us, it works fine, like in the following picture. The pulses are the CLK signal of each SPIM, 16 bits each. I am quite sure the interrupts are generated at the same time but one is delayed due to the other one's priority, but that's good enough.

But ideally I would like TIMER 1 to tick every 100 us and TIMER 2 every 50 or 25 us. When I change that (SPIM 2 being the yellow trace), it looks like this, SPIM 2 triggering whenever SPIM 1 allows.

Since there are four possible instances of SPIM, I had the idea they would work independently, but checking the Product Specification (https://infocenter.nordicsemi.com/pdf/nRF52840_OPS_v0.5.pdf, page 12), the block diagram shows only one physical SPIM peripheral:

In a nutshell: Is it somehow possible to start more than one SPIM transfer at the same time (if so, how?), or only one SPIM transfer can be started because they share the same physical peripheral? Or another explanation?

Best regards,

Fran89

[Fran89]

Hi,

First of all, thanks for your help, I solved my problem.

When accessing the registers directly I meant the TIMER peripheral registers. Using the example's timer initialization plus callback function was very inefficient and the cause of the delay. That was an unknown I had had since the beginning of last year. Luckily I found in the forum someone who implemented them writing the registers directly. The delay has been reduced and I have achieved a 1 us resolution, which if more than enough for what I need.

But while it works now, I am not completely sure how they are working. Where should I refer to next time when I want to learn how to use the peripherals more in detail? The infocenter is more like a reference manual and the examples are inefficient in terms of resources, I have found this forum more useful. I totally agree making my own driver using the HAL would be the most efficient.

Best regards,

[haakonsh]

The nRF52840 Product Specification is crucial. It will define how a given peripheral operates, f.ex SPIM — Serial peripheral interface master with EasyDMA. It's important to read both the operational description as well as the register description, as the registers are the interface that is used to control the peripheral. 
You can also read the given driver source file as an implementation example, but drivers usually leave out some of the functionality that is exposed by the register interface. 

In the end, the PPI peripheral gives you so many options that it's not feasible to document and create examples for a handful. 

You can for instance stream SPIM data directly to the RADIO peripheral and out onto the air, just by using a few PPI channels and EasyDMA.
If you read the peripheral documentation and its register description while knowing that any EVENT can be connected to any TASK, you will discover all sorts of state-machines that can be implemented in HW. 

[Fran89]

That last application is ultimately what I want to do, thanks for the heads up.

I will check the link and eventually open another thread if I need help for the implementation.

Thanks a lot,

Fran89