Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added all timers for all variants as described by CubeMX #133

Merged
merged 2 commits into from
Nov 20, 2019
Merged

Added all timers for all variants as described by CubeMX #133

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
6901c54
Added all timers for all variants as described by CubeMX
cs2dsb Nov 10, 2019
ba2e15d
Fixed indentation
cs2dsb Nov 10, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ and this project adheres to [Semantic Versioning](http://semver.org/).
- Added `select_frequency` method to RTC
- Unidirectional DMA support for SPI (TX only)
- Added USB driver for `stm32f102` and `stm32f103` devices

- Added all timers for all variants as described by CubeMX. Commented out {TIM9, TIM10} for XL and {TIM12, TIM13, TIM14} for XL and F100-HIGH due to missing fields for those devices in stm32-rs.
- ADC measurement now can be run by timer

### Breaking changes
Expand All @@ -27,6 +27,7 @@ and this project adheres to [Semantic Versioning](http://semver.org/).
- Starting the timer does not generate interrupt requests anymore
- Make MAPR::mapr() private
- i2c mode now takes Hertz instead of a generic u32
- Timers that were previously incorrectly available without medium/high/xl density features may now be missing

### Fixed

Expand Down
11 changes: 10 additions & 1 deletion README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,10 +11,19 @@

This crate supports multiple microcontrollers in the
stm32f1 family. Which specific microcontroller you want to build for has to be
specified with a feature, for example `stm32f103`.
specified with a feature, for example `stm32f103`.

If no microcontroller is specified, the crate will not compile.

You may also need to specify the density of the device with `medium`, `high` or `xl`
to enable certain peripherals. Generally the density can be determined by the 2nd character
after the number in the device name (i.e. For STM32F103C6U, the 6 indicates a low-density
device) but check the datasheet or CubeMX to be sure.
* 4, 6 => low density, no feature required
* 8, B => `medium` feature
* C, D, E => `high` feature
* F, G => `xl` feature

### Supported Microcontrollers

* `stm32f100`
Expand Down
17 changes: 13 additions & 4 deletions src/adc.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,10 +11,13 @@ use core::sync::atomic::{self, Ordering};
use cortex_m::asm::delay;

use crate::stm32::ADC1;
#[cfg(any(
#[cfg(feature = "stm32f103")]
use crate::stm32::ADC2;
#[cfg(all(
feature = "stm32f103",
feature = "high",
))]
use crate::stm32::ADC2;
use crate::stm32::ADC3;

/// Continuous mode
pub struct Continuous;
Expand Down Expand Up @@ -484,11 +487,17 @@ adc_hal! {
ADC1: (adc1),
}

#[cfg(any(
#[cfg(feature = "stm32f103")]
adc_hal! {
ADC2: (adc2),
}

#[cfg(all(
feature = "stm32f103",
feature = "high",
))]
adc_hal! {
ADC2: (adc2),
ADC3: (adc3),
}

pub struct AdcPayload<PINS, MODE> {
Expand Down
13 changes: 10 additions & 3 deletions src/lib.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -94,14 +94,21 @@

#![no_std]

// Some pac crates have fields specified in such a way that they are safe and other
// have them unsafe (likely an SVD error that needs patching). Unsafe blocks for
// one device cause warnings for the safe devices. This disables that warning.
#![allow(unused_unsafe)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this error should have been fixed by the latest PAC release, could you check that?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are still instances of mixed safe & unsafe registers. Examples:
stm32f100::tim1::aar::AAR_W::bits is safe
stm32f100::tim6::aar::AAR_W::bits is unsafe

I think the original comment still stands for now.

Copy link
Member

@TheZoq2 TheZoq2 Nov 20, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Depending on how many such warnings there are, I would prefer having the #[allow] thing on the lines/functions where it happens. That way we don't miss actually useful warnings

Although, we could do that in a separate PR


// If no target specified, print error message.
#[cfg(not(any(feature = "stm32f100", feature = "stm32f101", feature = "stm32f103")))]
compile_error!("Target not found. A `--feature <target-name>` is required.");

// If any two or more targets are specified, print error message.
#[cfg(all(feature = "stm32f100", feature = "stm32f101"))]
#[cfg(all(feature = "stm32f100", feature = "stm32f103"))]
#[cfg(all(feature = "stm32f101", feature = "stm32f103"))]
#[cfg(any(
all(feature = "stm32f100", feature = "stm32f101"),
all(feature = "stm32f100", feature = "stm32f103"),
all(feature = "stm32f101", feature = "stm32f103"),
))]
compile_error!("Multiple targets specified. Only a single `--feature <target-name>` can be specified.");

#[cfg(feature = "device-selected")]
Expand Down
Loading