Teensy 4.0 & 4.1

Discussion and questions about boards that can run MicroPython but don't have a dedicated forum.
Target audience: Everyone interested in running MicroPython on other hardware.
User avatar
Roberthh
Posts: 3667
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: Teensy 4.0 & 4.1

Post by Roberthh » Sun Aug 22, 2021 6:10 am

I've just re-tested it here and it works. It is a basic port-independent mechanism. What do you get, when you execute these three lines:

import sys
sys.path.append("/lib")
print(sys.path)

User avatar
Roberthh
Posts: 3667
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: Teensy 4.0 & 4.1

Post by Roberthh » Wed Sep 22, 2021 7:49 am

@RobH and others: Since getting PR's approved can take a while, I have bundled the actual PR into a set of binaries and placed them at https://github.com/robert-hh/Shared-Stuff. Beyond the actual official firmware includes support for Ethernet, PWM, WDT, DHT and 32 MByte heap size for the MIMXRT1020 and MIMXRT1050 boards. The Microypython code execution speed is also improved. The pystone_lowmem rate at Teensy 4.1 andMIMXRT1050 is now in the 9000 range. For MIMXRT1020 and MIMXRT1010 it's in the 4000 range.

User avatar
RobH
Posts: 91
Joined: Fri Mar 23, 2018 3:37 pm
Location: Netherlands
Contact:

Re: Teensy 4.0 & 4.1

Post by RobH » Wed Sep 22, 2021 2:08 pm

@Roberthh: the performance boost would be a impressive jump.
Just tried it on my Teensy 4.0 and noriced just over 7200 pystones, which is more than twice the value of the current firmware (1.17-68 performs a little over 3500 pystones). I would be interested to hear an explanation (understandable for someone without any knowledge of the architecture pls!).

User avatar
Roberthh
Posts: 3667
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: Teensy 4.0 & 4.1

Post by Roberthh » Wed Sep 22, 2021 2:48 pm

I assumed you would be interested on that optimisation. The 'how' is no secret. I moved the runtime engine of MicroPython from Flash to IRAM. Flash is serial & slow, IRAM is parallel and fast. That was just a first attempt without detailed profiling, and used just ~20k of the the 128k IRAM. So there is more space to use for timing critical activities. One example (already included) is to move the mpirq handler, responsible for callbacks, and machine_pin to IRAM as well. That reduced the Pin IRQ latency for hard callbacks to about 1 µs. It was ~2.5µs before, quite good already. So we can look for more heavily used a lot at runtime and move that to IRAM.

alphaFred
Posts: 31
Joined: Wed Apr 15, 2020 6:47 pm

Re: Teensy 4.0 & 4.1

Post by alphaFred » Wed Sep 22, 2021 3:05 pm

With the overall improvements in Linker scripts and flash configuration the task of optimisation got a lot simpler. Especially for the “less” powerful versions a rework of the OCRAM size might be beneficial in freeing up more space for ITCM.

We have a PR ready for support of the SDRAM but I am a bit sceptical now if we actually do us a favour with moving the heap there. I guess we could I implement an option to have more performance by keeping as much as possible in tightly coupled memory or have more space.

User avatar
rdagger
Posts: 143
Joined: Tue Feb 28, 2017 6:16 pm
Contact:

Re: Teensy 4.0 & 4.1

Post by rdagger » Mon Oct 04, 2021 8:54 pm

Roberthh wrote:
Wed Sep 22, 2021 7:49 am
@RobH and others: Since getting PR's approved can take a while, I have bundled the actual PR into a set of binaries and placed them at https://github.com/robert-hh/Shared-Stuff. Beyond the actual official firmware includes support for Ethernet, PWM, WDT, DHT and 32 MByte heap size for the MIMXRT1020 and MIMXRT1050 boards. The Microypython code execution speed is also improved. The pystone_lowmem rate at Teensy 4.1 andMIMXRT1050 is now in the 9000 range. For MIMXRT1020 and MIMXRT1010 it's in the 4000 range.
I tried your build and it works great! Any plans to implement I2S? The Teensy audio adapter board looks like a great solution for all types of projects. Also what are you guys using for file transfers with the Teensy?

User avatar
Roberthh
Posts: 3667
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: Teensy 4.0 & 4.1

Post by Roberthh » Tue Oct 05, 2021 6:14 am

I2S and SP-DIF is on our list for new modules. These may be the next ones we tackle.
I use mpremote for transferring files to teensy 4.0 and 4.1, and ftp for transfers to teensy 4.1. You may as well use rshell or any of the existing IDEs like Thonny.
Attached are copies of uftpd and utelnetsever for the board. uftp will start immediately after import, for utelnetserver you have to type:

import utelnetserver
utelnetserver.start()
ftp_telnet.zip
(6.08 KiB) Downloaded 266 times

loboris
Posts: 344
Joined: Fri Oct 02, 2015 6:19 pm

Re: Teensy 4.0 & 4.1

Post by loboris » Tue Oct 05, 2021 1:28 pm

@Roberthh

I'm building the firmware from your repository for the following boards and I have some issues.
Seeed's Arch-Mix based on RT1052
VisionSOM-RT module with RT1062 on VisionCB-RT-STD carrier board
Both boards are mostly compattible with MIMXRT1050_EVK and MIMXRT1060_EVK, same basic setup (USB ports, same qspi flash, etc.).
The build finishes fine and the firmware.bin is generated.
  • If I flash the firmware with J-Link, the firmware does not boot.
  • If I flash the firmware with MCUXpresso Secure Provisioning Tool (Note: Secure Provisioning Tool does not use FlexSPI Configuration Block (FCB, the first 4KB in Flash) from the generated firmware bin, but generates its own) the firmware boots, but with the following issues:
    - firmware freezes while executing _boot.py
    - If I comment the code in _boot.py where the flash fs initialization is performed, the firmware boots and I can access the REPL.
With firmware booted and REPL available the situation is as follows:
The Flash area where the file system is located (0x60100000) can be read correctly (I've flashed some data to that area with J-Link to have some more information):

Code: Select all

>>> import sys
>>> import mimxrt
>>> from machine import Pin
>>> bdev = mimxrt.Flash()
>>> buf = bytearray(1024)
>>> bdev.readblocks(0, buf)
>>> buf
bytearray(b'/*\n * This file is part of the MicroPython project, http://micropython.org/\n *\n * The MIT License (MIT)\n *\n * Copyright (c)
...
NT. IN NO EVENT SHALL THE\n * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY')
>>> 
but when I try to write some data, the block is erased, but nothing is written:

Code: Select all

>>> b = b'X'*128
>>> bdev.writeblocks(0, b)
0
>>> bdev.readblocks(0, buf)
>>> buf
bytearray(b'\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff
\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff
...
\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff')
furthermore, If I try to write the larger block, it freezes (that is the reason why the firmware does not start with unmodified _boot.py):

Code: Select all

>>> b = b'X'*256                                                                                                                            
>>> 
>>> 
>>> bdev.writeblocks(0, b)
=== FREEZES ===
The issues occurs on both tested boards.

Any help would be appreciated.

alphaFred
Posts: 31
Joined: Wed Apr 15, 2020 6:47 pm

Re: Teensy 4.0 & 4.1

Post by alphaFred » Tue Oct 05, 2021 2:00 pm

From which flash device are you booting?

The 1050_EVK is currently configured to boot from HyperFlash. You can configure the flash type with BOARD_FLASH_TYPE in boards/<BOARD>/mpconfigboard.mk.

It is important that the configured type matches the desired flash on the board and the boot selection since QSPI flash and HyperFlash require different FlexSPI configuration.

loboris
Posts: 344
Joined: Fri Oct 02, 2015 6:19 pm

Re: Teensy 4.0 & 4.1

Post by loboris » Tue Oct 05, 2021 2:14 pm

alphaFred wrote:
Tue Oct 05, 2021 2:00 pm
From which flash device are you booting?

The 1050_EVK is currently configured to boot from HyperFlash. You can configure the flash type with BOARD_FLASH_TYPE in boards/<BOARD>/mpconfigboard.mk.

It is important that the configured type matches the desired flash on the board and the boot selection since QSPI flash and HyperFlash require different FlexSPI configuration.
On both boards I'm booting from qspi flash.
For RT1052 the build command was:

Code: Select all

make BOARD=MIMXRT1050_EVK BOARD_FLASH_TYPE=qspi_nor
For RT1062 board the BOARD_FLASH_TYPE=qspi_nor is not needed as the default is to use qspi flash (I've built with this option anyway).

Anyway, as I've described, I can get the boards boot and the flash is accessible, only the flash write issues are present...

Post Reply