Writing to SPI without device connected does not throw

[stefanhaustein]

I'd expect failed writes to throw if no device is connected at the requested bus/address, but I only get this message:

[main] ERROR com.pi4j.plugin.linuxfs.provider.spi.LinuxFsSpi - Could not write SPI message. ret -1, error: 90

[stefanhaustein]

Well... where does the log error message come from in this case? Am So., 14. Sept. 2025 um 21:23 Uhr schrieb IAmNickNack < ***@***.***>:

…

*IAmNickNack* left a comment (Pi4J/pi4j#488) <#488 (comment)> How does the Pi know that no device is connected? IO is essentially fire and forget. Failure to send/receive would require some ACK/NACK to exist at the protocol level. SPI doesn't do this. — Reply to this email directly, view it on GitHub <#488 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABAVPT6KXYWNDU7WP2YV2NT3SW6CPAVCNFSM6AAAAACF3K72X6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTEOBZHAYDQMJTGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[IAmNickNack]

I suppose LinuxFsSpi is simply echoing the behaviour of the native library in this case and we get the same behaviour as if we were writing C and calling ioctl directly.

Adding an exception to the API in this case may make sense for the Pi4j abstraction, but it would be a breaking change to users that might be handling this based on the -1 returned by transfer.

pi4j/plugins/pi4j-plugin-linuxfs/src/main/java/com/pi4j/plugin/linuxfs/provider/spi/LinuxFsSpi.java

Lines 281 to 282 in c41b3b3

	logger.error("Could not write SPI message. ret {}, error: {}", ret, Native.getLastError());
	numberOfBytes = -1;

There is a possible issue here in that LinuxFsSpi doesn't actually stick the the interface definition in Spi.java, which appears to indicate that a C-style error code will be returned and not the number of bytes transferred (I think those mentioned in the javadoc are actually Pigpio error codes too, so maybe not relevant to the pi 5):

pi4j/pi4j-core/src/main/java/com/pi4j/io/spi/Spi.java

Line 125 in c41b3b3

* @return Returns 0 if OK, otherwise PI_BAD_HANDLE, PI_BAD_SPI_COUNT, or PI_SPI_XFER_FAILED.

I wouldn't expect a breaking change to be implemented as part of a minor revision, but this would really be up to the maintainers.

In the meantime, if you'd prefer an exception, you could wrap the the Spi instance in your own implementation, delegate calls to read, write and transfer and throw an exception when -1 is returned.

[stefanhaustein]

Is this behaviour consistent with older pi4j SPI implementations? It seems certainly surprising to me and not consistent with how writing to streams in Javas normally behaves.

[IAmNickNack]

I noticed that the develop branch appears now to be 4.0.0-snapshot. This could be a good time to raise a PR with a breaking change which might resolve this issue

[FDelporte]

@IAmNickNack indeed we are on V4-SNAPSHOT because of the move to Java 25 and ongoing work for a new FFM API-based plugin. Breaking changes can be done, but still be careful please ;-)

[stefanhaustein]

Did something change here recently? I am quite sure The St7789 driver test used to throw (as expected) if no device is connected, but now it seems to run regardlessly?

[IAmNickNack]

Given this comment in #500, I wonder whether it's worth making changes to the LinuxFS API to throw and provide native error codes if it's going to be deprecated / removed in an upcoming release.

Exception throwing functionality seems to exist in the FFM implementation.

[eitch]

Well like i said, nothing is definite yet

[DigitalSmile]

I bet we need to add more validations before running any hardware calls.

[stefanhaustein]

I can see the following arguments for exceptions in LinuxFS SPI

• Consistency with the current state of the upcoming FFM implementation
• Consistency with what one would expect from Java (IO streams may return fewer bytes than asked, but just to avoid extensive blocking -- not for error conditions)
• The return code in case of error seems to be 0 (at least at the current pr), which would clash with reading/writing 0 bytes, which doesn't seem optimal
• I have seen two different explanations here what the return code means / should mean. Which one is right?
• I am assuming that I2C would throw if it fails, but I didn't double check.
• We already have cases where we throw in error cases, e.g. duplicate ID or missing hardware. Let's be consistent (assuming nobody wants to define error codes for these)

IMHO, I think for v4 we should declare that failed IO operations throw in pi4j -- if not, that a bug.

[IAmNickNack]

It would be good if native exceptions provided the native error code too.

Currently this is only provided by the exception message: https://github.com/Pi4J/pi4j/blob/develop/plugins/pi4j-plugin-ffm/src/main/java/com/pi4j/plugin/ffm/common/Pi4JNativeContext.java#L55-L56