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)?
Generic sensor library best practices
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: Generic sensor library best practices
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.
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.
Index to my micropython libraries.
Re: Generic sensor library best practices
From your documentation:
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.).
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?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.
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.).