mciantyre / teensy4-rs

Rust support for the Teensy 4
Apache License 2.0
271 stars 31 forks source link

SD card driver #102

Closed mciantyre closed 1 year ago

mciantyre commented 3 years ago

This issue tracks ideas and discussions for a Rust-based SD card driver for Teensy 4.1 boards. Some possible goals:

  1. a driver that can interface SD cards, and is usable across all i.MX RT processors.
  2. a FAT32 filesystem for the Teensy 4.1, available through the BSP.

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.

mciantyre commented 3 years ago

Pinout

Screenshot below is from the Teensy 4.1 schematic.

image

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.

image

Couple of ideas:

anstylian commented 3 years ago

Can you provide a brief explanation about "Prototype a new pin trait in the imxrt-iomuxc crate."?

mciantyre commented 3 years ago

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.

mciantyre commented 2 years ago

imxrt-rs/imxrt-iomuxc#24 explores uSDHC pin traits and implementations for the Teensy 4.1's SDcard pads.

ameliamariecollins commented 1 year ago

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.

ameliamariecollins commented 1 year ago

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.

mciantyre commented 1 year ago

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.

mciantyre commented 1 year ago

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.