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.
andyy
Posts: 3
Joined: Sat Jan 22, 2022 1:38 pm

Re: 4.1 quadratur encoder

Post by andyy » Sat Jan 22, 2022 1:57 pm

Hello Robert and everyone else of course,

I saw the quadrature encoder module for mimxrt on your github account. For my "small" project (Dual EKF) on the Teensy4.1 I need a quadrature encoder for position messurement.
However, I don't know how to use the module? Could you provide a short exsample program to make it easier for me to start?
The build of the firmware shouldn't be a problem, I also compile the ulab modul.

Many thanks in advance.

If it's the wrong place of the post let me know

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 » Sat Jan 22, 2022 2:36 pm

I have a documentation, which is not yet processed as well. Attached is the PDF copy of if. A binary including the Encoder/Counter module is at https://github.com/robert-hh/Shared-Stuff
Attachments
qecnt.zip
(132.1 KiB) Downloaded 168 times

User avatar
Mike Teachman
Posts: 155
Joined: Mon Jun 13, 2016 3:19 pm
Location: Victoria, BC, Canada

Re: Teensy 4.0 & 4.1

Post by Mike Teachman » Sat Jan 22, 2022 10:33 pm

I2S Protocol Update

@Roberthh
@alphaFred

I2S support on the mimxrt port is about 99% complete. I considered submitting a PR but there are a couple of outstanding issues that are best discussed informally in the forum.

The mimxrt I2S implementation is in a github branch, here. The branch is rebased to the master (as of Jan 22), with one commit containing all changes for I2S, here

I2S is supported on the following development boards:
  • Teensy 4.1 (tested)
  • Teensy 4.0 (untested)
  • Seeed Arch Mix (untested)
Minor changes needed in mimxrt features:
  1. machine.SPI: The global DMA init in machine_spi.c stops the I2S DMA. This was fixed by adding a global DMA init, shared between the SPI and I2S features, in new files dma.c/dma.h
  2. machine.SDCard: The SD card write timeout was increased from 500ms to 3000ms to accommodate the very long write cycles that occasionally happen with SD cards.
Limitations on the mimxrt port:
  1. fixed set of sampling frequencies. 9 commonly used frequencies, from 8kHz to 48kHz.
  2. no I2S support for the MIMXRT10xx evaluation boards:
    • The evaluation board headers do not bring out I2S compatible processor pins
    • The built-in I2S device requires a MCK signal which is not presently supported by machine.I2S (future development?)
I2S examples: Outstanding issues:
  1. Docs: I could not find any docs to update for the mimxrt port.
  2. iomux_table_t typedef repeated in 5 C files: recommendation: move this typedef to a new file, iomux.h, add #include to these 5 files.
  3. combine the files dma.c (new) and dma_channel.c?: into dma.c?
@Roberthh, @alphaFred: can you please give me your thoughts on the outstanding issues listed above. Thanks!

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 Jan 23, 2022 8:55 am

Hello Mike,
thank you very much for your work. I had seen on your repository that you did a lot of work on the I2S support. The issues I have now with testing is, that @alphafred and me have MIMXRT10xx boards with Audio hardware, but not such a thing for the Teensy. So which output driver/hardware did you use for testing?

About the questions in the issues:

- Docs: I could not find any docs to update for the mimxrt port.
There is a doc PR present & ignored since a July. It's #7494.
- iomux_table_t typedef repeated in 5 C files: recommendation: move this typedef to a new file, iomux.h, add #include to these 5 files.
That grew indeed over time. AFAIK, the first one was in machine_uart.c. Good candidate for cleanup. A good file to put that in is mphalport.h, except for eth.c, where the definition of the type is different and would have to be renamed (e.g. iomux_table_eth_t).
- combine the files dma.c (new) and dma_channel.c?: into dma.c?
You can of course move the content of dma.* into dma_channel.*

I would add the as open issue:
- Support the MIMX10xx boards.

About SDCARD:
- The SDCARD driver will change in one of the next PRs, when the version of the NXP library will be ramped up from v2.6 (2018) to v2.11 (2022). I'm testing that already, but given the slow pace of PR approvals that will take another few months. The change consists of using the TransferBlocking() API from the library instead of the own coded. We cold not get TransferBlocking to work with Library v2.6.

P.S.: We can also discuss at your Github branch.
P.P.S.: Please do not issue a PR until we had a chance for testing.

User avatar
Mike Teachman
Posts: 155
Joined: Mon Jun 13, 2016 3:19 pm
Location: Victoria, BC, Canada

Re: Teensy 4.0 & 4.1

Post by Mike Teachman » Sun Jan 23, 2022 5:15 pm

Hi Robert,

Thank you for the fast response.
Roberthh wrote:
Sun Jan 23, 2022 8:55 am
So which output driver/hardware did you use for testing?
Here is the hardware I have been using:
Roberthh wrote:
Sun Jan 23, 2022 8:55 am
There is a doc PR present & ignored since a July. It's #7494.
That is frustrating. You made a lot of work in this PR. I hope it gets integrated soon.
Roberthh wrote:
Sun Jan 23, 2022 8:55 am
Good candidate for cleanup. A good file to put that in is mphalport.h, except for eth.c, where the definition of the type is different and would have to be renamed (e.g. iomux_table_eth_t).
I can move the typedef to mphalport.h and rename the other typedef in eth.c. Are you OK that I make these changes?
Roberthh wrote:
Sun Jan 23, 2022 8:55 am
You can of course move the content of dma.* into dma_channel.*
That is definitely the easiest option, but after adding a dma init function, the filename dma_channel.* no longer seems to be the best filename abstraction. dma.* might be a better file naming choice for all code that relates to dma? Please recommend what option you prefer and I can implement that.
Roberthh wrote:
Sun Jan 23, 2022 8:55 am
I would add the as open issue:
- Support the MIMX10xx boards.
Good idea. If there is enough demand I can add a Master Clock API option (e.g. mclk=Pin()) to all MicroPython ports that support the I2S protocol (esp32, stm32, rp2, mimxrt). A MicroPython driver will also be needed to configure the Audio CODEC device on the evaluation boards (WM8960 CODEC). The hardware configuration interface to this device is I2C. https://www.cirrus.com/products/wm8960/
Roberthh wrote:
Sun Jan 23, 2022 8:55 am
P.P.S.: Please do not issue a PR until we had a chance for testing.
Sure. There is no rush to submit the I2S PR. When the mimxrt Doc PR is accepted I will add documentation to the I2S PR.

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 Jan 23, 2022 5:32 pm

I can move the typedef to mphalport.h and rename the other typedef in eth.c. Are you OK that I make these changes?
Better keep that separate from the I2S PR. I have kind of regular Service type PR, which are use for such cleanup tasks.
That is definitely the easiest option, but after adding a dma init function, the filename dma_channel.* no longer seems to be the best filename abstraction. dma.* might be a better file naming choice for all code that relates to dma? Please recommend what option you prefer and I can implement that.
You can do that. The only other affected file seems to be machine_spi.c. dma.* seems to be a little bit too general, maybe dma_manager or dma_arbiter indicates the task better.
add a Master Clock API option
Please do that. There is no rush. I have ordered other boards for testing with the MIMXRT devices.

I made also a few comments at your github site's branch. There may be more as soon as I start testing.

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 » Mon Jan 24, 2022 12:52 pm

A MicroPython driver will also be needed to configure the Audio CODEC device on the evaluation boards (WM8960 CODEC).
The device looks complicated. But luckily there is a C-Driver provided by NXP, which can either be translated into Python, or be included for the MIMXRT10xx_EVK boards.

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

Re: Teensy 4.0 & 4.1

Post by alphaFred » Mon Jan 24, 2022 1:38 pm

or be included for the MIMXRT10xx_EVK boards
I am inconclusive about that. Such a driver for an external peripheral should not be a part of the mimxrt repo in my point of view.

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 » Mon Jan 24, 2022 2:02 pm

There are already board/MCU specific variants, like with 0, 1, or 2 Ethernet ports, or with/without USDHC support, or with/without QTimer/Encoder support. I have to verify which external signals are required, like for instance a clock signal. That would have to be configured even when the driver itself is external Python code.

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

Re: Teensy 4.0 & 4.1

Post by alphaFred » Mon Jan 24, 2022 2:39 pm

That is correct but I believe that a driver for an external IC is different. Supporting MCU specific features like you the ones you mentioned is of course important for the mimxrt port :)

Post Reply