<lanre[m]>
this is a great crash course, thank you
M9names[m] has quit [Quit: Idle timeout reached: 172800s]
Jubilee[m] has quit [Quit: Idle timeout reached: 172800s]
<lanre[m]>
from what i see, bingen is the best crate to use to generate bindings, correct?
cgc17[m] has quit [Quit: Idle timeout reached: 172800s]
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
drahnr[m] has joined #rust-embedded
<drahnr[m]>
Hey, is anyone trying to use a blackmagicprobe (BMP) with either the nrf52832 adafruit feathers, or the nrf52840-dk? probe-rs doesn't quite work as well as I remembered.
<JamesMunns[m]>
Might be worth asking in #probe-rs:matrix.org, I think BMP support is relatively new and there might be some bugs
crabbedhaloablut has quit []
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Client Quit]
crabbedhaloablut has joined #rust-embedded
cinemaSundays has joined #rust-embedded
AlexandrosLiarok has quit [Quit: Idle timeout reached: 172800s]
cinemaSundays has quit [Quit: Connection closed for inactivity]
<drahnr[m]>
<JamesMunns[m]> "Might be worth asking in #probe..." <- I tried the PR which supposedly works, but I had no luck so far flashing anything (I _think_ ).
<drahnr[m]>
drahnr[m]: also a patched `master`, but no luck either.
<drahnr[m]>
drahnr[m]: James Munns: what are you using? I've seen a few of your demo projects for nrf52 a few years back
<drahnr[m]>
<JamesMunns[m]> "What am I using for debuggers? I..." <- Thanks! My jlink on the nrf52840-dk seems borked, at least probe-rs does not show it
<drahnr[m]>
drahnr[m]: *nor in lsusb / cmye
<JamesMunns[m]>
IIRC there is a way to reflash it, or you might want to make sure you have the switches configured correctly, and that you are using a good USB cable that actually has data lines and isn't just a charging cable
igiona[m] has joined #rust-embedded
<igiona[m]>
drahnr[m]: I'm using rusty-probe, there is a 3d printable enclosure.
<igiona[m]>
igiona[m]: On Windows (maybe also Linux, don't know), in order to use jlink on a dk there are tweaks necessary to be done at driver level.
<igiona[m]>
Maybe there is a guide on probe-rs, I don't recall to be jones
<igiona[m]>
* On Windows (maybe also Linux, don't know), in order to use jlink on a dk there are tweaks necessary to be done at driver level.
<igiona[m]>
Maybe there is a guide on probe-rs, I don't recall to be honest
<diondokter[m]>
igiona[m]: You can just use zadig for that. But if that's needed probe-rs will now also print that
<igiona[m]>
* On Windows (maybe also Linux, don't know), in order to use jlink with probe-rs on a dk there are tweaks necessary to be done at driver level.
<igiona[m]>
Maybe there is a guide on probe-rs, I don't recall to be honest
<drahnr[m]>
JamesMunns[m]: These all align and I can see the JLink being powered on the oszilloscope
<drahnr[m]>
JamesMunns[m]: The cables used work fine with the BMP or flashing the bootloader of some bluefruit feathers with nrf52832 using the the adafruit nrfutil tool
<dirbaio[m]>
Is it async all the way down to async i2c?
<diondokter[m]>
Yeah
<diondokter[m]>
Spi
<dirbaio[m]>
Ah, anyway
<diondokter[m]>
It goes through some layers to get there, but when non-async that all just optimizes away. So I'm wondering why that doesn't happen...
<dirbaio[m]>
Yeah async i2c/spi have some code size overhead vs blocking, but 1.3kb seems a lot
<diondokter[m]>
Yeah looking into it now
<diondokter[m]>
But there are barely any tools that help afaik
<dirbaio[m]>
Do you have any generics that could cause some code to get compiled multiple times with different params?
<diondokter[m]>
Yeah an FnOnce for each operation, but I've already ruled that out by playing with it
<diondokter[m]>
No others really, I've tried to keep them out and use runtime values
<dirbaio[m]>
Another gotcha to watch out for is async fn foo() { bar().await } isn't zero cost
<dirbaio[m]>
(yes it's stupid)
<diondokter[m]>
Yeah... I might just be things like that adding up.
<diondokter[m]>
There's nothing exactly that, but there's definitely multiple layers
<dirbaio[m]>
This is zero cost: `fn foo() -> impl Future { bar() } `
<diondokter[m]>
s/I/It/
<dirbaio[m]>
Anyway if you're using spi, async is not worth it usually.
<diondokter[m]>
Meh... well maybe :P
<diondokter[m]>
I should try remove some async to actually see the difference
<dirbaio[m]>
If you do small register accesses of say, 2 bytes, at 8mhz it takes 2us
<diondokter[m]>
It's for a radio though, so when you receive or send a 1000 byte packet...
<dirbaio[m]>
An async context switch is ~100 cycles, at 100mhz it's 1us
<diondokter[m]>
I guess
<dirbaio[m]>
And to take advantage of it you need 2 context switches (one to another task, and one back), so 2us
<dirbaio[m]>
Its about even ;D
<dirbaio[m]>
With worse code size
<diondokter[m]>
:P
<diondokter[m]>
Yeah maybe I should reevaluate
<dirbaio[m]>
You can try mixing blocking for tiny register access, async for the big packet transfers
<diondokter[m]>
True, but then you need a spi that can do both at the same time... Which is every embassy spi I guess.
crabbedhaloablut has quit []
<dirbaio[m]>
Yeah its supported precisely for this use case
crabbedhaloablut has joined #rust-embedded
<diondokter[m]>
Most is done around irq waiting anyways, so I might just go that route
<diondokter[m]>
Keep just that part async or only the large spi transactions too
<dirbaio[m]>
For i2c the tradeoff is less obvious because i2c is slow as hell... At work I've ended up using only blocking i2c because we're flash-starved :( even though it's probably hurting perf/power.
<diondokter[m]>
Yeah I get that. Sometimes like in my case now async gives unreasonably large code.
<diondokter[m]>
If it was 'just' double, ok fine
<diondokter[m]>
Maybe I should look into the compiler for how this is done...
<diondokter[m]>
But probably that code will fly over my head with my current compiler knowledge haha
<diondokter[m]>
Maybe nerdsnipe a colleague like Folkert or Björn :P
danielb[m] has joined #rust-embedded
<danielb[m]>
dirbaio[m]: and that's where you add an interrupt executor in for literally everything else :D
<dirbaio[m]>
diondokter[m]: > <@diondokter:matrix.org> Yeah I get that. Sometimes like in my case now async gives unreasonably large code.
<dirbaio[m]>
> If it was 'just' double, ok fine
<dirbaio[m]>
Oh yeah theres *a lot* of room for improvement in the compiler around async
<dirbaio[m]>
It's basically doing zero optimizations before converting to state machine, and after that there's many things the optimizer can't do anymore.
<diondokter[m]>
That's already done in in/before mir right?
tiwalun[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
<diondokter[m]> "You can just use zadig for that...." <- for the nRF52840-DK's on-board J-Link: on Linux you need udev rules, on Windows you need zadig, and on macOS it just works.