profile
viewpoint
Ian McIntyre mciantyre Pittsburgh

mciantyre/teensy4-rs 62

Rust support for the Teensy 4

mciantyre/mock-smbus-arduino 5

Pretend like your Arduino is an SMBUS battery

imxrt-rs/imxrt-boot-gen 2

Generate data structures for booting iMXRT processors

mciantyre/ladderlogic 2

Ladder Logic graphical parser, written in Haskell

mciantyre/python-hospital-simulator 2

Teaching Python to BioEs, or teaching BioEs to Python

mciantyre/scipy-opencv-notebook 2

Jupyter's scipy-notebook Docker image from jupyter/docker-stacks, plus OpenCV

ebelski/rust-copter 1

A quadcopter build using a Teensy running Rust and some other cool stuff that's yet to be determined.

mciantyre/LabVLC 1

Programmatic video playback and control in LabVIEW using VLC

mciantyre/simple-stl-render 1

Simple STL viewer in the browser

mciantyre/teensy4-rs-template 1

A cargo-generate template for Teensy 4 projects

issue openedimxrt-rs/imxrt-rs

RFC: Maintain i.MX RT-specific drivers in separate repos

In #56, we discuss a split HAL, which will have a single HAL crate per i.MX RT processor family. The HALs will probably depend on imxrt-iomuxc, our custom driver for pad multiplexing and configuration.

We maintain imxrt-iomuxc in this repository. However, this issue proposes that we maintain imxrt-iomuxc, along with other foundational, chip-specific drivers, in separate repositories. The approach will have us maintain only the split HALs, the common HAL, and the RAL in this repository.

I define a "foundational, chip-specific driver" as a library that

  • is specialized for i.MX RT processors
  • could be used across higher-level i.MX RT libraries within our organization, and outside our organization
  • fully replaces the equivalent API provided by imxrt-ral
  • requires a higher-level, safe interface before exposing to end-users

Drivers that meet this criteria include

  • IOMUXC, released as imxrt-iomuxc
    • API for pad configuration and multiplexing, specific for our processors
    • Used in HAL, async HAL; depended on by teensy4-pins
    • Does not depend on the RAL
  • CCM, in development as imxrt-ccm
    • API for clock configuration, and clock gating. Prototyped in ccm module of async HAL, but considered for HAL integration in #92
    • By default, usable without the RAL. Will optionally depend on RAL as a convenience for RAL-based APIs (#92).
  • DMA, in development as imxrt-dma
    • Unsafe API for allocating DMA channels, and scheduling DMA transfers. Re-exported by HAL and async HAL behind a safe interface.
    • Developed in HAL, then ported to async HAL with minimal changes. There's much code and documentation that could be shared.
    • Will not depend on the RAL

Pros

My thoughts for separating the development of these crates from the HAL:

  • We signal that these crates are for public use. Today's imxrt-iomuxc crate appears to be an implementation detail of the HAL. However, I'm happy to support it for others who want to use it outside of our HALs, or to develop more convenience APIs for their systems (like teensy4-pins). I also intend to support imxrt-ccm and imxrt-dma for similar users.
  • We share capabilities within our organization, while ensuring that one use-case doesn't dominate development. I'd like to keep using imxrt-iomuxc in the async HAL, just as we use it within the HAL. By separating the repositories, we can ensure that changes to imxrt-iomuxc are not biased towards support of the HAL at the expense of the async HAL. This extends towards external users, too.
  • We can more easily track changes, discuss issues, add documentation, and maintain releases independent of the HAL.

Cons

This comes with some downsides. Namely, it's more difficult to integrate work into the HAL(s). However, after prototyping the async HAL, which depends on imxrt-iomuxc as a git dependency, I don't consider these to be difficult challenges. I've listed my thoughts on these downsides below the problem.

  • Changes require two separate commits in two separate repositories.
    • No way around this. Workaround includes instructing contributors to use local path dependencies / git dependencies when prototyping, if they prefer.
    • (I consider this a feature in the vein of "easily tracking changes" and making sure a driver's development isn't dominated by one use case.)
  • Path dependencies are not portable across development environments.
    • Path dependencies are solved by git dependencies.
  • Continuous integration is less obvious.
    • When the HAL depends on imxrt-iomuxc as a git dependency, it will ensure that the APIs work as expected. CI doesn't change.
    • imxrt-iomuxc, and the other foundation drivers, should be tested in isolation, without us relying on "it works in the HAL." Relates back to "dominate development for a single use-case."
  • Requires more release coordination
    • No more difficult than releasing imxrt-iomuxc before the HALs, which we already do.
    • Still need to figure this out for imxrt-iomuxc and the async HAL support in today's model.
  • Inconsistent with imxrt-ral maintenance, which happens in this repository.
    • A similar approach might have us maintain the RAL in a separate repo. Out of scope until we have a stable design for #56.

Alternatives

An alternative approach would have us maintain the foundational, chip-specific drivers in this repository. However, these drivers still be shared with the async HAL in the manner described above, which may relegate the async HAL to a "less important" project in our organization. Once we're sharing the crates across both HALs, there's no reason why the foundational crates should be maintained here, versus in the async HAL repository. (A further step might including moving the async HAL into this repository; however, I feel the projects are different enough to warrant a repository boundary and separate issue tracker.)

Another approach would do nothing. We continue maintaining imxrt-ccm and imxrt-dma as separate modules within each of the HAL and async HAL projects. I'm not opposed to this approach; I did this with the HAL's dma module to support async HAL prototyping. But, this results in code duplication, which could have been mitigated. Still need to figure out how imxrt-iomuxc is consumed by async HAL.

Next Steps

If accepted, I'll

  • port imxrt-iomuxc to a separate repo
    • ensure that we have no pending changes to imxrt-iomuxc
    • move the imxrt-iomuxc crate into a separate repo under the imxrt-rs organization
    • integrate the crate into the HAL
    • integrate the crate into the async HAL
    • improve the imxrt-iomuxc documentation, making it more useful for users and contributors
    • transition any IOMUXC issues (#87) to the new repo
  • publish imxrt-ccm in an imxrt-rs org repo
    • integrate the crate back into async HAL
    • [skipping integration into HAL until #92]
  • publish imxrt-dma in an imxrt-rs org repo
    • integrate crate into HAL
    • integrate crate into async HAL

We will maintain imxrt-iomuxc releases from the new repo. We can release imxrt-ccm and -dma once we explore the APIs in the HAL and async HAL.

created time in 14 hours

push eventimxrt-rs/imxrt-rs

Ian McIntyre

commit sha cab9dddcc66bf3ed2fe403876fada69ef291fd61

Fix documentation examples after 1062=>1060 rename

view details

push time in 17 hours

create barnchmciantyre/imxrt-rs

branch : clear-chip-ids

created branch time in 17 hours

push eventimxrt-rs/imxrt-rs

Tom Burdick

commit sha e3ca177b458a49a2bf204d519383fdae739df375

Creates chip specific imxrt1062-hal crate To start the hal split move the entire imxrt-hal crate to imxrt1062-hal, set all feature flags for dependencies appropriately, and fix the workspace to build on cargo build after checkout. A second imxrt1011-hal can now easily be added, and shared code moved appropriately to a common imxrt-hal-common crate as a dependency of both as time and energy permits.

view details

Tom Burdick

commit sha 43f2e5010da04e34bf307b8ac061479afa3076e7

Update documentation to account for multiple hal(s) Should be updated again when creating the common HAL and a imxrt1011-hal

view details

Ian McIntyre

commit sha be797ab7ed4efe28fd6decb8f392334cb3cfaf1e

iomuxc: fix feature naming discrepancies The "x" suffix is inconsistent with the NXP product naming scheme. Since it diverges, it's not clear what chips are supported for the "imxrt101x" feature. The commit updates the imxrt-iomuxc crate to use product naming conventions. The feature flag migration follows - "imxrt106x" => "imxrt1060" - "imxrt101x" => "imxrt1010" This change is reflected in the filesystem, and in all documentation and code updates.

view details

Ian McIntyre

commit sha 3cdfc6f75403ac6d4ffa81a5944b4cc3d2597fa9

hal: fix feature naming discrepancies See the previous commit for more details. This commit updates the HAL to use the NXP product identifies, instead of our custom "x" suffix.

view details

Ian McIntyre

commit sha 255ea2fd6d110f0108e6170f0bda2acbad5e33b2

iomuxc: eagerly bump version to 0.2 The feature-flag renaming is a breaking change. This commit bumps the imxrt-iomuxc commit to 0.2. The commit updates the HAL to use the new version. The HAL now re-exports a 0.2 imxrt-iomuxc API. Although the symbol names exported from the HAL have not changed, the compiler will still see the types as being incompatible. This means that the HAL has a breaking change. I'm relying on other incoming work in the project (#89) to bump the version for me. Or, we hold off on depending on the imxrt-iomuxc 0.2 release, and nothing breaks.

view details

Ian McIntyre

commit sha b151b1fc7e75b643548272f40c3026ecbc0da02f

Move imxrt1062-hal => imxrt1060-hal

view details

Ian McIntyre

commit sha efcd5bf751c533a260973649aafd0ca98e022011

Update documentation README still refers to the public imxrt-hal, but it points to our tracking issue for a split HAL. I've refined the HAL's README to describe the crate's capabilities. I updated CONTRIBUTING to define what a chip-specific HAL is intended to support.

view details

Ian McIntyre

commit sha 0fa10fa6162e857b8f47f2cc1b9f8408d7785823

cargo fmt

view details

Ian McIntyre

commit sha cacb44c3fa55ed1c42ea718e620504982ca1d034

Update CI job

view details

push time in 17 hours

issue commentimxrt-rs/imxrt-rs

[WIP] RFC: construct drivers from RAL instances

I was looking to port the clock interface work you've done in async-hal especially as I quite like the way you've done it there.

Thanks for the feedback. I've already separated that module into it's own crate, and I've integrated it back into the async HAL. I'll make the crate available for all of us soon.

mciantyre

comment created time in 4 days

issue commentimxrt-rs/imxrt-rs

RFC: A Split HAL

the concrete types depend on RAL types which vary over the chips.

It sounded like a unified RAL could solve that.

I want to make sure we're on the same page with what a unified RAL, and the common HAL, might look like. I linked to my experiments below.

https://github.com/mciantyre/proto-hal

Could you let me know if this meets your thoughts on how this could work? The experiment seems to show that, with some restructuring to our dependencies, we should be able to create general crates, like imxrt-uart-log, that use the common HAL without required feature selection.

bfrog

comment created time in 4 days

create barnchmciantyre/proto-hal

branch : master

created branch time in 4 days

created repositorymciantyre/proto-hal

Unmaintained experiment for a Rust i.MX RT HAL

created time in 4 days

push eventmciantyre/imxrt-rs

Ian McIntyre

commit sha 3f983c1550d941635db5060378c835653310ce47

Reset DMA channels before returning them to the user

view details

Ian McIntyre

commit sha 5bb5469cc983aec2385b65b6060f007f48acbe8a

dma: fix linear buffer length

view details

Ian McIntyre

commit sha b4a2c96508edb9f08474d4a396373e21a80c54e6

Reintroduce unsafe DMA transfer methods, remove ptr checks Besides the lifetime management, which is described in the set_[source|destination] transfer methods, there are other reasons why creating a Transfer is unsafe. This commit makes the methods unsafe again. Also, remove the pointer alignment check in buffer_circular. If the start pointer points at an offset, it's not aligned to the byte boundary. The safety documentation describes the alignment requirements to use the circular buffer transfers.

view details

push time in 6 days

push eventmciantyre/imxrt-rs

Malloc Voidstar

commit sha 29e1e412db924c624eae50ce5857bbe5784d6c85

Add IDEA dir to gitignore

view details

Malloc Voidstar

commit sha 3ca00a3fda96ae2b807b22af344eaf32bfceb6a7

Implement basic RTC support Supports enabling and setting the clocks.

view details

DavidTheFighter

commit sha 01ea56d4717236c14d67bffcc5d6dbfa17b4b91e

Transfer work to fork

view details

Malloc Voidstar

commit sha 441b8e0ab9672e3abae8e8e7ead856d146a52cfc

Update for review and sub-second times Now exclusively enables and uses the SRTC.

view details

Malloc Voidstar

commit sha aec0ed6731828b2826eef4839658e97f4dc78dfc

Add get_f64

view details

DavidTheFighter

commit sha 5e5d82b12d0c78536adee700b37b6e2f3edd7c76

Potential ADC implementation take 1

view details

DavidTheFighter

commit sha a788bceb8e027d9f9ff640acd50102826aa5e9e9

Added input data for all IMXRT106x pins

view details

DavidTheFighter

commit sha 7d2ee6ba4edb0fdb191047ae47933d746751bfa3

Added adc to peripherals

view details

DavidTheFighter

commit sha 1d21e1c6786db2f7c2b53574d939a91929c593c2

Changed AnalogPin creation

view details

Malloc Voidstar

commit sha a34282bbff4dd52622fb7a902eb09656c3a5c620

Revert "Add get_f64" This reverts commit aec0ed6731828b2826eef4839658e97f4dc78dfc.

view details

Malloc Voidstar

commit sha 7b3d0cee6c239b3ae9da3688f21df05b4e0c28f7

Use microseconds, add get_with_micros

view details

DavidTheFighter

commit sha d08a5141633ffa2da4a22669d795b34a089825ab

Finished up comments & example

view details

DavidTheFighter

commit sha d95826192434c981513951608569e86e7a1f3254

Fixed issues from checks

view details

DavidTheFighter

commit sha 368ff9d7a762ba723cb57523fa064efc7260022b

Hopefully actually fixed build issues

view details

DavidTheFighter

commit sha 2be73ec909e3461b9c92983306c70e14e1c0624c

3rd time's a charm, fix CI issues

view details

Malloc Voidstar

commit sha 621b103c1f1765fd94e2185ef32690d16610b724

Update following review

view details

Ian McIntyre

commit sha d9ce7eaeb81099109afcc112610f139413e4bbcd

imxrt-hal: add CHANGELOG entry for SRTC

view details

Ian McIntyre

commit sha a85b279102bceac3a6285782f4ca75d083e8603a

Merge branch 'AlyoshaVasilieva-srtc'

view details

Tom Burdick

commit sha 14aa29e05049e2cb84c07a3bee2f8fc473f277d2

Adds the imxrt101x iomux mod and uart pin defs

view details

Ian McIntyre

commit sha e716c4c4b4385041eb3718f506467252199551bb

Add DMA support for imxrt1011

view details

push time in 6 days

push eventmciantyre/imxrt-rs

Ian McIntyre

commit sha cd5ef5ad71399ffdda679ddcd68c3a23ad18f1a9

Refactor low-level DMA driver into its own crate The commit adds imxrt-dma, a lower-level i.MX RT driver. It provides an interface to schedule DMA transfers. I separated the lower-level details from the HAL in order to share the driver across projects. I'd specifically like to use it in the imxrt-async-hal crate, which has forked the necessary DMA modules. imxrt-dma includes a shim module that emulates the imxrt-rs register types and macros. The DMA implementation was already using a RAL-like interface in its implementation, so this wasn't too hard to achieve. imxrt-dma has no dependencies. Its up to higher-level code to make sure ownership of DMA peripheral instances are "transferred." The commit refactors imxrt-hal to use the new imxrt-dma interface. The HAL still implement the DMA peripheral adapter, along with the safe DMA buffer interface. I updated some of the internal interfaces to make a clearer distinction between imxrt-dma responsibility, and HAL responsibility. imxrt-dma should work across all i.MX RT processor variants. However, instead of using a feature to specify your chip, you use the "channels-32" feature to signal that your chip has 32 DMA channels. The "channels-32" feature is on by default, since the majority of the chips support 32 DMA channels. Users will need to disable default features to enforce 16 DMA channels. TODO - Update documentation. There are new, unsafe interfaces that need to be described. - Test it on hardware, and make sure nothing broke.

view details

Ian McIntyre

commit sha f5ee78bb299f6e8c70a632e792c9e23898adf16c

Add documentation; remove unsafe Transfer methods It's safe to create a Transfer, but it's not safe to use it.

view details

Ian McIntyre

commit sha a633569659846e97c4909f9a427418ad37de2031

Remove the DMA peripheral error types These operations should be infallible, or the driver should ensure that the operation is infallible.

view details

Ian McIntyre

commit sha d2d8ee8f92a5e91e10c9e444adf5373cb23d621a

dma: add top-level example

view details

Ian McIntyre

commit sha 5c96b05d5e9200f44a0191d3033f1e21d73894d6

dma: remove Transfer::buffer_linear len argument

view details

Ian McIntyre

commit sha 2ae05e3ad8154d9c100174d7e54db9b22449e22c

dma: separate enable / disable calls, add unsafe

view details

Ian McIntyre

commit sha d3e76767df90d346e57ae1973c12600475995256

Revert "dma: remove Transfer::buffer_linear len argument" This reverts commit d1355ff95a3264df28b5ed97cc728b3fbeb84f3f. Let's keep this around, just in case we want to change our guarantees...

view details

Ian McIntyre

commit sha e420d8f4c4bb29d34216f8b842ce77945977cc29

dma: document the default features

view details

Ian McIntyre

commit sha 22db6da8635bdd5f5d91256452c566947764cc40

dma: fix spelling in docs; generate README

view details

Ian McIntyre

commit sha bd70d9b88bf655dc420defcbe7097be1f220a5f4

hal: add enable_[source|destination] calls I accidentally removed these when removing the error type from the peripheral traits.

view details

Ian McIntyre

commit sha 74be846c82739ed56139fae6861be57d39e6d667

Add unsafe peripheral transfer / receive functions

view details

push time in 6 days

push eventmciantyre/imxrt-rs

Tom Burdick

commit sha e3ca177b458a49a2bf204d519383fdae739df375

Creates chip specific imxrt1062-hal crate To start the hal split move the entire imxrt-hal crate to imxrt1062-hal, set all feature flags for dependencies appropriately, and fix the workspace to build on cargo build after checkout. A second imxrt1011-hal can now easily be added, and shared code moved appropriately to a common imxrt-hal-common crate as a dependency of both as time and energy permits.

view details

Tom Burdick

commit sha 43f2e5010da04e34bf307b8ac061479afa3076e7

Update documentation to account for multiple hal(s) Should be updated again when creating the common HAL and a imxrt1011-hal

view details

Ian McIntyre

commit sha 5e2e4d80411362c456f7006030e81f48444734e5

Refactor low-level DMA driver into its own crate The commit adds imxrt-dma, a lower-level i.MX RT driver. It provides an interface to schedule DMA transfers. I separated the lower-level details from the HAL in order to share the driver across projects. I'd specifically like to use it in the imxrt-async-hal crate, which has forked the necessary DMA modules. imxrt-dma includes a shim module that emulates the imxrt-rs register types and macros. The DMA implementation was already using a RAL-like interface in its implementation, so this wasn't too hard to achieve. imxrt-dma has no dependencies. Its up to higher-level code to make sure ownership of DMA peripheral instances are "transferred." The commit refactors imxrt-hal to use the new imxrt-dma interface. The HAL still implement the DMA peripheral adapter, along with the safe DMA buffer interface. I updated some of the internal interfaces to make a clearer distinction between imxrt-dma responsibility, and HAL responsibility. imxrt-dma should work across all i.MX RT processor variants. However, instead of using a feature to specify your chip, you use the "channels-32" feature to signal that your chip has 32 DMA channels. The "channels-32" feature is on by default, since the majority of the chips support 32 DMA channels. Users will need to disable default features to enforce 16 DMA channels. TODO - Update documentation. There are new, unsafe interfaces that need to be described. - Test it on hardware, and make sure nothing broke.

view details

Ian McIntyre

commit sha aae32d329985eabacb486a67498c0264750dc16e

Add documentation; remove unsafe Transfer methods It's safe to create a Transfer, but it's not safe to use it.

view details

Ian McIntyre

commit sha efb7eb11f898dd70832420fdc72ed425e2fc602e

Remove the DMA peripheral error types These operations should be infallible, or the driver should ensure that the operation is infallible.

view details

Ian McIntyre

commit sha 3441db5fc72f9949b8647f8ce8ed25b0c2e70572

dma: add top-level example

view details

Ian McIntyre

commit sha d1355ff95a3264df28b5ed97cc728b3fbeb84f3f

dma: remove Transfer::buffer_linear len argument

view details

Ian McIntyre

commit sha ed51644506d580528cdf763ac749754d9bca99a6

dma: separate enable / disable calls, add unsafe

view details

Ian McIntyre

commit sha c7c316a20efd6caf1f5504dbd7782e9da643ab7a

Revert "dma: remove Transfer::buffer_linear len argument" This reverts commit d1355ff95a3264df28b5ed97cc728b3fbeb84f3f. Let's keep this around, just in case we want to change our guarantees...

view details

Ian McIntyre

commit sha c954dbc1f5c96948ff11ed578be38f0b7897c4c9

dma: document the default features

view details

Ian McIntyre

commit sha 5b9ec629e9494e4e7d1a8683d03d1e2c1a98d4ca

dma: fix spelling in docs; generate README

view details

Ian McIntyre

commit sha 91963cf857df7c9bfdbb8e24deca2db072b2af45

hal: add enable_[source|destination] calls I accidentally removed these when removing the error type from the peripheral traits.

view details

Ian McIntyre

commit sha b8cee81dab92641557d1b47ef49a23af8cc3efda

Add unsafe peripheral transfer / receive functions

view details

push time in 6 days

pull request commentimxrt-rs/imxrt-rs

Remove ambiguous 'x' chip suffix

How granular should we make our feature flags and HALs? This goes back to one of our discussions on #56, and it also relates to #89, which names the HAL 1062.

Let's take the 1061 and 1062 parts as an example. In #56, we note that they share a datasheet and reference manual. The 1062 has display and camera components, which are missing in the 1061.

As proposed, we could put them behind chip-specific HALs, and make our feature flags align. Or, we could create the imxrt1060-hal, with feature flags for the optional components. These would enable corresponding features in the common HAL, or would enable the implementation directly in the imxrt1060-hal:

[package]
name = "imxrt1060-hal"
# ...

[features]
lcd = ["imxrt-common-hal/imxrt1062-lcd"] # Enable the LCD driver
csi = ["imxrt-common-hal/imxrt1062-csi"] # Enable CSI driver
pxp = [] # Enable pixel pipeline (implemented here, not in common HAL)

I'm partial to the approach that maps to the datasheet & reference manual, rather than the product number. It makes it easier for us as maintainers, and I don't think we assume much additional documentation overhead.

The 1060 data sheet also list parts like IMXRT106A, IMXRT106F, and MXRT106L. Instead of our team releasing three additional crates, and adding three additional feature flags, a user could continue consuming the 1060 HAL and enable the peripheral features that they want. This approach also helps the 1062 user who want to compile anything that isn't stable across the chip family.

I realize I'm talking about HAL names, but the approach ties back to our feature-flag naming conventions. Are there strong reasons to take that one step further?

mciantyre

comment created time in 6 days

issue commentimxrt-rs/imxrt-rs

RFC: A Split HAL

I think it would be workable.

Sorry, I might be confused about the goals of the common HAL. When I see a reason for splitting up our crates, like

Some conditional compiling needed in imxrt-hal-common, specified by the chip crate on behalf of the end crate user

I'm interpreting that as "we only need conditional compiles when there's a drastic difference between chips." For UART and DMA HAL drivers -- the peripherals needed by imxrt-uart-log -- I'm not expecting to need feature flags in the common HAL.

and a feature flag would need to be set so the types match those in whatever chip hal your using.

Can you clarify why I need feature flags when designing against the common HAL, particularly when consuming a UART and DMA driver API?

bfrog

comment created time in 7 days

create barnchmciantyre/imxrt-rs

branch : imxrt-dma

created branch time in 7 days

push eventimxrt-rs/imxrt-async-hal

Ian McIntyre

commit sha 8df2b23cfc88cf6e65f9f5e9a0d3b1b7dc62e63b

Use public teensy4-fcb, teensy4-pins in examples

view details

push time in 7 days

push eventimxrt-rs/imxrt-async-hal

Ian McIntyre

commit sha a0a689f338b42f486c770476bc07c2341a730b08

Treat cortex-m-rt as an optional dependency Only enable it when the runtime flag is enabled

view details

Ian McIntyre

commit sha 29ed9fb4b704f0c8f848a90a82d6ae70a1f7ae9c

Rename imxrt106x=>imxrt1060, imxrt101x=>imxrt1010 See discussions in the imxrt-rs repo. It's easier to understand chip support when we remain consistent with NXP product naming conventions.

view details

push time in 7 days

push eventimxrt-rs/imxrt-uart-log

Ian McIntyre

commit sha 4372568feea19b084f6c0686e0ee24ae5a312a92

Update developer dependencies to use teensy4_bsp The previous developer dependencies were not tied to a specific release of the teensy4-rs project, nor were they tied to a specific HAL release. This means that a new clone of the repo would fail to build the examples. This commit updates the developer dependencies. Everything builds.

view details

Ian McIntyre

commit sha 0ab3cb2c9b7e67e2b7bd6adc5b1132a5a8b944e0

Add an LED activity indicator Helpful for sanity checking the examples without connecting your serial interface.

view details

push time in 8 days

issue openedimxrt-rs/imxrt-rs

[WIP] RFC: construct drivers from RAL instances

This more of a brain dump, not a well-formed RFC. I don't think it's ready for feedback. That being said, feel free to leave early thoughts if you see a thread of ideas. I'll revise this, then assign reviewers, when ideas are more coherent. My TODOs are emphasized throughout.

The RFC proposes that we change HAL driver initialization. Today, we have single Peripherals object that users take() or steal(). Instead of this API, we should let users supply HAL drivers with RAL instances, while still enforcing the driver states that we require.

Background

There's a few reasons we have the Peripherals object as the HAL driver entrypoint:

  • We previously used an svd2rust-generated peripheral access crate (PAC). This was the PAC API at the time, which we lifted into our API.
  • The approach lets us conveniently enforce driver states in the type system, without any extra thinking. For instance, we signal that all drivers are in an "unclocked" state, which requires that you "clock" them. We can insert this type state before users have any other ways to get the driver.
  • The approach let us include global system setup directly in the take() or steal() methods, without any extra thinking.
  • I thought I saw other HAL crates do this.
  • (Other reasons we did this that I don't remember...)

Downsides

Suppose a user wants to directly use the RAL API to control UART, but they want to use the rest of our HAL drivers. After calling Peripherals::take(), the user will need to unsafely steal the RAL LPUART2 instance. This is because Peripherals::take indiscriminately takes all of the RAL instances, leaving nothing for the user. Flip the sequence: the user safely takes the RAL's LPUART2 instance, then calls Peripherals::take(). The latter returns None, since the implementation sees that LPUART2 was already taken. The user needs to unsafely steal all of the peripherals. In either sequence, we see unsafe.

The approach requires that we mimic PAC APIs to support other embedded Rust frameworks. In #69, we implemented a steal() method on Peripherals to accommodate RTIC's requirements. Without this change, there would be no safe way for users to combine RTIC with the imxrt-hal. An alternative initialization API would let us use the HAL without duplicating API requirements in both our RAL and HAL.

Proposed Approach

HAL drivers accept RAL instances as inputs. We continue to enforce the driver clocking and other validity states through the type system.

(Insert self-contained, minimal example here. In lieu of that self-contained example, see the WIP imxrt-async-hal, which has prototyped the driver initialization flow I'm envisioning.)

Requirements

  1. Compatible with the imxrt-iomuxc crate. Specifically, we need to catch incorrect pairings of RAL peripheral instances with pads (i.e. you cannot combine a LPUART1 RAL instance with a LPUART2_TX pad). This should be caught at compile time.
  2. Enforce driver clocking, validity states through the type system.
  3. Amenable to a configure / release pattern (#20).

Discussion

This seems to be the favored approach in other Rust HALs. Recent study of STM32 HALs show a pattern of HAL drivers that accept PAC peripheral instances. We observe the same pattern in nrf-hal, which we're using as a model in #56.

The HAL would no longer need to explicitly support RTIC. The RAL is already compatible with RTIC. We teach users that, to use RTIC, you need to use the RAL, then construct HAL drivers from the RAL components.

Prototyping in imxrt-async-hal has shown ways to meet the three requirements, though they could be improved. Requirement 1 needs strongly-typed RAL instances, which we don't have. Strongly-typed RAL instances would signal their module number (the '2' in LPUART2) in the type system. To overcome this, the async HAL uses the instance interface. This incurs a runtime check, but it lets us meet the compile-time requirement, and it localizes an invalid state to a single call site. A new RAL API that signaled strongly-typed instances could help, but that comes with other trade-offs.

Requirement 2, specifically the clocking states, is enforced by combining the async HAL's ccm interface with peripheral initialization APIs. (Shown throughout the async HAL interfaces; see the code until I add more ideas here.)

created time in 8 days

PR opened imxrt-rs/imxrt-rs

Reviewers
Remove ambiguous 'x' chip suffix

In #56, we identified that the 'x' suffix for chip identifies is ambiguous. We've used the 'x' suffixes in feature flags, and in naming conventions for split HALs. However, the approach doesn't correlate to NXP product specifications, and we haven't documented what the 'x' means. For example, it's not clear if "imxrt101x" describes support for both 1011 and 1015. (It doesn't.)

The PR updates the the imxrt-iomuxc crate to use product naming conventions. The goal is to make it clear what support we're providing for a given API, feature flag, or split HAL crate. The migration follows

  • "imxrt106x" => "imxrt1060"
  • "imxrt101x" => "imxrt1010"

This change is reflected in the filesystem, and in all documentation and code updates.

The feature-flag renaming is a breaking change. This commit bumps the imxrt-iomuxc crate to 0.2. The commit updates the HAL to use the new version.

The HAL now re-exports a 0.2 imxrt-iomuxc API. Although the symbol names exported from the HAL have not changed, the compiler will still see the types as incompatible. This means that the HAL has a breaking change. I'm relying on other work in the project to bump that version for me.

+59 -59

0 comment

17 changed files

pr created time in 8 days

create barnchimxrt-rs/imxrt-rs

branch : clear-chip-ids

created branch time in 8 days

Pull request review commentimxrt-rs/imxrt-rs

Removes conditional feature compilation for HAL

 pub mod spi {         LPSPI_PODF_6 = ccm::CBCMR::LPSPI_PODF::RW::LPSPI_PODF_6,         /// 0b0111: divide by 8         LPSPI_PODF_7 = ccm::CBCMR::LPSPI_PODF::RW::LPSPI_PODF_7,-        /// 0b1000: divide by 9-        #[cfg(features = "imxrt1011")]-        LPSPI_PODF_8 = ccm::CBCMR::LPSPI_PODF::RW::LPSPI_PODF_8,-        /// 0b1001: divide by 10-        #[cfg(features = "imxrt1011")]-        LPSPI_PODF_9 = ccm::CBCMR::LPSPI_PODF::RW::LPSPI_PODF_9,-        /// 0b1010: divide by 11-        #[cfg(features = "imxrt1011")]-        LPSPI_PODF_10 = ccm::CBCMR::LPSPI_PODF::RW::LPSPI_PODF_10,-        /// 0b1011: divide by 12-        #[cfg(features = "imxrt1011")]-        LPSPI_PODF_11 = ccm::CBCMR::LPSPI_PODF::RW::LPSPI_PODF_11,-        /// 0b1100: divide by 13-        #[cfg(features = "imxrt1011")]-        LPSPI_PODF_12 = ccm::CBCMR::LPSPI_PODF::RW::LPSPI_PODF_12,-        /// 0b1101: divide by 14-        #[cfg(features = "imxrt1011")]-        LPSPI_PODF_13 = ccm::CBCMR::LPSPI_PODF::RW::LPSPI_PODF_13,-        /// 0b1110: divide by 15-        #[cfg(features = "imxrt1011")]-        LPSPI_PODF_14 = ccm::CBCMR::LPSPI_PODF::RW::LPSPI_PODF_14,-        /// 0b1111: divide by 16-        #[cfg(features = "imxrt1011")]-        LPSPI_PODF_15 = ccm::CBCMR::LPSPI_PODF::RW::LPSPI_PODF_15,

OK with me to remove these. But, if we choose to keep them, it might make it easier to move this enum to a common HAL without having to remember that there are more variants for a 1011.

bfrog

comment created time in 8 days

PullRequestReviewEvent
PullRequestReviewEvent

issue commentimxrt-rs/imxrt-rs

RFC: A Split HAL

[...] simply refer to those examples (with links hopefully) [...]

Links back to examples works for me. We lose the benefit of documentation tests that make sure our examples are relevant. It's on us to make sure these links don't point to stale or unreleased examples; a crate release from 5 years ago will need to keep pointing to 5 year old examples.

I would recommend we select the correct hal with a feature flag for each variant supported.

We've cited reasons why required, narrowly-scoped feature flags aren't the best. This sounds like we're putting our current problem on users who want to do the same thing we're doing: create drivers that work across chips. If we're all trying to build drivers that work across these systems, shouldn't we help the community figure this out, without having them adopt an approach that tried and didn't like?

bfrog

comment created time in 8 days

pull request commentimxrt-rs/imxrt-rs

WIP of a Unified RAL

I'm looking at how the RAL script generates the LPUART instances. Here's what it looks like:

$ cd imxrt-ral
$ find . -iname "*lpuart.rs"
./src/imxrt/imxrt1015/lpuart.rs
./src/imxrt/instances/lpuart.rs
./src/imxrt/imxrt1011/lpuart.rs
./src/imxrt/imxrt1021/lpuart.rs

It looks like it's putting the "most general" instances together in instances. Then, it's separating the 1011, 1015, and 1021 instances out because it's identified them as unique.

I'd be curious to see if the 1021 could be part of that "most general" grouping, or if there's a strong reason to keep it separate. And, I'm curous to see if there are dramatic differences between 1011 and 1015.

From a previous, cursory reference manual study, the 1011 and 1015 only have 4 instances; every other variant has 8. When comparing the 1011 to the 1062, I did not notice a difference in register block layout or fields. The auto-generated code might confirm that; both the 1011 and "most general" grouping reference the lpuart_v1 register block.

This might be due to the buggy SVDs...

bfrog

comment created time in 8 days

pull request commentimxrt-rs/imxrt-rs

WIP of a Unified RAL

Sorry, but this is one, very large commit! I think we only changed an 8 to a 5 in the imxrtral.py script, then re-generated the RAL. Is that all? If there's more, consider separating the commits for easier review.

From my quick evaluation:

  • The filesystem is flatter.
  • Peripherals may have suffixes like v2. It's not entirely obvious that usb_analog_v2.rs corresponds to the 1050 series, but we can find that in the module's comments.
  • Instances may have obvious suffixes, like 1051_1052_1061_1062_1064.
  • I still need to specify one RAL feature.
  • I still cannot specify two or more RAL features.

The instance consolidation looks nifty. The RAL continues to re-export instances under their sane names. As a HAL designer, when I write something like

use ral::usbphy::Instance;

it's not immediately clear that the Instance comes from the usbphy_1011_1015_1021 module instead of the usbphy_1051_1052_1061_1062_1064 module. But, since I know how the RAL works, I can set up conditional compilations that group these chips together, just as they're grouped together by module names. That's how we're expected to create the common HAL, correct?

Is there anything specific you'd like feedback on?

bfrog

comment created time in 8 days

Pull request review commentebelski/rust-copter

Update project to use teensy4-bsp 0.1 release

 description = "Demonstration of interfacing an MPU9250 with the Teensy 4"  [dependencies] cortex-m = "0.6.3"+cortex-m-rt = "0.6.13"

Instead of that hack (above), we can directly use this library to boot the processor.

mciantyre

comment created time in 8 days

PullRequestReviewEvent

Pull request review commentebelski/rust-copter

Update project to use teensy4-bsp 0.1 release

 members = [ exclude = [     "tools/pymotion-sensor", ]--[patch.crates-io.cortex-m-rt]-git = "https://github.com/mciantyre/teensy4-rs"

We no longer need this hack to boot the processor.

mciantyre

comment created time in 8 days

PullRequestReviewEvent

PR opened ebelski/rust-copter

Update project to use teensy4-bsp 0.1 release

I held off for a while on a formal BSP release. The BSP was using some custom libraries that made it incompatible with the rest of the embedded Rust ecosystem. Recent learnings have shown ways to overcome those incompatibilities, so I was able to publish a real release.

The PR updates all tools in this project to use the new, public release of the BSP.

Tested by building the pwm-control demo, and flashing it on my board.

https://crates.io/crates/teensy4-bsp https://docs.rs/teensy4-bsp/0.1.0/teensy4_bsp/

+73 -44

0 comment

9 changed files

pr created time in 8 days

create barnchebelski/rust-copter

branch : teensy4-bsp-0.1

created branch time in 8 days

issue commentimxrt-rs/imxrt-rs

RFC: A Split HAL

One of the previously stated values of a spit HAL was to support documentation, so I'd like to get your thoughts on how that will work.

In #89, we're changing documentation examples from imxrt_hal to imxrt106x_hal. As we consolidate drivers into something like imxrt_hal_common, we'll re-export those drivers from the imxrt106x_hal and other chip-specific HALs. I see documentation working a few different ways:

  1. When we move the driver code into the common HAL, we also move the driver documentation. Those imxrt106x_hal namespaces become something like imxrt_hal_common. Since the chip-specific HAL's re-export the driver as-is, the end-user sees namespaces with imxrt_hal_common in the imxrt106x_hal documentation. This is inconsistent for the end-user, but can be taught by a top-level statement resembling "assume that all documentation implicitly includes use imxrt106x_hal as imxrt_hal_common."
  2. When we move the driver code into the common HAL, we do not move the driver documentation. Instead, we only document the re-exported driver in the chip-specific HAL. This requires us to apply documentation examples across all chip-specific HALs. However, the documentation for the imxrt106x_hal is consistent with its name. We're OK with having little documentation on the common HAL.

Are there other approaches we could take that don't have these trade-offs? It doesn't look like the nrf-hal has an approach for documentation examples, as the crates do not yet have documentation examples.


Supposed I'm a user who wants to design a higher-level crate that works across multiple i.MX RT chips. The imxrt-uart-log crate falls into this category (let's pretend that it's maintained outside of the imxrt-rs project). What will be our policy for supporting users who want to design these libraries?

  1. We'll let users consume the imxrt_hal_common crate, so that their API works easily for all chip-specific HALs. This is similar to where we are today. To support this, we need to keep maintaining the feature-flag documentation. This goes against the nrf-hal approach, which says "Don't use this directly.".
  2. We adopt the same approach as nrf-hal: the imxrt_hal_common is an implementation detail, and we're free to break users to satisfy our chip-specific HALs. As an imxrt-uart-log developer, I need to either mimic the structure of the public HALs, and implement imxrt106x-uart-log, imxrt101x-uart-log, etc. crates; or, I need to adopt feature flags that selectively choose a chip-specific HAL.

Is there another way to support external users who want to create libraries for multiple chips?


Should we change imxrt-ral so there's only one device family, but multiple RegisterBlock types when differening devices exist?

Concretely, this would mean imxrt-ral has a feature called "imxrt106x" which consolidates the two "imxrt1061"1 and"imxrt1062"` features? If so, I'd say no, we don't need to have multiple register blocks. In some previous studies, it looked like the 1061 and 1062 chips were so similar they wouldn't warrant different register blocks. If we need to support multiple register blocks, they should be behind a different RAL feature.

Semi-related: we may want to change our chip naming schema to more closely match the reference manuals and product identifiers. I proposed the "x" suffix back when we started discussing split HAL, and then I used it in the imxrt-iomuxc crate. I'm concerned that was the wrong call, since the "x" suffix doesn't distinguish common support for the 1010 and 1015 families, which seem to be pretty different.

bfrog

comment created time in 8 days

created tagmciantyre/teensy4-rs

tagteensy4-fcb-0.2.0

Rust support for the Teensy 4

created time in 9 days

created tagmciantyre/teensy4-rs

tagteensy4-pins-0.1.0

Rust support for the Teensy 4

created time in 9 days

created tagmciantyre/teensy4-rs

tagteensy4-bsp-0.1.0

Rust support for the Teensy 4

created time in 9 days

pull request commentmciantyre/teensy4-rs

Add features jobs to bors checks

bors merge

mciantyre

comment created time in 9 days

PR opened mciantyre/teensy4-rs

Add features jobs to bors checks
+7 -0

0 comment

1 changed file

pr created time in 9 days

create barnchmciantyre/teensy4-rs

branch : bors-features

created branch time in 9 days

push eventmciantyre/teensy4-rs

Ian McIntyre

commit sha 6745c63207520469e56128b361c07c43fefa8920

Add licenses to pins, fcb crates

view details

Ian McIntyre

commit sha 131e3953abcab82686a288037b19544004145cdc

Move outdated documentation into docs/old Note that the documents are unmaintained.

view details

Ian McIntyre

commit sha de69863fee5a6555eeb8f2cdc3cb8d347a251ccb

Set packaged files, FCB version, in BSP manifest

view details

push time in 9 days

pull request commentmciantyre/teensy4-rs

Use public cortex-m-rt crate for runtime

bors merge

mciantyre

comment created time in 9 days

push eventmciantyre/teensy4-rs-template

Ian McIntyre

commit sha 28535ca245c4f49794d21d89f152a8e66d28d12f

Use cortex_m_rt; update linker script See mciantyre/teensy4-rs#83 for more information.

view details

push time in 9 days

push eventmciantyre/teensy4-rs

Ian McIntyre

commit sha b1a6b5ceb54f5ed4f6b33cf0f39b9844bb076229

Update FBC docs; generate FCB README

view details

Ian McIntyre

commit sha ce7c78174b9bba04451f24cabbcce837ff5fa9e9

Update pins documentation; create pins README

view details

push time in 9 days

PR opened imxrt-rs/imxrt-rs

Reviewers
IOMUXC: Add I2C, SPI traits for 1011 pads

The PR adds I2C and SPI imxrt-iomuxc trait implementations for the 1011 pads.

Part of #87.

+332 -0

0 comment

3 changed files

pr created time in 9 days

create barnchimxrt-rs/imxrt-rs

branch : iomuxc-101x-i2c-spi

created branch time in 9 days

issue commentimxrt-rs/imxrt-rs

IOMUXC: full support for 101x

#85 introduced the imxrt101x IOMUXC feature, with UART and GPIO support.

mciantyre

comment created time in 9 days

issue openedimxrt-rs/imxrt-rs

IOMUXC: full support for 101x

This issue tracks the imxrt-iomuxc traits implementations for the 101x family. See imxrt-rs/imxrt-async-hal#4 for more details. The bolded peripherals are required for fully using today's async HAL.

  • [ ] ADC
  • [x] GPIO
  • [ ] I2C
  • [ ] PWM
  • [ ] SPI
  • [x] UART

created time in 9 days

push eventimxrt-rs/imxrt-rs

DavidTheFighter

commit sha 01ea56d4717236c14d67bffcc5d6dbfa17b4b91e

Transfer work to fork

view details

DavidTheFighter

commit sha 5e5d82b12d0c78536adee700b37b6e2f3edd7c76

Potential ADC implementation take 1

view details

DavidTheFighter

commit sha a788bceb8e027d9f9ff640acd50102826aa5e9e9

Added input data for all IMXRT106x pins

view details

DavidTheFighter

commit sha 7d2ee6ba4edb0fdb191047ae47933d746751bfa3

Added adc to peripherals

view details

DavidTheFighter

commit sha 1d21e1c6786db2f7c2b53574d939a91929c593c2

Changed AnalogPin creation

view details

DavidTheFighter

commit sha d08a5141633ffa2da4a22669d795b34a089825ab

Finished up comments & example

view details

DavidTheFighter

commit sha d95826192434c981513951608569e86e7a1f3254

Fixed issues from checks

view details

DavidTheFighter

commit sha 368ff9d7a762ba723cb57523fa064efc7260022b

Hopefully actually fixed build issues

view details

DavidTheFighter

commit sha 2be73ec909e3461b9c92983306c70e14e1c0624c

3rd time's a charm, fix CI issues

view details

DavidTheFighter

commit sha b927833e9774b1f257ff11b20e46c13ca811198a

Implemented suggestions

view details

DavidTheFighter

commit sha 0afaaf9c0537407a26ed3022fbb144d548f65932

(Hopefully) removed Cargo.toml from changes

view details

Ian McIntyre

commit sha 072bb28ff7c2f52cd4b5d6f55fbf44fce3ac573f

Merge branch 'proto/adc' of https://github.com/DavidTheFighter/imxrt-rs into DavidTheFighter-proto/adc

view details

Ian McIntyre

commit sha 352a47e542684447ecadacc238c82107d86d3711

hal: add CHANGELOG entry for ADC feature

view details

Ian McIntyre

commit sha 4d492dcc738bdaac3fe71da15a6cdae6c63b6bfc

Merge branch 'DavidTheFighter-proto/adc'

view details

push time in 9 days

PR merged imxrt-rs/imxrt-rs

ADC Implementation enhancement imxrt-hal

This PR adds an ADC functionality and implements the embedded-hal 0.2.3 traits (0.2.4 makes a few small changes). It closes #47. This has all the features that I will reasonably use, and has a couple extra features for power users. I decided to go with a simpler interface rather than letting the user change every setting possible, so real power users might want more functionality but we can always add that later. This was tested on a Teensy 4.1 Feel free to nitpick over things :)

+497 -0

4 comments

6 changed files

DavidTheFighter

pr closed time in 9 days

issue closedimxrt-rs/imxrt-rs

ADC implementation

embedded-hal specifies ADC traits here

It seems that this crate does not implement those yet. This would be useful in order to e.g. read analog values from the pins of a Teensy 4 board.


Would love to try and help with this, if someone could point me to the right direction & provide a bit of mentoring 🙂

closed time in 9 days

Walther

pull request commentmciantyre/teensy4-rs

Use public cortex-m-rt crate for runtime

bors try

mciantyre

comment created time in 9 days

push eventmciantyre/teensy4-rs

Ian McIntyre

commit sha ce71c2f2daba83ab54602cbe954861f3ac47b1af

Update documentation This documents the runtime changes required to address #76. Closes #76.

view details

Ian McIntyre

commit sha ae6f4985372299d11142b09d82ae5d0c4666941e

Only link against t4start for runtime feature

view details

push time in 9 days

pull request commentmciantyre/teensy4-rs

Use public cortex-m-rt crate for runtime

bors try

mciantyre

comment created time in 9 days

push eventmciantyre/teensy4-rs

Ian McIntyre

commit sha d2765b1f2630cde79bdefabb0a9ad35171087053

Remove quotes from features CI arguments

view details

push time in 9 days

pull request commentmciantyre/teensy4-rs

Use public cortex-m-rt crate for runtime

bors try

mciantyre

comment created time in 9 days

push eventmciantyre/teensy4-rs

Ian McIntyre

commit sha 59493469b554783ea56ef992a2f19c04a40aea8b

Fix spelling...

view details

push time in 9 days

pull request commentmciantyre/teensy4-rs

Use public cortex-m-rt crate for runtime

bors try

mciantyre

comment created time in 9 days

push eventmciantyre/teensy4-rs

Ian McIntyre

commit sha 5fdf15455f39a1cd833b8014cabae9306d469ffd

Fix formatting of CI job

view details

push time in 9 days

pull request commentmciantyre/teensy4-rs

Use public cortex-m-rt crate for runtime

Draft until we update documentation.

bors try

mciantyre

comment created time in 9 days

PR opened mciantyre/teensy4-rs

Use public cortex-m-rt crate for runtime

The PR updates the project to use the public and widely-used cortex-m-rt runtime crate. We integrate the runtime directly into the BSP. The PR removes the teensy4-rt and the cortex-m-rt-patch crates, since they're no longer required.

The PR closes #12. There is no need to support cortex-m-rt-macros anymore, since they're provided by the dependency. This PR updates all examples.

After this PR lands, we should be able to release the BSP to crates.io.

+407 -638

0 comment

48 changed files

pr created time in 9 days

create barnchmciantyre/teensy4-rs

branch : feature/cortex-m-rt

created branch time in 9 days

pull request commentmciantyre/teensy4-rs

Restructure project

bors merge

mciantyre

comment created time in 9 days

PR opened mciantyre/teensy4-rs

Restructure project

The PR performs some project restructuring:

  • Separate the examples. We move examples for the pure BSP into an examples/bsp directory, and we separate RTIC examples into examples/rtic. The approach lets users more easily understand the dependencies that go into each example.
  • Directly integrates the teensy4-usb-sys crate into the teensy4-bsp crate. I don't intend on supporting the teensy4-usb-sys crate independent of the BSP. We still maintain a logical separation within the BSP crate, just in case anyone wants to fork and support teensy4-usb-sys as its own library.
+249 -162

0 comment

46 changed files

pr created time in 9 days

push eventmciantyre/teensy4-rs

Ian McIntyre

commit sha 3f777bf9d4d307b2a0ff1277d06e2abc7a714b6c

Move examples into bin directories This simplifies the manifests, letting us just add the file along with the required features

view details

Ian McIntyre

commit sha 598db566bb74c2eccf78cfbe7d880467fcfbb3e8

Properly integrate SRTC example Bad rebase...

view details

push time in 9 days

push eventmciantyre/teensy4-rs

Ian McIntyre

commit sha 363ace638eb44318568f627f1e604d68d2f7cded

Update template job Previous steps had hard-coded 'latest' and 'a specific version' in the same line. As of this commit, we'll correctly download a specific version of cargo generate.

view details

bors[bot]

commit sha fcde0dcb576d31d20de3d39b6788039191a21383

Merge #80 80: Update template job r=mciantyre a=mciantyre Previous steps had hard-coded 'latest' and 'a specific version' in the same line. As of this commit, we'll correctly download a specific version of cargo generate. Co-authored-by: Ian McIntyre <ianpmcintyre@gmail.com>

view details

Ian McIntyre

commit sha 9e2bfe1fe2d3bef56e6ebe0180a9f41b33a27086

Remove unnecessary waits and delays Users don't have to add artifical delays to prevent a WFI-induced reset. Remove all waits from the examples. Tested with pit and rtic_blink examples. Skipping testing of the other twi RTIC demos, since they should be equivalent to rtic_blink.

view details

Ian McIntyre

commit sha a8ba07250d910871fa999f8f9802564a17e37df1

Fix USB writer example The split() function wasn't initializing the USB stack. Looks like there was a botched merge, or some regression, somewhere between c23ffcc and 16a55fb. Before this commit, the USB writer demo would not initialize the USB stack, so your host wouldn't detect the Teensy. Now, the example works as expected.

view details

bors[bot]

commit sha bf2f84860429652afb0649894344a694422518b2

Merge #79 79: Disable low-power wait mode during startup r=mciantyre a=mciantyre Set the low-power state to run mode, rather than keeping the default wait mode. Seems to mitigate #76. Tested on the `led.rs` example. The PR also moves the vector table into DTCM. Now, interrupt handles will be found in memory, and no longer require an address lookup in off-board FLASH. Co-authored-by: Ian McIntyre <ianpmcintyre@gmail.com>

view details

Malloc Voidstar

commit sha b949b9ef15d9ad05c40427a20aa359d4cd4c9c6c

Add IDEA to .gitignore

view details

Malloc Voidstar

commit sha 53979b61270af55fb419e85791ffb2d805536632

Add SRTC example Add a basic example for using the SRTC including receiving time over USB.

view details

Malloc Voidstar

commit sha 308ba5f801fd7725e732257ff3306571e08f6b3d

Remove delay Also log the received time to make it obvious if something went wrong. And format the code.

view details

Malloc Voidstar

commit sha a1b317f446d3c129d2ea86f2ba9ec87df56b550f

Update to main repo

view details

bors[bot]

commit sha e05e370bd74ad15c6e5df8e3e82d8ea4628f2144

Merge #81 81: Add SRTC example r=mciantyre a=AlyoshaVasilieva Adds an example for the SRTC using https://github.com/imxrt-rs/imxrt-rs/pull/83, based on your prototype example. I believe this is more-or-less a realistic example of basic usage. I'll change this as necessary if I need to make any changes to the imxrt-hal SRTC support. Co-authored-by: Malloc Voidstar <1284317+AlyoshaVasilieva@users.noreply.github.com>

view details

Ian McIntyre

commit sha df7d764adf7508a441c2a415b51bdb58dfe89805

Reorganize RTIC examples into separate crate

view details

Ian McIntyre

commit sha d1d751da2fd2aa440efcda911a8a9b7bc5c6ace2

Move BSP examples to a BSP binary crate

view details

Ian McIntyre

commit sha 1b8ac53d4abcbacd7bf07314198235b4238b7fd0

Update CI to build workspace-separated examples

view details

Ian McIntyre

commit sha d1ab58df7d6d0d6bd1f4dbda8d2f419232a07e9b

Add documentation pointers for examples

view details

Ian McIntyre

commit sha f42285b158c30709c4e536b7b647f92b4573f3bf

Move teensy4-usb-sys crate into BSP crate

view details

Ian McIntyre

commit sha ebb86c35adf6e7a9070c7ecbd0f0af5a65dd0fe4

Document the teensy4-fcb crate

view details

push time in 9 days

delete branch mciantyre/teensy4-rs

delete branch : development

delete time in 10 days

pull request commentmciantyre/teensy4-rs

Add SRTC example

Thanks again for the RTC implementation!

bors merge

AlyoshaVasilieva

comment created time in 10 days

delete branch mciantyre/teensy4-rs

delete branch : proto/rtc

delete time in 10 days

PullRequestReviewEvent

push eventimxrt-rs/imxrt-async-hal

Ian McIntyre

commit sha e6110edcd04acef94e3e227f816bc7710609c183

Remove unused linker sections

view details

push time in 10 days

issue openedimxrt-rs/imxrt-async-hal

Examples for imxrt101x

The crate compiles with the "imxrt101x feature. But, that doesn't mean it works on the hardware! I don't have the hardware to test the async HAL for those chips, so I'm looking for someone to help add examples that demonstrate the "imxrt101x" feature.

This is depends #4. I'm happy to tackle imxrt-iomuxc extensions, since I can do that by looking at reference manuals.

created time in 10 days

issue openedimxrt-rs/imxrt-async-hal

Fix warnings when compiling single peripherals

There are many compiler warnings when building the async HAL with only one peripheral feature. See an example of the warnings here.

Fix the build so that there are no warnings. Then, ensure warnings trigger CI failures for those single-peripheral feature jobs.

created time in 10 days

push eventimxrt-rs/imxrt-async-hal

Ian McIntyre

commit sha 5be40c212f28bd7e7d5ccede568f17690a3a195e

Address clippy documentation warnings

view details

push time in 10 days

push eventimxrt-rs/imxrt-async-hal

Ian McIntyre

commit sha 806dc531959c4ab8ba4ed142c0424546b0f221ec

Update README, contributing; add crate category

view details

push time in 10 days

issue openedimxrt-rs/imxrt-async-hal

imxrt101x feature depends on imxrt-iomuxc

By using the "imxrt101x" feature flag, we can compile the async HAL crate for i.MX RT 1010 variants. It compiles with all peripherals. However, we can only use the

  • [x] UART

peripheral to perform I/O. This is because the imxrt-iomuxc only supports those pads.

This is a tracking task for complete "imxrt101x support in the async HAL. We'll keep this up to date as new imxrt-iomuxc capabilities are added to that crate. We'll close it once we have complete peripheral support for the chip.

created time in 10 days

issue openedimxrt-rs/imxrt-async-hal

Utilize all GPT output compare registers

Today's GPT implementation uses a single output compare register (OCR) for implementing delays. However, a GPT peripheral has three OCRs. There's a chance that a single hardware GPT could be represented as three GPT channels, which could support three separate tasks. This would bring up the effective number of GPTs from 2 to 6.

Revise the implementation to utilize all three OCRs. Then, change the API to create three GPTs from a single ral::gpt::Instance.

created time in 10 days

issue openedimxrt-rs/imxrt-async-hal

Prototype embedded-hal async traits

The embedded-hal project has at least one set of traits for async peripherals. They're in the proposal / review phase. Select a set of traits, and implement them for the BSP's peripherals.

created time in 10 days

issue openedimxrt-rs/imxrt-async-hal

Forgettable Futures

The DMA-based futures should be memory-safe. Because they take references to the transfer / receive data buffer, the futures cannot outlive the buffer. Furthermore, if the future is dropped, the DMA transaction is cancelled. This means that you can use task-allocated buffers for DMA transfers, and you don't have to manually cancel the transfer when cleaning-up the stack.

One thing we're not considering is core::mem::forget. If you call forget on the future, you lose ownership of the DMA transaction handle, and it doesn't drop. The DMA transaction could still be active and borrowing memory. A forget call could result in a DMA transaction that's interacting with invalidated or re-purposed memory, and it's all possible without unsafe code.

The current recommendation is "don't forget your DMA futures." But, that may not be good enough. Identify if forgettable futures could be a problem in practice. If it is an issue, see if we can prevent it.

"It's an issue"

[Propose real-world code that demonstrates the issue.]

"It's not an issue"

To poll futures, you first need to Pin them. Pinned futures are required by the Future trait. If you forget the future, you violate Pin's drop guarantee.

Concretely, for pinned data you have to maintain the invariant that its memory will not get invalidated or repurposed from the moment it gets pinned until when drop is called.

created time in 10 days

create barnchimxrt-rs/imxrt-async-hal

branch : master

created branch time in 10 days

created repositoryimxrt-rs/imxrt-async-hal

Embedded, async Rust for i.MX RT processors

created time in 10 days

delete branch imxrt-rs/imxrt-rs

delete branch : all-chips-dma

delete time in 10 days

push eventimxrt-rs/imxrt-rs

Ian McIntyre

commit sha 2084a63fbafeec605c9e1cf3e1067caffe0de21c

Fix emphasis in DMA channel documentation

view details

push time in 11 days

push eventimxrt-rs/imxrt-rs

Ian McIntyre

commit sha 69fcdcae466332e5e2f7d9010f4ebec82e7260fe

Use raw pointers for DMA register addresses

view details

Ian McIntyre

commit sha 2e0c9599ee312cfec9ced5ae7c25aa480044410f

Document how many DMA channels are initialized We only initialize the first CHANNEL_COUNT channels. If the code runs on a 1011, that means only the lower half of the array will have valid channels. The rest are none. I couldn't think of an elegant way to signal this at compile time. Users are free to use the CHANNEL_COUNT constant to do something fancies. Or, we could consider signaling a compile-time configuration from a build script.

view details

push time in 11 days

delete branch mciantyre/imxrt-rs

delete branch : all-chips-dma

delete time in 11 days

push eventimxrt-rs/imxrt-rs

Ian McIntyre

commit sha f078b43786b22e56825fec69ac18e958138dadde

Rename channel count constant; fix a missed len DMA_CHANNEL_COUNT could also be written as dma::CHANNEL_COUNT, using the module name to qualify 'dma'. Fix the length of the channel priority register array. It should also be CHANNEL_COUNT long.

view details

push time in 11 days

create barnchmciantyre/imxrt-rs

branch : all-chips-dma

created branch time in 11 days

pull request commentimxrt-rs/imxrt-rs

DMA support for all chip variants

Draft until we figure out

  • [ ] what DMA_CHANNEL_COUNT should be if there are no feature flags
  • [ ] what to do when users do something like this in their "generic" code:
let mut dma_channels = peripherals.dma.clock(&mut peripherals.ccm.handle);

let tx_channel = dma_channels[9].take().unwrap();  // OK; 9 < 16
let mut rx_channel = dma_channels[25].take().unwrap(); // Err, 25 > 16, won't work for 1011 generic code
mciantyre

comment created time in 12 days

PR opened imxrt-rs/imxrt-rs

Reviewers
DMA support for all chip variants

The PR provides DMA support for all chip variants. DMA support is probably lower on #56's TODO list. However, the DMA implementation is more unique than the other peripherals, since the RAL interface was hand-written. Hand-writing the RAL was necessary for providing a simpler API, since the svd2ral script generated a lot of symbols.

I arrived at this implementation by studying the reference manuals. In summary, the 1011 chip only has 16 DMA channels; chips that are 1015 and higher hav 32 DMA channels. When you have more than 16 DMA channels, you have the option for channel grouping. Today's DMA driver doesn't support channel grouping, so this is only a comment in the code.

The conditional compiles are hidden behind a new chip module, private to the DMA driver. We use the common symbols from the chip module throughout the implementation.

This is a backwards-compatible change. We now export a new constant, DMA_CHANNEL_COUNT, which signals the number of DMA channels supported in the implementation. Crate users should favor that constant instead of hard-coded 32s.

+111 -36

0 comment

3 changed files

pr created time in 12 days

create barnchimxrt-rs/imxrt-rs

branch : all-chips-dma

created branch time in 12 days

issue commentimxrt-rs/imxrt-rs

RFC: A Split HAL

Sounds reasonable! With goals for common register blocks and optional feature flags, it sounds like we're moving away from a "split HAL," and more towards a "unified RAL." Is that the thinking?

Not requiring feature-flags would be a boon for library development. Then, when users are ready to compile their binaries for their system, they can enable a chip-specific feature without too much effort.

A single bitflag difference in LPUART, RIDMA, exists for some but not all chips in the ixmrt line, with no real rhyme or reason.

Looks like it's missing from the 1021 SVD. I confirmed that the RIDMAE bit exists in the LPUART BAUD register, offset 20, in each 1010, 1015, 1020, 1050, 1060, and 1064 reference manual.

bfrog

comment created time in 12 days

PR merged imxrt-rs/imxrt-rs

Implement basic support for the SRTC enhancement imxrt-hal

This implements very basic support for the real-time clock: enabling the SRTC and RTC, setting the SRTC, and getting the current time.

The implementation is a bit awkward, but I'm not sure how to improve it; unlike the other peripherals I know of, the SRTC keeps running until it loses power or it is specifically disabled, so having two methods of enabling it (one that sets the time, one that does not) makes sense. I guess a builder pattern (like I2C) could be used, but not sure if it's worth it currently.

Also, setting the time while the RTC is running also makes sense, so that needs to be available while the RTC is running (and requires disabling it).

This implementation also takes ownership of the Secure Non-Volatile Storage instance, but the SNVS does a lot more than just the (S)RTC. It also has:

  • A monotonic counter
  • Security key storage
  • Power glitch detection
  • General-purpose register (in the low-power domain, so may be preserved across reboot and through loss of main power)
  • Probably other things

Taking ownership of the SNVS is therefore not ideal, since it's involved in those other things too. I've implemented reading the current time without the use of the SNVS instance (using an unsafe block) since I know that's safe, but I don't know what else is or isn't safe to do. I would like to improve this but don't know how.

This PR also adds the .idea directory to gitignore, since I use IDEA rather than VSCode.

+243 -0

5 comments

3 changed files

AlyoshaVasilieva

pr closed time in 14 days

push eventimxrt-rs/imxrt-rs

Malloc Voidstar

commit sha 29e1e412db924c624eae50ce5857bbe5784d6c85

Add IDEA dir to gitignore

view details

Malloc Voidstar

commit sha 3ca00a3fda96ae2b807b22af344eaf32bfceb6a7

Implement basic RTC support Supports enabling and setting the clocks.

view details

Malloc Voidstar

commit sha 441b8e0ab9672e3abae8e8e7ead856d146a52cfc

Update for review and sub-second times Now exclusively enables and uses the SRTC.

view details

Malloc Voidstar

commit sha aec0ed6731828b2826eef4839658e97f4dc78dfc

Add get_f64

view details

Malloc Voidstar

commit sha a34282bbff4dd52622fb7a902eb09656c3a5c620

Revert "Add get_f64" This reverts commit aec0ed6731828b2826eef4839658e97f4dc78dfc.

view details

Malloc Voidstar

commit sha 7b3d0cee6c239b3ae9da3688f21df05b4e0c28f7

Use microseconds, add get_with_micros

view details

Malloc Voidstar

commit sha 621b103c1f1765fd94e2185ef32690d16610b724

Update following review

view details

Ian McIntyre

commit sha d9ce7eaeb81099109afcc112610f139413e4bbcd

imxrt-hal: add CHANGELOG entry for SRTC

view details

Ian McIntyre

commit sha a85b279102bceac3a6285782f4ca75d083e8603a

Merge branch 'AlyoshaVasilieva-srtc'

view details

push time in 14 days

pull request commentimxrt-rs/imxrt-rs

Implement basic support for the SRTC

LGTM! Thanks again for the new timer.

AlyoshaVasilieva

comment created time in 14 days

create barnchmciantyre/teensy4-rs

branch : development

created branch time in 14 days

delete branch mciantyre/teensy4-rs

delete branch : development

delete time in 14 days

create barnchmciantyre/teensy4-rs

branch : restructure

created branch time in 14 days

Pull request review commentimxrt-rs/imxrt-rs

ADC Implementation

+//! ADC+//!+//! This ADC driver supports `embedded_hal`'s ADC traits+//!+//! # Example+//! ```no_run+//! use imxrt_hal::{self, adc};+//! use embedded_hal::adc::OneShot;+//!+//! let mut peripherals = imxrt_hal::Peripherals::take().unwrap();+//! let (adc1_builder, _) = peripherals.adc.clock(&mut peripherals.ccm.handle);+//!+//! let mut adc1 = adc1_builder.build(adc::ClockSelect::default(), adc::ClockDivision::default());+//! let mut a1 = adc::AnalogInput::new(peripherals.iomuxc.ad_b1.p02, &adc1);+//!+//! let reading: u16 = adc1.read(&mut a1).unwrap();+//!```++use crate::ccm;+use crate::iomuxc::adc::{prepare_adc_pin, Pin, ADC1, ADC2};+use crate::iomuxc::{adc, consts::Unsigned};+use crate::ral;+use core::marker::PhantomData;+use embedded_hal::adc::{Channel, OneShot};++/// The clock input for an ADC+#[allow(non_camel_case_types)]+pub enum ClockSelect {+    IPG,   // IPG clock+    IPG_2, // IPG clock / 2+    ADACK, // Asynchronous clock+}++/// How much to divide the clock input+pub enum ClockDivision {+    Div1, // Input clock / 1+    Div2, // Input clock / 2+    Div4, // Input clock / 4+    Div8, // Input clock / 8+}++impl ClockSelect {+    pub fn default() -> Self {+        ClockSelect::ADACK+    }+}++impl ClockDivision {+    pub fn default() -> Self {+        ClockDivision::Div2+    }+}++/// Conversion speeds done by clock cycles+pub enum ConversionSpeed {+    Slow,     // 25 ADC clock cycles (24 on imxrt102x)+    Medium,   // 17 ADC clock cycles (16 on imxrt102x)+    Fast,     // 9 ADC clock cycles (8 on imxrt102x)+    VeryFast, // 3 ADC clock cycles (2 on imxrt102x)+}++/// Denotes how much hardware averaging to do+pub enum AveragingCount {+    Avg1,+    Avg4,+    Avg8,+    Avg16,+    Avg32,+}++// Specifies the resolution the ADC+pub enum ResolutionBits {+    Res8,+    Res10,+    Res12,+}++/// A pin representing an analog input for a particular ADC+pub struct AnalogInput<ADCx, P> {+    _module: PhantomData<ADCx>,+    _pin: P,+}++impl<P, ADCx> Channel<ADCx> for AnalogInput<ADCx, P>+where+    P: Pin<ADCx>,+    ADCx: adc::ADC,+{+    type ID = u16;++    fn channel() -> Self::ID {+        <P as Pin<ADCx>>::Input::U16+    }+}++impl<P, ADCx> AnalogInput<ADCx, P>+where+    P: Pin<ADCx>,+    ADCx: adc::ADC,+{+    /// Creates a new analog input pin+    pub fn new(mut pin: P, _adc: &ADC<ADCx>) -> Self {+        prepare_adc_pin(&mut pin);+        Self {+            _module: PhantomData,+            _pin: pin,+        }+    }+}++pub struct ADC<ADCx> {+    _module: PhantomData<ADCx>,+    reg: ral::adc::Instance,+}++impl<ADCx> ADC<ADCx> {+    fn new(reg: ral::adc::Instance) -> Self {+        let inst = Self {+            _module: PhantomData,+            reg,+        };++        inst.set_resolution(ResolutionBits::Res10);+        inst.set_low_power_mode(false);++        // Calibrate w/ slow settings initially+        inst.set_averaging(AveragingCount::Avg32);+        inst.set_conversion_speed(ConversionSpeed::Slow);+        inst.calibrate();++        // Set to default of 4 hardware averages & medium conversion speed+        inst.set_averaging(AveragingCount::Avg4);+        inst.set_conversion_speed(ConversionSpeed::Medium);++        inst+    }++    /// Sets the resolution that analog reads return, in bits+    pub fn set_resolution(&self, bits: ResolutionBits) {

This kind of pertains to the above conversation about interrupt safety: should these set_* methods take a &mut self receiver, rather than a &self? Same for calibrate()? They're mutating something owned by the ADC.

The Oneshot method already takes a &mut self receiver. Once everything it signaling mutability, anyone who wants to modify an ADC across execution contexts will need to wrap it in a mutex, or their favorite interrupt-free construct, to synchronize it across execution contexts.

DavidTheFighter

comment created time in 14 days

PullRequestReviewEvent

Pull request review commentimxrt-rs/imxrt-rs

ADC Implementation

+//! ADC+//!+//! This ADC driver supports `embedded_hal`'s ADC traits+//!+//! # Example+//! ```no_run+//! use imxrt_hal::{self, adc};+//! use embedded_hal::adc::OneShot;+//!+//! let mut peripherals = imxrt_hal::Peripherals::take().unwrap();+//! let (adc1_builder, _) = peripherals.adc.clock(&mut peripherals.ccm.handle);+//!+//! let mut adc1 = adc1_builder.build(adc::ClockSelect::default(), adc::ClockDivision::default());+//! let mut a1 = adc::AnalogInput::new(peripherals.iomuxc.ad_b1.p02, &adc1);+//!+//! let reading: u16 = adc1.read(&mut a1).unwrap();+//!```++use crate::ccm;+use crate::iomuxc::adc::{prepare_adc_pin, Pin, ADC1, ADC2};+use crate::iomuxc::{adc, consts::Unsigned};+use crate::ral;+use core::marker::PhantomData;+use embedded_hal::adc::{Channel, OneShot};++/// The clock input for an ADC+#[allow(non_camel_case_types)]+pub enum ClockSelect {+    IPG,   // IPG clock+    IPG_2, // IPG clock / 2+    ADACK, // Asynchronous clock+}++/// How much to divide the clock input+pub enum ClockDivision {+    Div1, // Input clock / 1+    Div2, // Input clock / 2+    Div4, // Input clock / 4+    Div8, // Input clock / 8+}++impl ClockSelect {+    pub fn default() -> Self {+        ClockSelect::ADACK+    }+}++impl ClockDivision {+    pub fn default() -> Self {+        ClockDivision::Div2+    }+}++/// Conversion speeds done by clock cycles+pub enum ConversionSpeed {+    Slow,     // 25 ADC clock cycles (24 on imxrt102x)+    Medium,   // 17 ADC clock cycles (16 on imxrt102x)+    Fast,     // 9 ADC clock cycles (8 on imxrt102x)+    VeryFast, // 3 ADC clock cycles (2 on imxrt102x)+}++/// Denotes how much hardware averaging to do+pub enum AveragingCount {+    Avg1,+    Avg4,+    Avg8,+    Avg16,+    Avg32,+}++// Specifies the resolution the ADC+pub enum ResolutionBits {+    Res8,+    Res10,+    Res12,+}++/// A pin representing an analog input for a particular ADC+pub struct AnalogInput<ADCx, P> {+    _module: PhantomData<ADCx>,+    _pin: P,+}++impl<P, ADCx> Channel<ADCx> for AnalogInput<ADCx, P>+where+    P: Pin<ADCx>,+    ADCx: adc::ADC,+{+    type ID = u16;++    fn channel() -> Self::ID {+        <P as Pin<ADCx>>::Input::U16+    }+}++impl<P, ADCx> AnalogInput<ADCx, P>+where+    P: Pin<ADCx>,+    ADCx: adc::ADC,+{+    /// Creates a new analog input pin+    pub fn new(mut pin: P, _adc: &ADC<ADCx>) -> Self {+        prepare_adc_pin(&mut pin);+        Self {+            _module: PhantomData,+            _pin: pin,+        }+    }+}

Good thought! There hasn't been a need for an unprepare function yet. We could unprepare to the reset state, but that would require us to specify the reset states in code...

We can release the pad in an unspecified state. If a user wants to re-use the pad for something else, they will call a different prepare function on the pad.

DavidTheFighter

comment created time in 14 days

more