branan / cntrlr Goto Github PK

For clock rates above 120MHz the MK66FX1M0 has a special "high speed" mode. This mode has a bunch of additional restrictions compared to normal run mode, so supporting it will end up requiring modifications to several bits of logic.

From the datasheet:

• The maximum allowable change in frequency of the system, bus, flash or core clocks is restricted to x2.
• Before exiting HSRUN mode, clock frequencies should be reduced back down to those acceptable in RUN mode.
• Stop mode entry is not supported from HSRUN.
• Modifications to clock gating control bits are prohibited.
• Flash programming/erasing is not allowed.

Need to add basic CI to enable PR review. It should do more or less this:

rustup install nightly
cargo +nightly install --path cntrlr-build
for BOARD in $(cago +nightly cntrlr build --board=help); do
    cargo +nightly cntrlr build --examples --release --board=$BOARD
done

On many boards (and definitely on the Teensies), some peripherals have multiple pins they can be routed to.

Roughly, I think this looks like the following:

• In each board file, instead of using type FooPin = , instead create an enum FooPin..., with variants for each supported pin.
• Unsafe impl the appropriate peripheral pin marker trait for that enum.
• In peripheral init code, choose the pin based on which options are present.

The current set of examples is pretty minimal. More complex ones that show some real-world usage would be nice to have.

Right now the GPIO/digital pin API is taken pretty much straight from Arduino. It suffices, and it optimizes as well as can be expected. The big issue is that every call needs to lock and then release the pin. this prevents the pin API from optimizing down to direct memory writes.

One option would be to have pin_XX() functions, just like there is for Serial ports (or perhaps pin<XX>()). These could return a struct which owns the pin for its entire lifetime, thus avoiding the need to re-lock every use.

Maybe there's space for both types of API? Or something else?

Right now, it's possible to get instances of periphreal access structs for a different MCU than an application was built for. This is a soundness hole, since the memory region the struct points to may be the same as some other memory that Rust is using.

Places where unsafe is used should have documentation explaining why, and what preconditions they meet/require

Add a way to await for pin state changes (rising/falling edges)

The current hard-coded interrupt tables have two big deficiencies:

1. The ISRs are always referenced, which means they and any data structures they reference (such as WakerSets) are always included in the binary. It would be nice to not include ISRs we're not using
2. There's no way for a user to override an ISR.

Both of these should be solvable by storing the interrupt table in RAM and having a simple API to specify ISR functions.

Since the allocator and runtime modules are both private, there is no access to a function which can set the initial brk value from a user reset vector.