nrf_drv_spi_transfer larger transfer size

[kane]

Hi,

I'm working with an SPI FLASH chip that has a page size 256. I noticed that when I call nrf_drv_spi_transfer(), the rx length of 256 rolls over the uint8_t container and is zero!

Digging deeper, I found that the RX size is used for nrf_spim_rx_buffer_set(), also taking the argument as uint8_t. This function sets p_spim->RXD.MAXCNT = length; MAXCNT is size uint32_t. Is there a reason I shouldn't mess with these sizes?

I'm also thinking I'd need a tx buffer size at least 256 to write a page at a time.

[Clem Taylor]

Somebody wasn't thinking this through at design time. For example with a nrf51 design I'm doing ~512 byte SPI transactions to clock pixels out to an oled display. The amount of CPU overhead to clock out one display frame is rather sad. With a nrf52 based design I am planning on using a display with 2x or 4x the pixels. Only 8 bits on MAXCNT and AMOUNT seems way too small, it isn't even enough to write a full page of a cheap SPI flash part. At 55nm how many picocents would it have cost to add a few more bits on the EasyDMA counters?

Yes, I know I can use the list feature, but it seems like un-necessary extra complexity that could have been trivially fixed at design time with a few more counter bits.