embed-rs / stm32f7-discovery Goto Github PK

• move ISRS into InterruptHandler
• use unchecked_index to get rid of the index check when accessing the tables
• generalize the InterruptHandler by making it independent of the low level hardware via generics and a hardware trait.

You can provoke a Deadlock with following interactions:
Interrupt the program while text is printed through std_out.

I'm not sure where we have to synchronize this.

I have one of these devices, tried running the code, and got an error. I think maybe this crate is for stm32f7x6, would you consider changing the name, or supporting the x9 boards as well?

The ethernet controller can be configured to generate interrupts on various conditions. We should use these interrupts instead of polling.

Note that the ethernet code currently only compiles in release mode due to #73.

The ethernet task currently throws an linker error in debug mode. It compiles in release mode.

I reported it upstream: rust-embedded/cortex-m-rt#157

We could use https://github.com/japaric/embedded-hal for our hal implementation.

The problem is that the functions of the traits only get &self and not &mut self. I think it makes more sense to use &mut self, because you "change" the timer when you call pause()...
For example:

pub trait Timer {
    /// A time unit that can be converted into a human time unit (e.g. seconds)
    type Time;

    /// Returns the current timeout
    fn get_timeout(&self) -> Self::Time;

    /// Pauses the timer
    fn pause(&self);

    /// Restarts the timer count to zero
    fn restart(&self);

    /// Resumes the timer count
    fn resume(&self);

    /// Sets a new timeout
    fn set_timeout<T>(&self, timeout: T)
    where
        T: Into<Self::Time>;

    /// "Waits" until the timer times out
    fn wait(&self) -> nb::Result<(), !>;
}

The new allocator uses a spin-lock to synchronize the access to the ALLOCATOR(LockedHeap).

Following sequence can result in a deadlock:

1. ISR1 is entering the lock.
2. ISR1 is preempted. ISR2 has higher priority and tries to access the lock. Scine the lock is already entered by ISR1, ISR2 has to wait in a loop until ISR1 has left the lock.

ISR1 and ISR2 don't make progress => Deadlock

Solution: Use the PRIMASK register on cortex m processors to synchronize the critical section by disabling interrutps.

See pull request for CortexMHeap rust-embedded/embedded-alloc#6

When drawing to layer1, the first and 4th bit of the blue channel are swapped. This can easily be observed by drawing a gradient across the screen.

... so when trying to obtain the same pins later we have some description of who else locked them.

Maybe even throw backtraces in there in debug mode?

Depends on smoltcp-rs/smoltcp#63 and smoltcp-rs/smoltcp#186.

I really just want something like

let _ = tim6.repeat(1000, Priority::P1 || {
                // toggle the led
                let current_state = led.get();
                led.set(!current_state);
});

instead of

    tim6.sr.update(|sr| sr.set_uif(false));

    // setup timing
    tim6.psc.update(|psc| psc.set_psc(42000));
    tim6.arr.update(|arr| arr.set_arr(3000));

    // enable interrupt
    tim6.dier.update(|dier| dier.set_uie(true));
    // start the timer counter
    tim6.cr1.update(|cr1| cr1.set_cen(true));

            let _ = interrupt_table.register(InterruptRequest::Tim6Dac, Priority::P1, || {
                // toggle the led
                let current_state = led.get();
                led.set(!current_state);
                // make sure the interrupt doesn't just restart again by clearing the flag
                tim6.sr.update(|sr| sr.set_uif(false));
            });

This causes continuous Truncated errors when we let our controller run for a while.

See smoltcp-rs/smoltcp#186 (comment) for more information.

When you print on the last line using println!, the screen gets cleared immediately; anything println!ed on the last line will thusly not be shown.

This is because the newline character causes the TextWriter to issue calls to newline() (which increases the cursor's y-position by 8 (moving it off the screen when printing on the last line)) and carriage_return(), which resets the cursor's x-position to 0 and, if the cursor's y-position if off-screen, resets it to 0 too.

Textwriter:

    fn newline(&mut self) {
        self.y_pos += 8;
        self.carriage_return()
    }
    fn carriage_return(&mut self) {
        if self.y_pos >= HEIGHT {
            self.clear();
        } else {
            self.x_pos = 0;
        }
    }

A simple fix would be to move if self.y_pos >= HEIGHT: clear() to line 341; this would clear the screen only when a character is about to be written on the next (off-screen) line.

address 0x014

bit 27 (LPM INT) missing in full speed variant

half speed does not support this bit

• The read/modify/write API takes only &self instead of &mut self for write and modify, which makes the register structs !Sync.
• The Peripherals API creates an empty type for each register block that derefs to a RegisterBlock type, which contains the actual struct. This makes it impossible to get a &'static mut reference to the register block without boxing and unsafe. Instead, the Peripherals struct could directly contain &'static mut RegisterBlock references.

Currently we're counting cycles, I think it would be great to have the same example, just with a recurring timer-interrupt set to 0.5 seconds.

I get this error when building with xargo. Is there a dependency missing from the documentation, or have I got something misconfigured?

I'm running Fedora 25.

$ xargo build
   Compiling stm32f7_discovery v0.1.0 (file:///home/jonathan/Documents/programming/stm32f7-discovery)
error: could not exec the linker `ld.lld-5.0`: No such file or directory (os error 2)
  |
  = note: "ld.lld-5.0" "-L" "/home/jonathan/.xargo/lib/rustlib/stm32f7/lib" "/home/jonathan/Documents/programming/stm32f7-discovery/target/stm32f7/debug/deps/stm32f7_discovery-8bd3543bbcf36c0f.0.o" "-o" "/home/jonathan/Documents/programming/stm32f7-discovery/target/stm32f7/debug/deps/stm32f7_discovery-8bd3543bbcf36c0f" "--gc-sections" "-L" "/home/jonathan/Documents/programming/stm32f7-discovery/target/stm32f7/debug/deps" "-L" "/home/jonathan/Documents/programming/stm32f7-discovery/target/debug/deps" "-L" "/home/jonathan/.xargo/lib/rustlib/stm32f7/lib" "-Bstatic" "/home/jonathan/Documents/programming/stm32f7-discovery/target/stm32f7/debug/deps/libr0-4c9ac95f64aec4f1.rlib" "/home/jonathan/Documents/programming/stm32f7-discovery/target/stm32f7/debug/deps/libstm32f7_discovery-6153ba08cda4cfc2.rlib" "/home/jonathan/Documents/programming/stm32f7-discovery/target/stm32f7/debug/deps/libspin-1433c0b45b26eec6.rlib" "/home/jonathan/Documents/programming/stm32f7-discovery/target/stm32f7/debug/deps/libembedded_stm32f7-51243b9927c774bd.rlib" "/home/jonathan/Documents/programming/stm32f7-discovery/target/stm32f7/debug/deps/libonce-ca6431046f69cecf.rlib" "/home/jonathan/Documents/programming/stm32f7-discovery/target/stm32f7/debug/deps/libembedded-0b061f7c242587d9.rlib" "/home/jonathan/Documents/programming/stm32f7-discovery/target/stm32f7/debug/deps/libvolatile-e95a9c93c95b4d05.rlib" "/home/jonathan/Documents/programming/stm32f7-discovery/target/stm32f7/debug/deps/libbit_field-a45edf4fa6f9a542.rlib" "/home/jonathan/Documents/programming/stm32f7-discovery/target/stm32f7/debug/deps/libbitflags-b857f06d8702b68e.rlib" "/home/jonathan/Documents/programming/stm32f7-discovery/target/stm32f7/debug/deps/libarrayvec-45a597b5892cf267.rlib" "/home/jonathan/Documents/programming/stm32f7-discovery/target/stm32f7/debug/deps/libnodrop-e6d7a15cb157c190.rlib" "/home/jonathan/Documents/programming/stm32f7-discovery/target/stm32f7/debug/deps/libodds-4d86427aaea60869.rlib" "/home/jonathan/Documents/programming/stm32f7-discovery/target/stm32f7/debug/deps/libbit_field-60b9c6c0d7fc80d3.rlib" "/home/jonathan/Documents/programming/stm32f7-discovery/target/stm32f7/debug/deps/libbit_field-9493560445ae6fc0.rlib" "/home/jonathan/Documents/programming/stm32f7-discovery/target/stm32f7/debug/deps/libnet-70d5d8d662ef3204.rlib" "/home/jonathan/Documents/programming/stm32f7-discovery/target/stm32f7/debug/deps/libbyteorder-574f80dfed4c7759.rlib" "/home/jonathan/.xargo/lib/rustlib/stm32f7/lib/libcollections-3258484305ade22a.rlib" "/home/jonathan/.xargo/lib/rustlib/stm32f7/lib/liballoc-b141cff101af6ec4.rlib" "/home/jonathan/Documents/programming/stm32f7-discovery/target/stm32f7/debug/deps/liballoc_cortex_m-4b9118521c562789.rlib" "/home/jonathan/Documents/programming/stm32f7-discovery/target/stm32f7/debug/deps/liblinked_list_allocator-4596ac83bd7de26f.rlib" "/home/jonathan/Documents/programming/stm32f7-discovery/target/stm32f7/debug/deps/libcortex_m-e3e3b27db187a72c.rlib" "/home/jonathan/Documents/programming/stm32f7-discovery/target/stm32f7/debug/deps/libvolatile_register-bd1a05ad8326c8e1.rlib" "/home/jonathan/.xargo/lib/rustlib/stm32f7/lib/libstd_unicode-9c985ead028450d3.rlib" "/home/jonathan/.xargo/lib/rustlib/stm32f7/lib/libcore-38427e0ea84eda51.rlib" "/home/jonathan/.xargo/lib/rustlib/stm32f7/lib/libcompiler_builtins-48645c160d69be81.rlib" "-Bdynamic"

error: aborting due to previous error

error: Could not compile `stm32f7_discovery`.

To learn more, run the command again with --verbose.

I got the following error today with rustc 1.35.0-nightly (3de010678 2019-04-11) went back to *
rustc 1.35.0-nightly (0576ac109 2019-03-24)* and everything compiled without error.

error[E0053]: method `poll` has an incompatible type for trait
  --> core/src/lib.rs:39:9
   |
39 |         fn poll(self: Pin<&mut Self>, lw: &Waker) -> Poll {
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ types differ in mutability
   |
   = note: expected type `fn(core::pin::Pin<&mut future::GenFuture>, &mut core::task::Context<'_>) -> core::task::Poll<::Return>`
              found type `fn(core::pin::Pin<&mut future::GenFuture>, &core::task::Waker) -> core::task::Poll<::Return>`

The blinking_led example always checks out the master branch of the repository. But a pull request that fixes the project will not be in the master branch, so travis will fail.

We chose not to use a path dependency because it will allow copy pasting the blinking_led example anywhere. Not sure how to proceed here.

I tried to enable audio interrupts, so that we get an interrupt whenever there is new audio data from the microphone. I did everything in the same as it's done in the official STM32Cube_FW_F7_V1.2.0 code:

• Configure GPIO pin H-15 as input pin.
• Enable various interrupts in the sai.aim/bim registers.
• Configure the syscfg.exticr4 register to use port H for exti15 line.
• Configure and unmask exti15 line.
• Add a interrupt handler for the EXTI15_10 interrupt.

But I still don't receive any audio interrupts. The H-15 pin is always 1, even directly after reading out data, when the register bit that the pin mirrors is 0. So there is a bug somewhere.

For now I just read the audio data on idle as a workaround, but it would be nice if we could get the actual audio interrupts working.

The pull request smoltcp-rs/smoltcp#186 was forced-pushed, so the commit referenced in the Cargo.lock does no longer exist. Updating the Cargo.lock is not possible at the moment because the new branch contains an invalid Cargo.toml: smoltcp-rs/smoltcp#186 (comment).

I think the best solution is to wait a bit and hope that the pull request gets merged soon. If it takes to long, we can use an own fork the branch to ensure that no force-pushes occur.

Not sure how feasible this is. We probably don't get this information from the svd.

The alloc feature was added in rust-lang/futures-rs#1479. Maybe we can use it instead of our futures fork at https://github.com/embed-rs/futures-rs.