<dkhayes117[m]>
Dipping my toes into embedded-hal. I'm looking at updating a driver, that I want to use in the future, from eh-0.2 to eh-1. Are there any examples of crates that already have migrated, specifically i2c/spi.
<dkhayes117[m]>
Making some progress looking closer at the docs along with the migration guide 🙂
cr1901 has joined #rust-embedded
emerent has quit [Ping timeout: 260 seconds]
emerent has joined #rust-embedded
spinfast[m] has joined #rust-embedded
<spinfast[m]>
<d3zd3z[m]> "byteorder needs std to..." <- I believe nom could do it?
<spinfast[m]>
If the format is simple
<spinfast[m]>
Enough
<spinfast[m]>
s/Enough/enough /
notgull has joined #rust-embedded
M762spr[m] has quit [Quit: Idle timeout reached: 172800s]
notgull has quit [Ping timeout: 264 seconds]
rjmp[m] has quit [Quit: Idle timeout reached: 172800s]
eldruin[m] has joined #rust-embedded
<eldruin[m]>
<dkhayes117[m]> "Dipping my toes into embedded-..." <- My [BMI160](https://github.com/eldruin/bmi160-rs) IMU is an example of a driver updated to e-h 1.0 supports allows both SPI and I2C.
<thejpster[m]>
weird that target_arch gets collapsed to arm for all the various Cortex-M targets
<thejpster[m]>
* weird that target_arch gets collapsed to arm for all the various ~~Cortex-M targets~~ M-Profile Arm targets
<thejpster[m]>
> Note that this does not affect Cargo’s dependency resolution. This cannot be used to enable an optional dependency, or enable other Cargo features.
<thejpster[m]>
boo
<thejpster[m]>
I also want to optionally include a package depending on the chosen target
<JamesMunns[m]>
thejpster[m]: the issue with build-rs is that it runs AFTER all deps, BEFORE the target package
<thejpster[m]>
yeah makes sense
<thejpster[m]>
maybe target_arch is enough
<JamesMunns[m]>
afaik there's no way to affect feature decisions other than a full wrapping tool like just
<JamesMunns[m]>
(e.g., change what you pass to cargo itself)
<thejpster[m]>
it's weird that you can't, say, depend on a soft-float library but only on Arm chips that don't have an FPU. You have to always build it and then only optionally use it.
<JamesMunns[m]>
I'm trying to think of metaphors for this, maybe crates that have multiplatform support for targets?
<JamesMunns[m]>
honestly, you could totally make a case for adding "has fpu" as a target feature for cortex-m targets. Just nobody has done it.
<thejpster[m]>
I also have an issue with tying FPU support to being able to use FPU registers for parameter passing
<thejpster[m]>
eabihf is about the latter, but you can use a Cortex-M4F with just eabi and still use the FPU.
<thejpster[m]>
If, say, you wanted ABI compatibility with some C code, but still to do Fast Maths in Rust land.
<JamesMunns[m]>
I imagine that is going to break a lot of assumptions and cause a ton of problems. It probably shouldn't, but I bet it totally would, across both rustc and llvm
<JamesMunns[m]>
but, idk.
<thejpster[m]>
well it breaks cortex-m-rt to start, because the has-fpu flag is set based on the name of the target, and not the enabled CPU options.
<JamesMunns[m]>
that's a hack, because there was no other way to determine it
<JamesMunns[m]>
if it WAS exposed via target-features, cmrt should switch to that
<thejpster[m]>
it's one of those things I feel like I want to fix, but at the same time I'd rather Arm fixed it because they know their CPU archtecture and the permutations of the IP they sell better than I do.
<JamesMunns[m]>
I guess there's two things going on here:
<JamesMunns[m]>
* "hard vs soft float shouldn't be as magic/special cased": whew probably agree personally but whew
<JamesMunns[m]>
* rustc should expose stuff like "has fpu"/"is a hard float target": within the scope of rust, could happen IMO
<adamgreig[m]>
and the couple day embedded workshop afterwards 👀 we discussed it a little late last year
<adamgreig[m]>
(details on that are still tbc, as far as i know)
<JamesMunns[m]>
> Following the conference RustNL will facilitate a multi day unconference for Rust maintainers in the mobile and embedded space. Contact us at 2024@rustnl.org if you're interested in sponsoring the conference or unconference.
<JamesMunns[m]>
yeah, haven't seen more details than that yet.
IlPalazzo-ojiisa has joined #rust-embedded
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
Guest7282 has left #rust-embedded [Error from remote client]
Guest7282 has joined #rust-embedded
cmaiolino has joined #rust-embedded
<thejpster[m]>
ah, weirdly, I was looking that up on my phone whilst out at lunch .... at the exact same time .... without having seen the tweet
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
onsdag[m] has quit [Quit: Idle timeout reached: 172800s]
ryan-summers[m] has joined #rust-embedded
<ryan-summers[m]>
Anyone know if they're looking for talks etc?
<JamesMunns[m]>
I emailed them asking the same :D
JomerDev[m] has joined #rust-embedded
<JomerDev[m]>
Does anybody know if there is a way to do something on panic (e.g. enabled an led) while still using panic-probe?
<adamgreig[m]>
I don't think panic-probe has any hooks, but you could write your own panic handler and do an rtt print inside it, it's only a few loc
<JomerDev[m]>
Yeah, I saw that it wasn't much, but wanted to avoid just cloning the code for that if I could
<adamgreig[m]>
you can skip the parts of that to do with picking which rtt/defmt and probably which target and so forth, so all you really need is a few lines
<adamgreig[m]>
but nothing in those few lines lets you hook your own function on a panic
<dirbaio[m]>
panic-probe does udf to escalate to a hardfault, you can put your custom code in the hardfault handler
<adamgreig[m]>
oh, yea, do that
<adamgreig[m]>
has the bonus of also triggering on a non-panic hardfault
firefrommoonligh has joined #rust-embedded
<firefrommoonligh>
Does anyone know of any tricks re stm32H7 ADCs, other than enabling PLL2P or a/r? I am having a struggle! Ty
<firefrommoonligh>
Of note, I do ADC ops on G4 all the time
<dirbaio[m]>
tricks to make it work?
<JomerDev[m]>
<dirbaio[m]> "panic-probe does udf to..." <- If you could tell/link me to how I can do that? 😅
<JomerDev[m]>
Oh right, but I can't make the led blink without the peripherals anyway and I don't think I can share them over a panic and/or a hard fault 🤦
potato[m] has quit [Quit: Idle timeout reached: 172800s]
<firefrommoonligh>
<dirbaio[m]> "tricks to make it work?" <- Well, for example, the default-disabled default clock. I'm just kind of hitting a wall with the "it should work but it doesn't"
<dirbaio[m]>
yeah.. i'm not sure if there's anything else
<dirbaio[m]>
set ADCSEL to PLL2_P, then make PLL2 output something on P
<dirbaio[m]>
then set ADC12EN or ADC3EN
<firefrommoonligh>
Thank you. I will try that. Trying the stm32h7xx-hal example now
<dirbaio[m]>
the shared ADC12EN bit is a common gotcha
<dirbaio[m]>
enable ADC1, enable ADC2, disable ADC1 and boom ADC2 stops working 💩
<firefrommoonligh>
What's kind of interesting is I'm running into this problem on both my own flight control firmware and the OSS Betaflight, but it works in Ardupilot
<firefrommoonligh>
(This measures battery voltage as a proxy for life remaining)
<firefrommoonligh>
I was sure I had a hardware problem at first!
<dirbaio[m]>
if you make the HAL do "enable/disable RCC bit" automatically :(
<firefrommoonligh>
dirbaio[m]: Actually you helped me with this issue on a G4 board recently! (Diff use case; that was 14 separate ADC channels across 2 ADCs, and only one ADC would work at a time until we chatted)
<dirbaio[m]>
embassy refcounts the bit now
<firefrommoonligh>
OK - the STM32h7xx hal example works. So something my code is forked
<JamesMunns[m]>
It might be worth running from RAM as a demo, to rule out flash latency
<JamesMunns[m]>
it might not be a SOLUTION, but would help you eliminate flash latency, icache, and wait states as a cause (or reveal it as a big part).
<JamesMunns[m]>
You almost certainly should not be seeing latencies that high if you aren't critical sectioning or similar. ISR latencies on cortex-m are like 10-20 cycles, at 480x20 that's nearly 10k cycles which means something is very weird.
<JamesMunns[m]>
(I think external flash and wait states could bring that number higher than 10-20, I think that's spec'd at zero flash wait states, which isn't achieveable at 480mhz usually, but it should be way closer to 10 than 10k)
<RockBoynton[m]>
are there examples for loading the app into ram?
<JamesMunns[m]>
it's mostly changing your linker script to pretend that the FLASH section is actually in the RAM range
<JamesMunns[m]>
dirbaio will correct me, I thought that probe-rs/probe-run could support this, so it should just be changing the linker script to totally ignore the flash regions, then do a cargo run
<JamesMunns[m]>
if probe-rs can't do it, you definitely can do it with gdb and calling load
<dirbaio[m]>
they can "flash" to RAM, but they can't boot from ram. teleprobe can
<JamesMunns[m]>
ah, that's annoying. I've definitely done this in the past, but it's been a while
<thejpster[m]>
<JamesMunns[m]> "I don't think I had to manually..." <- Sometimes gdb or openocd does it for you. Caught me out recent because it was bypassing my boot Rom. An extra monitor reset halt after flashing did the trick.
<JamesMunns[m]>
you'd probably want a 1ghz scope to resolve a pulse that triggers on a 480MHz clock, assuming that gpio ops can be done in a single cycle.
<JamesMunns[m]>
also if you don't clear an interrupt, it'll keep retriggering forever, are you sure it isn't just pulsing and it takes some time for you to see it on your scope Rock Boynton?
<JamesMunns[m]>
what happens if you just set the LED high the first time the pulse occurs ("latching"), or until you press a button to clear or something?
<JamesMunns[m]>
I'd be interested in looking at those projects to see if I can see anything significantly different about them.
<dirbaio[m]>
I think he mentioned he was getting ~20us with all 3
<RockBoynton[m]>
yes dirbaio is right
<JamesMunns[m]>
ah, I thought he had one where he got like 200ns latency once
<RockBoynton[m]>
I'll clean up my mess of testing and try to make it reproducible for you.
<JamesMunns[m]>
I don't have a board, so I probably can't reproduce, but I can peek!
<dirbaio[m]>
makes me wonder if it's something flaky with the measurement setup?
<RockBoynton[m]>
James Munns the fastest interrupt latency I have seen is 600 ns using rtic with an L4
<JamesMunns[m]>
I have an STM32H743VI, not on a nucleo board (it's a weact)
<dirbaio[m]>
what're you using to make the "trigger" pulse? how's the wiring done? are the wires too long maybe?
<dirbaio[m]>
can you check with an oscilloscope to verify the edges are clean/fast?
<RockBoynton[m]>
dirbaio[m]: I was starting to think the image wasn't getting loaded or something but I have switched up the behavior slightly (e.g only toggling instead of pulsing) and see my changes reflected. I have also tried switching back to the L4 and seeing the right behavior there as well
<JamesMunns[m]>
what chip is your H7 again?
<RockBoynton[m]>
dirbaio[m]: the wires are the ones included with the salae with the prongs manually held on the pads of the nucleo extension headers (ok, I'll admit this is jank af, but I was doing this on all of my testing, same on both nucleos)
<RockBoynton[m]>
stm32h743zit6u is the exact printing on the chip
<JamesMunns[m]>
oh wow maybe I do have that exact chip lol
<JamesMunns[m]>
VIT6 instead of ZIT6, but damn, close
<JamesMunns[m]>
so yeah, make me a repro, I'll play with it this weekend.
<JamesMunns[m]>
you're measuring your 100nf capacitor's rise time!
<RockBoynton[m]>
dirbaio[m]: Now that you say it it makes so much sense, forgive my ignorance
<JamesMunns[m]>
lmao
<JamesMunns[m]>
you could probably calculate the time constant of the RC network and figure out how close you got... or wire up an MCU to a pin that DOESN'T expect you to charge a cap first :)
<RockBoynton[m]>
it is always a hardware problem
<JamesMunns[m]>
"wontfix: works as designed"
<RockBoynton[m]>
or a problem between keyboard and seat
<JamesMunns[m]>
it's friday, don't be too hard on yourself :D
<JamesMunns[m]>
when in doubt tho, "check the schematic" is always a fair shout
<RockBoynton[m]>
Hell of a debugging session fellas, much appreciated. I will make my test case more representative and report back with results
<JackGreenbaum[m]>
@rock
<JackGreenbaum[m]>
* @rock, Is there a timer running at full clock speed on the chip? If so you can trigger the interrupt from the timer and read the timer in the handler to measure interrupts by clock cycles precisely.
<JackGreenbaum[m]>
* @rock, Is there a timer running at full clock speed on the chip? If so you can trigger the interrupt from the timer and read the timer in the handler to measure interrupts by clock cycles precisely. Or are you specifically trying to measure "from the pins"?
<JackGreenbaum[m]>
* @rockboynton:matrix.org , Is there a timer running at full clock speed on the chip? If so you can trigger the interrupt from the timer and read the timer in the handler to measure interrupts by clock cycles precisely. Or are you specifically trying to measure "from the pins"?
<JamesMunns[m]>
JackGreenbaum[m]: The original goal was "latency from gpio interrupt to MCU response"
<JamesMunns[m]>
The goal was to use a gpio interrupt as a "start transfer" signal with a 1us turnaround time from trigger to starting send
<JamesMunns[m]>
So "interrupt sets a gpio high" was the minimum viable measurement baseline
<JackGreenbaum[m]>
Sounds like the answer involves "How hard can we drive the GPIO pin?"
<JamesMunns[m]>
Maybe! The root issue is we found "the hardest button to button", to quote a different Jack.
<JamesMunns[m]>
(I think as long as the answer was sub-us, the precise answer didn't matter QUITE as much.)
vollbrecht[m] has quit [Quit: Idle timeout reached: 172800s]
Ralph[m] has quit [Quit: Idle timeout reached: 172800s]
GrantM11235[m] has quit [Quit: Idle timeout reached: 172800s]
<RockBoynton[m]>
<dirbaio[m]> "use another mcu to generate..." <- I'm having trouble getting this to work: For my setup, I powered my L4 board loaded with a simple blinky LED from an external power supply, I measure and verify the pin is toggling the way I want. Then I loaded the H7 with my latency test app. Now I am trying to wire up everything to allow me to measure the input side of the H7 pin connected to the output pin of the L4 that is
<RockBoynton[m]>
toggling, as well as the output of the H7, but I can't figure out how to connect all the grounds that make the measurement I want possible between the Salae and the external power supply. I feel my electronics fundamentals is lacking here
<dirbaio[m]>
everything is connected to the same PC via USB?
<RockBoynton[m]>
yes
<RockBoynton[m]>
this was happening when I was using an external psu on the L4 as well
<RockBoynton[m]>
I am using a USB hub (thanks mac), would that affect anything?
<JamesMunns[m]>
you're not connecting any powers together, and not connecting like one device that is driving a pin high while another is driving the pin low?
<dirbaio[m]>
why do you need external PSUs?
<dirbaio[m]>
connecting GNDs from different PSUs is sometimes risky because they can be at different levels
<dirbaio[m]>
it's better if you power everything from the same PSU
<dirbaio[m]>
easiest is from USB
<dirbaio[m]>
(from the Mac, or from the hub's PSU if it's powered)
<RockBoynton[m]>
dirbaio[m]: external psu was only cause I couldn't find another micro usb cable (but had a psu on my desk, funny I know). But I found another micro USB so external psu is out of the picture now
<dirbaio[m]>
then I don't know what could be wrong :S
<RockBoynton[m]>
ok I had a crazy idea, but I think it worked. I used the psu and set it to output 3v3. I tapped it on the pin pad on the board as an input.
<JamesMunns[m]>
but if he's at 480mhz, 780ns is 390 cpu cycles
<JamesMunns[m]>
which is still way more than the 15-20 I expect
<dirbaio[m]>
yeah..
<JamesMunns[m]>
tho its really less
<dirbaio[m]>
maybe a pwm
<dirbaio[m]>
so it's toggled without cpu intervention
<JamesMunns[m]>
its 780ns from like 0.7v
<RockBoynton[m]>
JamesMunns[m]: Ok right, I set it to 3v3 instead and it is almost at 1us
<JamesMunns[m]>
that's... more?
<JamesMunns[m]>
or you mean for embassy?
<RockBoynton[m]>
no, the embassy app
<JamesMunns[m]>
ah, gotcha
<RockBoynton[m]>
the goal is to use embassy, so I'm trying to convince myself it will be make the requirement
<JamesMunns[m]>
I mean you're gunna need a custom interrupt either way
<JamesMunns[m]>
but you can have the rest of the app be embassy, or rtic 1 or rtic 2
<JamesMunns[m]>
but if you have a hard 1us deadline, you don't want cooperative multitasking on that path, you very much want a preemptive interrupt
<JamesMunns[m]>
480 cycles even for an interrupt executor would be brave, IMO.
<JamesMunns[m]>
maaaaybe, but it would be very close.
<dirbaio[m]>
why do you need to send this thing over SPI so fast?
<dirbaio[m]>
if you already have an FPGA, can't you design things in a way where all the real-time requirements are only in the FPGA?
<RockBoynton[m]>
I was hoping to just make it a higher priority, I think dirbaio mentioned with `interrupt-executor` you could guarantee that a task that makes a timing will _always_ make it, is that incorrect?
<JamesMunns[m]>
it will always be the HIGHEST priority
<JamesMunns[m]>
like, I'd believe you COULD do it. but flash wait states, critical sections, etc, are going to make it very easy to miss it by a bit. not a LOT but, a bit.
<JamesMunns[m]>
vs an interrupt which is like 20-50 cpu cycles, guaranteed.
<JamesMunns[m]>
I dunno, that's my gut feeling. Data beats gut feeling any day, for sure. but my gut is you'd be very close, and it's probably not worth the hassle vs just writing a small interrupt that pops from a queue and shoves it in a fifo, or slaps the "start" button on a DMA transfer.
<JamesMunns[m]>
I'd trust dirbaio's gut over mine here, tho.
<RockBoynton[m]>
hmm, a lot to think about
<JamesMunns[m]>
<dirbaio[m]> "if you already have an FPGA, can..." <- I think this is a very good suggestion too