<Max[m]>
<Max[m]> "but i do get this output of..." <- Noah: anything else i can do? would love to throw code at my board :)
pcs38 has joined #rust-embedded
sroemer has joined #rust-embedded
sroemer has quit [Ping timeout: 276 seconds]
sroemer has joined #rust-embedded
sroemer has quit [Quit: WeeChat 4.5.2]
rainingmessages has quit [Quit: bye]
rainingmessages has joined #rust-embedded
<jason-kairos[m]>
Is there anyplace I can learn about setting up rust language server (or any tool / ide / etc.) to make it play nice with rust workspaces that use custom build tools?
<jason-kairos[m]>
(Hubris OS in this case uses a custom builder it calls xtask, and cross compiles, and autogenerates a lot of code in build.rs scripts)
<jason-kairos[m]>
* build.rs scripts, huge workspace project with 100+ local crates)
<jason-kairos[m]>
We do not use cargo build or cargo run directly because they are too inflexible for our purposes. We have a complex multi-architecture build, which is a bit beyond them.
<jason-kairos[m]>
Instead, the repo includes a Cargo extension called xtask that namespaces our custom build commands.
<jason-kairos[m]>
occasionally, VSCode does
<jason-kairos[m]>
Oh, I guess it's rust-analyzer now?
<jason-kairos[m]>
this looks more complicated to set up than I'd like
mkj[m] has quit [Quit: Idle timeout reached: 172800s]
chrysn[m] has quit [Quit: Idle timeout reached: 172800s]
<Max[m]>
has anyone experience in running rust on an stm32mp1 cortex A7 board? i mean baremetal, not ontop of linux with mmu etc..
<sourcebox[m]>
I have an ongoing project using the MP1 but it's currently on hiatus until the customer is finished with some essential steps.
<sourcebox[m]>
s/is/has/, s/with//
pcs38 has quit [Quit: leaving]
hjeldin__[m] has joined #rust-embedded
<hjeldin__[m]>
hey all, i'm having a hard time debugging uart issues between an stm32 and a rpico 2 w.
<hjeldin__[m]>
the two devices's peri are configured the same, but while my stm board receives data without issue, the rpico panics with an overrun error. this is consistent between methods (read, read_exact, blocking_read), peripheral type (BufferedUart, Uart (both blocking and not)) and even across soft resets (meaning that once the first overrun is thrown if i flash a new version of the firmware it immediately throws another overrun error).
<hjeldin__[m]>
there must be something dumb i'm doing but the code is so small i'm starting to thing it's something electrical
<hjeldin__[m]>
i guess my question is: is there something fucky going on with the rpi uart hal? i might try using the rpi debug probe to read/write to the pico uart, so that would exclude the stm32 board as a possible culprit
RobertJrdens[m] has quit [Quit: Idle timeout reached: 172800s]
<jason-kairos[m]>
(this is common for serial communications, message passing, etc. on embedded)
<hjeldin__[m]>
<hjeldin__[m]> "i guess my question is: is there..." <- no error, but no data either. just a stream of 0xff
KevinPFleming[m] has joined #rust-embedded
<KevinPFleming[m]>
<jason-kairos[m]> "is there a good way to copy as..." <- I tried using 'slice' library functions in my project on thumbv6m, but they ended generating much larger object code than a simple for-loop.
<KevinPFleming[m]>
* they ended up generating much
<jason-kairos[m]>
KevinPFleming[m]: Yeah... you're right. Iterators and bounds checking don't really seem to optimize away like they
<jason-kairos[m]>
* like they the advertised to do
<KevinPFleming[m]>
jason-kairos[m]: They do on amd64, and probably on other platforms, but not on thumbv6m or thumbv7m in the testing I did.
<jason-kairos[m]>
* seem to (meaningfully) optimize away, * like they the advertised to do in most situations
<jason-kairos[m]>
KevinPFleming[m]: Why is this the case? lack of attention I'd guess
<KevinPFleming[m]>
jason-kairos[m]: I did not have time to dive into it, since the workaround was very simple :_)
<KevinPFleming[m]>
s/:_/:-/
<jason-kairos[m]>
* seem to (meaningfully) optimize away, * like they were advertised to do in most situations
bitts[m] has joined #rust-embedded
<bitts[m]>
<KevinPFleming[m]> "I tried using 'slice' library..." <- Compiling with --release makes a huge difference, but you're probably doing that...
<KevinPFleming[m]>
bitts[m]: Yes, maximum optimization is enabled.
pcs38 has joined #rust-embedded
BentoMon has quit [Ping timeout: 252 seconds]
WSalmon has quit [Quit: No Ping reply in 210 seconds.]
kevlan[m] has quit [Quit: Idle timeout reached: 172800s]
WSalmon has joined #rust-embedded
LeandroMarceddu[ has quit [Quit: Idle timeout reached: 172800s]
DanielakaCyReVol has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
I haven't been very good at doing CHANGELOG updates so please let me know if i missed anything major
BentoMon has joined #rust-embedded
Mihael[m] has joined #rust-embedded
<Mihael[m]>
Is it common to "make up for" stuff you can't achieve with physical limitations.
<Mihael[m]>
Such as: having a rotary encoder be able to do 1 rotation = 1 action, due to limitations to compensate for that in code using with a "on x changes, i'll register '1 action'"
<JamesMunns[m]>
I'm not sure I totally understand the question?
<JamesMunns[m]>
you mean like, there's no way to ask the hardware to notify you after 4 pulses, so you have to do a stepdown counter in software to count to 4 before you actually trigger the next action?
<JamesMunns[m]>
if that's it: there IS sometimes ways to do that, most timer/pwm peripherals allow for interrupts after a certain number of pulses have been reached
<JamesMunns[m]>
but in cases where that isn't true, like if your chip doesn't support it, then yes, it is very common to "fix it in software" instead of changing to a bigger/different chip
<Mihael[m]>
JamesMunns[m]: for example i'm working on that thermostat right, i have a rotary encoder like this one
<JamesMunns[m]>
I think on esp32 you can map most peripherals to any pins?
<JamesMunns[m]>
(other than very high speed SPI?)
<JamesMunns[m]>
not sure exactly how to use it, or how complete the drivers are, might be worth asking folks in the esp-rs room tho!
<Mihael[m]>
yeah fair point
<Mihael[m]>
thanks man
<JamesMunns[m]>
in general, if the hardware CAN handle it for you, like this, its usually a good idea! digital logic makes it easier to avoid potentially missing pulses
DominicFischer[m has joined #rust-embedded
<DominicFischer[m>
The PCNT drivers are good enough for quadrature encoders at least.
<DominicFischer[m>
You can also do the "interrupt every 4 pulses" thing
pcs38 has quit [Quit: leaving]
<DominicFischer[m>
You're limited to 80MHz of course
<DominicFischer[m>
It can also do noise filtering if you need it
<Mihael[m]>
i think only superman could spin it faster than that
<JamesMunns[m]>
<DominicFischer[m> "You're limited to 80MHz of..." <- 1.6 BILLION RPM, for the record
cbjamo[m] has joined #rust-embedded
<cbjamo[m]>
I want to build something that needs a faster encoder than that.
<cbjamo[m]>
I'm not sure that's actually possible, but a man can dream.
<JamesMunns[m]>
well, I googled the fastest rotating thing in the world, apparently some university got a nanoparticle to spin at 300 billion rpm
<JamesMunns[m]>
dunno how you'd hook it up to a rotary encoder tho
<cbjamo[m]>
A 1cm cylinder spinning at 1.6 billion rpm has a surface speed ~1.6 times the escape velocity of the milky way.
<JamesMunns[m]>
lol
Mathias[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
seems todays fastest motors hit <= 1M rpm or so
<cbjamo[m]>
so we just need one of those and a 1000-1 gearbox, easy.
<JamesMunns[m]>
I'm starting to think researchers just like making things spinning really really fast
<JamesMunns[m]>
s/spinning/spin/
<i509vcb[m]>
I really doubt there exists the equipment to test a quadrature encoder at 1 billion rpm lol
<JamesMunns[m]>
lol at that point you're probably just using a laser tach or something?
<cbjamo[m]>
Holding a gyroscope is fun, so if we could spin it faster that'd be more fun, right?
<adamgreig[m]>
i don't think much would survive being spun at 1Brpms
<adamgreig[m]>
man, yea, the forces on even a tiny tiny cylinder would absolutely shred it
<JamesMunns[m]>
lol the fact that I've seen the typing indicator start and stop makes me think that you've been sitting there doing calculations for the last 8 minutes on exactly how much force or linear speed that would be
<Mihael[m]>
i forgot i can just like stack gears lmao
<Mihael[m]>
transfer with an additional gear
<Mihael[m]>
goddamn sometimes i dont deserve brain
<Mihael[m]>
s
<JamesMunns[m]>
btw, note that the encoder is only rated for 70000 cycles (I assume full rotations?), and the bouncing is rated at 5ms, which means you probably shouldn't more than 200 pulses per second or so
<JamesMunns[m]>
I guess at 1:24, that's still 8.3 rotations per second of the big wheel, which is still a lot
<adamgreig[m]>
the numbers got too big to really make sense
<adamgreig[m]>
but yes 😅
<JamesMunns[m]>
:D
<adamgreig[m]>
if you had a picogram glued on the outside of a 1cm cylinder spinning at 1Brpm the force trying to pull it off would be also enough to launch a rocket to orbit
<JamesMunns[m]>
apparently enough to escape the milky way galaxy as well
<adamgreig[m]>
I think it's actually 31 times the milky way escape velocity, but that's not so fast really
<JamesMunns[m]>
lol
<adamgreig[m]>
10% of the speed of light...
<adamgreig[m]>
that does suggest an obvious limit actually
<JamesMunns[m]>
when you have to consider relativistic effects in your force diagram, things have gone a bit sideways
<adamgreig[m]>
a 10cm cylinder doing 1Brpm would be illegal
<adamgreig[m]>
ah, no, my bad, that's Hz not rpm
<adamgreig[m]>
you actually need a 6m diameter cylinder to be illegal!
<adamgreig[m]>
not so bad
<Mihael[m]>
<JamesMunns[m]> "I guess at 1:24, that's still 8...." <- it'll be used for regulating temperature on a thermostat
<Mihael[m]>
if anyone will be rotating it to the point of doing that many rotations
<Mihael[m]>
i can't really do much about it
bartmassey[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
Yeah, the 70k lifetime is more interesting, since you are doing 24x more rotations
JamesSizeland[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
But still, yeah, people probably aren't going to fidget toy their thermostat
<Mihael[m]>
<JamesMunns[m]> "Yeah, the 70k lifetime is more..." <- i did check some other mechanical encoders, some have 30k