embed-rs / stm32f7-discovery Goto Github PK
View Code? Open in Web Editor NEWLicense: Apache License 2.0
License: Apache License 2.0
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<(), !>;
}
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));
});
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.
InterruptHandler
unchecked_index
to get rid of the index check when accessing the tablesInterruptHandler
by making it independent of the low level hardware via generics and a hardware trait.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.
This causes continuous Truncated
errors when we let our controller run for a while.
See smoltcp-rs/smoltcp#186 (comment) for more information.
Not sure how feasible this is. We probably don't get this information from the svd.
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?
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:
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.
The new allocator uses a spin-lock to synchronize the access to the ALLOCATOR
(LockedHeap).
Following sequence can result in a deadlock:
ISR1
is entering the lock.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
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.
Depends on smoltcp-rs/smoltcp#63 and smoltcp-rs/smoltcp#186.
&self
instead of &mut self
for write
and modify
, which makes the register structs !Sync
.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.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.
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.
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
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.
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.
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.
address 0x014
bit 27 (LPM INT) missing in full speed variant
half speed does not support this bit
... 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?
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.