SPI providers are too helpful

[IAmNickNack]

Most functions provided by SPI are arguably not required at the "driver" level.

The only is actually required per plugin is transfer. This could be considered problematic for a few reasons:

• Every plugin duplicates the same code for read, write and array-slicing operations.
• Because these functions depend on transfer and this then being dependent hardware, unit testing duplicate code can become complicated or repetitive.
• The array-slicing functions make the implementation not particularly SOLID as they are a responsibility beyond communicating with the hardware. They may be something a user wishes to do, but it is questionable whether it is the responsibility of the hardware layer to provide this functionality.

I'm not suggesting they are not useful. Simply that, if they were elsewhere in the codebase, writing and unit testing additional plugins might be simpler.

Maybe this is a long-winded way of suggesting they move to the abstract base class or Spi interface where they can be properly tested with a fake implementation of transfer.

[IAmNickNack]

This is similar to this I2C issue #522

[taartspi]

SPI considerations for FFM

Some time back a user offered a fix for pigpio, it was accepted. Recently
that user asked for that fix in linuxfs and I said I would move it. In doing
the move I saw the fix breaks a buffer larger than
/sys/module/spidev/parameters/bufsiz into chunks and each sent as a unique
transfer. I worry that even if the app holds the chipselect line the entire time
the SPI target IC may not handle the clocking interruptions. Not holding the
chipselect would increase the chance the spi chip operation fail.

This should be a single transfer with a spi_ioc_transfer[] .

In addition there is conversation on creating a general use SPI write API for the
drivers.

*A
First, should we handle the large buffer for the user or tell them to
increase the buffer size to the MAX and call spi_write multiple times
if needed and control the chipselect ?

*B
If 'A' is we handle it. Do we do this in various providers or add
this support to the above mentioned API, implementing the API code so it
is usable from the providers ?

I have a version of the linuxfs-spi with the above changes. transfers with one
element in the array works, more than one fails. I've done this in C no problem
and don't see my error in this java implementation. If the plan is we do this,
I will continue debug.

[stefanhaustein]

Can you share the code you have so far for the array-based transfer? Perhaps it just needs a second pair of eyes?

Not holding the chipselect would increase the chance the spi chip operation fail.

The latest iteration of the implementation seems to force a CS toggle, which seems to be the opposite of the quote above. I am concerned that this will force a break up of large logical transfers and might even disrupt logical transfers done in chunks.

[eitch]

Do you mean the myriad of transfer methods on Spi? If so, then as they are all default implementations, i don't see it necessary to test them in each implementation, but rather that we test com.pi4j.io.spi.Spi#transfer(byte[], int, byte[], int, int).
From quickly looking at the tests, i do see that the other transfer methods aren't properly tested in the pi4j-test project, so that could certainly be done. The test in SpiRawDataTest seems to only test methods on IODataWriter. I can't even find usages for Spi.transfer() anywhere.

[taartspi]

Tonight i will push that code as another set of eyes would be good. Thanks The code leaves CS asserted until the last element in the array. The existing code does release the CS each time, the prologue explains this as it was the pigpio way and not the best. I saw Stefans comments on the existing code. If debugging my problem with a preferred implementation is lengthy I will update the present implementation from the comments.

…

On Tue, Oct 7, 2025 at 4:13 AM Stefan Haustein ***@***.***> wrote: Can you share the code you have so far for the array-based transfer? Perhaps it just needs a second pair of eyes? Not holding the chipselect would increase the chance the spi chip operation fail. The latest iteration of the implementation seems to force a CS toggle, which seems to be the opposite of the quote above. I am concerned that this will force a break up of large logical transfers and might even disrupt logical transfers done in chunks. — Reply to this email directly, view it on GitHub <#521 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK5A324JZARXX7PN2P66RAT3WN75HAVCNFSM6AAAAACIOIOIWOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTINRRGMYDKNQ> . You are receiving this because you commented.Message ID: ***@***.***>