Skip to content

GitLab

    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
    • Menu
    Projects Groups Snippets
  • Sign up now
  • Login
  • Sign in / Register
  • T Teensy 4
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 1
    • Issues 1
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Teensy Rust
  • Teensy 4
  • Issues
  • #1
Closed
Open
Created Jan 01, 2020 by Ian McIntyre@mciantyre

On combining our "Teensy 4 in Rust" efforts

Hey Maciej! I've been keeping an eye on your Rust project, and I'm wondering if you'd be interested in combining our efforts into one Teensy 4 Rust project.

Around the time that you started your Teensy 4 project, I was also developing a set of Rust crates to support Teensy 4 development. I've been working on my project over here. Our projects differ in a few ways, and we may be able to benefit from one another's work. In particular,

  • I really like the way you're automatically managing the SVD changes. I've made some manual changes to the MIMXRT1062 SVD file, but you've provided automation and reproducibility atop the publicly-available SVD.
  • Your project supports more peripheral APIs than ours. We're still bringing-up the I2C peripheral, and we haven't even started on UART. I also appreciate your more minimal approach towards IOMUXC code generation. Basically, your approach towards the HAL > our approach towards the HAL.

We may have also solved some issues for you:

  • We've worked around some of the limitations presented by the massive MIMXRT1062 PAC. We semi-automatically create a crate per peripheral, then export the peripheral from a top-level crate. The approach lets us parallelize the build while keeping the API consistent with the normal svd2rust output. On my 2015 MBP, I can compile the entire PAC crate, and the entire repo, in under 1 minute, 30 seconds (release mode). (Proof of concept here.)
  • We have explicit separation between the iMXRT1062 HAL / runtime, and Teensy 4 BSP. This goes all the way down to the firmware configuration block (FCB), where we have a way of defining FCBs in build.rs scripts. It lets us separate some Teensy-specific startup components from our cortex-m-rt-like run-time crate. Although our project's focus is on Teensy 4 support, we also want our crates to be usable in other iMXRT106x systems.
  • Once the work from this PR is published to crates.io, we can use the public version of the cortex-m-rt-macros crate, which let us reduce our reliance on forked cortex-m-rt crates.
  • We have support for PWM output, as well as logging over USB CDC. We're using the standard C Teensy 4 USB stack to achieve the latter.

Would you be interested in talking more about your project's goals? If you're interested, I'd love to find any opportunities to collaborate.

Thanks!

Assignee
Assign to
Time tracking