CircuitPython Now Working On Teensy 4.0

Python is often touted as a great language for beginner coders to learn. Until recently, however, it simply wasn’t a viable choice in the embedded space. That’s begun to change with projects like CircuitPython, and now it’s available on the Teensy 4.0!

This milestone is thanks in part to [arturo182], who did the ground work of getting CircuitPython to run on the iMX RT series of microcontrollers. This was built upon by [tannewt], who is the lead in charge of the CircuitPython project.

There are some bugs to work out; currently, the project is in a very early stage of development. [Paul Stoffregen], who heads Teensy development, has already pointed out that there needs to be allowance for the 4096 byte recovery partition in the Teensy 4.0’s storage, for example. Development continues at a rapid pace, and those with ideas about where the project should go can weigh in online.

It’s an exciting development, which brings easy Python development to one of the more powerful embedded development platforms on the market. We look forward to seeing many more projects take advantage of the power of the Teensy 4.0 moving forward. If you’re eager to see what can be done with CircuitPython, be sure to check out projects we’ve featured before. Video after the break.

30 thoughts on “CircuitPython Now Working On Teensy 4.0

      1. While they forked of Micropython, anyone knows why they forked and renamed it? There are forks of MicroPython for various other platforms as well, and they didn’t feel like the need to rename the project.

        It is pretty cool if you have an overpowered microcontroller and just want to quickly put something together. And as controllers are cheap these days, there generally isn’t a huge reason not to use micropython/circuitpython for a quick one-off project.

          1. Hi all, I’m Scott Shawcroft. I didn’t say explicitly before but I am the lead for CircuitPython for Adafruit. I’d like to clarify the trademark stuff.

            Adafruit is working directly with the Python foundation’s legal team and Damien (MicroPython) to help protect the name “Python” and variants like MicroPython and CircuitPython.

            It became an issue because a Chinese seller of MicroPython boards had registered the MicroPython trademark in China and was preventing other Taobao sellers from listing.

            It was brought up on the MicroPython forum here: https://forum.micropython.org/viewtopic.php?f=2&t=6971&p=39702 Adafruit publicly documented it on the Adafruit blog here too: https://blog.adafruit.com/2019/10/05/micropython-trademark-in-china/

            Adafruit is working with MicroPython, and the Python foundation, to figure out what will help Damien, Adafruit, and the community the most, including registering CircuitPython in the USA and China.

            Adafruit is donating time and resources to both Python and MicroPython for this and all of the ongoing Python and MicroPython efforts.

    1. RTFM at circuitpython.org:

      “It’s a high-level programming language which means it’s designed to be easier to read, write and maintain. It supports modules and packages which means it’s easy to reuse your code for other projects. It has a built in interpreter which means there are no extra steps, like compiling, to get your code to work”

      1. Yeah but the CPU itself can’t run python. Is it running an OS or bootloader with an interpreter? When the python code changes the state of a pin how is it telling the CPU?

        1. CircuitPython is written in C under the hood. It parses Python code into byte codes which run through a big loop in C. There are also Python modules that are implemented in C for interfacing with the hardware. The VM will call into these C modules based on the Python byte code and the C module will set the pin value (or do whatever) just like regular embedded C programming. This gets us the best of both worlds, the fast iteration of Python plus the fast C code under the hood.

          1. As far as I know MicroPython also supports REPL, which means, you add a serial console, type in text and your uC board interprets it.
            Apparently there is also a “Web REPL”, which works over sockets.

            I’m not sure, but I have vague memories that REPL has scrapped in circuitpytyhon.

            Micropython also runs on an ESP8266, which is probaby a bit cheaper to try it out than those Teensy boards, but you may have to flash the esp8266 (or other supported board) first to get Python on it.

            This 10min video seems to be a nice introduction on how a MicroPython board works:
            https://www.youtube.com/watch?v=5LbgyDmRu9s

            Also: MicroPython is based on Python3, and after a few minutes of searching I gave up on which version of Python that circuitpython is based, but I assume its python 2, which is officially obsolete as of this month.

            Pleasy move on (after 10 years!) and try to forget python2. 10 years of 2 incompatible python versions is already much more than should have been.

          2. re: paulvdh

            CircuitPython has a REPL as well although it doesn’t include the leftover VM state from main.py. We do not have a WebREPL like MicroPython because we don’t support ESP (wifi) chips.

            CircuitPython is a fork of MicroPython so it shares the same VM core and is, therefore, also Python 3.4+.

  1. Ooh, I’ve just bought a Teensy 4. I really like having CircuitPython on boards which also run Arduino/C, my knowledge of Python is much better so I can do a quick prototype in CircuitPython to get the design and function straight in my head and then figure out how to achieve that in Arduino/C. Knowing that my general idea of how peripheral interactions should work is fine because the CircuitPython version works can be a useful reference for debugging my poorer Arduino/C version.

    1. Out of curiosity, aside from performance and memory footprint, is there a compelling reason to re-code it in Arduino/C if you already having it working in CircuitPython? Again, assuming performance is acceptable and it all fits properly into memory…

      1. One area we (CircuitPython) need to improve is power consumption. Right now when “sleeping” we’re busy waiting using the CPU instead of actually idling. It’s on our radar and something we plan on improving this year.

        Besides that, I don’t know why you’d rewrite it if it all works ok.

      2. Occasionally performance, partly also a desire to be better at Arduino/C++ for other projects I’d like to eventually do. Python is showing up in a lot of places but C/++ still seems to be the universal language. Plus, if I can talk to I2C/SPI devices properly with Python but not Arduino/C then I know it’s my C code and not my understanding of how to talk to the devices which is wrong. Some chips have fairly odd (to a self-taught amateur) requirements for how you talk to them, and I still feel like my Arduino/C is very clumsy.

      1. For starters MicroPython is the original “python for microcontrollers” project. I like the balance of functionality, and compatibility with CPython vs ease of use that Micropython tries to achieve.

        CircuitPython is a fork of Micropython that emphasizes even more ‘ease of use’ and was intended (at least initially) to run on a low performance cortex-m0 microcontrollers. It means that the API modules are a bit simpler , giving the programmer less control over the hardware peripherals such as ADC or I2C modules. It also lacks things like concurrency, deep-sleep (last I checked) and interrupt functionality.

        Admittedly I haven’t used circuitPython on the teensy 4.0 so this opinion is based on my experience running circuitpython on samd21 vs micropython on the stm32f411

      2. I have been programming uC’s in C and C++ from before Python existed, and don’t have much interest in Python on a uC. Though I can se some use of it (For example generating test signals while breadboarding / testing new electonic circuits)

        Just did a search for circuitpython on the MicroPython forum:
        https://forum.micropython.org/search.php?st=0&sk=t&sd=d&sr=posts&keywords=circuitpython
        Results are very likely biased.

        It seems that circuitpython is more targeted to absolute beginners, and thereforehas bloated it’s libraries to make them more compatible among different target boards, while MicroPython is apparently more compact and has more functions.

        I have no personal experience with either, but if I were to experiment with it, it would definately start with the original micropython instead of adafruit’s fork.

        Does anyone know why Adafruit forked micropython into circuitpython?
        To me it looks like vendor lockin, as I assume that adafruit made libraries for a lot of their boards for circuitpython.

        According to the micropython forum, porting a library from circuitpython to micropython is usually done by “throwing half the code away”.

        Teensy 4.0 also seems to be popular on the micropython forum:
        https://forum.micropython.org/search.php?keywords=Teensy+4.0

  2. “…That’s begun to change with projects like CircuitPython…”

    don’t you mean:

    “…That’s begun to change with projects like MicroPython…”?

    Fair play to CircuitPython and this project, which is great, but credit where its due.

  3. Ditto,
    Since from the first crowd funding campaign a lot of hard work has gone into MicroPython by it’s founders and the community, particularly the initial concept for the adaption which got the project rolling. I find the breathless articles on the wondrous new innovative CircuitPython somewhat tastless and consequently lacking in validity. They took someone elses work, hung a new name on it and did some fiddling to sell their products with it. Adafruit could have provided a branch, shown some ongoing respect by staying with the project and gained some kudos to boot. Now the efforts are divided and the overall impact is to the detriment of the community.

  4. When you say ‘working’, I’d say barely and even then only on adafruit hardware simply to keep us in their ecosystems. I’m very wary of being locked in like this which is reason enough to avoid CircuitPython. I have a few things that work in micropython (ok, on other boards to be fair) which I’ve tried to port to CircuitPython that simply don’t work. Adding to the frustration is the terrible documentation which is largely incomplete forcing me to dig into the source and examples to try and work out the properties and methods available in modules. In one case I’ve had to take a module that already exist in micropython and port it myself to circuitpython only to find the adafruit_frambuf makes a mess of the text() by outputting dotted lines rather than the text.
    The adafruit circuitpython website is so badly organised it’s very difficult to find information that’s needed.
    I’m going to switch back to other devices and micropython, or even back to c++ for the projects where I don’t need them to be understood by beginners.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.