Skip to content

Instantly share code, notes, and snippets.

@dglaude

dglaude/CircuitPython2020.md Secret

Created January 12, 2020 20:40
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save dglaude/9a9ca530f2a96d6087142fcc42ac40fa to your computer and use it in GitHub Desktop.
Save dglaude/9a9ca530f2a96d6087142fcc42ac40fa to your computer and use it in GitHub Desktop.
Download ZIP
#CircuitPython2020 by David Glaude
Raw
CircuitPython2020.md

I am David Glaude from Belgium and I am currently preparing a CircuitPython presentation for FOSDEM'20: https://fosdem.org/2020/schedule/event/iotcircuitpython/

In order to propose that presentation, I first worked on some demo I could present. Rather than to reinvent the wheel, I took some of the example code I could find around, picking stuff that could bring a WoW effect and that is based on BLE or Airlift.

Now that the presentation is accepted, I need to work on the slide and the story I want to tell. So I am forcing myself to consolidate my knowledge of CircuitPython history, release, hardware support, key decision, ...

I also wanted to experience first hand the community by hanging out on Discord, proposing an example of thermal camera on the PyGamer using DisplayIO, suggesting fix to some documentation. I may have done one of those thing in the past since I found my name on blog post of the release of 2.1.0.

I discovered the existance of Micropython thanks to and IoT (ESP8266) HAT for Raspberry Pi from Pimoroni. At the time I was playing a lot with Raspberry Pi, so writing Python code "bare metal" was a surprise for me. Thanks to Tony DiCola video, I learned a lot about MicroPython on ESP8266 and Adafruit.

So I followed by trying CircuitPython on the same hardware, then likely on a Trinked M0 and a Gemma M0.

I still feel that this fork is hurting and dividing the community and effort should be made to reduce rather than increase the gap between the two projects. I was also sad when ESP8266 support was dropped as that has been a cheap way for user to experience to discover CircuitPython on their existing hardware.

In June 2017 I ordered the CPE directly from Adafruit to get the full CircuitPython experience. I wanted that board so badly that I was ready to double the price due to shipping and import tax. I guess that since then I have been following every release of CP to at least give it a try.

Here are some idea for CircuitPython in 2020. Rather than to do this without outside influance, I readed most of the other post. My appologie if you see some of your suggestion without proper attribution.

MicroPython

  • In December MicroPython release 1.12 with a lot of change came out with a lot of new feature. So with new hardware support in CircuitPython and new feature on MicroPython, the gap between the two might be increasing, where I would like to see that gap reduce with more compatibility and possible sharing of libraries, microprocessor support and feature.
  • I support Dan quest for asynchronous programming and multitasking that could let us avoid the poll loop in all of our code... but I still believe the MicroPython interupt should be build in, whatever the limitation and difficulties.

BLE

  • I would love Adafruit to do for BLE what was done for Wifi with Airlift, maybe using the same ESP32 board (Tina-fw seems to support BLE).
  • I support Dan proposal for a "EZ BLE" library or whatever solution to avoid duplicating the same user code (pattern/boilterplate).

Blinka (DisplayIO and BLE)

  • Like Melissa, I would love to have some DisplayIO support in adafruit_blinka, I am especially interested in Raspberry Pi and support for the framebuffer to display on HDMI or other. Of course driving Adafruit SPI (or I2C) screen for the Pi is also welcome. If I could test code on a Pi with a 240x240 screen before moving to the Gizmo would be great.
  • I would love to also have some BLE support in adafruit_blinka to be able to use the same library as on microprocessor. Adafruit already has a BLE library for Pi and OSX, maybe this can be used.

Documentation

  • I feel the CircuitPython library could have better documentation, right now you have to use the learn guide, check example or read the code to know all options. I know learning by example is great, but you could frequently miss a feature/option/function if that one is not in use.
  • There seems to be a lot of duplication in the board documentation, each one assuming this is you first board and you need the basics on Library, Mu, ... maybe something can be improved. I don't know how the learn backend works, so I don't know how much is duplication and how much is soft link.

Starting from here, it become less something to do/put in the code, more something around Circuit Python that Adafruit could do.

Education

  • I am not a native english speaker, and I have participated once in a Coder Dojo as a coach here in Belgium. While scratch is fun for the kids, and easy to teach because we have localised documentation... I was wondering how I could teach CircuitPlayground to kids (maybe I should to MakerCode first). I try to figure out how to introduce hardware to kids, but one challenge will be the language barrier. So I am interested in any structured "curiculum" that would have permisive licence to permit localisation. I have already seen some interesting stuff. I don't say it should be Adafruit doing this, but any help is welcome. The localisation of CircuitPython message is a good thing (I did try to help the French version) but there is more to it. In Belgium we have the local Adafruit distributor Mc Hobby that frequently translate stuff from Adafruit, while I don't need that for me, I am sure this is usefull to some customer, especially the not IT expert.

Buyer Guide

  • There is also a lot of Adafruit jargon in use that contain some branded names, sometime trademark. I can understand the marketting need, but sometime plain english on what it is can help understand. I started a jargon file for myself and I already shared it.
  • While I know my way arround Adafruit products and I can decide what board to use or not based on the form factor, the kind of usage, ... I can understand it might be difficult for newcomers.
  • So a centralised place that could recommend to use "Express" board for the increased storage, to choose M4 or nRF if you want to do Wifi stuff (Airlift), or use uf2 board for easy upgrade, ... could help. I guess asking a few basic question could guide the customer:
    • Do you need a specific form factor (Feather, Arduino, ...)?
    • Do you want solderless connnection such as alligator or sewable contact?
    • Do you want easy upgrade of the Circuit Python version?
    • Do you want Makecode support?
    • Do you want Wifi connectivity?
    • Do you want BLE connectivity?
    • Do you want a screen?
    • Do you want build in sensor?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment