Skip to content

Latest commit

 

History

History

apds9960-testing

README.md

APDS9960 Testing

Testing the APDS9960's individual functions on the Adafruit Clue nRF52840.

Deep Notes

Overview

The APDS9960 is a complex I2C peripheral, packing three related but distinctly different functions into a very tiny package.

  • Proximity sensing
  • Light intensity and RGB color sensing
  • Gesture detection

This little chip has a ton of configuration options for each of the three core functions including some very useful features for 'interrupts' that can be read from a register or even picked up from signal on the chip's interrupt pin. This configurability makes it a bit more difficult to work with than your average I2C sensor.

With this experiment I'm hoping to write some scripts to work with all of these features to both demonstrate their use and, ideally, to assist with routine testing while experimenting with potential enhancements or feature additions to the driver package.

The current state of the driver is serviceable and works for most simple cases. But operation of the device can be a bit wonky due to a combination of hard-coded defaults and inability to easily access some useful configuration options.

Since I've been digging in the code lately I'm planning on diving into this a bit more and this will be a home for notes and code generated along the way.

Boards

Several dev boards have this chip built-in, making those boards handy for testing. There are also a few easy to use breakouts available.

Boards:

Projects/Guides/Example Code:

Boards to Test With

In particular, I'm mostly focusing on the Clue for initial functionality testing since its got a display and a pair of buttons for human interfacing.

But before landing on any proper solutions I'll be testing on the Proximity Trinkey as a most-constrained-case type thing. Its just got a SAMD21, which is still quite capable but is much more constrained in memory (32k!) and storage (just 256k flash!).

My primary development iterations are being run on a Clue though, since this nRF52 board has a bit more memory head-room to work with making it much more forgiving for hashing out the algorithms for retrieving and processing data.

Revisions

While testing out ideas I've developed a few "revisions" of both my testing code and the driver code itself. If its noteworthy or interesting enough I'll be adding it to sub-directories here with v<version> tagged. If I'm really feeling punchy I'll also add info on the 'revision' here with a note.

  • v0 - Super early testing code
    • Involved some very hacky modification of the driver for my first testing iteration so no driver code there since, well, its more confusing than useful :)
  • v1 - First major algorithm refactor
    • After a bunch of halting steps in the right-ish direction this was the first "oh dang it works" revision
    • It's a heavyweight though so its probably not ready for prime time...
  • v2 - Proper run at optimization
    • The v1 code was huge, both in mpy file size and post-import memory footprint. We can do better.
    • Thorough A/B testing with different optimizations yielded a much-improved driver with a much smaller footprint that achieves the same major goals
    • This version lacks the tuning options of the v1 driver though, so an advanced version may be warranted

Links