Could we provide two set interface like spi master:
struct spi_ops_s
{
CODE uint32_t (*send)(FAR struct spi_dev_s *dev, uint32_t wd);
#ifdef CONFIG_SPI_EXCHANGE
CODE void (*exchange)(FAR struct spi_dev_s *dev,
FAR const void *txbuffer, FAR void *rxbuffer,
size_t nwords);
#else
CODE void (*sndblock)(FAR struct spi_dev_s *dev,
FAR const void *buffer, size_t nwords);
CODE void (*recvblock)(FAR struct spi_dev_s *dev, FAR void *buffer,
size_t nwords);
#endif
};
send for a single word, exchange/sndblock/recvblock for a buffer. So
the new code get the better performance, but the old code still work
as before.
On Fri, May 22, 2020 at 2:16 PM Laitinen, Jukka
<jukka.laiti...@intel.com> wrote:
>
>
>
> Hi,
>
>
>
> *The attached patch is just for opening a discussion, please don’t merge*
>
>
>
> We used the SPI slave interfaces on stm32h7 platform, in a configuration where
>
> two stm32h7 chips were connected together with SPI bus, one in master
> simplex-tx and one
>
> in slave simplex-rx mode.
>
>
>
> There was quite high data rate from master to slave, and the slave controller
> & device interfaces,
>
> which are defined in include/nuttx/spi/slave.h were quite inefficient to use.
>
>
>
> Namely, we needed this kind of features to the slave interfaces:
>
> a possibility for slave controller driver to just buffer incoming data and
> slave device driver to poll for it at certain interval
> possibility for copying larger buffers of data at one call; now each call to
> getdata can only return 2 bytes at a time
>
>
>
> I tackled these issues by changing the spi slave interface like in the
> attached patch. So adding a “poll” function for the controller interface and
> modifying
>
> the data handling functions in a way that larger blocks of data can be
> managed in one call.
>
>
>
> Obviously, this approach is incompatible with the existing SPI slave
> controller & spi slave drivers (on samv7 platform).
>
>
>
> So the questions which arise
>
> Do you think that there is an alternative way to reach those goals using the
> existing interface?
> Would it be reasonable to re-visit the spi slave interfaces to support high
> data rates more efficiently?
>
>
>
> Br,
>
> Jukka
>
>
