<JamesMunns[m]>
(it's basically what I did for poststation devices too)
<Noah[m]>
but I have a a more pressing question actually wrt smoltcp ^^ I run into a `failed to parse deploymant target specified in MACOSX_DEPLOYMENT_TARGET` even when I build for thumbv7. It only happens when I enable mediums or sockets.
<Noah[m]>
Trying to find some docs but seemingly I do the same as examples and this still happens. I have never seen that one before :D
<Noah[m]>
I also get that errormessage when I just run `rustc -v` I realize now. I have no clue what's up. It builds fine with smoltcp features disabled.
<whitequark[cis]>
that sounds like a cargo issue somehow
<whitequark[cis]>
it probably enables a tap phy
<whitequark[cis]>
try disabling that if you can
<Noah[m]>
JamesMunns[m]: I am! Thanks! I am mostly catching up on where the ecosystem went in the many years I did not do embedded :D
<Noah[m]>
whitequark[cis]: ok thanks, lemme check!
<JamesMunns[m]>
Are you in a workspace, btw @Noah ?
<Noah[m]>
JamesMunns[m]: yeah :/
<Noah[m]>
I dread what will follow after this question :D
<JamesMunns[m]>
You're gunna have a bad time if you try to workspace a std target and a no std target together
<JamesMunns[m]>
or really, different targets in general together
<JamesMunns[m]>
I highly recommend one workspace per target, and just use path deps between them
<Noah[m]>
i mostly use a workspace because of an xtask :/
<JamesMunns[m]>
Even the newer resolver is just Not Good at only enabling the features for the given target that you care about
<JamesMunns[m]>
it's going to merge the features together and give you weird things, and not handle target selection right.
<JamesMunns[m]>
yeah, it's a bummer, and there's definitely some "well you could try setting this and arranging it like this or try this unstable feature...", but IMO it's just not worth it to try and handle multiple different targets in the same workspace. My $0.02 is "just don't".
fstracke has joined #rust-embedded
<Noah[m]>
Yeah totally fair
<Noah[m]>
moving out of a workspace did not fix it though :(
<JamesMunns[m]>
What does cargo tree -e features -i smoltcp show in the project?
<JamesMunns[m]>
(and is something enabling some tap phy feature?)
<Noah[m]>
the same error message
<Noah[m]>
wait, something is severely messed up now lol
<JamesMunns[m]>
do you have a .cargo/config.toml in some folder in the paths above your project?
<JamesMunns[m]>
particularly one that is setting some target or native library?
<JamesMunns[m]>
or do you have some goofy env vars set?
<JamesMunns[m]>
(does env on the terminal print something weird?)
TomB[m] has quit [Quit: Idle timeout reached: 172800s]
<Noah[m]>
OMG this is so dumb
<Noah[m]>
I trolled myself into this
<Noah[m]>
It's a nix problem
<Noah[m]>
And somehow I must have used two shells that then gave me contradicting results because one was working
<Noah[m]>
Thanks for helping me cure my own stupidity!
<JamesMunns[m]>
Oh no Nix
<Noah[m]>
Ah, btw, not-single workspace has rustanalyzer funkyness :D
<Noah[m]>
but also some pluses :D
fstracke has quit [Quit: fstracke]
Tidur has quit [Quit: Tidur]
RobWells[m] has quit [Quit: Idle timeout reached: 172800s]
ouilemur has quit [Quit: WeeChat 4.6.3]
<thejpster[m]>
another day, another time I really wished Rust would just auto-deref when I do maths on &i32 or &&i32
<thejpster[m]>
it loves to auto-deref, but not with maths on references to numbers
<Noah[m]>
yeah that would be very nice :)
<thejpster[m]>
(for anyone who hasn't seen this issue, try filtering an iterator to only pick the even numbers)
<dirbaio[m]>
do .cloned() on the iterator
<dirbaio[m]>
or .copied()
<thejpster[m]>
gets rid one one deref, not the other
<dirbaio[m]>
ah right
<thejpster[m]>
filter takes `FnMut(&Self::Item)`
<dirbaio[m]>
you can use patterns in the closure args `|&x| x%2==0`
<dirbaio[m]>
but yeah it's annoying :D
<thejpster[m]>
yes but then I have to explain that function parameters are in fact irrefutable patterns
<thejpster[m]>
or I can explain what 2 * **x does
<thejpster[m]>
and neither is fun
RoyBuitenhuis[m] has joined #rust-embedded
<RoyBuitenhuis[m]>
`2 & x.deref().deref()` ? :P
<RoyBuitenhuis[m]>
s/:P/😛/
<RoyBuitenhuis[m]>
s/&/*/, s/:P/😛/
Ralph[m] has quit [Quit: Idle timeout reached: 172800s]
<jason-kairos[m]>
(in this case my server is a static mut wrapped in MaybeUninit - I didn't want to put the server on the stack since I hand out its address to DMA)
<jason-kairos[m]>
(also: I am confident that what I am doing is okay with regards to soundness, being signal threaded and having various protection mechanisms in place)
<jason-kairos[m]>
s/signal/single/
<jason-kairos[m]>
(and I don't want to turn off the warning either, that is cheating)
<RoyBuitenhuis[m]>
I am looking for a HTTPS server crate that can be used on embedded, probably on embassy. Does anything come to mind?
<JamesMunns[m]>
Soundness is defined in terms of the rust abstract machine, I don't think there's any other definition of "real" soundness, at least as far as I know :)
<jason-kairos[m]>
Operations can be sound, defined, etc.
<jason-kairos[m]>
Operations can follow a set of rules, like the ones rust perscribes
<jason-kairos[m]>
But the two are not necessarily related.
<jason-kairos[m]>
(They often are very closely related)
jfsimon has joined #rust-embedded
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
<jason-kairos[m]>
* Operations can be sound, defined, etc. in certain contexts
<jason-kairos[m]>
Operations can follow a set of rules, like the ones rust perscribes
<jason-kairos[m]>
But the two are not necessarily related.
<jason-kairos[m]>
* Operations can be sound, defined, predictable, correct etc. in certain contexts
<jason-kairos[m]>
Operations can follow a set of rules, like the ones rust perscribes
<jason-kairos[m]>
But the two are not necessarily related.
<jason-kairos[m]>
* Operations can be sound, defined, predictable, correct etc. in certain contexts
<jason-kairos[m]>
Operations can follow a set of rules, like the ones rust prescribes and the compiler enforces
<jason-kairos[m]>
But the two are not necessarily related.
<jason-kairos[m]>
The rust model aim to work in many places. On many types of systems.
<jason-kairos[m]>
In embedded contexts, like here, that frequently is undesirable.
<jason-kairos[m]>
s/aim/aims/
<jason-kairos[m]>
Or rather, has a cost.
<jason-kairos[m]>
The actual low level implementation of how to handle various things like static mut, mutexes, etc. varies a great deal depending on the details of the system
<jason-kairos[m]>
Traits like Sync have a very specific meanings in the Rust abstract model. But often the finer details of those definitions breaks down or becomes irrelevant on something like a cortex-M0
<jason-kairos[m]>
If you are writing low level primitives from scratch, the context matters a lot.
<jason-kairos[m]>
* the context of where it will run matters a
<JamesMunns[m]>
I uh, strongly disagree. I'd suggest reading things like:
<JamesMunns[m]>
"Soundness" is a specific term, in respect to the Rust compiler and the Rust abstract machine. There are questions of soundness and UB in C and C++ as well, but in general, only Rust's model matters when you are writing Rust.
<dngrs[m]>
I looked into whether matrix supports roles (so you could highlight e.g. `@arm-team` to get more visibility) but sadly it apparently does not. Maybe it makes sense to augment the e-wg `README` with a list of matrix usernames for each team so one could copy paste from there?
<JamesMunns[m]>
As with any unsafe code, if you know that certain code will ONLY be run in a certain context, e.g. in a system where you always have all interrupts disabled (though NMIs are still a thing!), you may choose to allow certain unsafe code that wouldn't otherwise be considered sound or safe
<JamesMunns[m]>
but you're still responsible, as the unsafe code writer, for guaranteeing that your code is sound.
<JamesMunns[m]>
And if it contains behaviors considered undefined, even if it happens to work, it is still undefined behavior.
<jason-kairos[m]>
I agree James.
<jason-kairos[m]>
The only point of contention is regarding terminology.
<jason-kairos[m]>
* of contention I see is regarding
<jason-kairos[m]>
If we were to be very strict about the terms, then likely no project using any of the rust embedded working group crates could be considered "sound."
<jason-kairos[m]>
But that would be silly.
<dngrs[m]>
I find it mildly entertaining that the mut keyword might be more accurate read as "mutex" than "mutable"
<dngrs[m]>
and/or I do like explaining this part of Rust in terms of "AXM" (aliasing XOR mutability)
<JamesMunns[m]>
jason-kairos[m]: AFAIK, the only known soundness issues in wg crates are:
<JamesMunns[m]>
* The static mut transform in interrupt handlers is unsound in some cases (multicore, iirc?)
<JamesMunns[m]>
* The use of `pre_init` functions written in Rust are unsound
<JamesMunns[m]>
If there are others, that would be a surprise to me.
jfsimon has quit [Remote host closed the connection]
<firefrommoonligh>
Rust is just a lang like any, and IMO it has many nice qualities that I think are nicer than C or C++. You can go the full dogmatic safety approach, or just git-er-done
<firefrommoonligh>
Perfect is the enemy of good?
<dirbaio[m]>
> You can go the full dogmatic safety approach, or just git-er-done
<dirbaio[m]>
why not both? 😎
<firefrommoonligh>
Yea def! Finding the right compromises, if there are any that must be made
<firefrommoonligh>
Tradeoffs; engineering
<Noah[m]>
Hmm what could be possible reasons that smoltcp cannot get a route in it's neighbor cache after sending an ARP request? I seemingly get packets, so I guess I have connectivity?
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
<Noah[m]>
do I need to populate the cache myself somehow?
<dirbaio[m]>
It gets populated when it receives the arp response
<Noah[m]>
hmm so I guess I don't get any responses
<Noah[m]>
I have not understood the pieces of smoltcp yet at all, so might as well be that I do sth terribly wrong.
<Noah[m]>
But I get packets for sure :
<dirbaio[m]>
If you're not receiving it, try sniffing on the other side. That'll tell you if the request or the response is getting lost
<dirbaio[m]>
So if the issue is on rx or tx
<dirbaio[m]>
What mcu is it you're using?
<Noah[m]>
Hmm I also also get BufferFull veeery quickly (after 2 frames and there should be 12 slots)
<jason-kairos[m]>
I spent like two years living in wireshark for an embedded Ethernet product.
<jason-kairos[m]>
if you're RX somebody elses ARP that is one thing, but does the device even know its own IP address and subnet? Can it TX ARP?
<jason-kairos[m]>
s/RX/RXing/, s/elses/else's/
<jason-kairos[m]>
(although, I might be misremembering. I seem to recall every device on the network doing it's own ARP stuff totally independently)
timokrgr[m] has joined #rust-embedded
<timokrgr[m]>
re static cell: there is a overhead of 1 byte for each variable (the AtomicBool flag)
<timokrgr[m]>
has anyone made a macro to define multiple variables which all share a common AtomicU32?
<timokrgr[m]>
that would be only 1 bit overhead (assuming we define 32 variables)
<timokrgr[m]>
could be scaled to use the smallest AtomicUx to hold the number of required variables
danielb[m] has joined #rust-embedded
<danielb[m]>
timokrgr[m]: would that be significantly different from storing a struct in a staticcell?
<timokrgr[m]>
you could fetch the reference from different places (e.g deeper down the call stack of task)
<timokrgr[m]>
otherwise the struct approach would be the most efficient (thats a pattern I have used a few times, too)
<danielb[m]>
so, create a macro that creates a module with a struct (so you can't access fields directly), generate accessors that fetch-or bits in an atomicu8/atomicu32, profit? doesn't sound too difficult, except that it's very macro-only
<danielb[m]>
I guess `StaticCell2<A, B>` et al wouldn't be impossible either, just not very ergonomic with `.slot1()` etc 🤔
<dirbaio[m]>
If you're so starved of ram, just yolo unsafe it
<danielb[m]>
where's the fun in that
<dirbaio[m]>
Unsafe is endless fun
<Noah[m]>
tell me more, I have not heard of it yet
<Noah[m]>
Ok, so I am actually not getting any ARP packets. I am sending them though and I get UDP packets from my partners Pixel lol
<Noah[m]>
So it's working but not really.
<danielb[m]>
dirbaio[m]: is this the equivalent of "everything is a toy if you're brave enough"?
<timokrgr[m]>
<danielb[m]> so, create a macro that creates a module with a struct (so you can't access fields directly), generate accessors that fetch-or bits in an atomicu8/atomicu32, profit? doesn't sound too difficult, except that it's very macro-only
<timokrgr[m]>
thats the idea
<timokrgr[m]>
not too motivated to create it though, thats why I hoped it to exist already
<Noah[m]>
dirbaio if I connect directly (just between laptop and MCU), I get ARP responses. But seemingly they are broken. the response says: src=MAC-of-macbook/0.0.0.0 tgt=00-00-00-00-00-00/ip-of-mac ... I am so confused by that packet ...
<dirbaio[m]>
maybe you haven't configured your mac addr in the eth hw?
<Noah[m]>
Supposedly I do. You could not build an interface if it wasnt, no?
<dirbaio[m]>
in the hardware, not in smoltcp
<dirbaio[m]>
there's typically some register for "this is my mac"
<Noah[m]>
ah hmm, but in the outgoing packet the mac is correct
<dirbaio[m]>
you're sniffing on the computer?
<Noah[m]>
no, I just realized I might be lied to
<Noah[m]>
but why does my mac send this: src=MAC-of-macbook/0.0.0.0 tgt=00-00-00-00-00-00/ip-of-mac like the ip of the mac should be where the MAC of the mac is (src) ... I don't get it.
<dirbaio[m]>
hard to know without more info
<dirbaio[m]>
can sniff on the computer and post the .pcap, and the full verbose smoltcp logs?
<Noah[m]>
im on it, this stupid computer is locked down to the max lol ... now using the private one
<Noah[m]>
uhm if I connect it to my private mac it suddenly works lol
<Noah[m]>
duck me sideways
<Noah[m]>
I also log a lot of ICMP pings now and now it blarbs stuff like "iface:malformed"
<Noah[m]>
lol, thats work for tomorrow
<Noah[m]>
Thanks so much everyone <3
slpslp has joined #rust-embedded
<RockBoynton[m]>
<diondokter[m]> Guinea Wheek: Could you try out this branch and see if the compile times are now acceptable?...
<RockBoynton[m]>
I saw the you pushed a release to GH, anything blocking pushing to crates.io? Anxious for my compile times to be reasonable again 🙏
feldrinh[m] has quit [Quit: Idle timeout reached: 172800s]