Guest7282 has left #rust-embedded [Error from remote client]
Guest7282 has joined #rust-embedded
Guest7282 has left #rust-embedded [Error from remote client]
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
emerent has quit [Ping timeout: 260 seconds]
emerent has joined #rust-embedded
jbeaurivage[m] has joined #rust-embedded
<jbeaurivage[m]>
Hi people, I made a little crate to help trace+debug async tasks for #![no_std] projects. For example, but not limited to, flipping a GPIO pin when entering, exiting or polling a Future. Check it out if it's interesting to you: https://github.com/jbeaurivage/embedded-trace
crabbedhaloablut has joined #rust-embedded
<Farooq>
<xiretza[cis]> "not that it's really related..." <- could we have an offtopic room for such these stuff?
<Farooq>
Thank you folks for the advices
<Farooq>
<diondokter[m]> "SMT-Through-Hole-Soldering.jpg" <- this is really nice
<maxtech[m]>
A hair too much solder, and the shape of the blobs makes me think the iron might still be a bit cold for the solder you're using. Definitely progress though!
Guest7282 has joined #rust-embedded
FreeKill[m] has joined #rust-embedded
<FreeKill[m]>
Also looks like not enough flux
<FreeKill[m]>
Potentially
<Lumpio->
And don't forget to tin your tip (add a small amount of solder to it every time you clean it). Otherwise it won't make good contact with anything.
<Lumpio->
(Metal to metal point contact isn't the best at transferring heat)
<Henk[m]>
Noah[m]1: Well, embassy is doing the read call here, so I'm jsut assuming it's correct?
Lumpio[m] has joined #rust-embedded
<Lumpio[m]>
<Noah[m]1> "Lumpio is back 🤗" <- I never left afaict 🤔
<Henk[m]>
Henk[m]: Note that the application runs correctly on the device itself
<Noah[m]1>
Lumpio[m]: I didn't see you in a long while also on GH :) That's why I'm happy :)
<Noah[m]1>
But then again, not everyone is spamming as much as me :P
<dirbaio[m]>
Henk[m]: wut
<Noah[m]1>
dirbaio[m]: Hmm
<dirbaio[m]>
Noah[m]1: are you proxying at the level of registers? , like, every single register read/write?
<Henk[m]>
dirbaio[m]: Yes, I've forked `vcell` and patched it a teeny bit
<dirbaio[m]>
Henk[m]: stm32-metapac doesn't use vcell
<Henk[m]>
dirbaio[m]: Ah yes and I also patched metapac
<Henk[m]>
Henk[m]: So no segfaults anymore
<dirbaio[m]>
Henk[m]: fun
<Henk[m]>
dirbaio[m]: Well, it was awesome to see the previous implementation actually work
<dirbaio[m]>
Henk[m]: make sure you're doing the memory accesses with the right size. ie a 32bit register read should be a 32bit read, not 4x 8bit reads
<dirbaio[m]>
dirbaio[m]: make sure you're resetting the chip, embassy-stm32 assumes the rcc is in reset state. a `reset_and_halt` should do it
<Farooq>
Is it okay that I am posting these pictures here and asking for comments?
<JamesMunns[m]>
Usually to avoid over heating the pads, I'll make two passes when soldering pin headers, a first pass to just get enough solder on, but maybe not make a perfect joint. Then I come back and tap it one more time like I described with the iron to make sure it is totally flowed and it looks like all the "good solder joint" pictures we shared
<JamesMunns[m]>
Farooq: I don't mind, I think it's vaguely relevant, you're not bothering me :)
<Farooq>
Thank you so much
<Farooq>
It's nice to have such a room :)
<JamesMunns[m]>
Others have mentioned "not enough flux", and I agree, the solder looks a little chunky. Definitely make sure the solder you have says it's "rosin core" or mentions flux, or if you clip it, you can see that the solder wire has what looks like a gel center, that's flux.
<JamesMunns[m]>
However the flux cooks off the longer you heat it, which is why you want to work decently quickly, only or or two sends of heat total per pad. If you heat it too long, or tap it too many times, the flux "cooks off", leaving you with solder that doesn't flow as well.
<JamesMunns[m]>
s/sends/seconds/
<JamesMunns[m]>
that's also why you add solder directly to the pad, instead of like melting it on your iron and then touching it to the pads to "apply" it: you don't want to cook off all the flux before you have a good solder joint.
<vollbrecht[m]>
well i think they are there two Lumpio's here or is it just my lag of coffee? :D
<FreeKill[m]>
<JamesMunns[m]> "Others have mentioned "not..." <- > <@jamesmunns:beeper.com> Others have mentioned "not enough flux", and I agree, the solder looks a little chunky. Definitely make sure the solder you have says it's "rosin core" or mentions flux, or if you clip it, you can see that the solder wire has what... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/RVgItzftKkkkvrGOhyfhmaGj>)
<JamesMunns[m]>
Yeah, definitely practice limiting your time on each pad. If it takes MUCH longer than a second to get the pad to melt, your iron isn't hot enough. If it melts and starts burning in less than a second, your iron is probably too hot. (this is for normal pads, there are some exceptions like soldering to big ground planes)
<JamesMunns[m]>
I dunno if there's a more precise timing, but "one-one-thousand" feel like how long I usually touch the iron to a pad, but you get a feel for it by watching the solder flow, more than any specific time
<FreeKill[m]>
Also also as a general bit of advice: melt your solder against the pin or the pad, not the iron.
<FreeKill[m]>
If you touch the solder to the iron it will melt even if the pad hasn't heated yet. If you wait until the pad itself melts it, you know it's ready! This also works for thermally "heavy" pins, like grounds :)
<JamesMunns[m]>
Then you usually adjust your iron temp to match the right "rhythm" for soldering.
<JamesMunns[m]>
Yesterday I suggested even heating the pad a bit first, then solder, then push against pin+pad. Esp for those header pins with plastic, I like keeping heat on them as little as possible to keep the pins from melting the plastic, even a little bit which can cause the pin to shift in the plastic header
<FreeKill[m]>
Yep melting the shroud is very irritating
<FreeKill[m]>
But you need a hot air gun to really annihilate your headers at a professional speed
<JamesMunns[m]>
I have a hot air station, but I feel like I've done more damage than help with it. That being said, it's really handy for hot glue and shrink tubing :p
<FreeKill[m]>
Also pulling up large packages, QFNs efc, is so painful without hot air
<FreeKill[m]>
(or a heat plate)
<JamesMunns[m]>
it is very helpful for getting clean hot-melt glue blobs if you want them for strain relief or holding down a bodge. I cut off a bit of a glue stick with an exacto knife, lay the slice where I want it, then breeze it with hot air in a couple passes and it makes a clean blob with no stringies
<FreeKill[m]>
Also also if you're doing hot air rework near plastic parts, polyamide tape pretty much perfectly saves them
<JamesMunns[m]>
or even a bit of tin foil, honestly
<FreeKill[m]>
Yep! I've built little tin tents to protect relays before 😁
<JamesMunns[m]>
Tho if you use hot air on glue, let it sit LONGER than you think! It'll look solid, the you flip the board or touch it, and surprise, still molten in the center!
<JamesMunns[m]>
I did that once, flipped the board over, then came back like two minutes later and realized the board was glued to my desk lol
<FreeKill[m]>
That's the ooey gooey delicious centre
SanchayanMaity_ has joined #rust-embedded
SanchayanMaity_ has quit [Client Quit]
<therealprof[m]>
<JamesMunns[m]> "it is very helpful for getting..." <- I prefer UV curing glue nowadays... Place a drop, illuminate for a few seconds with a UV LED keychain light and presto.
<JamesMunns[m]>
Yeah, hot melt is Not Great for a lot of reasons
<Lumpio->
Provessional hot snot (TM)
dngrsspookyvisio has joined #rust-embedded
<dngrsspookyvisio>
What's awesome is that it comes clean off with IPA
lehmrob has quit [Ping timeout: 255 seconds]
<JamesMunns[m]>
What's less awesome is that after some time or thermal cycles, it'll come clean off by itself :D
<thejpster[m]>
Good grief. Guess how much for a Zynq UltraScale+ board, then click the link:
<ithinuel[m]>
thejpster[m]: I'd say about 500£ at least
<ithinuel[m]>
ithinuel[m]: Oumph ok
<ithinuel[m]>
ithinuel[m]: I didn't expect to be so wrong
<Jonathan[m]1>
<thejpster[m]> "Has anyone tried using an ARMv8..." <- I'm experimenting with that right now
<thejpster[m]>
Are you writing a custom target JSON file?
<Jonathan[m]1>
Specifically the Cortex-R5 on Zynq Ultrascale+/Versal
<thejpster[m]>
Oh, I think R5 is just ARMv7-R. That works already.
<Jonathan[m]1>
I'm using the armv7ar-none-eabi at the moment
<Jonathan[m]1>
R52 is 64 bits?
<thejpster[m]>
No, it is to Cortex-R5 what Cortex-M33 is to Cortex-M3 ... a newer generation of the architecture with more instructions. But pretty sure it's still Aarch32 execution mode with A32 and T32 instructions.
<Jonathan[m]1>
So aarch32 with no 64 bits support, yeah these are pretty different :)
<thejpster[m]>
Cortex-R82 is an ARMv8-R in Aarch64 mode with A64 instructions. It has no Aarch32 mode IIUC.
<thejpster[m]>
what might be nice is if Arm came along and wrote all this stuff. Then it would line up with how they understand their architectures work.
dicklessgreat[m] has joined #rust-embedded
<dicklessgreat[m]>
Hi, is there ws2812/sk6812 LED serial driver for pico(or bare metal)?
<dicklessgreat[m]>
I found some for `esp32` or for `rppal`, but none for `no_std`.
<dicklessgreat[m]>
JamesMunns[m]: OK, I'll check it out.
Guest7282 has joined #rust-embedded
Guest7282 has left #rust-embedded [Error from remote client]
dan_moore[m] has quit [Quit: Idle timeout reached: 172800s]
m3vict[m] has joined #rust-embedded
<m3vict[m]>
Hi all!
<m3vict[m]>
I am currently working on rewriting an Ethenet-PHY SPI device driver from C++ into Rust. I was wondering is there any way to make it generic, despite it using DMA to transfer and receive data via SPI bus? I've been reading different discussions about embedded-dma traits, but all of them were stale and outdated.
<dirbaio[m]>
embedded-hal-async traits are implementable with DMA
<dirbaio[m]>
(well, the embedded-hal blocking traits are also implementable with DMA, but it's a bit pointless to do so)
<m3vict[m]>
I looked it up on crates.io and seems like only esp32 hals depend on (implement) those traits.
<dirbaio[m]>
embassy implements the async traits for nrf, stm32, rp2040
<m3vict[m]>
So with hal-async it wouldn't be usable w/o modification on a RTIC+random hal setup? Embassy might actually be a nice approach, but I never used it before. The whole concept of async is kinda new to me, coming from “old school” embedded C interrupts handling (like before mentioned RTIC).
<dirbaio[m]>
it wouldn't support "any random HAL" though, the HAL has to have async support
<adamgreig[m]>
I think in principle you could use dma on the blocking traits implemented by an rtos with threading and it would make sense?
<adamgreig[m]>
Like how most similar apis in C rtos are "blocking" but your thread gets slept. Same deal on Linux I guess
<adamgreig[m]>
But for sure on a typical hal implementation there's not much point using dma for the blocking traits if you're just going to busy wait the CPU anyway
<dirbaio[m]>
currently only embassy and esp32 implement async that I know of. (iirc atsamd had some async stuff?)
<m3vict[m]>
<dirbaio[m]> "example project setup with..." <- That's a regular RTIC app w/o embassy executor, only using its hal. Do I understand it correctly?
<dirbaio[m]>
yep, nothing special
<m3vict[m]>
W/o being able to look at crate.io state I don't really know how popular are embassy-hals compared to others. Are they actually nice to use outside of embassy framework?
<vollbrecht[m]>
in no_std and esp-idf std hal's we are using embassy hal primitives as a direct dependency ( behind feature gates)
<vollbrecht[m]>
s/no_std/no\_std/, s/a//
<vollbrecht[m]>
if that's what your question is about, you can use them outside of the "framework" :D
<vollbrecht[m]>
* in no_std esp and esp-idf std hal's we are using embassy hal primitives as direct dependency ( behind feature gates)
GrantM11235[m] has quit [Quit: Idle timeout reached: 172800s]
Guest7282 has joined #rust-embedded
<m3vict[m]>
That was really helpful. I will look more into the hal-async and embassy. Thanks. 😎
PeterHansen[m] has quit [Quit: Idle timeout reached: 172800s]
K900 has quit [Quit: Idle timeout reached: 172800s]
sourcebox[m] has quit [Quit: Idle timeout reached: 172800s]
Mebus[m]1 has joined #rust-embedded
<Mebus[m]1>
Hi,
<Mebus[m]1>
I could run the ethernet example code from the embassy repo on my NUCLEO-HT745Zi-Q board successfully the first time, but now that I reconnected the board, it doesn't want to run again. Does sb. have a tip why? I didn't make any changes to the code.
<dirbaio[m]>
it ight be the "power SMPS soft brick" 🥲
<Mebus[m]1>
and it compiles. Still need to unbrick the board.
<Mebus[m]1>
😃😃😃 It's alive!
<Mebus[m]1>
Thanks!
<barnabyw[m]>
this is probably a “rust noob” question rather than an embedded specific question, but it’s in an embedded project. in this code https://gist.github.com/barnabywalters/3a876f6d9c41f3150df45a9e4cb3299e I have `let mut sensor_values = [0_i16; 28];` which I’m splitting up into 7-item long chunks with `split_array_mut`, and passing each chunk as `&mut` to an async function, which reads some sensors and fills the values in.
<barnabyw[m]>
This all works fine, but once the sensor reads are over, the borrow checker doesn’t let me access the original `sensor_values` because it was borrowed as mutable when I passed the chunks of it to the sensor reading functions
<barnabyw[m]>
afaik it should be safe to read the values at this point. is there a way to tell the borrow checker this? or do I need to use some unsafe to reconstruct the array from pointers, or just find a different way of getting the values out (e.g. returning them from the functions and putting them all back together into one big array)
<adamgreig[m]>
Try splitting it up inside the loop
<adamgreig[m]>
The problem is you reuse the mutable refs the next go around the loop, so they're still live and preventing access to the underlying array
<JamesMunns[m]>
err, but also do the "print sensor_values" after the match too
<JamesMunns[m]>
ah, no
<JamesMunns[m]>
nevermind, adam is totally right
Auri[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
Why does link.x.in provide _stext and __stext? And why does it force .text to start at _stext, which is calculated to be the end of the .vector_table section? Asking for a friend who really wants something to be somewhere in the first 4K of flash.
<thejpster[m]>
I could stuff it in .Reset (eww) but there's a real chance that with inlining, the reset function + the vector table ends up being more than 4K.
jamwaffles[m] has quit [Quit: Idle timeout reached: 172800s]
<M9names[m]>
<ithinuel[m]> "I didn't expect to be so wrong..." <- my guess was 50% too high. guess I know too much :P
notgull has quit [Ping timeout: 264 seconds]
notgull has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
kpcyrd[m] has joined #rust-embedded
<kpcyrd[m]>
I'm trying to do interrupts for the first time, I managed to get the interrupt handler to execute and toggle an LED, but instead of doing that I want to pass this event back into my main loop. Would I also use critical_section::Mutex for this?