It's been a while since 0.1.0 and it's time to release an updated version. Perhaps use cargo-release and add a change log too?

We should be documenting changes for this crate. Check out https://keepachangelog.com/en/1.0.0/ for more info.

I'm trying to determine if the SPI implementation can support I2S? If not, any plans in the future to add this?
I assume that its related to SPI, as the datasheet for stm32f747zg suggests:

Up to 6 SPIs (up to 50 Mbit/s), 3 with muxed simplex I2S for audio class accuracy via internal audio PLL or external clock

Thanks!

I think there are 2 ways to solve this

1. Remove the Rcc argument and access the register internally using unsafe. Serial::new does this.
2. Split the Rcc struct, one part which configures the clock and another part which can turn on/off the peripherals.

Dear maintainers,

Thank you for creating this awesome crate, it really is a pleasure to work with.
But there is one thing that would working with this crate even more pleasant, and that is releasing a new version on crates.io
Currently some features like the random implementation are not released yet due to this, and that is unfortunate, since it means that your awesome new work is only usable by setting the git link or downloading it.

So can you please release a new version on crates.io?

If I can help with this in any means (testing the examples on my 767ZI board, or submit a PR), please let me know.
Martijn

Currently, we use Travis CI for building, testing and formatting this crate. However, Travis CI is not as featured as the new Github Actions offering. Additionally, some of the other stm32-hal crates have already migrated. To keep this crate consistent and improve CI overall we should switch over.

Before the migration to embedded-time it was possible to write HSEClock::new(216.mhz(), HSEClockMode::Oscillator). This isn't possible anymore, because Into<Hertz> isn't implemented for embedded-times Megahertz.

The way the conversion is implemented in embedded-time makes more sense, because it prevents possible integer overflows. But the use of Into<Hertz> in e.g. HSEClock::new suggests that values with any frequency unit could be used. I didn't expect this behavior while porting to the new version and had to look into why this didn't work anymore.

Would it be better to change the API to take Hertz values instead of impl Into<Hertz> values? This way the types should make the user aware that they need to convert the value into hertz first if they want to use another unit (e.g. 216.MHz().try_into().unwrap()).

Another option would be to change the type bounds from Into<Hertz> to TryInto<Hertz>, but this would mean that all functions that take a frequency would need to return a Result. I don't think this would be a good idea.

This code in timer.rs:

pub fn unlisten(&mut self, event: Event) {
    match event {
        Event::TimeOut => {
            // Enable update event interrupt
            self.tim.dier.write(|w| w.uie().clear_bit());
        }
    }
}

should be

pub fn unlisten(&mut self, event: Event) {
    match event {
        Event::TimeOut => {
            // Enable update event interrupt
            self.tim.dier.modify(|_r, w| w.uie().clear_bit());
        }
    }
}

The write call will disable all the interrupts, not just that specified one.

Exampe serial has started giving

        serial::Config {
        ^^^^^^^^^^^^^^ missing `character_match`

It seems no now need character_match added:

      serial::Config {
           baud_rate: 115_200.bps(),
           oversampling: serial::Oversampling::By16,
           character_match: None,
       },

Follow up issue from #66

The following config for SPI1 is not available on every part in the F7 family:

            SCK: [
                gpio::gpiog::PG11<Alternate<AF5>>,
            ],
            MISO: [
                gpio::gpiog::PG9<Alternate<AF5>>,
            ],
            MOSI: [
                gpio::gpiod::PD7<Alternate<AF5>>,
            ],

This pin config should be disabled for F70x-F73x parts. We should double check this with the datasheets and make a minor change to spi.rs.

I've found it useful in the past if the UART object implements core::fmt::Write. This would mean you can write:

let serial = Serial(...);
writeln!(serial, "Hello, {}!", name).unwrap();

I tried doing my own impl in my application, but as I've defined neither the core::fmt::Write trait, nor the Serial object, the compiler won't let me (even with the changes that went into 1.41).

I found more update version of library - https://github.com/dtjones190/stm32f7xx-hal.
Could you ask me about plans to update with common state such as stm32f4xx-hal, I can create PR based on upper changes.

It would be useful to have an example showing how to use the EXTI traits for a GPIO input pin.

While writing this example, I also noticed that ExtiPin::make_interrupt_source will not work unless we configure the SYSCFG bit of apb2enr in the RCC. It would be nice if this bit was enabled by default when we callmake_interrupt_source, however since this is a larger "system level" configuration maybe it does not belong in gpio.rs? A simple solution may to just make APB2::enr in rcc.rs public to the user instead of just public to the crate.

I'll open a pull request to make this more clear.

The linker scripts mark start of the RAM to 0x2000000 which is where DTCM is placed, for example for the STM32F767, the SRAM1 starts at 0x2002000 and then there is the small SRAM2 further in the memory. This way the data is placed in the wrong memory region and also a significant portion of SRAM is unused.

So if the DTCM can be used as a regular RAM, the sizes should be expanded accordingly, or the start of the RAM region should be moved to the correct SRAM addresses. As of now I propose fixing the addresses to match SRAM.

Can some of the community's embedded wizards please maybe shine a bit of light into the correct mapping? @japaric @jonas-schievink Thanks!

I have the "STM32F723E-DISCO" and would like to make use of the display.

It looks like this is attached via the FMC, using an ST7789H2 controller.

I tried to get started with the display example in the examples folder, but it looks that doesn't work with the stm32f723 feature enabled.

To me it looks like UART5 is missing:

#[cfg(any(feature = "device-selected",))]
impl_instance! {
    USART1: (apb2enr, usart1sel, usart1en),
    USART2: (apb1enr, usart2sel, usart2en),
    USART3: (apb1enr, usart3sel, usart3en),
    UART4:  (apb1enr, uart4sel,  uart4en),
    USART6: (apb2enr, usart6sel, usart6en),
    UART7:  (apb1enr, uart7sel,  uart7en),
}

Hello! Can you add STM32F730 support?

I'd like to use the microSD slot on the STM32F7-Discovery board. This is connected to:

I have an embedded-sdmmc crate, but that only handles SD cards connected to generic embedded-hal::spi devices. I'd like to add an implementation of the embedded-sdmmc::blockdevice::BlockDevice for the SDMMC peripheral on the STM32F7.

I'll try a few things out in my fork and send a PR once I think it's working.

stm32f4xx-hal has an implementation for RNG, Is this ok to Copy that or it will create any problems?

The blocking embedded-hal traits are quite useful but as far as I can tell, this HAL doesn't opt-in to them.

There's a fork of this repository, maintained by @musitdev for his own use, that contains some features not present in this repository. I'm currently working on making some improvements there, and as part of this project, I'm trying to sync up both repositories to get them closer together.

(My work on that repository is the reason for my pull requests this week, by the way. Thank you @mvertescher, for reviewing and merging them so quickly!)

@mvertescher: I've opened this issue to inform you about those features and summarize the state they're in, in case you want to include them in this repository. Since those features are purpose-built to @musitdev's needs, they are not necessarily in a shape that allows them to be submitted here.

I've rebased musitdev/master on top of mvertescher/master: mvertescher/stm32f7xx-hal@master...braun-embedded:master

These are the main changes, and what I plan to do about them:

• Oversampling configuration for USART: What I'm observing doesn't match the documentation, and I don't understand why. I have a WIP branch (see commit messages for more info). I plan to take another look at this today, but if I can't get it to work quickly, I'll move on to the next task.
• DAC: I haven't looked into this one, and don't currently plan to.
• SPI: I'll take a closer look at this next week. Depending on how it goes, I'll either submit a pull request, or update this issue with the reason I'm not submitting one.

It'd be nice to have consistent formatting on this repository. Leaning toward a non-blocking CI run atm...

On line 6 of memory_2048_368.x there is
"RAM : ORIGIN = 0x20000000, LENGTH = 368K + 16K"
according to datasheet it would be
"RAM : ORIGIN = 0x20000000, LENGTH = 128K + 368K + 16K"
or
"RAM : ORIGIN = 0x20020000, LENGTH = 368K + 16K"

The file memory_1024_240.x appears to declare the RAM section as 256KB for these models. However, I think the correct amount is 320KB.

From the table on this page:

Also from the datasheet for STM32F745xx/STM32F746xx:

As far as I can tell, this change would effect two files:

• memory_1024_240.x
• build.rs

Happy to make the fix if others can concur.

If you create a timer at, say, 250.khz() you will get a timer at very slightly less than that.

When you set the auto-reload register arr, you need to specify the last valid counter before it wraps to zero - i.e. one less than the period in clock cycles.

RngExt::init enables the main PLL, if it isn't already enabled. There are no checks that the PLL multiplication/division factors are correct or that a valid clock is supplied to the PLL.

To improve this I would suggest to remove the PLL related code from init and change it to take a &Clocks argument. Clocks contains a pll48clk_valid field, which could be used to check that a valid clock is supplied to the RNG.

Is the RCC HAL implementation supposed to enable the PLL automatically? I didn't have time to investigate myself, but I think it is:

But if I try to configure the RCC using the following code the assertions fails and sysclk is 8 MHz:

let clocks = rcc
    .cfgr
    .hse(HSEClock::new(8.mhz(), HSEClockMode::Oscillator))
    .sysclk(216.mhz())
    .freeze();

assert_eq!(clocks.sysclk(), 216.mhz().into());

If I add a .use_pll() the configuration works as expected. @no111u3 could you clarify if this is a bug or the intended behavior?

The suggestion was brought up by @dutchmartin in #118. I haven't worked with it yet, but I agree that it would probably be useful.

In code that uses multiple device crates I have started having cargo update problems because of the change in the dependency bxcan = "0.5" (see stm32-rs/bxcan#22 (comment)). Can the dependency be more flexible, say bxcan = ">=0.4" ?

I believe that my original design for the SPI API isn't quite optimal. The current architecture works well enough for non-DMA uses, and I've managed to make it work with DMA too. But implementing send_all and receive_all, i.e. using DMA for only sending or receiving, will require additional changes to spi::Transfer, making everything more complicated.

I believe the following design would be better: Split the API into separate parts for sending and receiving, like this (pseudocode):

pub struct SPI {
    pub rx: Rx,
    pub tx: Tx,
    // other private fields
}

In this model, Rx would have a read_all method and Tx would have a write_all method, that would use the DMA in a simple way, pretty much like USART does too. SPI would still have transfer_all and the FullDuplex implementation.

spi::Transfer would have to stay as it is (no way around that, I believe), but at least this would allow for methods like write_all, without adding DMA wrappers to the SPI module.

I will look into this the next time I work on that code, but don't have any plans right now for when/if that might happen. If anyone else wants to pick this up, please go ahead!

The Timer assumes that the clock speed is equal to the peripheral clock, but that is only true in certain circumstances.
See Page 154 https://www.st.com/content/ccc/resource/technical/document/reference_manual/group0/96/8b/0d/ec/16/22/43/71/DM00224583/files/DM00224583.pdf/jcr:content/translations/en.DM00224583.pdf

Hi, Rust beginner here. I'm trying to use this excellent crate to blink an LED on an stm32f769; however, I get a "could not find prelude in stm32f7xx_hal" error when I import with the stm32f769 feature enabled. If I use the stm32f746 feature everything works perfectly, but wouldn't there be potential hardware issues from using code intended for another device?

I created a PR #108 in order to start a discussion around adding some CAN support for the crate.

The current PR is mostly copied from stm32-rs/stm32f1xx-hal#293 with a few modifications to simplify it's initial adoption.

Your implementation of HAL for stm32f7xx so good but:

• I not found any version on crates.io: which plans to release your hal?
• I have my version with ahead implementation for some featues - https://github.com/no111u3/stm32f7x7-hal, and I ready to integrate my features to your crate.

I'm so very interesting of use your HAL version but I need answer to upper questions.

Hi! I'm trying to test out the new LTDC driver to run an ILI9342 display with an STM32F767, but the display needs initialising over SPI first. The SPI interface is just CS, CLK, and MOSI; there's no MISO. On this board both possible MISO pins for the SPI4 peripheral I'm using are used as outputs for other LCD functions (enable and controller reset), so I can't configure them to be AFs.

However I can't figure out how to create an SPI driver instance without a MISO pin. I don't need any change to the SPI configuration, I just don't want to actually connect any pins to the SPI AF. So far my best guess is making my own fake SPI struct and transmuting it to a HAL SPI struct but that's a bit gross.

In stm32-rs/stm32h7xx-hal#74 the H7 HAL added the ability to create a driver without passing in any pins, which would enable this use case, perhaps the same could happen here?

I cloned repo and launched example with:

cargo +stable run --example stm32f7disco-screen --features="stm32f746 rt"

I have my discovery board plugged into USB, flashed succesfuly, when I halt the MCU in the gdb it shows it is in an infinite loop at the end of the example, but I cannot see any pixel drawn, just dark blank screen.

PS. I have tried it on two STM32F746G-DISCO boards and they both are fine with ST demos

Than I tried build example for stm32fdisco-scree I got some interested message of compilation:

   Compiling stm32f7xx-hal v0.2.0 (/Users/nis/Develop/stm32f7xx-hal)
error: linking with `rust-lld` failed: exit code: 1
  |
  <skipped by unnecessary> 
  = note: rust-lld: error: section '.bss' will not fit in region 'RAM': overflowed by 130048 bytes
          rust-lld: error: section '.bss' will not fit in region 'RAM': overflowed by 130049 bytes
          rust-lld: error: section '.bss' will not fit in region 'RAM': overflowed by 130050 bytes
          rust-lld: error: section '.bss' will not fit in region 'RAM': overflowed by 130052 bytes
          rust-lld: error: section '.uninit' will not fit in region 'RAM': overflowed by 130052 bytes
          rust-lld: error: section '.uninit' will not fit in region 'RAM': overflowed by 130052 bytes
          rust-lld: error: section '.uninit' will not fit in region 'RAM': overflowed by 130052 bytes


error: aborting due to previous error

error: could not compile `stm32f7xx-hal`.

I think we need to use generation for memory.x

Looks like the logic which calculates the value of the TIMINGR register is broken.

The code is located here: https://github.com/stm32-rs/stm32f7xx-hal/blob/master/src/i2c.rs#L338
One obvious problem with it, is that after:
let fscll_mhz: f32 = base_clk_mhz / (scll as f32 + 1.0);
the prescaler is then calculated with
let presc = base_clk_mhz / fscll_mhz;
which could be simplified to just
let presc = sccl + 1;
which is obiously wrong.

That said, I could not decipher how the entire logic is even supposed to work...

I see two possible ways to fix the problem:

1. Instead of calculating this at runtime, have a way to provide this parameter as an argument to I2C initialization. TIMINGR can then be calculated using STM32CubeMX tool as can be seen in the screenshot below:

2. Improve the calculation logic. I found pretty complex (and probably slow) implementation in the STM32Duino probject:

https://github.com/stm32duino/Arduino_Core_STM32/blob/master/libraries/Wire/src/utility/twi.c#L383

Timer in stm32f4xx-hal crate implements the Cancel trait.
You may be interested in doing the same for this crate.
Examples:

• https://github.com/stm32-rs/stm32f4xx-hal/blob/master/examples/timer-periph.rs
• https://github.com/stm32-rs/stm32f4xx-hal/blob/master/examples/timer-syst.rs

Hey!

I am very new to embedded programming, so please excuse me if this question is not relevant.

I have a NUCLEO-F767ZI, which has a STM32F767ZI chip.

This chips seems to me to support both usb_fs and usb_hs, but it's not enabled on the lines:

https://github.com/stm32-rs/stm32f7xx-hal/blob/master/src/lib.rs#L83-L93

Is this a mistake, or is something more needed to enable this functionality? Also in the serial_usb example, there is as feature for usb_hs, but I cannot see this mentioned anywhere else. Is this just for future reference?

Thanks for the awesome crate and any answers 😄

There's an initial DAC implementation here: https://github.com/musitdev/stm32f7xx-hal/commits/master/src/dac.rs . It would be good to merge this back!

Do an initial release! 🚢

While I prepared PR #137 I noticed that DisplayContoller::new directly changes the RCC clock configuration. Any changes to the clock configuration at this point won't be reflected in the Clocks struct that is returned when CFGR::freeze is called.

While the changes are limited to PLLSAI, which isn't used by other peripherals at the moment, it would be better to handle all clock setup in rcc.rs.

DisplayController::new does select PLLSAI frequency to match the required pixel clock, which was probably the reason to combine LTDC and clock setup into a single function. But the same could be achieved by adding a pixel_clock(&self) -> Hertz getter to DisplayContig.

BitsPerSecond

I didn't find any ways to configure spi as slave or using hardware nss pins. Is it implimented?

There seems to be some issue with the examples/timer implementations.

attempting to run the timer example on a stock nucleo-f767zi board prints the message in main but TIM2 never fires.

Steps to Reproduce

1. Clone the following project

git clone [email protected]:seanybaggins/blinky-769.git

2. Checkout the commit containing the bug

git checkout a8a02896871f19aaa9de09256ce517179ec934ac

3. Follow the instructions within the readme.md for opening the environment within a docker container using VSCode.

4. Use Cargo check to get the compiler error

cargo check \
    --target thumbv7em-none-eabihf \
    --features stm32f769

Would you have plans to release new version of crate?

Where is adc? It is in device:: in release 0.2.0. On git device:: has disappeared but adc does not seem to be in any of the usual places.

When I originally submitted the DMA API, I couldn't quite figure out how to support multiple DMA streams per peripheral instance. I must have gotten less stupid since then, because I believe the solution is quite simple:

Convert Target::Stream from an associated type to a regular type parameter. The Target trait can be implemented multiple times for the same type, as we'd be implementing Target<Stream1> and Target<Stream2>, for example, which are different types.

This means my comment on the impl_target! invocation is misleading, as the Rx/Tx types don't need parameters.

I will fix this the next time I work on that code, but don't have any plans right now for when/if that might happen. If anyone else wants to pick this up, please go ahead!