Skip to main content

Module driver

Module driver 

Source
Expand description

Top-level driver handle.

The driver is split into two types that together model the chip’s lifecycle explicitly:

  • Atecc owns the HAL and represents a chip that is asleep (or about to be: the chip’s actual state is unknown until a channel is opened). It has no command API. Its sole role is to hand out AteccChannel instances.
  • AteccChannel is the awake-and-talking handle. All high-level commands (Info, Sign, GenKey, etc.) live as methods on this type in the crate::command modules. They share the same execution skeleton implemented here as AteccChannel::execute_command (for commands returning a data payload) and AteccChannel::execute_command_status (for commands that signal success with a single 0x00 status byte).

§Lifecycle

Every command goes through the same dance:

  1. Open a channel: Atecc::open_channel wakes the chip and returns an AteccChannel.
  2. Send the command frame, prefixed with the command word address.
  3. Poll for the response. The driver waits the nominal execution time for that opcode, then re-reads at fixed intervals until the chip responds or until the global timeout elapses.
  4. Verify the response CRC and parse it into either a payload or a chip status byte.
  5. Close the channel: AteccChannel::close sends the idle token so the watchdog does not fire on the next call. The borrow on Atecc is released.

Within one channel the caller may run as many commands as needed (this is how multi-step workflows like Nonce + Sign or Nonce + GenDig + Write keep TempKey alive between steps). The channel must always be closed explicitly so the chip’s state stays in sync with the driver’s view.

§Why a separate AteccChannel type

The ATECC608B requires a wake pulse before any command. After commands are done, it must be put back to idle (or sleep), otherwise the chip’s internal watchdog (~1.3 s) silently transitions it to sleep without informing the driver. A subsequent command would then see a NACK because the driver still believes the chip is awake.

Modeling “awake” as a separate type tied to a lifetime forces the caller to acquire a channel for every command sequence and close it when done, which keeps the chip’s state synchronized with the driver’s view at every program point. The borrow checker enforces that you cannot “forget” to wake, and a Drop warning (see AteccChannel) catches the case where a channel is dropped without close().

Structs§

Atecc
Driver handle owning the HAL.
AteccChannel
An open communication channel with a woken chip.

Constants§

STATUS_RESPONSE_LEN 🔒
Smallest valid response frame: count + status + crc(2).

Functions§

map_build_error 🔒
map_parse_error 🔒