Closed mciantyre closed 1 year ago
Screenshot below is from the Teensy 4.1 schematic.
These pins are assigned to the USDHC peripheral. Notice how the designated clock pin aligns with USDHC1_CLK in the SD_B0_01 pin muxing.
Couple of ideas:
Can you provide a brief explanation about "Prototype a new pin trait in the imxrt-iomuxc crate."?
The imxrt-iomuxc crate defines i.MX RT pins. The crate uses traits to indicate what pins can support a peripheral function. For instance, these 1060 pins can be used with SAI peripherals. The SAI pin trait and helper types are defined here. We might need something similar for pins that support USDHC peripherals.
imxrt-rs/imxrt-iomuxc#24 explores uSDHC pin traits and implementations for the Teensy 4.1's SDcard pads.
I'm pretty interested in getting FatFS and LittleFS filesystems up and running on SDIO devices as well as SD over SPI. Of the searchable crates...
amelia@luna:project/pirouette % cargo search fatfs
fatfs = "0.3.6" # FAT filesystem library.
drone-fatfs = "0.2.3" # Bindings to ChaN's FatFs.
[...various drone-fatfs-* crates...]
fatfs-sys = "0.2.0" # Unsafe Rust bindings for fatfs, a library for exFAT and FAT32 filesystems. Currently untested…
...none successfully compiled when added as dependencies, even being careful with included features. I think the right thing to do is make a library specific to microcontrollers. I propose something like embedded-fs
with constructors for filesystems.
Chan's ELM FatFS looks like the most mature and feature rich of FatFS implementations, but it's unclear if it's the ideal one for this purpose. But it's thread-safe, supports Unicode, and it's distributed under a BSD-like license.
I'm happy to support prototyping here, in a separate branch. If we're striving for the first goal, we should eventually contribute the driver to the imxrt-rs org. If we'd like to start in that separate repo, I can create a repo in the org, too.
Yep, this makes sense. It's almost like it's at the level of embedded, certainly above just imxrt, but gets pulled into imrxt-fs or something, and from there into BSPs for Teensy and others.
I have soooooo much to do before diving into this. (For example, learning Rust! Than asking zillions of newbie questions. Then getting a sense of the balance between the projects. Then writing fledgling code that we can all put on an anvil and hammer it until it's solid and good.) But I'd love to be a part of making this happen.
If you're interested in FAT file systems, take a look into embedded-sdmmc. Maybe there's a way to implement the BlockDevice
trait for the uSDHC peripheral.
Also note that embedded-sdmmc already has some kind of SPI support. Here's the BlockSpi
adapter, which provides a default BlocKDevice
implementation. That might already play well with imxrt-hal's SPI drivers, so the "SD over SPI" problem might already be solved.
I'm closing this issue in favor of the imxrt-rs/imxrt-hal#119 upstream issue. An SD card driver would benefit all those who use imxrt-hal, so we should track development there.
This issue tracks ideas and discussions for a Rust-based SD card driver for Teensy 4.1 boards. Some possible goals:
Since it represents new driver development, the effort might span this project, and the imxrt-rs projects. Approaches should consider using the imxrt-ral to access peripheral registers, and imxrt-iomuxc to define any peripheral pins.
I'm happy to support prototyping here, in a separate branch. If we're striving for the first goal, we should eventually contribute the driver to the imxrt-rs org. If we'd like to start in that separate repo, I can create a repo in the org, too.
For general resources, including how to acquire the MCU reference manuals, see the imxrt-hal's resources docs.