How to do SPIM with handshakes

RE: How to do SPIM with handshakes

hmolesworth — Wed, 08 Jan 2025 21:11:26 GMT

Don't need toggle. The trick is to know the a single pin can be input to (but not output from) several GPIOTE channels. This works, I tested it on some other stuff.

#define PIN_SPIM_XON_XOFF  14
#define PPI_SPIM_SUSPEND    0
#define PPI_SPIM_RESUME     1
#define GPIOTE_SPIM_SUSPEND 0
#define GPIOTE_SPIM_RESUME  1

static void TestPPI_SPIM_SuspendResume(void)
{
    NRF_P0->OUTCLR = (1 << PIN_SPIM_XON_XOFF);
    // Configuration                       Direction    Input            Pullup         Drive Level      Sense Level
    // ================================    ==========   ==============   ============   ==============   =============
    NRF_P0->PIN_CNF[PIN_SPIM_XON_XOFF]  = (PIN_INPUT  | PIN_CONNECT    | PIN_PULLNONE | PIN_DRIVE_H0H1 | PIN_SENSE_LOW);

    // Configure input for resume on rising edge with suspend on falling edge
    NRF_GPIOTE->CONFIG[GPIOTE_SPIM_RESUME]  = GPIOTE_CONFIG_MODE_Event      << GPIOTE_CONFIG_MODE_Pos     |
                                              GPIOTE_CONFIG_POLARITY_LoToHi << GPIOTE_CONFIG_POLARITY_Pos |
                                              PIN_SPIM_XON_XOFF             << GPIOTE_CONFIG_PSEL_Pos     |
                                              GPIOTE_CONFIG_OUTINIT_Low     << GPIOTE_CONFIG_OUTINIT_Pos;
    NRF_GPIOTE->CONFIG[GPIOTE_SPIM_SUSPEND] = GPIOTE_CONFIG_MODE_Event      << GPIOTE_CONFIG_MODE_Pos     |
                                              GPIOTE_CONFIG_POLARITY_HiToLo << GPIOTE_CONFIG_POLARITY_Pos |
                                              PIN_SPIM_XON_XOFF             << GPIOTE_CONFIG_PSEL_Pos     |
                                              GPIOTE_CONFIG_OUTINIT_Low     << GPIOTE_CONFIG_OUTINIT_Pos;

    // Resume SPIM transfer on rising edge of pulse via PPI
    NRF_PPI->CH[PPI_SPIM_RESUME].EEP = (uint32_t)&NRF_GPIOTE->EVENTS_IN[GPIOTE_CHANNEL_B];
    NRF_PPI->CH[PPI_SPIM_RESUME].TEP = (uint32_t)&NRF_SPIM0->TASKS_RESUME;

    // Suspend SPIM transfer on falling edge via PPI
    NRF_PPI->CH[PPI_SPIM_SUSPEND].EEP = (uint32_t)&NRF_GPIOTE->EVENTS_IN[GPIOTE_CHANNEL_A]; // Event
    NRF_PPI->CH[PPI_SPIM_SUSPEND].TEP = (uint32_t)&NRF_SPIM0->TASKS_SUSPEND;                // Task #1
    // Let's add an EGU interrupt to play with
    NRF_PPI->FORK[PPI_SPIM_SUSPEND].TEP = (uint32_t)&NRF_EGU0->TASKS_TRIGGER[0];            // Task #2

    // Enable the Suspend/Resume PPI channels
    NRF_GPIOTE->EVENTS_PORT = 0;
    NRF_PPI->CHENSET = (1UL << PPI_SPIM_RESUME) | (1UL << PPI_SPIM_SUSPEND);

    blah_blah();
}

RE: How to do SPIM with handshakes

Randy Lee — Wed, 08 Jan 2025 18:35:33 GMT

OK, this is more in line with my understanding of how this works.... I'll try to deal with it that direction. Timing could be somewhat tight here but it helps that these parts are fast....

Thanx for you folks help on this; you guys are great at it...

RE: How to do SPIM with handshakes

Hieu — Wed, 08 Jan 2025 17:48:57 GMT

You are right that there is only a single event for both edge. The PPI will not actually pingpong anything. It will simply trigger the PPI channel that is enabled.

So, if both the suspend and resume channels are enabled, both tasks are triggered, which is obviously not what we want, and I have no idea what will happen in that case.

And you are also completely right that you will need to use ISR.

There are several options to do this:

Manual "pingpong" like you mentioned. The simplest and fastest (shortest ISR time) way is to only enable one of the two PPI channels during initialization.
The ISR handle will disable one channel and enable the other.
1. A potential downside with this approach is a race condition if the next edge arrive before the ISR handling is done.
  How big a risk this is depends on the particularities of your system. There might be ways to work around it.
The ISR handler controls the SPI suspending and resuming. It can do both tasks; or it can do one, and the other task is still done by PPI.

RE: How to do SPIM with handshakes

Randy Lee — Tue, 07 Jan 2025 15:48:51 GMT

Yah, I get the HITOLO and that thing... here's the question then:

I've got one pin that the HITOLO would cause a suspend and the LOTOHI would cause the resume. Setting this to check on TOGGLE makes sense since it's a single pin and both edges are significant (but different)

How then would I work nrf_drv_ppi_channel_assign() since the pin is going to generate events on both edges and the nrf_drv_gpiote_in_event_addr_get(READY_PIN) wouldn't therefor distinguish which edge it's seeing.

Does PPI just pingpong between the edges when you get both like this?

Or do I need to assign an ISR to this nrfx_gpiote_in_init() and reset the association during that (i.e. a manual pingpong)?

RE: How to do SPIM with handshakes

Hieu — Tue, 07 Jan 2025 13:08:00 GMT

Hi Randy,

The key lies in the configuration of the GPIOTE input:

    nrf_drv_gpiote_in_config_t ready_pin_config = GPIOTE_CONFIG_IN_SENSE_TOGGLE(false);

Here, a preset configuration was used. The preset configurations can be found in modules/nrfx/drivers/include/nrfx_gpiote.h.

/**
 * @brief Macro for configuring a pin to use a GPIO IN or PORT EVENT to detect low-to-high transition.
 * @details Set hi_accu to true to use IN_EVENT.
 */
#define NRFX_GPIOTE_CONFIG_IN_SENSE_LOTOHI(hi_accu) \
{                                                   \
    .sense = NRF_GPIOTE_POLARITY_LOTOHI,            \
    .pull = NRF_GPIO_PIN_NOPULL,                    \
    .is_watcher = false,                            \
    .hi_accuracy = hi_accu,                         \
    .skip_gpio_setup = false,                       \
}

/**
 * @brief Macro for configuring a pin to use a GPIO IN or PORT EVENT to detect high-to-low transition.
 * @details Set hi_accu to true to use IN_EVENT.
 */
#define NRFX_GPIOTE_CONFIG_IN_SENSE_HITOLO(hi_accu) \
{                                                   \
    .sense = NRF_GPIOTE_POLARITY_HITOLO,            \
    .pull = NRF_GPIO_PIN_NOPULL,                    \
    .is_watcher = false,                            \
    .hi_accuracy = hi_accu,                         \
    .skip_gpio_setup = false,                       \
}

/**
 * @brief Macro for configuring a pin to use a GPIO IN or PORT EVENT to detect any change on the pin.
 * @details Set hi_accu to true to use IN_EVENT.
 */
#define NRFX_GPIOTE_CONFIG_IN_SENSE_TOGGLE(hi_accu) \
{                                                   \
    .sense = NRF_GPIOTE_POLARITY_TOGGLE,            \
    .pull = NRF_GPIO_PIN_NOPULL,                    \
    .is_watcher = false,                            \
    .hi_accuracy = hi_accu,                         \
    .skip_gpio_setup = false,                       \
}

You might notice the symbols are named a little different. That's because they are given aliases in integration/nrfx/legacy/nrf_drv_gpiote.h.

/** @brief Macro for forwarding the new implementation. */
#define GPIOTE_CONFIG_IN_SENSE_LOTOHI     NRFX_GPIOTE_CONFIG_IN_SENSE_LOTOHI
/** @brief Macro for forwarding the new implementation. */
#define GPIOTE_CONFIG_IN_SENSE_HITOLO     NRFX_GPIOTE_CONFIG_IN_SENSE_HITOLO
/** @brief Macro for forwarding the new implementation. */
#define GPIOTE_CONFIG_IN_SENSE_TOGGLE     NRFX_GPIOTE_CONFIG_IN_SENSE_TOGGLE

These aliases are to adapt usage of the old nrf_drv APIs to new nrfx APIs.

Hieu

RE: How to do SPIM with handshakes

Randy Lee — Mon, 06 Jan 2025 23:10:43 GMT

Thanx.. No problem on my side...

RE: How to do SPIM with handshakes

Simonr — Mon, 06 Jan 2025 15:54:44 GMT

Hi Randy

Susheel is currently out of office, and will be back on Monday next week. We're currently working through our backlog after the Christmas period, so we'll get back to you before Monday if we find the time to read through and explain the code snippet. If not you'll hear back from Susheel on Monday.

Best regards,

Simon

RE: How to do SPIM with handshakes

Randy Lee — Mon, 30 Dec 2024 21:26:21 GMT

How does this code know which edge is active and which is not? I'm looking for a down edge as suspend and an up edge as resume..

RE: How to do SPIM with handshakes

Randy Lee — Mon, 16 Dec 2024 14:28:00 GMT

Great! Thanx... this should get me there..

RE: How to do SPIM with handshakes

Susheel Nuguru — Mon, 16 Dec 2024 11:38:41 GMT

I got involved just because I saw FreeRTOS here but the code that you seek does not necessarily depend on FreeRTOS.

After you initialize the SPI using nrf_drv_spim_init, I think you can use something like below code as template to have the connections you see through PPI to the tasks.

static nrf_ppi_channel_t ppi_channel_suspend;
static nrf_ppi_channel_t ppi_channel_resume;

void gpio_ppi_init(void)
{
    APP_ERROR_CHECK(nrf_drv_gpiote_init());

    // Set up the READY_PIN as an input that can detect both active and inactive edges.
    // This will let us sense when the external device signals us to pause or resume.
    nrf_drv_gpiote_in_config_t ready_pin_config = GPIOTE_CONFIG_IN_SENSE_TOGGLE(false);
    ready_pin_config.pull = NRF_GPIO_PIN_NOPULL; // adjust if your circuit requires it.
    APP_ERROR_CHECK(nrf_drv_gpiote_in_init(READY_PIN, &ready_pin_config, NULL));

    // Reserve two PPI channels: one for pausing SPI (SUSPEND) and one for resuming it (RESUME).
    APP_ERROR_CHECK(nrf_drv_ppi_channel_alloc(&ppi_channel_suspend));
    APP_ERROR_CHECK(nrf_drv_ppi_channel_alloc(&ppi_channel_resume));

    // Link the READY_PIN's "active edge" event to the SPIM's SUSPEND task.
    // This ensures the SPI pauses when the device signals us to stop.
    APP_ERROR_CHECK(nrf_drv_ppi_channel_assign(
        ppi_channel_suspend,
        nrf_drv_gpiote_in_event_addr_get(READY_PIN),
        (uint32_t)&NRF_SPIM0->TASKS_SUSPEND
    ));

    // Link the READY_PIN's "inactive edge" event to the SPIM's RESUME task.
    // This ensures the SPI resumes when the device signals it's ready to continue.
    APP_ERROR_CHECK(nrf_drv_ppi_channel_enable(ppi_channel_suspend));
    APP_ERROR_CHECK(nrf_drv_ppi_channel_enable(ppi_channel_resume));
}

This is uncompiled code trying to show you the logic. Please use that as template.

RE: How to do SPIM with handshakes

Randy Lee — Tue, 10 Dec 2024 16:58:13 GMT

Very interesting indeed.... sounds like that's the ticket for sure. I don't suppose someone has some example code of how to do it?

RE: How to do SPIM with handshakes

hmolesworth — Tue, 10 Dec 2024 16:55:49 GMT

Yes, there is a similar XON/XOFF functionality in the SPIM, use PPI to trigger hardware SPIM TASKS_SUSPEND and TASKS_RESUME from the active and inactive edges of the external hold signal.

"A transaction can be suspended and resumed using the SUSPEND and RESUME tasks. When the SUSPEND task is triggered, the SPI master will complete transmitting and receiving the current ongoing byte before it is suspended"

RE: How to do SPIM with handshakes

Randy Lee — Tue, 10 Dec 2024 13:48:44 GMT

nuts,,,, wrong button here.. let me see if I can clear the idea.

Think of RS232 XON/XOFF functionality. In this case we're using an outside signal to hold off the transmission of bytes. When it asserts, I need to not send the next byte (while keeping the select signal asserted). Once it de-asserts, I can resume sending bytes via SPI

RE: How to do SPIM with handshakes

Simonr — Tue, 10 Dec 2024 11:48:42 GMT

I'm sorry, but I'm not sure what you're asking how to handle here. Is the READY handshake interrupting your transfers when you're not expecting it to, or what exactly is the issue here? There could be buffer that reaches its limit for example, but please share some more information here on what the issue here is.

Best regards,

Simon