Teensy 4.0 & 4.1
- Mike Teachman
- Posts: 155
- Joined: Mon Jun 13, 2016 3:19 pm
- Location: Victoria, BC, Canada
Re: Teensy 4.0 & 4.1
16 and 32 bits are supported
Re: Teensy 4.0 & 4.1
Does the Teensy firmware support ulab?
Re: Teensy 4.0 & 4.1
No. It is not integrated into the firmware. It shuold be possible to create such an image, but it will most probably never be a standard image.
Re: Teensy 4.0 & 4.1
I was able to build micropython with ulab for teensy 4.1 without too much trouble.
Re: Teensy 4.0 & 4.1
Nice. Maybe if you give us some sort of step by step guide we could include it in the documentation at least? @Robert-hh what do you think?
Re: Teensy 4.0 & 4.1
Sounds good. The Teensy with it's 768kB heap should work well with ulab. The ARCH MIX board with it's 32 MB heap would be even better for large projects.
Re: Teensy 4.0 & 4.1
[I2s] @miketeachman @rdagger It just noticed, that running the SPI driver without DMA for the SD Card stops the crackling in I2S playback. It works fine for MIMXRT10xx_EVK boards. So there is a kind of interference between DMA used by both the SPI and I2S. With Teensy and SGTL5000 the device locks up after a while. That has to be analyzed further. I do not expect this to be related to the Codec.
edit: The unexpected halt on Teensy disappeared.
edit: The unexpected halt on Teensy disappeared.
Re: Teensy 4.0 & 4.1
[I2S, SPI] No, the problem is still there. What is the situation:
Non-DMA for SPI does not interfere with I2S. So you have a clear sound. But with MIMXRT105x/106x MCUs, non-Blocking transfer with SPI stalls at higher baud rates. The best I could get with a Teensy 4.x audio shield was about 5 MBaud. For 44.1 Samples/sec stereo this is still fast enough. On a Seeed Arch Mix board with long patch cables to a SD Micro shield it was about 2 MBaud. I did bit get that error with MIMXRT101x/102x boards. When the fault happens, the code simply locks up in an endless loop inside the SPI Library function.
But there is silver lining at the horizon: The problem disappears when using a more recent version of the NXP library. At the moment, the project uses version ~2.6. With version 2.10 the SPI problem is gone. And the driver can be compiled to not stall in such a case, allowing to raise an exception and handle the case in the Python script.
The move to library v2.10 or v2.11 is under construction since a while. The problem with that version: it is not backward compatible. So it's quite bit of work and testing, which is mostly done.
Non-DMA for SPI does not interfere with I2S. So you have a clear sound. But with MIMXRT105x/106x MCUs, non-Blocking transfer with SPI stalls at higher baud rates. The best I could get with a Teensy 4.x audio shield was about 5 MBaud. For 44.1 Samples/sec stereo this is still fast enough. On a Seeed Arch Mix board with long patch cables to a SD Micro shield it was about 2 MBaud. I did bit get that error with MIMXRT101x/102x boards. When the fault happens, the code simply locks up in an endless loop inside the SPI Library function.
But there is silver lining at the horizon: The problem disappears when using a more recent version of the NXP library. At the moment, the project uses version ~2.6. With version 2.10 the SPI problem is gone. And the driver can be compiled to not stall in such a case, allowing to raise an exception and handle the case in the Python script.
The move to library v2.10 or v2.11 is under construction since a while. The problem with that version: it is not backward compatible. So it's quite bit of work and testing, which is mostly done.
- Mike Teachman
- Posts: 155
- Joined: Mon Jun 13, 2016 3:19 pm
- Location: Victoria, BC, Canada
Re: Teensy 4.0 & 4.1
I would like to try reproducing the problem with a Teensy 4.1, then try to find the root cause. Can you recommend a configuration that is likely to cause the audio distortion? thanks!
Re: Teensy 4.0 & 4.1
Just connect a SD Micro Card by SPI at pins 10-13 and use that for the file system. The driver is drivers/sdcard/sdcard.py. I use the little script below for mounting. A cs pin has to be provided to the driver, even if the MIMXRT SPI block drives CS itself. The baudrate can be lower, if there are problems.
The SPI driver in machine_spi,c uses BlockingTransfer for short blocks and eDMA for longer blocks. The value for the discrimination is in variable dma_min_size_threshold in line 247. If set to 0, all transfers are eDMA, if set to a high value (e.g. 1 Million), all transfers are BlockingTransfer. For Blocking transfer and SDCard, you have to use alower baudrate, like 5 Mbaud. The SPI driver does not work any more that way with newer versions of the NXP lib. At the moment I prefer use BlockingTransfer only. It's robust, fast and small.
The SPI driver in machine_spi,c uses BlockingTransfer for short blocks and eDMA for longer blocks. The value for the discrimination is in variable dma_min_size_threshold in line 247. If set to 0, all transfers are eDMA, if set to a high value (e.g. 1 Million), all transfers are BlockingTransfer. For Blocking transfer and SDCard, you have to use alower baudrate, like 5 Mbaud. The SPI driver does not work any more that way with newer versions of the NXP lib. At the moment I prefer use BlockingTransfer only. It's robust, fast and small.
Code: Select all
import os, sdcard, machine
spi = machine.SPI(0) # SPI0 with cs1 used for SDCARD
cs = machine.Pin(10, machine.Pin.OUT, value=1)
sd = sdcard.SDCard(spi, cs, baudrate=20_000_000)
vfs = os.VfsFat(sd)
os.mount(vfs, "/sdcard")
os.chdir("/sdcard")