send more than 255 bytes by spi, nrf52

[makouda]

I'm communicating with N25 flash memory, the page size is 256 bytes. there is a page_program command which can write up to 256 bytes. there is no way to write in the middle of page (page @ + offset).

the issue it that SPI function has size parameter as uint8_t, so by adding the instruction code and the address to the frame (4 bytes in total), I always loose 4 bytes for each page.

is there anyway to send more then 255 bytes with nrf_drv_spi_transfer

[RK]

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.

[makouda]

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

[mfdevzone]

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.

[RK]

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.

[mfdevzone]

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.