Re: FW: SPI slave interface discussion

2020-05-22 Thread Xiang Xiao
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
 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
>
>


FW: SPI slave interface discussion

2020-05-22 Thread Laitinen, Jukka

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