# `Circuits.SPI.Bus`
[🔗](https://github.com/elixir-circuits/circuits_spi/blob/v2.0.4/lib/spi/bus.ex#L5)

A bus is the connection to a real or virtual SPI controller

# `t`

```elixir
@type t() :: term()
```

All the types that implement this protocol.

# `close`

```elixir
@spec close(t()) :: :ok
```

Free up resources associated with the bus

Well behaved backends free up their resources with the help of the Erlang garbage collector. However, it is good
practice for users to call `Circuits.SPI.close/1` (and hence this function) so that
limited resources are freed before they're needed again.

# `config`

```elixir
@spec config(t()) :: {:ok, Circuits.SPI.spi_option_map()} | {:error, term()}
```

Return the configuration for this SPI bus

The configuration could be different that what was given to `open/2` if
the device had to change it for it to work.

# `max_transfer_size`

```elixir
@spec max_transfer_size(t()) :: non_neg_integer()
```

Return the maximum transfer size in bytes

The number of bytes that can be sent and received at a time
may be capped by the low level SPI interface. For example,
the Linux `spidev` driver allocates its transfer buffer at
initialization based on the `bufsiz` parameter and rejects
requests that won't fit.

If you're sending large amounts of data over SPI, use this
function to determine how to split up large messages.

# `transfer`

```elixir
@spec transfer(t(), iodata()) :: {:ok, binary()} | {:error, term()}
```

Transfer data

Since each SPI transfer sends and receives simultaneously, the return value
will be a binary of the same length as `data`.

---

*Consult [api-reference.md](api-reference.md) for complete listing*
