CircuitPython on Teensy 4!

Hi! Thanks for the interest in CircuitPython. I've answered each of your questions below.

I also want to remind folks that Teensy support isn't a focus for Adafruit folks who work on CircuitPython. The features we add for the iMX RT benefit Teensy but aren't driven by the goal of supporting Teensy. We'd love contributions for these things though. It's just not a priority for us.

I don't yet have a Teensy 4.1, just Teensy 4.0.

Any new feature of Teensy 4.1 (with respect Teensy 4.0) is implemented in CircuitPython 5.4.0-beta.0 for Teensy 4.1 ?
- internal 8MB flash memory seems recognized, with 7MB as file system, from post #93;

Different flash sizes are easy to support and should already work.

- all additional pins (to be confirmed);

All pins should just work. When we add support for an MCU we add all pins on it regardless of what is broken out on the board. The only board specific pin support is the name mapping made available in the `board` module. We do end up finding some data copy issues for pins that haven't been tested. These bugs are somewhat rare and easy to fix when we find them.

- microSD (most important feature, IMHO) ?

We currently support SD cards with a Python library: https://github.com/adafruit/Adafruit_CircuitPython_SD/ This will work on any board with SPI support on SD card pins. Jeff (jepler) is also actively working on native SD card support (both SPI and SDIO) for STM and SAMD51 I believe. This will make it easier to support on iMX because the APIs will be established already. However, I don't know if adding iMX RT support is planned.

- QSPI Memory via external PSRAM and/or flash chips ?

We don't have any immediate plans to support additional RAM or FLASH. It should be usable over the SPI connection but not natively.

- USB host via Teensy 4.1's USB Host port ?

This would depend on USB host support for iMX RT in TinyUSB and also establishing USB host APIs in CircuitPython. It is something we'd like to do at some point but it's not something we plan to do soon.

- Ethernet network via 10/100 Mbit Ethernet PHY ?

We don't have plans to add support for this. We have "native" support for WizNet but we'll likely deprecate it. Most of our network support is from Python-only and I'd like us to have a better API that handles Python support primarily and then fits native into that. We'll be evolving the APIs for this with the ESP32S2 WiFi support that is upcoming and a priority.

Hope that gives some insight into our priorities! As always, we'd love more contributors to CircuitPython and are always happy to help get folks working on CircuitPython. These priorities are for those of us sponsored by Adafruit.
 
Thanks @tannewt for the detailed answer. Excellent, the microSD can work with the Adafruit_CircuitPython_SD library, and the community can develop drivers to access PSRAM and/or flash external IC's via SPI interface.

Together with more internal flash memory (as file system) and more exposed pins, these features make the Teensy 4.1 worth when using CircuitPython, compared to Teensy 4.0.

So I'll buy some Teensy 4.1.
 
Last edited:
There is a check in the Teensy loader that prevents loading Teensy 4.0 on Teensy 4.1 systems, and vice versa.

That hardware compatibility check only works if the .elf file corresponding to the .hex file is present in the same folder, and only if the .elf file was built by gcc using settings similar to what's normally used with Arduino & Teensyduino. The .hex file alone simply does not contain the necessary info for Teensy Loader to check which board was meant to be used.

Looks like the Circuit Python site is only providing the .hex file. But the filename does contain the board name, so this hardly seems like an issue. If you do load the wrong .hex file, you can always just press the button on Teensy to get back into bootloader mode. Or you can do the 15 second press to fully wipe the flash and restore a known-good LED blink if things go really wrong.
 
That hardware compatibility check only works if the .elf file corresponding to the .hex file is present in the same folder, and only if the .elf file was built by gcc using settings similar to what's normally used with Arduino & Teensyduino. The .hex file alone simply does not contain the necessary info for Teensy Loader to check which board was meant to be used.

Looks like the Circuit Python site is only providing the .hex file. But the filename does contain the board name, so this hardly seems like an issue. If you do load the wrong .hex file, you can always just press the button on Teensy to get back into bootloader mode. Or you can do the 15 second press to fully wipe the flash and restore a known-good LED blink if things go really wrong.

Hmmm, you are right. I thought I had checked running the 4.0 version on 4.1 and the loader rejected it. I was able to load the Teensy 4.0 version on to the Teensy 4.1, and it gave me 1 megabyte file instead of the 7 megabyte file normally with the 4.1. I didn't do any tests on whether it worked, I just looked at the size of the CIRCUITPY file system that was mounted.
 
Paul:
On the Teensy 4.0 and Teensy 4.1, did you blow the fuses for the FlexRAM memory controller, or is it firmware configured at boot?
If you did a hard allocation with the fuses, could you share what the configuration is?

Thanks,
--- Graham

==
 
@GrahamH - Obviously Paul is the best one to answer this, but might help if you mentioned what you are looking for.

That is, you might be able to find what you are looking for, by looking at a couple of files that are part to cores\teensy4

including the linker scripts: like imxrt1062.ld for the T4 and imxrt1062_t41.ld for T4.1

And then look at startup.c. where you find inclusion of data from the linker scripts

Also has functions like configure_cache()
Which sets up all of the memory regions, with their different caching options.

And likewise configure_external_ram() which on T4.1 can handle the memory that is optionally added to bottom.

The main handler is the function ResetHandler()
Which calls the above, plus configures DTCM/ITCM and copies the stuff down from the Flash...

But if you are referring to things like reserved space for default program or EEPROM space reserved, that is probably something different.
 
Hi Kurt:
"might help if you mentioned what you are looking for."

I am trying to figure out if the FlexRam RAM allocations are fixed, ie. the fuses have been blown, or if the RAM allocations can be modified, ie. they are being set by firmware at time of boot and might be modifiable by the files you mentioned.

I don't understand enough yet to know what would happen if there was a conflict.

Thanks,
--- Graham
 
Yes, since the RT1062 has four times the RAM as the 1011, optimum allocations are probably different. I am just trying to verify that the allocations can be changed.
--- Graham
 
Thanks for adding DCache support. I added T4 v6 lines to benchmarks in post #14. Some tests are faster than v5 dcache-hack, some are slower.
 
Thanks for adding DCache support. I added T4 v6 lines to benchmarks in post #14. Some tests are faster than v5 dcache-hack, some are slower.

Thank you! My guess is the slight perf hit to OCRAM will cause any test that uses the heap to be a bit slower than the hacked version. This version works with USB though. :)
 
I'm curious what the state of Circuitpython is on Teensy 4.x? I know that it's not a priority, but I'm curious if there have been any improvements. Thank you for everyone's hard work!
 
I'm curious what the state of Circuitpython is on Teensy 4.x? I know that it's not a priority, but I'm curious if there have been any improvements. Thank you for everyone's hard work!

Not much has happened recently. Most focus has been on the ESP32-S2 and RP2040. We (Adafruit) do have a design of a metro with an iMX RT on it so we'll be revisiting iMX RT support when that launches. We'll at least make sure what we have now is solid. It's hard to know what additional work will be done.
 
I know there will be a good reason, but why does an ATSAMD21 board (Adafruit QT Py) have rotaryio support under circuitpython but the Teensy 4.0 does not? Interested to know why this happens.
 
I know there will be a good reason, but why does an ATSAMD21 board (Adafruit QT Py) have rotaryio support under circuitpython but the Teensy 4.0 does not? Interested to know why this happens.

Most development of CircuitPython is funded by Adafruit. (I'm paid full-time to work on CircuitPython for them. A couple others are paid as well.) That means we focus on adding support for Adafruit boards and many of them have the SAMD21. Adafruit doesn't currently make any iMX RT boards so they haven't sponsored anyone to implement it. Much of the iMX RT port was done by volunteers but they never got to `rotaryio`. So, if you want to see it supported, I suggest digging into it yourself or sponsoring someone to.
 
I'm having a hard time figuring out how to get I2C working with CircuitPython on Teensy 4.0.
I get "RuntimeError: No pull up found on SDA or SCL; check your wiring"
I can't seem to find any information online on how to setup the pinMode for board.SCL & board.SDA correctly with CircuitPython.
Can anyone point me in the right direction?

unnamed.jpg

Code:
import time
import board
import busio
import digitalio

i2c = busio.I2C(board.SCL, board.SDA)

while not i2c.try_lock():
    pass

try:
    while True:
        print("I2C addresses found:", [hex(device_address)
              for device_address in i2c.scan()])
        time.sleep(2)

finally:  # unlock the i2c bus when ctrl-c'ing out of the loop
    i2c.unlock()
 
These are the pin definitions for the default board.I2C() in CircuitPython:

SDA: GPIO_AD_B1_01
SCL: GPIO_AD_B1_00

It looks like those are the pins you selected, but double check. Did you measure the voltage at those pins to see if the pull-ups are working and the wiring is OK?

If you ask in our forums (https://forums.adafruit.com) or Discord (https://adafru.it/discord), more eyes would see your query.
 
These are the pin definitions for the default board.I2C() in CircuitPython:

SDA: GPIO_AD_B1_01
SCL: GPIO_AD_B1_00

It looks like those are the pins you selected, but double check. Did you measure the voltage at those pins to see if the pull-ups are working and the wiring is OK?

If you ask in our forums (https://forums.adafruit.com) or Discord (https://adafru.it/discord), more eyes would see your query.

I checked the levels of the pins. They were low. I checked them again, and as I checked the second time I saw pin 19 go from low to high. I checked pin 18 and it was low, then it went high.
I saved the code which restarted it and the code ran without error showing the address of the BNO055 board as 0x28.
I pulled the USB cable out and reinserted it. At that point it wouldn't show up as a USB flash drive or serial device. But when I pulled the wires from pins 18 & 19 it would show up as a drive.
When I insert the wires as it is plugged in it remains a USB serial device and can run the code.

I have repeated this exact behavior with a total of 6 Teensy 4.0 boards.
This can't be expected behavior can it?
 
The BNO055 board has its own pullups. So when it's not wired to the Teensy, you should see about 3.3V on the SCL and SDA pins on the breakout. You have 3V from the Teensy going to VIN on the breakout, I think, but it's a little hard to see from the picture.

What version of CircuitPython are you using? Try the latest (7.0.0-rc.2) and also 6.3.0 if you have not already.
 
The BNO055 board has its own pullups. So when it's not wired to the Teensy, you should see about 3.3V on the SCL and SDA pins on the breakout. You have 3V from the Teensy going to VIN on the breakout, I think, but it's a little hard to see from the picture.

What version of CircuitPython are you using? Try the latest (7.0.0-rc.2) and also 6.3.0 if you have not already.

Based on this page, 7.0 isn't available for Teensy. https://circuitpython.org/board/teensy40/
So yes, I am running 6.3.0.
I do have 3V from the Teensy to VIN on the breakout. Is that a mistake? I have it wired according to this diagram. https://learn.adafruit.com/assets/91713

When I have the SCL and SDA pins on the BNO055 disconnected I see 3.3V on the pins. The SCL and SDA pins on the Teensy are 0.0V.
When I have the SCL and SDA pins on the BNO055 connected to the Teensy it won't show up as a USB device on my PC. I can't program it or run the code or see the serial output.
If I pull one or both of the wires then the Teensy will show up as a USB device. If while it is connected to USB I re-connect the pulled wires I can then update the code and it will run.

I have tried the same scenario with a total of 6 Teensy 4.0 boards and 3 different I2C devices.
I have successfully connected to the I2C devices using an Adafruit Clue board.
Obviously this is untenable and to me seems like some kind of bug in the configuration of the Teensy pins.
Am I the first person to try to connect i2C devices to a Teensy 4.0 with CircuitPython?
 
LOL the buttons are gray so I thought it wasn't available. duh. Loading the 7.0 version asap.
I posted on the Adafruit forum last night. no response so far. fingers crossed.
 
Back
Top