<re_irc> <@dirbaio:matrix.org> yeah... it is
<re_irc> <@oddstr13:matrix.org> welp, code builds, better get wireshark up and running
<re_irc> <@dirbaio:matrix.org> I can't get a repro of code requiring the `&*` in the playground 🀣
<re_irc> <@dirbaio:matrix.org> I've definitely seen it before
<re_irc> <@dirbaio:matrix.org> always something to do with `&'static mut`
<re_irc> <@dirbaio:matrix.org> but I don't fully understand why it happens
<re_irc> <@oddstr13:matrix.org> welp, dongle crashed, time to move it over to the dk I guess xD
<re_irc> <@oddstr13:matrix.org> this is where something arduino-like stuff would help
<re_irc> <@dirbaio:matrix.org> nrf52xx-dk + probe-run + defmt is quite seamless :P
<re_irc> <@dirbaio:matrix.org> you get logs and stacktrace on crash and everything
<re_irc> <@dirbaio:matrix.org> it's so weird
<re_irc> <@dirbaio:matrix.org> it's due to the double borrow
<re_irc> <@dirbaio:matrix.org> `thing` is `&'static mut u32`, so `&thing` is `&&'static mut u32`
<re_irc> <@dirbaio:matrix.org> which the function call coerces to `&'static u32`
<re_irc> <@dirbaio:matrix.org> and I have absolutely zero idea why, but that makes the borrow checker explode
<re_irc> <@dirbaio:matrix.org> if you do `bar(thing)` then it works as expected
<re_irc> <@dirbaio:matrix.org> so Oddstr13 that's a better fix for your code, change `&clocks` to `clocks`
<re_irc> <@oddstr13:matrix.org> dirbaio:matrix.org: yep, I'm aware, it's just that I've got only one dk :P
<re_irc> <@dirbaio:matrix.org> ahhhhh :(
<re_irc> <@oddstr13:matrix.org> I did grab a couple of debug probes along with the particle boards tho, so I guess I could use those too
<re_irc> <@oddstr13:matrix.org> haven't tried hooking up a debug probe to the usb dongles yet
GenTooMan has joined #rust-embedded
<re_irc> <@oddstr13:matrix.org> well, that's no good, the iee802154 thing in smoltcp panics if received packet is "garbage"
<re_irc> <@oddstr13:matrix.org> triggered by another dongle transmitting `Hello, World!`
<re_irc> <@dirbaio:matrix.org> probably part of the WIPness :S
<re_irc> <@dirbaio:matrix.org> panics on incoming garbage shouldn't happen yup
<re_irc> <@oddstr13:matrix.org> hehe
fabic_ has joined #rust-embedded
<re_irc> <@oddstr13:matrix.org> dirbaio: seems I'm never hitting TxToken consume, any idea why that might be?
fabic_ has quit [Remote host closed the connection]
<re_irc> <@dirbaio:matrix.org> maybe because it isn't trying to tx anything..?
fabic has joined #rust-embedded
<re_irc> <@dirbaio:matrix.org> if you're using defmt, you can enable features defmt + defmt-trace to see more stuff
<re_irc> <@dirbaio:matrix.org> is it hitting Device::transmit?
<re_irc> <@dirbaio:matrix.org> it is normal for the TxToken from Device::receive to go unused, smoltcp will only use it if it wants to transmit a response to the just-received packet
<re_irc> <@dirbaio:matrix.org> it's rarer for the TxToken from Device::transmit to go unused, smoltcp will only call Device::transmit when it actually wants to transmit something
<re_irc> <@oddstr13:matrix.org> I'll have a look at the trace stuff, but I know it's hitting this block;
<re_irc> <@oddstr13:matrix.org> conveniently only had to bump loglevel to trace :P
<re_irc> <@oddstr13:matrix.org> Well, that's fun
<re_irc> <@oddstr13:matrix.org> multicast addresses are even more fun, lol
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
<re_irc> <@oddstr13:matrix.org> alright, *now* we're talinkg!
<re_irc> <@dirbaio:matrix.org> Oh boi
<re_irc> <@oddstr13:matrix.org> hey, baby steps, okay? 🀣
<re_irc> <@oddstr13:matrix.org> actually, I wonder what type Frame.buffer is…
<re_irc> <@oddstr13:matrix.org> ah, that would probably be my ieee802154::Packet, whoops
dcz_ has joined #rust-embedded
<re_irc> <@cryptollision:matrix.org> m
<re_irc> <@cryptollision:matrix.org> ol
emerent has quit [Ping timeout: 252 seconds]
emerent has joined #rust-embedded
PyroPeter has quit [Ping timeout: 252 seconds]
GenTooMan has quit [Ping timeout: 265 seconds]
PyroPeter has joined #rust-embedded
GenTooMan has joined #rust-embedded
<re_irc> <@oddstr13:matrix.org> dirbaio: I'm getting two bytes cut off at the end on udp rx it seems, but other than that it looks like it's working! πŸŽ‰
<re_irc> <@oddstr13:matrix.org> Still need to figure out how neighbor discovery is *supposed* to work tho, I was having trouble with the manually set one timing out from cache too quickly πŸ˜†
DepthDeluxe has quit [Read error: Connection reset by peer]
Ekho has quit [*.net *.split]
Ekho has joined #rust-embedded
inara has quit [*.net *.split]
mrkajetanp has quit [*.net *.split]
dkm has quit [*.net *.split]
vancz has quit [*.net *.split]
dkm_ has joined #rust-embedded
vancz has joined #rust-embedded
inara has joined #rust-embedded
mrkajetanp has joined #rust-embedded
DepthDeluxe has joined #rust-embedded
dcz has joined #rust-embedded
dcz_ has quit [Ping timeout: 265 seconds]
dkm_ is now known as dkm
<re_irc> <@ildar:matrix.org> greetings! a newbie question here...
<re_irc> <@ildar:matrix.org> https://defuse.ca/b/8MurBZUNlCgGkGfizcUId2
<re_irc> <@ildar:matrix.org> is there no easier way to read GPIO then `replace`-ing the cell back and forth?
<re_irc> <@grantm11235:matrix.org> Can you replace the `RefCell<Option<Pin<Input<Floating>>>>` with just `Pin<Input<Floating>>` or `&Pin<Input<Floating>>`?
<re_irc> <@ildar:matrix.org> hmm. I tried `&` and it brings a lot of problems with the lifetime
<re_irc> <@ildar:matrix.org> RefCell allows me to use its contents (pin) while having multiple immutable refs to the outer struct.
<re_irc> <@ildar:matrix.org> so the question is: how good GPIO APIs with RefCell pattern? It is promoted in the Book but in practice I need to `replace()` it back and forth
DepthDeluxe has quit [Ping timeout: 268 seconds]
<re_irc> <@grantm11235:matrix.org> I'm not sure why you would need a RefCell for a GPIO input, you can read the state with an immutable reference
<re_irc> <@ildar:matrix.org> hmm, indeed
<re_irc> <@ildar:matrix.org> ok, I'll think about it
<re_irc> <@ildar:matrix.org> thanks
<re_irc> <@grantm11235:matrix.org> It would make more sense for a GPIO output because that requires a mutable reference in order to use it.
gsalazar_ has joined #rust-embedded
gsalazar_ is now known as gsalazar
hifi has quit [Remote host closed the connection]
hifi has joined #rust-embedded
<Lumpio-> ildar: Why replace when you have borrow_mut?
<Lumpio-> Or even better if only that method needs access to it, arrange it so that others don't have any access ( ot even shared references)
<Lumpio-> not*
<re_irc> <@therealprof:matrix.org> The idea of replace is to move the pin from a global context to a local context to avoid having to disable interrupts all the time.
<re_irc> <@therealprof:matrix.org> As in: do it once, not go back and forth. πŸ˜‰
<re_irc> <@therealprof:matrix.org> Also the `borrow_mut` makes it somewhat convoluted to avoid having to `unwrap`.
karlp has left #rust-embedded [WeeChat 3.1]
Shell has quit [Quit: ZNC 1.8.2 - https://znc.in]
Shell has joined #rust-embedded
Shell has quit [Remote host closed the connection]
Shell has joined #rust-embedded
<re_irc> <@ildar:matrix.org> I tried to use refs and mut refs. This approach doesn't work since unwrapping the Option<Pin> requires owning.
fabic has quit [Ping timeout: 260 seconds]
creich has quit [Ping timeout: 245 seconds]
<re_irc> <@ildar:matrix.org> hmm, it seems `Option::as_ref()` can save the day
<re_irc> <@ildar:matrix.org> like this:
<re_irc> <@ildar:matrix.org> > let pin = context.input_pin.borrow();
<re_irc> <@ildar:matrix.org> > };
<re_irc> <@ildar:matrix.org> > pin.as_ref().unwrap()
<re_irc> <@ildar:matrix.org> > let the_pin = if pin.is_none() { return; } else {
<re_irc> <@ildar:matrix.org> πŸ€”
<re_irc> <@jamesmunns:matrix.org> let pin = if let Some(the_pin) = context.input_pin.borrow() {
<re_irc> <@jamesmunns:matrix.org> ```rust
<re_irc> <@jamesmunns:matrix.org> the_pin
<re_irc> <@jamesmunns:matrix.org> } else {
<Lumpio-> Sometimes I wish there was a shorthand for this exact syntax
<re_irc> <@korken89:matrix.org> I have an `unwrap_or_return!` macro for exactly this that I use a lot :)
<Lumpio-> heh
<re_irc> <@jamesmunns:matrix.org> Yeah, if I need that a lot, I usually make "inner" functions that return options/results
<re_irc> <@korken89:matrix.org> /// Unwraps an `Option` or returns the function.
<re_irc> <@korken89:matrix.org> ( $e:expr ) => {
<re_irc> <@korken89:matrix.org> macro_rules! unwrap_or_return {
<re_irc> <@korken89:matrix.org> match $e {
<re_irc> <@pmnxis:matrix.org> made PCB for rust
<Lumpio-> What does it do?
<re_irc> <@pmnxis:matrix.org> Special adapter for paper dispenser machine (such as a dollar).
<re_irc> <@pmnxis:matrix.org> I am using two types of the machine.
<re_irc> <@pmnxis:matrix.org> One is prallel GPIO communication model with 12V.
<re_irc> <@pmnxis:matrix.org> And another is serial (RS232) communication model with 24V.
<re_irc> <@pmnxis:matrix.org> But my previous product is designed to use serial(rs232) 24V model.
<re_irc> <@pmnxis:matrix.org> But by some reason, I need to use parallel-12v model. So making adapter for 24v-rs232 to 12v-parallel with rust as practice
<Lumpio-> Oh like a paper money dispenser, alright
<re_irc> <@mathias_koch:matrix.org> jamesmunns: Any chance you could give https://github.com/jamesmunns/bbqueue/pull/90 a look some time? I would love to do a round of releases, but can't with git patches in my dep tree
fabic has joined #rust-embedded
<re_irc> <@jamesmunns:matrix.org> MathiasKoch: ACK, I'll get this merged and released tonight.
<re_irc> <@mathias_koch:matrix.org> Awesome! Thank you very much! :)
DepthDeluxe has joined #rust-embedded
DepthDeluxe has quit [Ping timeout: 268 seconds]
DepthDeluxe has joined #rust-embedded
fabic has quit [Ping timeout: 268 seconds]
<re_irc> <@roedimqf:ruhr-uni-bochum.de> korken89:
DepthDeluxe has quit [Ping timeout: 268 seconds]
<re_irc> <@jamesmunns:matrix.org> MathiasKoch: released v0.5.0!
<re_irc> <@mathias_koch:matrix.org> Yaayy! πŸŽ‰πŸŽ‰ Thank you very much jamesmunns
<re_irc> <@jamesmunns:matrix.org> I did make a couple changes beyond the PR, namely:
<re_irc> <@jamesmunns:matrix.org> * Got rid of ConstBBBuffer entirely
<re_irc> <@jamesmunns:matrix.org> * Removed deprecated modules
<re_irc> <@jamesmunns:matrix.org> * Removed deprecated items
<re_irc> <@mathias_koch:matrix.org> No issues here πŸ‘
<re_irc> <@mathias_koch:matrix.org> Thanks for a great library πŸ‘Œ
edm has quit []
edm has joined #rust-embedded
dreamcat4 has quit []
dreamcat4 has joined #rust-embedded
darknighte has quit []
darknighte has joined #rust-embedded
GenTooMan has quit [Ping timeout: 260 seconds]
dcz has quit [Ping timeout: 268 seconds]
<re_irc> <@osannolik:matrix.org> Beginner question here! What is the best way to allow changing an output pin to an input dito (and the reverse) using the embedded-hal crates? For example, using stm32l0xx-hal, I run into issues due to e.g. into_floating_input() consumes the variable holding the pin. It becomes difficult to keep it in another struct. I managed to hack together something that kind of works by wrapping it in an enum, but it's..
<re_irc> <@dirbaio:matrix.org> Yeah the enum is the way to go, unfortunately
<re_irc> <@dirbaio:matrix.org> you can
<re_irc> <@dirbaio:matrix.org> ```rust
<re_irc> <@dirbaio:matrix.org> Temp,
<re_irc> <@dirbaio:matrix.org> enum IoPin {
<re_irc> <@dirbaio:matrix.org> AsOutput(gpioa::PA8<Output<PushPull>>>,
<re_irc> <@osannolik:matrix.org> I see, thank you. I ran into the same issue a couple of years ago and made a PR to embedded-hal for a Tristate trait adding Floating as a pin state. As of then I have not been doing much rust, but since not much happened to the PR I assumed there already was a simple solution...
<re_irc> <@xiretza:xiretza.xyz> which HAL are you using?
SanchayanMaity has quit []
SanchayanMaity has joined #rust-embedded
<re_irc> <@osannolik:matrix.org> I'm using stm32l0xx-hal right now.
<re_irc> <@osannolik:matrix.org> 0.7.0
<re_irc> <@xiretza:xiretza.xyz> yeah, that one doesn't seem to have dynamic pins - unlike e.g. `stm32f1xx_hal`: https://docs.rs/stm32f1xx-hal/0.7.0/stm32f1xx_hal/gpio/gpioa/struct.PA0.html#method.into_dynamic
gsalazar has quit [Remote host closed the connection]
gsalazar has joined #rust-embedded
<re_irc> <@osannolik:matrix.org> Interesting, that's pretty much what I was looking for. I might try to suggest something similar for stm32l0xx.
<re_irc> <@firefrommoonlight:matrix.org> On stm32-hal, you run `pin.mode(PinMode::Input)`
GenTooMan has joined #rust-embedded
emerent has quit [Ping timeout: 252 seconds]
emerent has joined #rust-embedded