send more than 255 bytes by spi, nrf52

RE: send more than 255 bytes by spi, nrf52

Sumen — Mon, 14 Jun 2021 00:16:37 GMT

Been a pity on 64MHz. 🙂
But BLE + ARM good work. Thanks, Nordicsemi.

RE: send more than 255 bytes by spi, nrf52

Einar Thorsrud — Mon, 27 May 2019 06:19:29 GMT

Hi,

The answer from RK describes this perfectly:

[quote user="rols"]it's uint8_t because the DMA is limited to 255 and the SDK is designed to be compatible with the chips which do and don't have it.[/quote]

The point is that the DMA of the nRF52832 is limited to 8 bits length field. So it does not matter what you do in SW, you still cannot buypass this HW limitation.

Note that the nRF52832 was the only device in the 52 series when this thread was created. Now there are other nRF52 devices which support longer DMA transfers (for instance MAXCNT for the nRF52840 is 16 bit, even though it is only 8 for the nRF52832).

RE: send more than 255 bytes by spi, nrf52

Kolonka — Fri, 24 May 2019 23:33:37 GMT

did you changed the xxx_buffer_length's to uint16_t or the p_xxx_buffer?

RE: send more than 255 bytes by spi, nrf52

mfdevzone — Wed, 26 Apr 2017 23:09:36 GMT

If the type was set to uint16_t instead of uint8_t it would still be compatible with 255-byte limits for DMA (just don't use more than 255). Pushing such a hardware specialization/restriction in to software used more broadly than DMA is a software mistake.

Re Modifying the SDK: Even if you have source, once modified, you now have to maintain it across SDK upgrades. Avoiding changes is a good idea.

Re: Stack/SDK. 'Stack' is often used as a broad term to refer to "the software stack" entire.

RE: send more than 255 bytes by spi, nrf52

RK — Wed, 26 Apr 2017 22:57:04 GMT

it's uint8_t because the DMA is limited to 255 and the SDK is designed to be compatible with the chips which do and don't have it. And this isn't the stack, this is the SDK, and you can do whatever you like with it. I treat it as reference code.

RE: send more than 255 bytes by spi, nrf52

mfdevzone — Wed, 26 Apr 2017 22:51:29 GMT

In my opinion this is an error in the Nordic spi driver implementation, as maximum SPI write length should be set more explicitly, rather than simply because they use uint8_t for the rx_ and tx_ buffer length values.

I modified this (and tested it, though not a huge amount) by changing nrf_drv_spi.c and .h to use uint16_t for rx and tx buffers, as well as bytes_transferred in the spi_control_block_t struct.

I generally dislike modifying the stack but they provide source and this is an annoying constraint.

RE: send more than 255 bytes by spi, nrf52

makouda — Wed, 21 Sep 2016 13:19:57 GMT

I do loooooooooooooooooooooooooooooose 4 bytes :D , thanks for your answer

RE: send more than 255 bytes by spi, nrf52

RK — Wed, 21 Sep 2016 13:14:46 GMT

No there isn't a way to send more than 255 bytes in one single transfer, you need to do multiple transfers right after each other without toggling the chip select line.

And you don't 'loose' 4 bytes, you 'lose' 4 bytes.