nRF8001 chip select pin

[MBlau]

Hi

I have a MCU with an external sensor connected via SPI sampling data at 1000Hz. Using the nRF8001 with REQN and RDYN lines is making trouble. The REQN line is pulled LOW after sending data to the nRF8001 for too long. It is pulled low by the lib from the time the data is send to the time the nRF8001 is ready to get the data. This is more then 1ms and way to long for a 1000Hz sampling from the sensor connected via SPI.

My quedtion is, is it possible to separate the REQN line from the chip select line? With a separation the SPI bus is blocked only when transmitting data via SPI.

In the lib a port named optional_chip_select is available but it seems like it is not used in the sdk.

[David Edwin]

Let me try to understand your question by re-phrasing it. You are sharing the SPI with the nRF8001 and a sensor and the sensor needs to be sampled once every 1000 times a second i,e, once every millisecond. I will assume that the sensor SPI takes about 100 micro seconds.

This means that the nRF8001 transaction must finish within 900 micro seconds, you need to run the SPI at its fastest i.e. 3MHz and also reduce the interbyte distance on the SPI.

It is also possible to bit bang an SPI on separate lines as the option of last resort so that the sensor is not disturbed and the nRF8001 can also operate.

Is my understanding correct ?

Do you think you can share some SPI analyzer traces, with REQN, RDYN and the SPI lines.

[MBlau]

Thx for the answer!

I was playing around a litte bit with 3MHz SPI connection and got it sending some values in time. As the MCU needs about 600 - 680 micro seconds for calculations with the sensor values I had a few sample rate problems (but not much). It was working fine most of the time, but I was sending just one 2 Byte value instead of like 10 4 Byte values to the nRF8001.

I will go on trying, but I think I will give the nRF51822 a try to get no timing problems on the main CPU and let the nRF51822 do all the BLE work, just sending it the values over SPI from the MCU. This sound like being a more stable solution.

I'm sorry, but I have no SPI analyzer traces.

I have been testing again. When I send 20 Bytes (on one pipe) it takes too much time until the data is send, even with the nRF8001 SPI bus running at 3 MHz and the sensors SPI bus running at 20MHz. The pure SPI transfer would be fast enough, but the REQN line is pulled low for to long.

Maybe there is another solution cause I only send data via BLE every 10th cycle (100Hz). I could split up the data and send it between the next 9 cycles, but this just doesn't seam to be the right way to handle this. And send via one pipe the receiving device has to get the data back together...

[David Edwin]

Are you using DMA on the nRF8001 SPI ? You will get much better performance with DMA as most of the time is spent in the SPI master in reloading the bytes, using a DMA will help. A simple method may be to clock 32bytes or whatever is the largest SPI packet for the nRF8001, using DMA every time the SPI is run, this may mean zero padding the actual message.

When I looked at some of the samples I see that an example micro processor spends 26 to 100 microseconds between each byte when the SPI master is loaded byte by byte. I assume that using DMA on the SPI master will be a lot faster and should be able to fit your constraint.

Can you try out the DMA option if your SPI master supports it ?

[MBlau]

I need some tome to get into DMA. Never heard it before ;) But it sounds nice. I'm actually trying to get the nRF51822 running as SPI Slave with DMA too.