CircuitPython on Teensy 4!

As a follow up to my previous post on a settable system clock for circuit python on the T4.1 I finally got it working I think. Its basically a conversion of the T4 clocks.c in the core
Code:
PU freq: %d 960000000
Pystone(1.2) time for 500 passes = 57769777 ms
This machine benchmarks at 8655 pystones/second

CPU freq: %d 600000000
Pystone(1.2) time for 500 passes = 79864499 ms
This machine benchmarks at 6260 pystones/second

Here are the files if you want to play.

1. In /ports/mimxrt10xx/common-hal/microcontroller the file Processor.c has to be updated to:
View attachment Processor.h View attachment Processor.c

2. In ports/mimxrt10xx/peripherals/mimxrt10xx clocks.h should change to:
View attachment clocks.h

3. In ports/mimxrt10xx/peripherals/mimxrt10xx/MIMXRT1062 clocks.c should change to:
View attachment clocks.c

and

4.In shared-bindings\microcontroller
View attachment Processor.h View attachment Processor.c


To set a new clock speed:
Code:
microcontroller.cpu.setfreq(xxxx)
 
@mjs513

Great work, will have to sync it up...

I was distracted today with how do uarts work on CircuitPython. Still not sure :eek:

A simple Uart test, where I receive text from the usb serial inpu(), then send it to uart1, which when it receives it sends it to uart2 object:
Code:
uart1 = busio.UART(board.D1, board.D0, baudrate=1000000)
uart2 = busio.UART(board.D8, board.D7, baudrate=1000000)

The echo worked fine on current released version, but screws up on the next beta and current sources... So I thought I would try it on some other
board to see if changes to teensy (IMXRT) or main code... So tried Adafruit Feather RP2040... Ran into interesting issues where the board would crash, and it would not allow me to
create two uart objects (it has two)... Theory is one of them is taken up by one defined in board.... board.UART(), ok fine... Now how do I set the baud rate.
My attempts caused the system to fault out into safe mode... had to reflash and run code to reformat the logical disk....

Then tried an ESP32-S3 ... Which I know is in alpha state, and tried running sketch that is up on circuit python page for uarts, that enumerates all of the logical pins defined in board object as rx and tx and sees if any of them succeed and print that out... Ran it on the ESP32, and Mu serial area showed some info, and then board completely crashed, took out mu serial area, logical disk... Ended up reflashing it, still did not run, then first erased spi flash and then reflashed and it would boot again...

So not overly productive today... maybe best to get back to figure out where in the uart serial code that changed and see what is going on.
 
@KurtE

While implementing a settable clock for the T4.x's I was comparing the times to calculate 20K prime numbers and compared to the C++ implementation CPy was way slower:
Code:
C++: 0.003 minutes
CPy : 0.359 minutes

After doing some googling determined that the fault was mine. With CPy or Micropython you have be design your coding to with several things in mind. So after doing a minor rewrite a more realistic comparison is:
Code:
C++: 0.003 minutes
CPy : 0.150 minutes

Still on par with C++, 50x slower, but better than what I was reading about. Just by way of comparison using the same script
Code:
Adatfruit STM32F405 Express @168Mhz:  0.691671 minutes
ESP32S3 @240Mhz:                      0.43192 minutes
Adafruit QT PY RP2040 @135Mhz:        1.12076 minutes
Teensy 4.1 @150Mhz:                   0.58465 minutes
Teensy 4.1 @600Mhz:                   0.150 minutes

Have not seen any degradation in things like I2C or SPI speed yet.
 
Also wondering as it looks like CircuitPython was forked from MicroPython, if it would make sense to try to incorporate some of the changes that happened on Micropython after Circuit Python forked?

To be clear, CircuitPython has integrated changes from MicroPython since the original fork. We are currently up to date with the latest release, 1.18. This means the Python VM is almost identical between the two. This doesn't impact iMX port specific stuff though because our iMX ports were developed independently.
 
Back
Top