Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
sommersoft's #CircuitPython2020

2020: Year Of The Blinka (v3)

sommersoft’s Thoughts on CircuitPython in 2020

Its that time of year (the beginning) to call for the community’s thoughts on #CircuitPython2020. Here are my thoughts, and personal goals for 2020.

My 2019 In Review

Many of the submissions for last year’s #CircuitPython2019 included some introspective review of the things folks worked on in the previous year. I initially started with that format before the official call for 2020 went out. However, most of the submissions so far and the call itself are strictly forward-looking. Add to that the fact that my Year In Review got really long, I’ve decided to break it out from this and just link to it. It really only served as a personal stage-setter to advance my thoughts on the upcoming year. sommersoft’s CircuitPython 2019 Reflections

My Personal CircuitPython Goals For 2020

Overall, my goal is simple: make meaningful contributions where possible. I know, I know. Vague and cliché. Definitely not a SMART goal. I have some of those, though.

  • Automated Physical Testing for Core Contributions:

    • As mentioned in my review of last year, I spent a fair amount of time in 2019 to advance this idea. RosiePi and physaCI will continue to consume much of my attention in 2020. I hope to get RosiePi to a state where a node is easy to set up for anyone who wishes to host one. Hand-in-hand, I hope to have physaCI modular enough to support that goal. A major priority for both is that the whole system provides enough security, as nodes will likely be running on personal networks (like mine will). This is the point I’m actually working on currently. I hope to have this accomplished by spring of 2020.
    • Once the whole system is in a stable operating state, I’d like to turn my attention to getting a good baseline of tests written. These will not take advantage of GPIO interaction, since additional hardware components will make externally verified tests more comprehensive. The baseline tests will live in the CircuitPython core repository. I’m planning on having the baseline tests done by the end of spring 2020.
    • By early summer, I hope to start working out the hardware component side that will enable GPIO interaction. I plan on designing a Hat for the Raspberry Pi, and accompanying boards in the Arduino Shield and FeatherWing formats (for Metro & Feather boards). They’ll be proto-boarded in the beginning, of course.
  • CircuitPython Core:

    • I would actually like to contribute more to the core. C is not my strongest language, by far. Most of my C contributions to this point have had rather long review periods, and I often feel like a hindrance more than a help (not because of others; that’s all internal to me). While the length of our issue list could be considered “not that bad”, I would like to give some of the long-in-the-tooth issues some attention.
    • There are some remaining “TODO”s on the documentation work I did in 2019. I’d like to get those completed.
    • Some of my past core contributions are constrained to only one platform (e.g. frequencyio.FrequencyIn on SAMD51 only). I’d like to try and expand the supported platforms on them where possible.
  • Automation, Toolchains, Development Environments, etc.:

    • I think it's no secret to the community regulars; I dig this stuff. In my professional life, I work logistics for a large organization. Thought experiments about “How do I help mitigate X constraint on Y consumer?” consume a lot of my work hours. This translates easily for me over to my personal projects. I may not always have the ideas to address these issues in our space, but I will always be interested in providing solutions to them. That will not change in 2020. ;-)

What I’d Like To See In #CircuitPython2020

  • After a few blunders in my own 2019 contributions, the importance of testing has really taken root in my mind. While the ecosystem is not devoid of testing, I’d like to see more integrated testing. We rely on user testing quite a bit, which is of course necessary. However, where we can catch issues prior to that, I think it should be addressed. This of course will likely drive a conversation on some standards for testing…
  • The continued push to have a stable, and flexible BLE core. From a beginner's perspective, I believe having a more mobile-friendly environment will be huge in removing even more barriers to getting started.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.