Where Do I Think CircuitPython Should Focus for 2021
What IS a CircuitPython Anyway?
No, it's not some sort of snake or reptile. Nor is it some sort of SteamPunked techno-jazzed Ourobouros. CircuitPython is an adaptation of the Python programming language with a focus on MicroControllers. These can be used for all sorts of purposes, such as monitoring air quality, making blinky lights, operating garage doors, automatically feeding pets, etc. Pretty much anything to which you would say "It would be nice to have a gadget that ...", you're likely thinking about something that uses a MicroController.
Why Do I Care About CircuitPython Anyway?
This past year, particularly the last 5-6 months, I've started REALLY getting into the hardware side of technology. I've had a more than mild interest in it for quite some time, but things never seemed to line up for me to really do more than just dip the proverbial toe in.
This past year, like for so many other people out there, hobbies and mental distractions, such as reading, really helped keep things in some form of perspective. And so, I started investing more of my time in reading, learning, and really forging ahead with my hardware interest.
I've been following the work, projects and community of an incredible hardware company, Adafruit, for quite some time. What makes them incredible? Glad you asked, I made a list, albeit incomplete:
- They are an open-source hardware company
- They support the community in so many ways
- Their code of ethics is well laid out (see their editorial standards to get a good idea)
- Their focus on education and enriching lives is HUGE, and at the core of their principles
While I could go on, and elaborate on many of those items and many more, that's not what's on my mind today. Today, they shared a blog post regarding where their programming language, CircuitPython should focus for this year. Being such a community focussed organization, they're seeking, like they do every year, input from the community of CircuitPython users.
Ok, Genius. What Are Your "Great" Ideas?
Since I've really been neck-deep in it lately, I had a few ideas which I thought I would contribute, in case others out there also thought of, or raise pain points which others have either accepted or found alternate workarounds for.
As such, here are some of the things I've had ideas about doing:
- Managing libraries, and their dependencies
- Localization(ability?) of the platform
- "Build" tool
Ok. Tell Me More...
#1 - Library Management
One of the biggest pain points I've run into, and that I've noticed other users have as well, is making sure that all the required libraries for a given project, as well as their dependencies, are included and copied to the microcontroller. Having a tool that can manage the libraries and dependencies would make ensuring that nothing gets missed when testing the project on actual hardware.
Another benefit is that the base image for each board could be made much smaller so that only the libraries necessary are installed. For example, if you're using a board that has audio capabilities, but don't intend to have any audio as part of your project, that library can be left out. The benefits of this would likely be minimal since the CircuitPython language and framework exist in a different section of storage on the board - at least, that's my understanding of it. However, it might allow for simpler builds of CircuitPython across various boards based on the same platform.
#2 - Localizationability..ness of the platform
Another addition that might be nice for the platform and its wider adoption, is having the libraries be set up in a manner that would allow them to be localizable. The core framework and language are already localizable, and there are already many translations underway.
However, with the various libraries for the huge assortment of peripherals and sensors from both Adafruit and others in the community or developed by 3rd parties, most aren't localized, and there isn't a pattern or technique defined for localization. Part of the issue might also be that there's no way, at least that I've seen, to know which locale (language) is deployed to the board. Perhaps someplace helpful to put that, if not as part of the global memory space, would be to read it from the boot_out.txt file, as I've seen done for information regarding the version of CircuitPython installed on the board.
Being able to select either a .mpy file to copy to the board or better yet, a specific file-per-language which can be copied to the board, next to the .mpy file. Something like a .cpl for [C]ircuit[P]ython [L]ocale, or whatever would be determined to suit the community.
#3 A "Build" & Deploy Utility
note: This one turned out going on much longer than the previous two, and I detailed maybe a bit too much. Maybe it's a sign of putting too much functionality into it. So maybe it's a "suite"? Either way, it's a jumping-off point.
The final thought I had, which also quite nicely ties into the first to, is a type of packaging and deployment tool so that development can be done locally on a system that is separate from the microcontroller device, without the need to be connected to said device.
This tool could incorporate a few helpful features related to developing detached from the device. Features such as trimming excessive storage use within the code, by (optionally) stripping comments, reducing extra and simplifying whitespace (replace x spaces with a single tab, spaces within parenthesis), and other options similar to modification in Javascript.
This would also provide a uniform manner in which a linter could be used, with default "best practices" rules. These would be applied to the development code, that is, the code on the computer, and not the code pushed to the microcontroller.
Additionally, given that using print() statements for debugging is such a standard technique, it could allow stripping those calls from the code. Alternatively, it could lead to adding one or more similar methods, such as log(), debug(), warn() and the likes, or possibly a separate module. That module, or the calls to the debugging methods, could optionally be stripped out of the "release" code, so that the print() calls remain. Or to keep it more in line with the root Python language, making use of python decorators for debugging output? It would avoid the need to add and remove these debugging statements (if leaving them in but commented out takes too much storage space) after the problem has been isolated and rectified.
So this utility, combined with the functionality I described above in #1, would ensure that only the libraries necessary for the project, given the target board, would be copied. And when combined with what I've described with localization in #2, would ensure that the correct resources/files are deployed for the specified locale.
It could also, in the longer term, be used for updating the version of CircuitPython on the target board with ease for newer users, who are either unsure of themselves and their abilities or have a harder time getting the devices in boot-loader mode.
The final benefit of such a tool is to allow for the full copy of all files to the target device, without triggering a soft-reboot mid-copy. There are issues with editors who do not write files in a single block to CircuitPython devices, causing them to reboot mid-copy. There are also external utilities, such as operating system services/daemons, backup utilities, antivirus scanners, malware detectors, and their likes, which have caused issues rebooting boards unexpectedly due to a misguided "write".
Having a way such as this utility, that prevents the untimely occurrence of a soft-reboot, could be beneficial. In essence, a polite utility, which will hold the metaphorical door open for someone moving something heavy into a building.
Are We There Yet?
So there you have it, things that I believe would be of value to the CircuitPython ecosystem and community, that could be explored and developed for 2021, and quite possibly expanded upon for a few years thereafter. So how far off into left-field am I with these ideas? Am I in the same ballpark? Am I even playing the same sport??? I guess I'll find out!
I'm also extremely curious to hear what others in the community, especially the core developers and maintainers of the ecosystem, have as far as plans and proposals for the year. Regardless of what those are, I for one, welcome our new steam-punked snake overlords look forward to helping out in any meaningful way that I can!
Oldest comments (0)