atsams-rs / atsamx7x-rust Goto Github PK
View Code? Open in Web Editor NEWRust HAL, PACs, and examples for the Microship SAM E70/S70/V70/V71
License: Apache License 2.0
Rust HAL, PACs, and examples for the Microship SAM E70/S70/V70/V71
License: Apache License 2.0
Many of the crates in this megaproject has seen a lot of changes since last publication on crates.io. I just assume this has slipped the mind of the maintainers. Latest version (0.1.0) was published in March. It'd be nice to have the 0.3 versions of the HAL and board crates be published, if they are ready ofc. All the peripheral access APIs have a version of 0.25.0 in their Cargo.toml files but the latest version published is 0.21.0 also back in March.
Looking forward to getting acquainted with this. Keep it up <3
When setting the clock frequency for the twi peripheral the actual Clock Frequency ends up being half of your input value.
This is because the formula does not take into account that the period is twice the time given in 43.8.5, as that is only for the high or low time of the pulse.
Raised as result of discussion in #38.
Consider cargo-hack
to support feature permutations in CI.
On a reset the MCU will boot from 0x0 with a VTOR of 0. A deployed product with OTA will likely have to set GPNVM bit 1 externally, otherwise the system will reset into the SAM-BA boot loader.
We should add documentation on how these bits can be configured via openocd
.
Originally posted by @tmplt in #6 (comment)
We can flash 0x0 if the General-Purpse Non-Volatile Memory (GPNVM) bit 1 is set: this maps the internal flash to 0x0 instead of the ROM. These bits are set via the Enhanced Embedded Flash Controller (EEFC). An API to set/get these bits may be warranted.
Originally posted by @tmplt in #6 (comment)
Reported on CI and on my computer after rustc
upgrade:
error: ambiguous glob re-exports
--> hal/src/serial/mod.rs:23:9
|
23 | pub use uart::*;
| ^^^^^^^ the name `Tx` in the type namespace is first re-exported here
...
26 | pub use usart::*;
| -------- but the name `Tx` in the type namespace is also re-exported here
|
= note: `-D ambiguous-glob-reexports` implied by `-D warnings`
error: ambiguous glob re-exports
--> hal/src/serial/mod.rs:23:9
|
23 | pub use uart::*;
| ^^^^^^^ the name `Rx` in the type namespace is first re-exported here
...
26 | pub use usart::*;
| -------- but the name `Rx` in the type namespace is also re-exported here
error: ambiguous glob re-exports
--> hal/src/serial/mod.rs:23:9
|
23 | pub use uart::*;
| ^^^^^^^ the name `Uart` in the type namespace is first re-exported here
...
26 | pub use usart::*;
| -------- but the name `Uart` in the type namespace is also re-exported here
error: ambiguous glob re-exports
--> hal/src/serial/mod.rs:23:9
|
23 | pub use uart::*;
| ^^^^^^^ the name `UartError` in the type namespace is first re-exported here
...
26 | pub use usart::*;
| -------- but the name `UartError` in the type namespace is also re-exported here
error: ambiguous glob re-exports
--> hal/src/serial/mod.rs:23:9
|
23 | pub use uart::*;
| ^^^^^^^ the name `Event` in the type namespace is first re-exported here
...
34 | pub use spi::*;
| ------ but the name `Event` in the type namespace is also re-exported here
error: ambiguous glob re-exports
--> hal/src/serial/mod.rs:26:9
|
26 | pub use usart::*;
| ^^^^^^^^ the name `Client` in the type namespace is first re-exported here
...
34 | pub use spi::*;
| ------ but the name `Client` in the type namespace is also re-exported here
error: ambiguous glob re-exports
--> hal/src/serial/mod.rs:26:9
|
26 | pub use usart::*;
| ^^^^^^^^ the name `Spi` in the type namespace is first re-exported here
...
34 | pub use spi::*;
| ------ but the name `Spi` in the type namespace is also re-exported here
error: ambiguous glob re-exports
--> hal/src/serial/mod.rs:26:9
|
26 | pub use usart::*;
| ^^^^^^^^ the name `SpiError` in the type namespace is first re-exported here
...
34 | pub use spi::*;
| ------ but the name `SpiError` in the type namespace is also re-exported here
error: could not compile `atsamx7x-hal` (lib) due to 8 previous errors
Error: Process completed with exit code 101.
Dear All,
Small question on the PWM you (seem to have) implemented on SAM V71/E70:
https://github.com/atsams-rs/atsamx7x-rust/commits/development/hal/src/pwm.rs
Is it correct understanding we can't drive individually both H/L signals of a PWM channel on this device ?
Now I see that in this example, at least, you can have a single-sided (LOW only) pwm :
https://github.com/atsams-rs/atsamx7x-rust/blob/development/boards/atsamv71_xult/examples/pwm_tc_freq_meas.rs
For the context, on the Microchip MCLV-2 (with SAM E70 PIM module), in order to control a BLDC motor, I am driving a 6 MOSFET H-bridge where 6 PWM signals are used. The MPLAB example (C code) work obvisouly, so, somehow, there is a trick, but I am not sure if the limitation here is the Rust HAL/PAC or....something else ?
Hope you can find couple of minute just to give me hints here ! :)
Of course this can be discussed else where (element.io ?)
Thank you,
Cheers,
Ben
Tracks: miker1423/atsamv71q21#2
The repository linked above contributes to atsamv71q21
crate and the owner of that repository seem to be the owner of the crate. I kindly asked to transfer the ownership, so we could further maintain all PAC crates together.
As the title says.
The compiler version seems to be set in pac/templates/Cargo.toml.template
effectively causing the entire project to be stuck with a compiler version that is just over a year old at this point.
Copied from the internal issue tracker. By @martinmortsell:
The current implementation of the USART peripheral only supports at subset of the available interrupt sources.
pub enum Event {
RxReady,
TxReady,
Overrun,
TxEmpty,
}
The HAL should support more (all?) Event sources.
In particular, I was going to trigger an interrupt on NSSE in SPI mode.
Dear MichaΕ and atsams-rs Team,
Many thanks for crediting me in the latest newsletter, despite my humble contribution ! π
As I am about to dig a bit more this SAM platform for both the SAM V71 & E70 (respectively Xult & MCLV2 boards) but also the SAM RH707 (on its evaluation kit board), I would like to understand from you guys if there is any room/need/willingness for converging efforts:
1.) I'll have to derive the SAM RH707 PAC from its .svd
, and then hopefully its HAL: it is understood that specific PACs should now be hosted outside of this very atsams-rs repo
: is this OK I simply hold it on my personal GitHub then ?
(And anything already done for SAM RH707 ? Is the HAL easily inspired from existing ones, once I have it PAC generated ?)
2.) I believe this whole atsamx7x-rust
is based on the RTIC v1.x (or did I goof from branches? ) and I am mostly experimenting on RTIC v2.0.1 nowadays: is this valuable/appreciated if I push somehow/somewhere here my ported examples on RTIC v2.x ?
3.) Latest RTIC version seems to require a dedicated rtic-monotonics
implementation for this whole SAM 7xx family MCU, if we want to have a timer-based one (today only the 'Systick' one is working fine (maybe it is enough for most of us...?): is this also already ongoing effort somewhere by someone ?
Sorry if this is the wrong place to ask these points: please rick-roll me to the appropriate Matrix channel (is the RTIC channel on Element the right place to discuss this as most of you guys pop-up over there ?)
Thank you,
Have a good one π !
Cheers,
Ben
Hey, I've been working on ATSAME70 support specifically in a repo as part of some contracting work (OVL => OneVariable UG Labs).
Since I've been focused on just this one chip, and a relatively limited set of features, it's probably not ready to merge 1:1, but just in case someone is interested, the repo is here, and I've published the crate under the name ovl-atsamx7x-hal
for now, until this work gets upstreamed.
So far, I have the following components implemented:
smoltcp
implementation capable of maintaining a TCP connection. Only supports one set of pins ATMrtic-monotonic::Monotonic
and groundhog::RollingTimer
trait implementationsFeel free to take any of this work if you want/need it before I get a chance to upstream! I've kept the 0BSD license, so you can do what you'd like.
Edit (2022-04-22): Added RTT impl
The PMC is a fundamental component of this MCU family as it controls all system and user peripheral clocks. A solid HAL will require a PMC API which should bookkeep the clock configuration state in order to configure other peripherals.
The clock distribution is not too crazy (Β§31.3 from the family data sheet):
The objective for quite a long time is to remove PAC maintenance burden from this repo toward atsamx7x-pac that would in future fully automatically release following releases of svd2rust
.
So far, the code on that repo regenerates PACs that when used do svd2rust
heavy lifting on the user side, so we are able to keep very lightweight repository with copy of SVD files for reference.
Copied from internal issue tracker:
The current usb-device implementation is a reverse-engineering feat that was compared to the ATSAMx5x family implementation, along with an RTT (and Wireshark) trace of a CDC-serial example (the branch of which I have forgotten at the moment where I put it), and some ideas taken from the tinyusb implementation of the x7x.
At the time, the latter was not traceable due to tinyusb/#1520, but with it closed, we can now gather additional data and improve our own implementation. tinyusb also contains some abstracted class implementations in case available usb-device implementations are found to be lacking.
So, what we should do now is RTT/Wireshark trace the current implementation in this HAL and compare it with that of the tinyusb example. In this trace, we should send some known payload to the device which is simply echoed back (
usb_serial_echo
example). These should be attached in this issue and relevant MRs should be created, closing this issue when traces match.
Derived from #11 to address the issue of chips with hardware revision A that are probably no longer sold.
embedded-hal
has reached 1.0, There are some changes in traits since 0.2 and we should ideally update atsamx7x-hal
accordingly.
Caused by #25
The check for missing feature in hal/build.rs
is an impediment to operations of the rust-analyzer
. I don't recall observing this problem when the check was in the code.
[ERROR rust_analyzer::lsp_utils] rust-analyzer failed to load workspace: Failed to read Cargo metadata from Cargo.toml file /home/manveru/Projects/atsamx7x-rust/Cargo.toml, Some(Version { major: 1, minor: 63, patch: 0 }): Failed to run `"cargo" "metadata" "--format-version" "1" "--manifest-path" "/home/manveru/Projects/atsamx7x-rust/Cargo.toml" "--filter-platform" "thumbv7em-none-eabihf"`: `cargo metadata` exited with an error: error: failed to load manifest for workspace member `/home/manveru/Projects/atsamx7x-rust/pac/template`
Caused by:
failed to read `/home/manveru/Projects/atsamx7x-rust/pac/template/Cargo.toml`
Caused by:
No such file or directory (os error 2)
[ERROR rust_analyzer::lsp_utils] failed to run build scripts
error: failed to run custom build command for `atsamx7x-hal v0.3.0 (/home/manveru/Projects/atsamx7x-rust/hal)`
Caused by:
process didn't exit successfully: `/home/manveru/Projects/atsamx7x-rust/target/debug/build/atsamx7x-hal-c2579600962003a0/build-script-build` (exit status: 1)
--- stderr
Error: "The HAL is built for a specific target device selected using a feature, but no such a feature was selected."
Compiling atsamv71q19b v0.25.0 (/home/manveru/Projects/atsamx7x-rust/pac/atsamv71q19b)
warning: lint `const_err` has been removed: converted into hard error, see issue #71800 <https://github.com/rust-lang/rust/issues/71800> for more information
--> pac/atsams70n19b/src/lib.rs:3:9
|
3 | #![deny(const_err)]
| ^^^^^^^^^
|
= note: `#[warn(renamed_and_removed_lints)]` on by default
So, it's materialization of rust-lang/rust#71800.
We need CI to actually test with MRV and latest.
Mmmh quite an interesting choice to run ADC test/example code on the AFE0_AD6 channel...as this pin is not (easily) exposed on the SAM V71 Xultra (blue) PCB dev. kit: what am I missing here ? π€
Well, I just tested it on the Xult/EXT-1 PIN#4 (PA19/AFEC0_AD8), working fine: shall I commit the change ?
Dear SAM Team,
I am afraid the UART examples are not working out of the box on the SAM V71 Xultra (blue) Board anymore (? I can't confirm it ever did, first time I try it).
Maybe I am doing something wrong, or oversight of a minimum (undocumented) wiring here ?
Sounds like a Clock issue as we can easily track this error msg down to uart.rs:358
(might want to try and play with both MCK
and PCK
values).
I have the (exact) same situation for both the examples/uart_loopback_test.rs
and the examples/uart_interrupts
, while both examples/usart_loopback.rs
(using a small wiring PB00-PB01 on J505) and examples/usb_serial_echo.rs
(using second 9target) USB port) are working just fine.
Any hint/correction/suggestion is welcome here ! :)
Cheers,
Ben
The CI is broken since the last push.
The CI for #38 fails in a few places (where it decides to run).
First cause of failure is that the CI think every subfolder of ./pacs/
is a pac, it clears the two first characters at
normally, and builds with the selected pac as a feature.
Now there is a templates
folder resulting in an attempt to run cargo build --features unproven,mplates
.
Second Cause of failure mostly speaks for itself:
`cargo metadata` exited with an error: error: current package believes it's in a workspace when it's not:
current: /home/runner/work/atsamx7x-rust/atsamx7x-rust/boards/atsame70_xpro/Cargo.toml
workspace: /home/runner/work/atsamx7x-rust/atsamx7x-rust/Cargo.toml
this may be fixable by adding `boards/atsame70_xpro` to the `workspace.members` array of the manifest located at: /home/runner/work/atsamx7x-rust/atsamx7x-rust/Cargo.toml
Alternatively, to keep it out of the workspace, add the package to the `workspace.exclude` array, or add an empty `[workspace]` table to the package's manifest.
cargo-fmt
and results from the changes made to Cargo.toml
in the root folder.
I'm using the Usart peripheral in SPI Mode and it seems like the SCK is running at exactly 8 times the frequency I set it to.
E.g.
let spi_host_handle = handles.spi_host.configure(
&usart_spi,
&hclk,
SpiConfig {
bitrate: (2_000_000).bps(),
mode: MODE_1,
}, β
).unwrap();
yields a bitrate of 8MHz. I haven't explored this behaviour fully, but it seems to me that the cause is:
const MIN_OVERSAMPLE: u32 = 8;
let oversample_factor = MIN_OVERSAMPLE * if oversample { 2 } else { 1 };
in /usart/mod.rs
Compare 46.6.1.1 which is the current behaviour to 46.6.1.3 which is the desired behaviour in SPI Mode.
Label the codebase and publish crates.
Digging in changes to svd2rust
and how other PACs did things I figured we need critical-section
feature in HAL that would enable critical-section
dependency in PACs. I'm adding this to PACs at the moment, the next step is to fix things here.
To do this nicely we need breaking change is how rt
feature is handled, to simplify things and avoid viscous cycle of bizarre feature names.
Getting an error when trying to build the atsame70_xpro
example. The other atsamv71_xult
one builds fine.
error: linking with `rust-lld` failed: exit status: 1
|
= note: "rust-lld" "-flavor" "gnu" "/tmp/rustcvue7Jj/symbols.o" "/home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/examples/blinky_delay-873d777b61c44224.atsamx7x_hal-d5a980c4e9a39481.101fkh0e4q7472nd.rcgu.o.rcgu.o" "--as-needed" "-L" "/home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/deps" "-L" "/home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/debug/deps" "-L" "/home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/build/atsame70q21b-99c3868bec83c264/out" "-L" "/home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/build/cortex-m-bb856671e465605e/out" "-L" "/home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/build/cortex-m-rt-6a7ae1b79b44e4b7/out" "-L" "/home/cquick/.rustup/toolchains/1.63.0-x86_64-unknown-linux-gnu/lib/rustlib/thumbv7em-none-eabihf/lib" "-Bstatic" "/tmp/rustcvue7Jj/libcortex_m_rt-a8a12616f111b1f5.rlib" "--start-group" "/tmp/rustcvue7Jj/libcortex_m-aaa8d6483869b2d6.rlib" "--end-group" "/home/cquick/.rustup/toolchains/1.63.0-x86_64-unknown-linux-gnu/lib/rustlib/thumbv7em-none-eabihf/lib/libcompiler_builtins-814a2ee6da8588fb.rlib" "-Bdynamic" "--eh-frame-hdr" "-znoexecstack" "-L" "/home/cquick/.rustup/toolchains/1.63.0-x86_64-unknown-linux-gnu/lib/rustlib/thumbv7em-none-eabihf/lib" "-o" "/home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/examples/blinky_delay-873d777b61c44224" "--gc-sections" "-Tlink.x"
= note: rust-lld: error: undefined symbol: _SEGGER_RTT
>>> referenced by lib.rs:175 (/home/cquick/.cargo/registry/src/github.com-1ecc6299db9ec823/rtt-target-0.3.1/src/lib.rs:175)
>>> /home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/examples/blinky_delay-873d777b61c44224.atsamx7x_hal-d5a980c4e9a39481.101fkh0e4q7472nd.rcgu.o.rcgu.o:(rtt_target::UpChannel::conjure::hb1d03a52c6959c14)
>>> referenced by lib.rs:175 (/home/cquick/.cargo/registry/src/github.com-1ecc6299db9ec823/rtt-target-0.3.1/src/lib.rs:175)
>>> /home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/examples/blinky_delay-873d777b61c44224.atsamx7x_hal-d5a980c4e9a39481.101fkh0e4q7472nd.rcgu.o.rcgu.o:(rtt_target::UpChannel::conjure::hb1d03a52c6959c14)
>>> referenced by lib.rs:181 (/home/cquick/.cargo/registry/src/github.com-1ecc6299db9ec823/rtt-target-0.3.1/src/lib.rs:181)
>>> /home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/examples/blinky_delay-873d777b61c44224.atsamx7x_hal-d5a980c4e9a39481.101fkh0e4q7472nd.rcgu.o.rcgu.o:(rtt_target::UpChannel::conjure::hb1d03a52c6959c14)
>>> referenced 5 more times
error: could not compile `atsame70_xpro` due to previous error
warning: build failed, waiting for other jobs to finish...
error: linking with `rust-lld` failed: exit status: 1
|
= note: "rust-lld" "-flavor" "gnu" "/tmp/rustcjHhWm2/symbols.o" "/home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/examples/blinky_irq-59e0ab1a23c855ac.atsamx7x_hal-d5a980c4e9a39481.101fkh0e4q7472nd.rcgu.o.rcgu.o" "--as-needed" "-L" "/home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/deps" "-L" "/home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/debug/deps" "-L" "/home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/build/atsame70q21b-99c3868bec83c264/out" "-L" "/home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/build/cortex-m-bb856671e465605e/out" "-L" "/home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/build/cortex-m-rt-6a7ae1b79b44e4b7/out" "-L" "/home/cquick/.rustup/toolchains/1.63.0-x86_64-unknown-linux-gnu/lib/rustlib/thumbv7em-none-eabihf/lib" "-Bstatic" "/tmp/rustcjHhWm2/libcortex_m_rt-a8a12616f111b1f5.rlib" "--start-group" "/tmp/rustcjHhWm2/libcortex_m-aaa8d6483869b2d6.rlib" "--end-group" "/home/cquick/.rustup/toolchains/1.63.0-x86_64-unknown-linux-gnu/lib/rustlib/thumbv7em-none-eabihf/lib/libcompiler_builtins-814a2ee6da8588fb.rlib" "-Bdynamic" "--eh-frame-hdr" "-znoexecstack" "-L" "/home/cquick/.rustup/toolchains/1.63.0-x86_64-unknown-linux-gnu/lib/rustlib/thumbv7em-none-eabihf/lib" "-o" "/home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/examples/blinky_irq-59e0ab1a23c855ac" "--gc-sections" "-Tlink.x"
= note: rust-lld: error: undefined symbol: _SEGGER_RTT
>>> referenced by lib.rs:175 (/home/cquick/.cargo/registry/src/github.com-1ecc6299db9ec823/rtt-target-0.3.1/src/lib.rs:175)
>>> /home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/examples/blinky_irq-59e0ab1a23c855ac.atsamx7x_hal-d5a980c4e9a39481.101fkh0e4q7472nd.rcgu.o.rcgu.o:(rtt_target::UpChannel::conjure::hb1d03a52c6959c14)
>>> referenced by lib.rs:175 (/home/cquick/.cargo/registry/src/github.com-1ecc6299db9ec823/rtt-target-0.3.1/src/lib.rs:175)
>>> /home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/examples/blinky_irq-59e0ab1a23c855ac.atsamx7x_hal-d5a980c4e9a39481.101fkh0e4q7472nd.rcgu.o.rcgu.o:(rtt_target::UpChannel::conjure::hb1d03a52c6959c14)
>>> referenced by lib.rs:181 (/home/cquick/.cargo/registry/src/github.com-1ecc6299db9ec823/rtt-target-0.3.1/src/lib.rs:181)
>>> /home/cquick/atsamx7x-rust/boards/atsame70_xpro/target/thumbv7em-none-eabihf/debug/examples/blinky_irq-59e0ab1a23c855ac.atsamx7x_hal-d5a980c4e9a39481.101fkh0e4q7472nd.rcgu.o.rcgu.o:(rtt_target::UpChannel::conjure::hb1d03a52c6959c14)
>>> referenced 5 more times
error: could not compile `atsame70_xpro` due to previous error
Default host: x86_64-unknown-linux-gnu
rustup home: /home/cquick/.rustup
installed toolchains
--------------------
stable-x86_64-unknown-linux-gnu (default)
1.63.0-x86_64-unknown-linux-gnu
1.69.0-x86_64-unknown-linux-gnu
installed targets for active toolchain
--------------------------------------
thumbv7em-none-eabihf
x86_64-unknown-linux-gnu
active toolchain
----------------
1.63.0-x86_64-unknown-linux-gnu (overridden by '/home/cquick/atsamx7x-rust/rust-toolchain.toml')
rustc 1.63.0 (4b91a6ea7 2022-08-08)
This issue originates from cmsis-svd/cmsis-svd#153.
After a chat with Microchip it was pointed out that http://packs.download.atmel.com/ is outdated. The up-to-date pack repository is https://packs.download.microchip.com/, where much more recent SVD files for the SAM{E,V,S}7X chips can be found: the latest version for the SAME70 is 4.8.125 (from 2022), versus 2.4.166 (from 2019) mirrored in this repo.
An SVD issue regarding USART-SPI clock sources has also been filed recently; a bug-fix release is expected soon.
Currently there are no docs on docs.rs for the crate: https://docs.rs/crate/atsamx7x-hal/0.4.1
It seems like the build failed due to missing some feature flags
Copied from internal issue tracker:
USART setup is not done properly if the first mode to be entered is the "normal" mode.
When first entering the USART mode, the requested mode is compared against the reset mode, which is the normal USART mode. Therefore, in enter_mode, the check
if self.mode() == H::MODE {
// Already in the requested mode
return;
}
returns early and leaves my USART uninitialized unless I've switched to some other mode before.
My suggestion would simply be to remove this check, unless there's some really good reason why we wouldn't want to let the user soft-reset the peripheral by switching to the same mode.
After comparing PACs it was concluded that rev. B of all SVDs (from which crates with the b
-suffix are generated) include a more exhaustive memory-mapped API in comparison to rev. A. Most notable are perhaps the usage of USART::us_{mr,csr,cr}_{usart,spi}_mode
in rev. B and USART::us_{mr,csr,cr}
in rev. A. Of note in A is that some peripherals function register fields have different meaning depending on a master switch; i.e., when using USART in SPI mode auxilliary fields have different effects.
The idea of always using B SVDs/PACs sprung up but was altimately dropped after a brief conversation with Microchip: A/B have hardware changes for the Ethernet and CAN peripherals.
It is logical to support both revisions due to chip shortages.
So in summary, and with combination with Β§2 (below; see also Β§1 on page 14), we should add internal feature flags for permutations of the following predicates:
Further, in order to speed up development, I propose that PRs must not implement an API for both rev. A and B.
See CHANGELOG.md
, c.f. v0.3.0 entry.
The system IO pins, e.g. PB04 need to be handled by the MATRIX peripheral as well as the PIO peripheral.
This was feature gated behind the configurable-system-pins
feature, as using these pins for other things could potentially brick your device.
However, attempting to configure said pins without the feature fails silently, where it should fail to compile or at the very least panic during runtime.
Copied from the internal issue tracker:
The u32 extension of the Monotonic implementation in
tc/generate.rs
is subject to clock drift when the internal 16-bit counter overflows. We can probably compensate the RC register to nullify the drift.
Running the below RTIC application causes the MCU to jump into 0x0080000e8, the internal ROM which contains the SAM Boot Assistant (SAM-BA), instead of the defined interrupt handler app::uart0
.
#![no_std]
#![no_main]
use panic_semihosting as _;
#[rtic::app(device = atsamx7x_hal::target_device)]
mod app {
use atsamx7x_hal::target_device::Interrupt;
#[shared]
struct Shared {}
#[local]
struct Local {}
#[init]
fn init(_ctx: init::Context) -> (Shared, Local, init::Monotonics) {
cortex_m::peripheral::NVIC::pend(Interrupt::USART0);
(Shared {}, Local {}, init::Monotonics())
}
#[idle]
fn idle(_: idle::Context) -> ! {
loop {
cortex_m::asm::nop();
}
}
#[task(binds = USART0)]
fn usart0(_: usart0::Context) {
cortex_m::asm::bkpt();
}
}
It appears that we need to poke at the vector table. I have yet to verify where the table points to, but I theorize that it points to ROM.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.