nRF52832 and RFM95

[dariusBotha]

Good day,

I have seen a few people asking about connecting the Nordic devices with the RFM95/Sx1276 modules. I understand that it is SPI driven, but I am a complete novice at this (moved recently from Arduino - to have access to the bigger ram and more powerful processors). 

I had a look at the SPI example, and it shows how to write to an SPI device with a text string using nrf_drv_spi_transfer(). This, however, requires a Tx and an Rx buffer. Can you please explain why that is? Is it necessary to have both buffers? Or is there an SPI function I can call to send and receive separately? Furthermore, the documentation on the RFM95 module indicates that there are three access modes namely SIngle, Burst and FIFO. This seems to be controlled by the NSS pin ( how long it is high or low).  How do you control this? Is there an easy way to implement the different modes mentioned previously?

My question is: is there someone who can help me with an example of how to set/read a register using SPI? and if I'm lucky maybe send data?? Or is someone managed to implement this for the RFM95/Sx1278 or maybe help me to understand how to port the code from the RAK813  (which I believe has the two modules in one package)?

Thank you for your time and any assistance in helping me start my journey in the embedded C programming world

Much appreciated,

Darius

[Jørgen Holmefjord]

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

[dariusBotha]

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.

[Jørgen Holmefjord]

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)));

[dariusBotha]

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

[Jørgen Holmefjord]

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.