nRF52832 and RFM95

RE: nRF52832 and RFM95

Jørgen Holmefjord — Thu, 11 Feb 2021 10:44:46 GMT

The SPI Master driver supports two modes, blocking and non-blocking. In blocking mode, you do not pass any event handlers to the init-function, and the transfer functions will do a blocking wait internally until the transfer is completed. In non-blocking mode (which is used in the example), the transfer function simply starts a transfer and continues executing code, until it receives an end notification via the event handler that is provided during initialization. The example uses a flag (spi_xfer_done) to wait for the completion of the transfer, where the flag is set in the event handler.

So you should either wait for the flag before starting a new transfer, like this:

APP_ERROR_CHECK(nrf_drv_spi_transfer(&spi, m_tx1_buf, sizeof(m_tx1_buf), NULL, 0))
 
while (!spi_xfer_done)
{
    __WFE();
}

APP_ERROR_CHECK(nrf_drv_spi_transfer(&spi, m_tx_buf, sizeof(m_tx_buf), m_rx_buf, sizeof(m_tx_buf)+sizeof(m_rx_buf)));

Or you can pass NULL to the event handler, to operate the driver in blocking mode:

APP_ERROR_CHECK(nrf_drv_spi_init(&spi, &spi_config, NULL, NULL));

Another option is to use the SPI transaction manager library, to schedule multiple background transfers.

RE: nRF52832 and RFM95

dariusBotha — Wed, 10 Feb 2021 19:44:43 GMT

Hello, I have one more question.

Why would I get a fatal error when I try to do two transfers after one another? But if I put a 100ms delay it works fine. Is there a better way to do it?

In my main code, I do the following: ( I also just have the standard spi_event_handler()

 APP_ERROR_CHECK(nrf_drv_spi_transfer(&spi, m_tx1_buf, sizeof(m_tx1_buf), NULL, 0))
 //nrf_delay_ms(1000);
 APP_ERROR_CHECK(nrf_drv_spi_transfer(&spi, m_tx_buf, sizeof(m_tx_buf), m_rx_buf, sizeof(m_tx_buf)+sizeof(m_rx_buf)));

Thank you for your assistance so far

RE: nRF52832 and RFM95

Jørgen Holmefjord — Wed, 10 Feb 2021 11:24:53 GMT

Here are some examples of using the nrf_drv_spi_transfer() function:

uint8_t m_tx_buf[1] = 0xFF;
uint8_t m_rx_buf[3];

// Write 1 byte, receive 0 bytes
APP_ERROR_CHECK(nrf_drv_spi_transfer(&spi, m_tx_buf, sizeof(m_tx_buf), NULL, 0);

// Write 0 byte, receive 3 bytes
APP_ERROR_CHECK(nrf_drv_spi_transfer(&spi, NULL, 0, m_rx_buf, sizeof(m_rx_buf));

// Write 1 byte, then receive 3 bytes after write is done
APP_ERROR_CHECK(nrf_drv_spi_transfer(&spi, m_tx_buf, sizeof(m_tx_buf), m_rx_buf, sizeof(m_tx_buf) + sizeof(m_rx_buf)));

RE: nRF52832 and RFM95

dariusBotha — Tue, 09 Feb 2021 16:49:30 GMT

Wow, thank you. That makes so much more sense now!

I will try and implement it. If it is possible could you also provide the example so I can compare and see how the correct/efficient way of programming it should look like?

Really appreciate your help.

RE: nRF52832 and RFM95

Jørgen Holmefjord — Tue, 09 Feb 2021 15:01:02 GMT

Hi,

SPI is a synchronous protocol supporting full duplex transfers. This means that data is clocked in on MISO (Master-Input, Slave-Output) pin at the same time as data is clocked out on MOSI (Master-Output, Slave-Input) pin. Using both TX and RX buffers allows you to easily check that the protocol works by connecting MOSI/MISO pins and verify that received data is equal to the transmitted data.

As the API documentation for nrf_drv_spi_transfer() mention, both buffer pointers can be NULL if there is no data to be transmitted/received.

To me, it sounds like the NSS pin is just a normal SS/CSN pin for the SPI bus. The different modes are just determined by either the number of data bytes being transmitted in a single SPI transfer, or by the address (corresponding to FIFO or not). The address is typically the first byte in the SPI transfer, then follows one or more bytes for writing/reading the given address.

I do not have any experience with RFM95/Sx1278, so I cannot help you there, but I can help you with the SPI peripheral and example if you are not able to read/write the registers in the device.

Best regards,
Jørgen