async-ltc681x

Crates.ioasync-ltc681x
lib.rsasync-ltc681x
version0.1.1
created_at2025-07-25 18:20:15.789376+00
updated_at2025-07-25 18:23:50.521746+00
descriptionno_std Async Device Driver for the Ltc681x BMS Chips
homepagehttps://emkanea.dev
repositoryhttps://github.com/emkanea/async-ltc681x
max_upload_size
id1767898
size211,854
(emkanea-dev)

documentation

README

Device Driver for LTC681X BMS Analog-Frontend

License Crates.io CI

A no_std async device driver for the LTC681x BMS analog-frontend series.

Introduction

Motivation for this crate

In a typical bare-metal super loop application, where you cant block, you run in a typical problem. You need to nest alot of statemachines on top of each other. You need ofc statemachines to represent the state of your app and the actual state of the device connected to the MUC via i.e. SPI. In addition, as you can not block, you also need statemachines to track the state of I/O operations. This results even for fairly simple devices in a very compliacted mess of nested statemachines. One answer is the use of an RTOS which gives the ability to block on I/O operations. But we are a simple man and we want a simpler solution. We dont need threats and parallelism, we only want concurrency! We need someone to handle all the boilerplate I/O statemachines for me! We want to write non-blocking code that looks and feels like blocking code!

All of this was satisfied when we learned the details of Async Rust. No RTOS, no runtime just a reliable helper for my I/O statemachines. So we had to get to work and see this concept in action for a device where we produced our own share of C Spaghetti Code over the last years! So for know we only implemented parts of the full functionality of the chip as a first step to prove the benefits of async rust. We have developed drivers in C/C++ for this device with full functionality and FuSa compliance in proprietary projects. We intent to upgrade this crate gradually to reach this state. If anyone wants to accelerate that effort feel free to reach out.

The Device

The LTC681x series is a powerful battery management AEC-Q100 chipset for the use as a single device in low-voltage (~24-48V) or as a daisy chain of devices for HV battery stacks. Devices was originally developed by Linear Technolgies which is now a part of Analog Devices. It provides all necessary functions to measure the relevant parameters (Single Cell Voltage, Temperature and for LV batteries the current) of a Lithium Ion battery to ensure safe operation. Typical application architectures (single device, daisy chain, reversible daisy chain) can be found in datasheet linked below.

Under NDA the manufacturer provides a safety manual with implementaiton guidelines for the use in safety critical applications up to ISO2626 ASIL-C. It is a proven in use device which has shown create performance and stability for many years (We are not a part of Analog - just a folks who had way worse experience with similar chips of other manufacturers)

For further details about functionality and typical uses-cases see the datasheet for any of the three variants.

LTC6811-1

LTC6812-1

LTC6813-1 / ADBMS1818

ADBMS1818 is another compatible part as it is a non-automotive/low-cost variant of the LTC6813. As far as we understand it uses the same silicon but skips the automotive burn-in. This results in a slightly reduced lifetime performance of the measurement accuracies. We found no difference in the behavior between the ADBMS1818 and LTC6813 found.

State of implementation

Functional

  • Convert Cell channels with all command options
  • Convert GPIO channels with all command options
  • Read, Write and Manipulate all Cfg Register Bits
  • Daisy Chain support via const generic parameter
  • Implement Com Registers for I2C/SPI Controller
  • Implement I2C/SPI Driver
  • Implement PWM / S Control Registers
  • Command Addressing for LTC6811-2 for parallel operation

ISO26262

  • Perform overlapping selftest
  • Perform ADC accuracy selftest
  • Convert Status channels with all options (Driver implements conversion but not StatA/B Registers)
  • No check for valid measurement range (Digital Redundancy produces value outside of valid measurement range)
  • MUX Decoder Check
  • Functions which use register Clear commands to check for stuck-at conditions
  • Open Wire checks for Cells and/or GPIOs
  • Chip thermal shutdown and temperature control
  • Bidirectional ring communication for LTC6812 and LTC6813 to detect a broken wire
  • Full Coverage metrics / Test Strategy

Testing

On Hardware

We tested this crate on two different hardwares. We have tested the implementation on two different boards. One is in single-ended SPI configuration with a single LTC6811-1 connected. The other is up to four LTC6813/ADBMS1818 connected in reversible ISO-SPI daisy chain configuration. We did our best to verify the parts that are implemented with both. Testing Setup

Software Testing

Only rudimentary tests and testing strategy as a very basic proof-of-concept are implemented. Further Mocks, Setups and Test are TODO!

Further development

If you want to use this driver and need a specific feature let us know or feel free to contribute. We also worked with other BMS chips (and also non BMS related chips), so we are open to expand what we learned to other crates!

Commit count: 0

cargo fmt