What is the difference between nrf52840 spis and zephyr spis setting function

[mfinmuch]

Recently I want to add zephyr os to my nrf52840
I encountered a problem when using nrf52840 spi slave
In nrf52840, nrf_drv_spis_buffers_set(), I think it is to set (or define) spis to put the data to be sent or received in the tx/rx buffer
The spis setting (or definition) part of zephyr is not very clear
Refer to other people's writing methods, they will call spi_transceive() when they want to send or receive data
What I want to discuss is whether these two functions, spi_transceive() and nrf_drv_spis_buffers_set() do similar things? What is the difference between them?

zephyr version 2.4.99

[ejohnso49]

spi_transceive is part of the SPI driver API of Zephyr. This is a common call that will work for any supported chipset. It handles lots of internal steps and state for you. It also works for both master and slave roles on the SPI bus. In the master case, it will transmit the tx buffers provided, and receive data into rx buffers provided and then return. While in the slave case, it will wait until the master signals the start via the CS line and similarly use the provided tx/rx buffers.

nrf_drv_spis_buffers_set is a Nordic HAL function used in only the SPI slave scenario (hence the spis part of the function name). If you were to trace through the Zephyr source code, I believe you will see references within the Nordic driver to nrf_drv_spis_buffers_set. Put a different way, if you are using a Nordic SoC as a SPI slave device, spi_transceive will be calling into the Nordic driver, which will call into the Nordic HAL, and at some point call nrf_drv_spis_buffers_set.

In general you should be using the Zephyr API as much as possible. This is the most portable and simplified interface provided. You certainly can use the Nordic HAL directly, but it complicates interaction with Zephyr.

To configure your device as a SPI slave, you will need to likely modify the board's devicetree and set Kconfigs for your project to enable this functionality. I believe the default role with SPI is usually master.

[mfinmuch]

Thanks,
nrf_drv_spis_buffers_set of nrf52840 has entered IRQ_Handler to make some settings
Then where does spi_transceive enter the IRQ_Handler?
I traced down from spi_transceive, only to see that it called the api (this should refer to the corresponding board spi api?) and I did not find the IRQ_Handler that would go in when the spi interrupt was generated.
I want to make some judgments when an interruption occurs

PYL

[ejohnso49]

The IRQ handler, or rather because this is tying into the Nordic HAL, SPIS event handler, is defined internally to the Zephyr SPI driver. The Zephyr SPI driver always signals at the end of a SPI transaction, in the both the synchronous and asynchronous forms.

For instance with a device operating as a SPI slave, you would call trancsceive to receive the first n bytes. When that call returns you now have the bytes you need to act upon. The async version works similarly but uses the k_poll API to signal that the transaction completed rather than blocking the thread where the async transceive call is made.

If you're requiring finer granularity than SPI transactions, you will need to tie directly into the Nordic HAL and not use the Zephyr SPI driver calls.

[mfinmuch]

Thanks,
So if I want to improve the time it takes for zephyr to use spi_transceive, I have to use Nordic HAL directly?
I ask this question because I usedspi_transceive to implement spi slave (use zephyr on nrf52840) when doing tx (slave write to master), it took 100ms, rx (slave read from master) took 300ms, is this normal?
Then I use stm32 as the master.
It feels like it took a long time, how can I improve?

[ejohnso49]

Do you have a scope capture from this? My initial guesses on improvements would be increasing the clock frequency, and decreasing the setup time between toggling the CS line and beginning the clock. Without a capture of some sort though, this would be hard to diagnose. Additionally since SPI is master-initiated this will be introducing some latency, again the capture would help diagnose. If possible setting a GPIO and capturing it just before the transaction begins would help pinpoint how much latency is involved.

[mfinmuch]

Hello there
I use k_uptime_get_32(); to capture the current time
and I catched 304ms
Take recv as an example, as follows

start_time = k_uptime_get_32();
spi_slave_read(spi, &spi_cfg, &rx_data);
stop_time = k_uptime_get_32();
cycles_spent = stop_time - start_time;
printk("recv %d\n",cycles_spent);

Write is the same method, the time I catched is 104ms

I don't know where to set GPIO signal
Do you have suggestions?

In addition you said-->

would be increasing the clock frequency,

Does it mean that I set the value in the prj.conf file?
How to set the clock frequency?
Or do you mean set spi_cfg.frequency
I set 50M, this seems to be the maximum value that nrf52840 can set
spi_cfg.frequency = 50000000;

[ejohnso49]

I think this is likely an okay method to use, but it won't give enough information to completely understand what is going on. The best way to do that is via logic analyzer or oscilloscope. With a capture from one of these you would verify the clock frequency is actually 50 MHz, see what bytes and how many are being sent, the timing between each transaction, etc. Unfortunately I don't have the knowledge of the Zephyr internals to go too much further. I would also recommend possibly posting on the Zephyr Slack as others may see this and offer some guidance.

I would set the GPIO signal around/replace where your calls to k_uptime_get_32.