iqs7211e 0.1.2

Async I2C driver for the Azoteq IQS7211E capacitive touch and gesture controller
# Azoteq IQS7211E driver

`iqs7211e` is a `no_std` async driver for the [Azoteq IQS7211E]
capacitive touch and gesture controller. It provides a strongly-typed API
for configuring the sensor over I²C, plus an awaited event API that yields
gestures and one/two-finger snapshots.

## Status

- ✅ Runs on `embedded-hal` and `embedded-hal-async` 1.0
- ✅ End-to-end configuration routine that mirrors the reference design
- ✅ Strongly typed configuration helpers (Rx/Tx pin layout, gesture toggles, ATI tuning)
- ⚠️ Breaking API changes may still occur prior to `1.0`

## Getting started

Add the crate to your `Cargo.toml`:

```toml
[dependencies]
iqs7211e = "0.1.2"
```

Then initialise the device with an async I²C peripheral and a ready (RDY)
GPIO implementing `embedded_hal_async::digital::Wait`.

```rust
use embedded_hal_async::digital::Wait;
use embedded_hal_async::i2c::I2c;
use iqs7211e::{Config, Iqs7211e, Pinout, Pin};

async fn bring_up<I2C, RDY, E>(i2c: I2C, rdy: RDY) -> Result<Iqs7211e<I2C, RDY>, iqs7211e::Error<E>>
where
    I2C: I2c<embedded_hal_async::i2c::SevenBitAddress, Error = E>,
    RDY: Wait,
{
  let pinout = Pinout::new(
    [Pin::RxTx0, Pin::RxTx2, Pin::RxTx4],
    [Pin::Tx8, Pin::Tx9],
    [Pin::RxTx0],
    [Pin::Tx8],
  );
  let config = Config::default().with_pinout(pinout);

    let mut controller = Iqs7211e::new(i2c, rdy, config);
    _ = controller.initialize().await?;

    Ok(controller)
}
```

Refer to the [API documentation](https://docs.rs/iqs7211e) for the full listing of
types and helpers.

## Listening for touch events

Use `Iqs7211e::next_event()` to await gestures, single-touch, or multi-touch updates.
See runnable examples in `examples/`.

## Feature overview

- Full mirror of the Azoteq reference configuration sequence
- Strongly typed bitfield wrappers for gesture, ATI, and hardware settings
- Helpers for deriving valid sensing cycles from Rx/Tx pin layouts
- Manual setup session helper to read the counters documented in Azoteq's GUI workflow
- Convenience helpers to query firmware info, gesture bitfields, and
  per-finger touch snapshots
- No allocation, fits `no_std` targets

## Manual setup workflow

When replicating the "Basic Setup" procedure from Azoteq's reference
documentation you can let the crate act as a runtime setup assistant.

```rust
use embedded_hal_async::digital::Wait;
use embedded_hal_async::i2c::I2c;
use iqs7211e::{Config, Iqs7211e, SetupSnapshot};

async fn tune<I2C, RDY, E>(i2c: I2C, rdy: RDY) -> Result<(), iqs7211e::Error<E>>
where
    I2C: I2c<embedded_hal_async::i2c::SevenBitAddress, Error = E>,
    RDY: Wait,
{
  let config = Config::default(); // set your pin layout, thresholds, etc. before the session starts

    let mut controller = Iqs7211e::new(i2c, rdy, config);
    let mut session = controller.begin_setup();

    session.initialize().await?;            // mirrors the GUI "Start streaming" + "Write changes"
    session.enter_manual_control().await?;  // enables manual control and forces LP1 charge mode

    let snapshot: SetupSnapshot = session.snapshot().await?;
    let channels = snapshot.rx_count * snapshot.tx_count;
    let deltas = &snapshot.trackpad_deltas[..channels];
    let bases = &snapshot.trackpad_base_targets[..channels];
    // Present the counters however you prefer (defmt logging, rtt, serial, ...)
    // e.g. `defmt::info!("{:?}", bases);`

    session.finish().await?;                // leaves stream/manual modes in a clean state

    // Apply the captured values to `controller.config`, then run `initialize()` again
    // or bake them into your production configuration.
    Ok(())
}
```

The `SetupSnapshot` structure exposes the live counters typically recorded
during bring-up:

- `info` mirrors the GUI indicator block (charge mode, ATI status, etc.)
- `trackpad_deltas` and `trackpad_base_targets` read back addresses `0xE200`
  and `0xE100` flattened to `rx_count * tx_count` entries
- `rx_count` / `tx_count` help you reshape the flattened arrays into your
  physical matrix layout
- `alp_*` fields expose the ALP channel counts and compensation values

You can capture multiple snapshots while manual control is active (for example
after tweaking thresholds) and feed the numbers into your own logging or GUI.

### Advanced setup workflow

The Azoteq documentation splits tuning into intermediate and advanced passes
that refine ATI, thresholds, and power behaviour. The driver mirrors those
steps so you can script the process instead of relying on the GUI.

- For the notes below let `channels = snapshot.rx_count * snapshot.tx_count`.

- **Rx/Tx sanity checks** – While manual control is enabled, lightly touch the
  corners and inspect `snapshot.info.tp_movement` together with
  `&snapshot.trackpad_deltas[..channels]`. If the active channels do not match the board layout,
  revise the pinout configuration and rerun `initialize()`.
- **ATI iteration** – Use `snapshot.trackpad_base_targets` to determine the
  base-target counts (doc section 4.2). Adjust the trackpad ATI settings via
  `config.auto_tune.tune` (adjust `target`, `coarse_divider`, `coarse_multiplier`,
  `fine_divider`) until the reported counts align with the lookup table. After updating
  the config values, call `initialize()` again to write them back and trigger a fresh ATI.
- **Compensation window** – The `alp_comp_*` fields in the snapshot reflect the compensation
  values. Keep them near the centre of the valid range (typically ~512). If the
  snapshot shows values drifting to 0 or 1023, adjust
  `config.auto_tune.tune.compensation_divider` and repeat the ATI step.
- **Threshold tuning** – Record the per-channel deltas while pressing the
  corners (`&snapshot.trackpad_deltas[..channels]`) and compute the touch thresholds suggested in
  doc section 4.3. Apply the resulting multiplier to
  `config.channel_output.touch` (set/clear multipliers) and reinitialise.
- **Mode timing** – Once the touch performance is acceptable, restore event
  mode via `SetupSession::finish()`, then update the report-rate and timeout
  fields in `config.timing` before the final `initialize()`. The defaults match
  the reference design, but you can tailor them to your power budget by following
  section 5 of the guide.

Repeat the capture → adjust → initialise loop until the recorded values match
your targets. Because the configuration structure lives in memory, you can
serialise it (e.g. JSON, TOML, or Rust constants) once the tuning is complete
and feed the same values into production firmware.