From 28df44c1f7e93d83a4ffd2b7405a5b414ddd0e0d Mon Sep 17 00:00:00 2001 From: Dario Nieuwenhuis Date: Tue, 2 May 2023 20:08:00 +0200 Subject: [PATCH] spi: clarify flushing/blocking behavior. Fixes #455. --- embedded-hal/src/spi.rs | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/embedded-hal/src/spi.rs b/embedded-hal/src/spi.rs index f8f14ef..e8310d5 100644 --- a/embedded-hal/src/spi.rs +++ b/embedded-hal/src/spi.rs @@ -142,7 +142,11 @@ //! # Flushing //! //! To improve performance, [`SpiBus`] implementations are allowed to return before the operation is finished, i.e. when the bus is still not -//! idle. +//! idle. This allows pipelining SPI transfers with CPU work. +//! +//! When calling another method when a previous operation is still in progress, implementations can either wait for the previous operation +//! to finish, or enqueue the new one, but they must not return a "busy" error. Users must be able to do multiple method calls in a row +//! and have them executed "as if" they were done sequentially, without having to check for "busy" errors. //! //! When using a [`SpiBus`], call [`flush`](SpiBusFlush::flush) to wait for operations to actually finish. Examples of situations //! where this is needed are: