I started really diving into circuit python this past year and have been slowly trying to learn what works best for me. Most of my Going Forward is shaped by topics I think I can contribute to, or areas where I came across issues that I'm confident others will also experience (or I'm about to be exceptionally lucky and future me is about to learn the 'fix' to those issues that others are using.)
I've been heavily focused on adding sensors around my home in hopes of building up 'smart' behaviors in the home: blue-light alarms for waking up which turn on during lighter parts of sleep, air quality sensors to help remind me to replace the furnace filter, and some sensors at the ready to answer questions when I wonder, "what would happen if". So it's from that perspective that I look forward towards 2022.
Circuit Python does a lot of things exceptionally well. I think it's worth calling out one of it's best attributes: the community. It's so consistently welcoming, open, and helpful. I'm excited to see 2022 bring more new folks into the wonderful world of programming, electronics, and projects.
One of the largest areas I'm interested to see grow is a set of docs that sits between the learn guide layer, and the docstrings layer. There are notes in issues on many sensors that describe why a decision was made, and those notes are left to hide in the closed issues section of that github page. I'd love to see more of that reasoning featured in documentation.
Similarly, in the documentation for a number of sensors, there are comments about when and how the sensor is operational. Some sensors are accurate only if they're running within a temperature, humidity, air quality limits. Other sensors, like the Plaintowers PM2.5 are measurably inaccurate for some of their values that they report (PM10 values) while being accurate for other values they report, and a consistent place to acknowledge that inaccuracy would be helpful.
I think it would be useful to detail what some of the readings mean, power consumption during different states, families of small, 'how to do x' functions that aren't quite large enough projects for a learn guide, but are small enough to be sample code used in many larger projects, and so on.
The detailing of algorithms in Numpy, Scipy, and Scikit-Learn are examples of the organization of information I have in mind when I think of more fleshed out documentation.
With the added documentation comes increase in the amount of upfront work to document, and technical debt for maintaining the docs. So it's not an easy task to accomplish, and not one that can be done once and forgotten. I also imagine it might not be something many users are after. But it is an area of growth that I'd like to see and contribute to.
I'm very curious to see if the effort towards automated testing might be leveraged in a minor way to highlight documentation 'out-of-date-ness' as a means to help reduce technical debt. Maybe there's a way to construct a github action that says if there's a commit in a function, there has to be a review of the corresponding documentation sections which use that function. Again this is not a simple problem, and it adds technical debt, but I think it's worth looking into.
This might be my inexperience with these modules, but I find the interaction between these libraries to be noticeably dissimilar to their CPython equivalent. Any timing related libraries are a mess and difficult, so the need to compromise between faithfully copying the Datetime library and fitting the libraries into the Circuit Python ecosystem makes a lot of sense. But I found myself trying to do tasks like setting rtc.RTC().datetime by trying to evoke rtc.RTC().datetime.fromtimestamp() and the absence of a fromtimestamp() function threw me for a loop.
I was also recently bitten by the assumption that time.monotonic_ns() and time.mktime(rtc.RTC().datetime) would start the new second's place digit a the same time. Little things like that keep hitting me and I keep needing to make a note of, "If I do this, don't expect that".
This might be a good target for documentation--highlighting the functions that appear to be shared across all three, rtc, time, and datetime, but aren't the same, or maybe there's room for the code to share and synchronize across the three. I've only recently begun trying to get into the nitty-gritty of synchronizing timing between multiple microcontrollers with access to the internet, so there's a lot I don't know about between these functions.
This is a dream feature and I have no idea how to map it from idea to reality, but if I were making a list of "Wow that'd be neat!" items, a core that has limited functionality but is guaranteed to run once per x units time would be cool.
To the best of my knowledge, I2C and SPI both are similar in spirit so they can maintain communication timing requirements, but it'd be interesting extending the idea to a JIT that a user can place over a function to get similar timing consistency.
I'd imagine it would make sense to raise an error in the timing sensitive process that specifically addresses, RuntimeError: JIT execution time exceeded to break the process if it cannot complete the function in the set time, that way timing drift doesn't continue to propagate unless it's explicitly caught by the user.
High frequency sensor sampling, kinematics, audio and visual processes, etc, would all make sense to have that functionality. But some functions aren't valuable enough to add to the core (kinematics) compared to others (i2c, spi, audio), and the JIT could satisfy the use case.
With the family of sensors, the libraries for wifi, bluetooth, and LoRa, and the low power functions for some microcontrollers, I can see 2022 being a year where circuit python becomes heavily used in remote, scientific studies. The last few years of CircuitPython in maker projects is something I think makes circuit python even more well suited to scientific studies: a lot of labs don't have a dedicated EEs for designing remote sensing projects. The low cost, plus supportive community make circuit python a direction a lot of labs might be interested in going down, and enable more experiments.
2022 won't change the fact that Circuit Python isn't stable enough to be relied on in a life support capacity, and shouldn't be trusted to be secure from attackers. But a lot of lab experiments aren't that high stakes. There's a plethora of experiments that just needs some mostly reliable equipment, and a person can check in on it to make sure it's still online. A lot of those experiments are designed by folks without an EE background, and I think circuit python could extend a path for data acquisition that arduino and raspberry pi's opened up.
Rehashing above: Documentation addressing what sensors do and don't do well is important. Terribly noisy, and cheap sensors still produce very valuable signals. But being clear that a sensor has a given noise level is important. The datasheet for the sensor should say it, but a circuit python library for that sensor could highlight and cite that information as well in the documentation.
Expanding ulab would be interesting. It's a touch outside of direct circuit python, but it's integration with CircuitPython and MicroPython is so helpful. Alongside ulab it'd be interesting to try a subset of scikit-learn's programs.
Just having seen a little of how complex ulab is though I doubt expanding ulab to include a uscikit-learn is the way to go. I think if scikit-learn is pursued it would make sense to set it as it's own module built on ulab. There would be portions which make sense to omit (a full non-Negative Matrix Factorization implementation would stretch most microcontrollers when trying to run .fit()) but other modules, like Support Vector Machines might reasonably fit in some small micro's while having powerful results in projects.
To manage more complex functions, it makes sense to have a library structured to manage the pipeline for acquiring data from the microcontroller, sending it to a computer to process and fit(), and back to the microcontroller as a model ready to use .transform() on new data.
There's a wealth of issues with it--just managing data types and making sure weird conversion errors don't propagate will make up so many headaches inandof themselves. But that's a huge part of the fun of the challenge.
Circuit Python is fun. I don't know where it's going to go, but I'm going to keep trying to get a little bit more out of it, and hopefully get it done in a way that's useful and fun to others. This is by no means what I anticipate 2022 to complete, but a direction I can see it growing towards. Regardless, I hope a lot of folks dive into CircuitPython and find their own directions to go.