{
  "id": "eosti/micropython-aw210xx",
  "name": "micropython-aw210xx",
  "prettyName": "micropython-aw210xx",
  "description": "Driver for Awinic's AW210xx line of 8-bit RGB drivers",
  "version": "",
  "author": "eosti",
  "license": "MIT",
  "tags": [
    "aw210xx",
    "awinic",
    "driver",
    "led",
    "micropython"
  ],
  "status": "VALID",
  "official": false,
  "source": "https://github.com/eosti/micropython-aw210xx",
  "updatedAt": "2025-06-28T07:00:17.562Z",
  "page": "https://checkmim.com/packages/eosti+micropython-aw210xx",
  "createdAt": "2025-05-27T04:29:29.069Z",
  "submittedBy": "oliverr",
  "install": {
    "mpremote": "mpremote mip install github:eosti/micropython-aw210xx",
    "mip": "import mip; mip.install(\"github:eosti/micropython-aw210xx\")"
  },
  "readme": "# micropython-aw210xx\n> Driver for Awinic's AW210xx line of 8-bit RGB drivers\n\n## Getting Started\nThis package is installable with `mip`: \n\n```python\nmpremote mip install github:eosti/micropython-aw210xx\n```\n\nThis driver is compatible with any of the AW210xx devices, i.e. the 09, 12, 18, 24, and 36-channel versions. \nWhile TI's LP50xx is pin-compatible with these devices, the I2C interface sadly is not. \nAll this driver requires is the I2C object, as well as a bit of information about your specific configuration:\n\n```python\nfrom machine import I2C, Pin\nfrom aw210xx import AW210xx\n\n# To use default interface on RPi Pico:\ni2c = I2C(0, scl=Pin(1), sda=Pin(0), freq=400000)\n\n# Using the AW21024 with address pins pulled low and 3.65kOhm external resistor\nleds = AW210xx(i2c, addr=0x30, model=\"AW21024\", r_ext=3650)\n```\n\nThis library implements most of the features available on the chip, including basic LED operation, PWM adjustments, protections, and open/short checks. \nSome examples of these features have been put in `/examples` for your viewing convenience. \n\nNote that the datasheet labels the pins LED1 through LEDn, but registers REG0 through REGn-1. \nThis driver will zero-index all channel numbers to match the register values, so don't be confused when you want to turn on LED1 and writing to channel 1 turns on LED2 instead. \n\n### Help, it's not working! \nI suggest checking out the datasheet first, but here's a TL;DR of what you need to do to get anything outputting: \n\nThere are four factors that go into output brightness: global current control, white balance, channel current control, and channel brightness. \nAll four need to be non-zero in order to get anything output -- white balance is already at maximum on reset, but the other three are zeroed. \nAdditionally, the chip needs to be enabled, and the chip need to be told to update after brightness is set. \nHere's what that looks like: \n\n```python\nleds.chip_enabled(True)\nleds.global_current(255)    # Current is now limited by R_ext\nleds.col(0, 255)            # Channel 0, no current limit\nleds.br(0, 255)             # Channel 0, all the bright\nleds.update()               # Let there be light!\n```\n\n## Organization\nSince there seems to be no major consensus on MicroPython driver organization, I looked at a number of existing libraries and tried to match them somewhat. \nImportantly: no properties :(. \nThis comes straight from [MicroPython's driver guidelines](https://github.com/micropython/micropython/wiki/Driver-API-Design-Guidelines) for optimization reasons. \nThis means that most functions act as both a setter and a getter: don't pass an argument to use it as a getter, pass an argument to use it as a setter. \nIt makes me uncomfy but makes MicroPython happy so who am I to disagree?\n\nMost magic numbers such as register addresses and bitfields are stored in enums. \nMicroPython doesn't support enums, so unless you're typechecking during development, they act as normal objects. \nFor basic operations you will not need to interface with any enums, but for more advanced functionality you may need to, in which case import the appropriate enum before using. \n\nFor organizational convenience, the `AW210xx` object is structured as a mixin, using multiple-inheritance from subclasses that implement feature-specific methods. \nI hope this makes it easier to parse!\n\n## Contributing\nIf you run into an issue or want to see a feature added, feel free to drop me an issue, or better yet, a PR! \n\nFor PRs, please do some basic linting before opening the PR: `isort . && black . && pylint .`. \nTypechecking can be enabled by setting `TYPE_CHECKING = True` at the top of the file, and then running `mypy .`.\nI'm not too strict with `pylint` issues, just clean up the obviously non-MicroPython-related ones/don't make any new ones please!\n"
}