Generic sensor library best practices

General discussions and questions abound development of code with MicroPython that is not hardware specific.
Target audience: MicroPython Users.
Post Reply
meir
Posts: 2
Joined: Thu Jun 30, 2022 10:21 am

Generic sensor library best practices

Post by meir » Thu Jun 30, 2022 10:46 am

Hi,
TL;DR:
I am use a driver library that I wrote and I want to publish for all to use. My library supports different versions of the same module type, and I was wondering what the best practices were for making it generic. I will elaborate:

(What I am writing here is how I understand it, feel free to correct me if I got something wrong)
In Micropython there are "ports" and libraries can work with a specific port. For instance, if I have a module that works only on board A and B but not on other boards, then it will "belong" to that port.
But, what do we do if there are drivers that support an external module, or a group of modules that perform a similair function. On one hand, the module does NOT belong to a specific port, on the other hand at any given time I will probably want to use only one of the module implementations.
For instance, if I was using Python with no memory limitations, I would have the following structure:

ModuleInterface
| -> VariationAImplementation(ModuleInterface)
| -> VariationBImplementation(ModuleInterface)
| ....

On MicroPython that means that I will probably have "unused" files on the microcontroller, and it will take up space.
What is the best practice in cases like these (I am sure there are many examples)?

User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Generic sensor library best practices

Post by pythoncoder » Sat Jul 02, 2022 9:05 am

I suggest you look at existing examples of user-contributed libraries - see https://awesome-micropython.com/.

In general it is possible to write MicroPython drivers which work on all ports. For example I have written GUIs and display drivers which are cross-platform. With the right design, all the hardware specific configuration details are stored in a single small Python file which the user edits to match their hardware (e.g. pin numbers etc.).

See nano-gui for an example. The hardware details are stored in color_setup.py. Display drivers, which are specific to the display but run on any platform, are in the drivers tree.
Peter Hinch
Index to my micropython libraries.

meir
Posts: 2
Joined: Thu Jun 30, 2022 10:21 am

Re: Generic sensor library best practices

Post by meir » Sun Jul 03, 2022 3:51 am

From your documentation:
The easy approach is to copy everything to your hardware using rshell. This consumes about 508KiB of space on your filesystem. Substantial pruning can be done to eliminate unused drivers, fonts, widgets and demos.
This really is what I was asking. Are your instructions to "prune" unused files the right behaviour? Is there a better way to do it?

Regarding the color_setup.py file you mentioned, I am aware that this is an option, but only if all I need to do in such a file is hardware specifications. For instance, if I was trying to connect to a GSM modem, I would actually need to perform different logic based on the GSM modem I am using (SIM800, SIM7000, etc.).

Post Reply