From 51019b63c7c3aa2a2533115a46ac1bdf4efc675b Mon Sep 17 00:00:00 2001
From: Erhannis <Eyeillus@gmail.com>
Date: Sun, 11 May 2025 16:03:21 -0400
Subject: [PATCH] Give examples of bus wrappers

It was a frustrating experience trying to figure out how to actually get an `SpiDevice`, and "This crate provides mechanisms to connect an `SpiBus` and a `SpiDevice`", with no further explanation, did not help.  So I added some further explanation.
---
 embedded-hal-bus/README.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/embedded-hal-bus/README.md b/embedded-hal-bus/README.md
index 6f767aae..3346ab16 100644
--- a/embedded-hal-bus/README.md
+++ b/embedded-hal-bus/README.md
@@ -21,7 +21,9 @@ while `SpiDevice` represents a device on that bus. For further details on these
 However, device drivers should use the `SpiDevice` traits, _not the `SpiBus` traits_ if at all possible
 in order to allow for sharing of the bus they are connected to.
 
-This crate provides mechanisms to connect a `SpiBus` and a `SpiDevice`.
+This crate provides mechanisms to connect a `SpiBus` and a `SpiDevice`.  See for instance `ExclusiveDevice::new_no_delay`
+or `ExclusiveDevice::new`, or similarly for `CriticalSectionDevice`, `AtomicDevice`, `RefCellDevice`, etc., which wrap an
+`SpiBus` and provide an `SpiDevice` with differing access semantics.
 
 ## I2C