| Crates.io | async-ltc681x |
| lib.rs | async-ltc681x |
| version | 0.1.1 |
| created_at | 2025-07-25 18:20:15.789376+00 |
| updated_at | 2025-07-25 18:23:50.521746+00 |
| description | no_std Async Device Driver for the Ltc681x BMS Chips |
| homepage | https://emkanea.dev |
| repository | https://github.com/emkanea/async-ltc681x |
| max_upload_size | |
| id | 1767898 |
| size | 211,854 |
A no_std async device driver for the LTC681x BMS analog-frontend series.
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 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.
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.
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.
Only rudimentary tests and testing strategy as a very basic proof-of-concept are implemented. Further Mocks, Setups and Test are TODO!
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!