profile
viewpoint
imxrt-rs Rust on the most powerful microcontroller from NXP

imxrt-rs/imxrt-hal 32

Rust for NXP i.MX RT

imxrt-rs/imxrt-rt 4

i.MX RT Runtime Support

imxrt-rs/imxrt-boot-gen 2

Generate data structures for booting iMXRT processors

imxrt-rs/imxrt-uart-log 2

Logging over an i.MX RT serial interface

imxrt-rs/imxrt1060evk-bsp 2

NXP's i.MX RT 1060 Evaluation Kit Board Support Package

imxrt-rs/imxrt-async-hal 1

Embedded, async Rust for i.MX RT processors

imxrt-rs/imxrt-ccm 1

CCM driver for i.MX RT processors

imxrt-rs/imxrt-dma 1

DMA driver for i.MX RT processors

imxrt-rs/imxrt-ral 1

Register Access Layer for i.MX RT Microcontrollers

imxrt-rs/imxrt-iomuxc 0

Pin definitions, configurations, and multiplexing API

push eventimxrt-rs/imxrt-ccm

Ian McIntyre

commit sha baee7bfdd0b5100840317437ad24e0abcabc67a1

Target WIP RAL crate

view details

Ian McIntyre

commit sha dccfcd82983ff52fe00b36d777894ff201e66c12

Manual require deref coercion for Handle methods Not sure why this is required here, but not on the clock methods.

view details

Ian McIntyre

commit sha 77e7e4beed50a4159f3007b1a758057d582c598c

Revert "Manual require deref coercion for Handle methods" This reverts commit 72eedff613eab6eee36cd57e2c4cac8b68bb33c5.

view details

Ian McIntyre

commit sha de0bdabf1c11ef90e48af3ef643ee6a87bafd945

Manually derefence RAL instances for Handle calls I'm not sure why this is necessary. It seems that we can support deref coercion for the clock types, but not with the handle. This is a minor inconvenience for RAL users, but it keeps the CCM API consistent and usable for other purposes.

view details

push time in 32 minutes

create barnchimxrt-rs/imxrt-ccm

branch : ral-typenum-instances

created branch time in 33 minutes

push eventimxrt-rs/imxrt-ral

Ian McIntyre

commit sha 7d3e03c6d27aeb6ddd1baeaaa7dad8292beb0998

Implement DerefMut for Instance This implementation doesn't provide much for the end user. However, it's necessary when writing generic code that accepts mutable types. I'm exploring these kinds of APIs in the imxrt_ccm crate.

view details

Ian McIntyre

commit sha ef85664b559ddc25d1d20f4e5d08d328e5b75199

Add DerefMut implementations for instances See the previous commit for more context

view details

push time in 33 minutes

issue commentimxrt-rs/imxrt-hal

USB Support

Thanks for all the pointers, @bfrog @mciantyre! I'm not sure how much I'll be able help, but I'll definitely give it a shot. If you'd like me to put followup questions in another thread to keep this one more focused on actual development progress, I can open another issue.

bfrog

comment created time in 2 hours

push eventimxrt-rs/svdtools

Ian McIntyre

commit sha 1d9d1c83edf4acd1030fe01531ee32560f9e4504

Demonstrate derivedFrom modification in example

view details

Ian McIntyre

commit sha b15a1216411eaab074bf183cd2de78fd7319012c

Add imxrt CI checks

view details

push time in 17 hours

create barnchimxrt-rs/imxrt-ral

branch : typenum-instances

created branch time in 18 hours

create barnchimxrt-rs/svdtools

branch : modify-derivedFrom

created branch time in 18 hours

issue commentimxrt-rs/imxrt-hal

USB Support

what major differences do you think there might be between hardwares?

I believe the STM32 USB peripherals only support full-speed transfers. The i.MX RT USB peripherals support high-speed transfers. Since our peripheral needs to support faster transfers, there will be differences in the peripheral designs, particularly around transfer scheduling.

I'll recommend this application note to get a sense of how the i.MX RT USB peripheral works. The AN is for a different processor, but the i.MX RT chips use the same names, data structures, and patterns. I found this AN easier to read than the reference manual.

I cannot see how register pointers could ever be used in a threadsafe capacity.

Your intuition is right. It's our job to make sure its Sync. We'll need either a Mutex, or well-considered unsafe code.

bfrog

comment created time in 20 hours

issue commentimxrt-rs/imxrt-hal

USB Support

You can definitely refer to the stm32-usbd as a reference point. The stm32-rs project is mostly built around svd2rust generated register mappings, which for imxrt really didn't make sense to use (it took 10+ minutes to build the 1mloc+ svd2rust generated).

We instead based our register mapping on stm32ral, written by the stm32-rs project lead.

Point is there will be a difference in the way registers are accessed. You can always create your own register mapping as well if it makes sense. It might! You should keep in mind that there is the intent to support more than imxrt1062.

The sync issue above is likely being caused by the const *. You can instead take the Instance type, which your peripheral driver then owns and there shouldn't be any Sync issues.

bfrog

comment created time in a day

issue commentimxrt-rs/imxrt-hal

USB Support

Additionally, if I were to use the stm32-usbd implementation as reference, what major differences do you think there might be between hardwares?

bfrog

comment created time in 2 days

issue commentimxrt-rs/imxrt-hal

USB Support

Hey all, I'm fairly new to Rust and I know this is probably an unreasonable undertaking for me, but I really wanted to try working on keyboard firmware in Rust with a teensy 4 and eventually landed here as a starting point. I may not be the best candidate, but I would love to contribute to rewriting the USB driver in Rust.

I started putting together a crate with the existing code in the imxrt-usb branch, and the first actual issue I ran into is that the proposed Device<M> struct is not threadsafe:

error[E0277]: `*const imxrt_ral::usb::RegisterBlock` cannot be shared between threads safely
  --> src/device.rs:31:9
   |
31 | impl<M> UsbBus for Device<M>
   |         ^^^^^^ `*const imxrt_ral::usb::RegisterBlock` cannot be shared between threads safely
   | 
  ::: /Users/noahbkim/.cargo/registry/src/github.com-1ecc6299db9ec823/usb-device-0.2.7/src/bus.rs:17:19
   |
17 | pub trait UsbBus: Sync + Sized {
   |                   ---- required by this bound in `usb_device::bus::UsbBus`
   |
   = help: within `device::Device<M>`, the trait `core::marker::Sync` is not implemented for `*const imxrt_ral::usb::RegisterBlock`
   = note: required because it appears within the type `core::marker::PhantomData<*const imxrt_ral::usb::RegisterBlock>`
   = note: required because it appears within the type `imxrt_ral::usb::Instance`
   = note: required because it appears within the type `device::Device<M>`

In general, I cannot see how register pointers could ever be used in a threadsafe capacity. Could someone explain what I'm missing here/any suggestions of where to start looking/any references I should read through before continuing to tinker with this stuff?

bfrog

comment created time in 3 days

push eventimxrt-rs/imxrt-async-hal

mciantyre

commit sha 072de79a9800ed92fe4e530251d188801560dc79

deploy: be400de3159e627061c7a131439e7e769201175c

view details

push time in 7 days

push eventimxrt-rs/imxrt-async-hal

Ian McIntyre

commit sha be400de3159e627061c7a131439e7e769201175c

Rename PeriodicTimer to PIT Internal rename

view details

push time in 7 days

push eventimxrt-rs/imxrt-async-hal

mciantyre

commit sha 253752542f93acf1088082bca39e29d274c28cb7

deploy: 23c7bcbcc0c22ce176703a1467603080a533fce8

view details

push time in 7 days

delete branch imxrt-rs/imxrt-async-hal

delete branch : gpt-channels

delete time in 7 days

push eventimxrt-rs/imxrt-async-hal

Ian McIntyre

commit sha 5874bbf35a09ad169011dde3f0eac4372cac94e1

Rename GeneralPurposeTimer to GPT Public API doesn't change; just an internal rename.

view details

Ian McIntyre

commit sha 6a112a8f6c764235d073d73962cab41f97f9166b

Refactor GPT to support multiple channels

view details

Ian McIntyre

commit sha 07ace472e10f50f602f1edf0a14f240be860412b

Expose multi-channel GPTs through API Closes #3

view details

Ian McIntyre

commit sha 23c7bcbcc0c22ce176703a1467603080a533fce8

Update docs Since we're generating the docs in the repo, we can now point users to the published docs, rather than duplicating them in the README. The commit simplifies the README to refer to the published docs.

view details

push time in 7 days

PR merged imxrt-rs/imxrt-async-hal

Add multiple GPT channels

The PR adds multiple GPT timer channels. Closes #3.

+140 -194

0 comment

11 changed files

mciantyre

pr closed time in 7 days

issue closedimxrt-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.

closed time in 7 days

mciantyre

PR opened imxrt-rs/imxrt-async-hal

Add multiple GPT channels

The PR adds multiple GPT timer channels. Closes #3.

+140 -194

0 comment

11 changed files

pr created time in 7 days

push eventimxrt-rs/imxrt-async-hal

Ian McIntyre

commit sha 448be3d296a9834acbb068b84b871d0c270b3be1

Update docs Since we're generating the docs in the repo, we can now point users to the published docs, rather than duplicating them in the README. The commit simplifies the README to refer to the published docs.

view details

push time in 7 days

push eventimxrt-rs/imxrt-async-hal

mciantyre

commit sha 422ca1b06c6784edd2a6f8891e5a1bc89f35b7ff

deploy: 063fff3e1aa847ff658baa27308eb341f998edd3

view details

push time in 7 days

push eventimxrt-rs/imxrt-async-hal

Ian McIntyre

commit sha 063fff3e1aa847ff658baa27308eb341f998edd3

Fix CI triggering Remove staging, trying branches, which are leftovers from the teensy4 repo. Add PRs to master.

view details

Ian McIntyre

commit sha eb2b5927274922511157b0845c6e354ddb1ad521

Rename GeneralPurposeTimer to GPT Public API doesn't change; just an internal rename.

view details

Ian McIntyre

commit sha ce129e84c31da92e10958426971b4dded13693dc

Refactor GPT to support multiple channels

view details

Ian McIntyre

commit sha cc2257c0d5ec2d6da6018d1386156ed864009716

Expose multi-channel GPTs through API Closes #3

view details

push time in 7 days

push eventimxrt-rs/imxrt-async-hal

Ian McIntyre

commit sha 142631cd3fea6fa96e52dd75223337f6ef15d439

Run cargo intraconv to convert documentation links Remove outdated documentation. Manually fix the documentation issues noted when generating the new docs.

view details

Ian McIntyre

commit sha 063fff3e1aa847ff658baa27308eb341f998edd3

Fix CI triggering Remove staging, trying branches, which are leftovers from the teensy4 repo. Add PRs to master.

view details

push time in 7 days

create barnchimxrt-rs/imxrt-async-hal

branch : gpt-channels

created branch time in 7 days

push eventimxrt-rs/imxrt-async-hal

mciantyre

commit sha c9a5487689a396929b20f188ff20058a3a4aca74

deploy: 78c2a8658a56b4a7b895bf077b547c4ac32581ca

view details

push time in 8 days

push eventimxrt-rs/imxrt-async-hal

Ian McIntyre

commit sha 78c2a8658a56b4a7b895bf077b547c4ac32581ca

Pin nightly toolchain for documentation generation

view details

push time in 8 days

push eventimxrt-rs/imxrt-async-hal

Ian McIntyre

commit sha bf4e5df2b8384fa74c9f32dec8b800f316d0ebd9

Refactor PIT, removing software global state Refactor the PIT driver to remove the software global state. We can track the timer state by the register changes.

view details

Ian McIntyre

commit sha 1450bcefc3ad92370943b40e76f3f2fc5160ab20

Refactor GPT, removing software global state See the previous commit for more context.

view details

push time in 8 days

issue commentimxrt-rs/imxrt-hal

Controller Area Network (CAN)

I've not worked with CAN before, and I haven't heard of anyone working on a Rust-based CAN driver for these processors. I'm happy to support an i.MX RT CAN driver's development, then maintain it here.

Here's a quick summary of CAN support across the i.MX RT processor families. Let me know if we see a discrepancy.

i.MX RT CAN support? CANFD support?
1010 NO NO
1015 NO NO
1020 YES NO
1050 YES NO
1060 YES YES
1064 YES YES

We could implement embedded-can, then transition to the embedded-hal equivalent traits if / when it's merged.

reneherrero

comment created time in 8 days

issue openedimxrt-rs/imxrt-hal

Controller Area Network (CAN)

Hi,

Wondering if anyone has ventured into the Controller Area Network (CAN) space?

Thanks,

created time in 8 days

startedimxrt-rs/imxrt-hal

started time in 9 days

more