Short Tutorial on Writing an I2C Device Driver

[DavesCodeMusings]

I got my hands on a BH1750 ambient light sensor recently and ended up writing my own driver module for it. I learned a lot about I2C in the process and wrote it all up as a short tutorial.

If anyone is interested in some tips on how to go from datasheet to MicroPython module, I have it laid out in the README in this repository:

https://github.com/DavesCodeMusings/BH1750-MicroPython

If you just want the BH1750 driver, details are in the QUICKSTART document.

Hopefully this will be useful to the next person who finds a nifty I2C device and wants to use it with MicroPython.

[Josverl]

Thanks Dave ,
that's a nice One !

[davefes]

+1. I have been interfacing hardware to microcontrollers for 25 years. With the move to Micropython I haven't been brave enough to write my own classes. This article is good encouragement, to have a go.

Thanks for taking the time to write these things up.

[mattytrentini]

Excellent @DavesCodeMusings, thanks for pulling this together! I hope you don't mind if, at some point in the future, I steal (with attribution!) heavily from this? :)

I'd like to extend it to explain how to allow mip installation and potentially mocking/unit testing. And possibly clarifying a few points - like why it's a good idea to pass in an I2C device (as you've done!) rather than configure it inside the driver, which is a common anti-pattern for the inexperienced.

[DavesCodeMusings]

Thanks for the encouragement, everyone! I've been eyeing the Sensirion SHT30 temperature humidity sensor for my next I2C attempt. The datasheet makes it look pretty straightforward. So maybe more coming.

@mattytrentini , feel free to borrow / steal whatever you like. That's why I published it. Also, you mentioned mip installation. I think the GitHub action that creates the .mpy file whenever code changes are merged is particularly useful in that respect.

[Josverl]

I think the GitHub action that creates the .mpy file whenever code changes are merged is particularly useful in that respect.

When publishing cross-compiled .mpy files, you need to consider the MicroPython versions the end users need long term as .mpy files have a limited compatibility range.

[DavesCodeMusings]

If I'm developing with MicroPython 1.24.1, how far back will my .mpy file be good for? Is it limited to just 1.24.x or does it usable for earlier versions like 1.23 as well? I kind of figured it would be a matter of version specific features I'm using (or not using) in the code and this would be the same with .py or .mpy files. But, I'm the first to admit mpy-cross and bytecode is all relatively new to me.

[Josverl]

There is a table that gives the details for the various versions and bytecode versions on the ref page for .mpy files

https://docs.micropython.org/en/latest/reference/mpyfiles.html#versioning-and-compatibility-of-mpy-files

Also with the mpy-cross package on PyPI, there are options to specify for which version to compile

[DavesCodeMusings]

Thanks for the link. I was not aware of this. Now to figure out what version is being produced by mpy-cross in the GitHub Actions Ubuntu system.

[DavesCodeMusings]

Now to figure out what version is being produced by mpy-cross in the GitHub Actions Ubuntu system.

The first three bytes in the resulting file are 0x4D, 0x06, 0x00 or M, 6, 0. So that should be version 6.0 with no native machine code. I should be good down to MicroPython v1.19.x with this.