<flippette[m]>
i guess if i just don't touch the PIOs on this thing then all is well
enaut[m] has joined #rust-embedded
<enaut[m]>
<flippette[m]> "1000216701.mp4" <- Is the framerate so smoth because of the size and monochrome?Just asking because I wondered how I can get the frame rate of 2 fps full screen color up to something higher or at least have some double buffering so that the lines when updating do not show so bad.
<flippette[m]>
<enaut[m]> "Is the framerate so smoth..." <- this one was 15fps full color at 160x140
<flippette[m]>
the crate i use to drive the display does batching by default
<flippette[m]>
also i bumped the spi frequency to the max specified in the datasheet
<flippette[m]>
which for this one happens to be 70.5 mhz
barafael[m] has joined #rust-embedded
<barafael[m]>
I'm considering using an icm20948. The rust drivers for it do not support using the internal dmp.
<barafael[m]>
I just want a quaternion for orientation. If no dmp, I'll have to do the calculations myself somehow, right? There are crates for this. But I assume the manufacturer knows what they are doing. Is the dmp providing much better data quality or are the open source fusion algorithms comparable?
anton_star has quit [Quit: Client closed]
Makarov has joined #rust-embedded
Makarov has quit [Quit: Ping timeout (120 seconds)]
Makarov has joined #rust-embedded
Makarov has quit [Client Quit]
sroemer has quit [Ping timeout: 252 seconds]
silverhorn[m] has joined #rust-embedded
<silverhorn[m]>
Hi all. I'm new in Rust embedded programming. I followed all steps in the guide https://docs.rust-embedded.org/discovery/microbit/. But it fails to compile. I use MacOS. The command: cargo embed --target thumbv7em-none-eabihf. Fails with: use microbit::hal::prelude::*;
<silverhorn[m]>
| ^^^^^^^^ use of undeclared crate or module `microbit` and etc. Can someone help me?
marmrt[m] has joined #rust-embedded
<marmrt[m]>
Do you have the microbit crate in your cargo.toml?
Makarov has joined #rust-embedded
<silverhorn[m]>
Yes, sure. I have. It seems I found the cause. It requires to specify --features v2 to compile cause I have microbit V2. Thanks.
Makarov has quit [Quit: Ping timeout (120 seconds)]
Makarov has joined #rust-embedded
Makarov has quit [Quit: Client closed]
Makarov has joined #rust-embedded
Makarov has quit [Quit: Client closed]
Makarov has joined #rust-embedded
anton_star has joined #rust-embedded
Makarov has quit [Quit: Ping timeout (120 seconds)]
<JamesMunns[m]>
I'm not sure the best way for RTT to "signal" the executor
<JamesMunns[m]>
I wonder if you could trigger an interrupt with RTT or something? I could always have a low prio task that polls, but that's a little lame
<JamesMunns[m]>
s/RTT/probe-rs/
ryan-summers[m] has joined #rust-embedded
<ryan-summers[m]>
Maybe the DWT or debug module would have memory monitoring capabilities that you could use?
<Lumpio->
The "speed" of RTT is based on background memory access where available, it doesn't really provide a reliable way to signal anything in and of itself. I think you might need to have some kind of task polling a flag for example.
<Lumpio->
Unless you can cause a software interrupt via the memory interface..?
<JamesMunns[m]>
yeah, I guess if RTT is attached, we're PROBABLY not low power, so polling at 1ms or something isn't too offensive
<Lumpio->
That would be pretty platform dependent
<ryan-summers[m]>
Maybe DMA could be hijacked for something like this too
<JamesMunns[m]>
Lumpio-: I feel like if you had a custom header, you could put the "sacrificial" interrupt ID there, if probe-rs can NVIC-pend an interrupt by ID?
<JamesMunns[m]>
ryan-summers[m]: hmm, maybe, but DMA isn't very portable
<JamesMunns[m]>
I'm hoping to write a portable postcard-rpc transport for RTT
<Lumpio->
Can you pend an interrupt without causing large delays :think:
<JamesMunns[m]>
and right now that means implementing an async "send frame" and "recv frame" intervace
<JamesMunns[m]>
s/intervace/interface/
<Lumpio->
The reason I originally wanted to use RTT anyways was debugging USB because I couldn't have a debugger pause or something that causes a large amount of delays
<JamesMunns[m]>
yeah, totally agree
<JamesMunns[m]>
But yeah, if anyone has any ideas for how to trigger a function callback or an interrupt via probe-rs, without halting the target or requiring some kind of expensive round trip, let me know :)
<JamesMunns[m]>
(and in a way that will work on Cortex-M0+, if that matters)
<ryan-summers[m]>
Why not pend the SW interrupt on the NVIC using the probe? Don't know the impact on timing of the MCU in that case
<Lumpio->
I was just seeing how the interrupt pending registers work on Cortex-M0
<ryan-summers[m]>
But would undoubtedly introduce some bus activity and introduce an intrusive bus access
<JamesMunns[m]>
I mean that's what I want! I just didn't know if that was possible :D
<Lumpio->
Maybe just writing the ISPR is enough
<ryan-summers[m]>
Yeah the probe has access to the buses usually, depending on the infra
<Lumpio->
I think it's "1 to pend, 0 is ignored" so it should be safe to write asynchronously
<Lumpio->
But whether it works depends on how the memory interface is tied into everything - does it only see RAM or can it access peripherals as well?
hustor[m] has quit [Quit: Idle timeout reached: 172800s]
Lumpio[m] has quit [Quit: Idle timeout reached: 172800s]
anton_star has quit [Quit: Client closed]
Lumpio[m] has joined #rust-embedded
<Lumpio[m]>
Is it expected for "probe-rs run" and "probe-rs download" to leave the target halted? There doesn't seem to be an obvious command line argument to stop that at least
czarop[m] has joined #rust-embedded
<czarop[m]>
settings problem.
<czarop[m]>
Hi, can anyone help with set up for RP Pico W (RP2040) with probe-rs? Ideally I’m looking for a link to a VS code template that’s working nicely… so I can see where I’m going wrong. My attempts are inconsistently able to get prints back to console (works some runs not others), but debug sessions are also ending as soon as I do anything with Wi-Fi chip firmware. The program runs fine without debugging so assuming it’s a
<czarop[m]>
Hi can anyone send a link to a repo with Vscode project set up for RP pico W with probe-rs & embassy? I can’t seem to nail the correct settings, printing text to console works some runs not others, and my debug sessions end as soon as I touch Wi-Fi chip firmware. Assume it’s probe-rs settings issue as the program works fine when not debugging.
<Lumpio[m]>
<JamesMunns[m]> "I won't get to that today, but..." <- Hey, what do you know, it works! (At least on Cortex-M4 which is what I had on hand). You can pend interrupts via the memory interface by just doing `core.write_word_32(0xE000E200 + (4 * (irqn >> 5)), 1 << (irqn & 0x1f))` where the magic value is the NVIC_ISPR0 (interrupt set pending) register.
<Lumpio[m]>
Took me less time to write than to find an interrupt that "embassy-stm32" wasn't already using. I guess there's no way to ask it to not reserve them?
<JamesMunns[m]>
Very cool!
<JamesMunns[m]>
I think I can make it work by adding the "reserved interrupt ID" in a fixed location table, like the RTT configuration section
GrantM11235[m] has joined #rust-embedded
<GrantM11235[m]>
Instead of storing an interrupt id, you could make it more general by simply storing an address and a value to write.
<GrantM11235[m]>
That way the host doesn't need to know about the NVIC registers, or the difference between arm and risc-v, etc
<JamesMunns[m]>
Open to it, I'm just happy it's possible, I think the impl details will shake out
<GrantM11235[m]>
At the cost of a few more bytes of course
<JamesMunns[m]>
I'm not familiar enough with riscv to know if a "poke" is likely to work on the various impls
<GrantM11235[m]>
That's a good point, I'm not familiar either
anton_star has joined #rust-embedded
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
Amanieu has joined #rust-embedded
explodingwaffle1 has joined #rust-embedded
<explodingwaffle1>
not all riscv cores have memory access without halting, which really sucks
<explodingwaffle1>
it is possible but optional with the standard debug interface. “system bus access” is the keyword
<whitequark[cis]>
that would make the core considerably more expensive...
<whitequark[cis]>
* more expensive... (and possibly slower too)
<whitequark[cis]>
the data bus is almost certainly your critical path, so adding a new rarely-used port to it is not easy to justify
<JamesMunns[m]>
that's fair, it's just a bummer coming from cortex-m where it's standard
<whitequark[cis]>
although to be clear by "considerably" i mean "it is a consideration in the design process" i.e. "not free"
i509vcb[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
IIRC the 2350 puts the debug access to memory on the second core. Seems a reasonable trade off.
<thejpster[m]>
(In RISC-V mode)
mabez[m] has quit [Quit: Idle timeout reached: 172800s]
<Lumpio[m]>
The best solution for RTT type stuff would be to have like an actual, official, easy to use, logging/console type deal over the debug port but no
<M9names[m]>
It's meant to be used with cargo generate, so `cargo install cargo-generate` then `cargo generate 9names/embassy-rp-quickstart`
Amanieu has quit []
<thejpster[m]>
You mean like ITM?
<RockBoynton[m]>
Does someone have a solution for supporting multiple USB ports with a microcontroller as a USB host? I'm trying to scope the work to accomplish this on an STM32L4
<RockBoynton[m]>
For a uC to support multiple physical USB ports does it need to have multiple PHYs? If it only has one PHY, can I use an external PHY to work around that? Or can it use the one PHY as a sort of hub (using the USB hub class)?
<M9names[m]>
Hubs are a very specific bit of hardware. You don't implement those in software, USB peripherals don't supply one, it's an external IC you attach to a phy.
<RockBoynton[m]>
So you could use an external USB hub IC that is connected to the microcontroller's USB peripheral? There must be some other firmware support to handle the multiple connections thought right?
<M9names[m]>
Looks like L4 only has one USB full-speed peripheral and it has an integrated phy, so you don't need an external phy and attaching a hub is your only option
<M9names[m]>
Your firmware does need to know how to talk through a hub, yes
anton_star has quit [Quit: Client closed]
<M9names[m]>
Also, host support in embedded rust is not a solved problem yet. There are a few host stacks but I would anticipate you'll have to implement a bunch of things yourself.