<re_irc> <@j​axter184:m​atrix.org> ive been messing around with stm32-eth, and it seems to be working? im using the `pktgen` example, and it shows Rx packets whenever i nmap
<re_irc> <@j​axter184:m​atrix.org> ive never used wireshark, is there a oneliner i can just run that will show me whether or not this is working right?
<Darius> you could use an embedded DHCP server to make it easy to plug a PC in and get an IP for configuration
<Darius> if you had device-device only then link local addresses and multicast DNS probably make more sense
<re_irc> <@j​axter184:m​atrix.org> oh wireshark is neat
<re_irc> <@j​axter184:m​atrix.org> i feel so powerful
<re_irc> <@n​ewam:m​atrix.org> I highly recommend wireshark, it is extremely useful for debugging embedded networking.
<Darius> the most annoying thing is the difference between the filter language when capturing vs the only when searching in the GUI IMO
<Darius> you can write your own protocol parsers for it too (in Lua) - it's very neat
<re_irc> <@j​axter184:m​atrix.org> i think im seeing the packets from my stm32 in wireshark?
<re_irc> <@n​ewam:m​atrix.org> Yeah the filtering is a pain; but if you're doing point-to-point with the device connected to your PC then there's nothing to filter.
<re_irc> <@j​axter184:m​atrix.org> this is cool
<re_irc> <@j​axter184:m​atrix.org> easier to get to this point than i thought it would be
<re_irc> <@j​axter184:m​atrix.org> ty for yalls help so far
<Darius> I think the filtering is OK per se, juts that it's got a different syntax to the filter you use in the GUI after capture which is a baffling historical wart IMO
<Darius> wireshark can also pcap USB which can be handy for many hacker adjacent things :)
<re_irc> <@n​ewam:m​atrix.org> Do read the warnings before enabling USB pcap; very easy to get yourself into a situation where your USB keyboard stops working.
<re_irc> <@n​ewam:m​atrix.org> I definitely didn't learn _that_ one from experience.
<Darius> haha
GenTooMan has quit [Ping timeout: 250 seconds]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 250 seconds]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 250 seconds]
fabic has joined #rust-embedded
GenTooMan has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
zBeeble has quit [Quit: Leaving]
dcz has joined #rust-embedded
fabic has quit [Ping timeout: 240 seconds]
troth has quit [Ping timeout: 250 seconds]
crabbedhaloablut has quit [Remote host closed the connection]
troth has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
cr1901 has quit [Ping timeout: 240 seconds]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 250 seconds]
fabic has joined #rust-embedded
cr1901 has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
<re_irc> <@f​rank_a_stevenson:m​atrix.org> I am writing a small function that does a i2c::Read and i2c::Write using embedded-hal. But I am having problems finding a reasonable Error type for the Result. The Read and Write traits have different associated Error types, and I am puzzled how I can combine them into a single Result.
<re_irc> <@c​hrysn:p​rivacytools.io> well, think of what'd the error be if there'd be anything else that can go wrong in there too, or if maybe there's a GPIO operation involved. does it makes sense to propagate out the precise cause in the first place? (rather than, say, just propagate that there's an `enum Error { I2CError, ParsingError }`?)
<re_irc> <@c​hrysn:p​rivacytools.io> you can propagate an `enum Error { I2CWrite(<D as i2c::Write>::Error), I2CRead(<D as i2c::Read>::Error), ...}`, so that'd work, but it may be overkill.
<re_irc> <@f​rank_a_stevenson:m​atrix.org> I went down the second path, but the type signatures got out of hand, and the compiler was not all that helpful. I was hoping to get away with ? propagation of the errors, but think it is easier to introduce a new errors type instead. Thanks
<re_irc> <@d​irbaio:m​atrix.org> You can force the two error types to be the same with trait bounds
<re_irc> <@d​irbaio:m​atrix.org> In most of the hals it's the same
<re_irc> <@d​khayes117:m​atrix.org> I did this with a PR to the LM75-rs driver crate. There was an enum with all possible errors with I2c having type <E> and using trait bounds
<re_irc> <@d​khayes117:m​atrix.org> /// All possible errors in this crate
<re_irc> <@d​khayes117:m​atrix.org> pub enum Error<E> {
<re_irc> <@d​khayes117:m​atrix.org> #[derive(Debug)]
<re_irc> <@d​irbaio:m​atrix.org> But you'd be ruling out use with hals where it's not the same, not sure if there any
<re_irc> <@d​irbaio:m​atrix.org> Yup exactly with these bounds 👆
<re_irc> <@c​hrysn:p​rivacytools.io> I'd softly caution against that; sure can be done, but for someone it will just not work on the one HAL that uses distinct error types.
<re_irc> <@d​irbaio:m​atrix.org> I think that's quite widespread among driver crates :S
<re_irc> <@b​urrbull:m​atrix.org> What about something like (just thought):
<re_irc> <@b​urrbull:m​atrix.org> where
<re_irc> <@b​urrbull:m​atrix.org> impl<I2C, E> Lm75<I2C, ic::Pct2075>
<re_irc> <@b​urrbull:m​atrix.org> I2C: i2c::Write + i2c::WriteRead,
<re_irc> <@d​irbaio:m​atrix.org> Hala usually don't impl Into..
<re_irc> <@d​irbaio:m​atrix.org> And I think if you write it that way type inference won't work
<re_irc> <@x​iretza:x​iretza.xyz> ```rust
<re_irc> <@x​iretza:x​iretza.xyz> where I2C: i2c::Write + i2c::WriteRead {
<re_irc> <@x​iretza:x​iretza.xyz> can't you just pass the `I2C` generic to the error enum?
<re_irc> <@x​iretza:x​iretza.xyz> enum Error<I2C>
GenTooMan has quit [Ping timeout: 250 seconds]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 250 seconds]
GenTooMan has joined #rust-embedded
<re_irc> <@r​obyoung:m​atrix.org> Hi, I've been working on a blog post to help people completely new to embedded development pick a good first development board for doing embedded rust. Being very new to the field myself I'm aware some of what I have written may be inaccurate. I really don't want to ruin anyone's journey right at the start so I...
<re_irc> ... was wondering if anyone might have time to review it for me. It's about 1600 words so should take about 15 minutes to read.
<re_irc> <@n​ewam:m​atrix.org> robyoung: Sure!
<re_irc> <@j​axter184:m​atrix.org> i feel like the best first board is just the stm32f4discovery
<re_irc> <@n​ewam:m​atrix.org> No matter what devboard you recommend someone will complain they don't have it 😀
<re_irc> <@n​ewam:m​atrix.org> and mention "why didn't you use x?"
<re_irc> <@d​khayes117:m​atrix.org> The microbit boards will be good too with its addition to the discovery book
<re_irc> <@r​obyoung:m​atrix.org> jaxter184: Phew! 😅 That is actually bone of the boards recommended in the end.
<re_irc> <@r​obyoung:m​atrix.org> Actually, I think I'll just chuck the link in here. If you have time to review I would really appreciate it. https://docs.google.com/document/d/1w2iKe8X0d9vE6DomE4Y4T3UdX6VTgmEzJS1NEcZEvOU/edit?usp=drivesdk
<re_irc> <@f​rank_a_stevenson:m​atrix.org> Most STM32 microcontrollers have 52 weeks lead time now, and there is a danger that dev boards will become unobtainable.
<re_irc> <@n​ewam:m​atrix.org> That goes for everything right now, doesn't it?
<re_irc> <@f​rank_a_stevenson:m​atrix.org> NXP and SAMD are avialable among others. Broabably also Nordic also
<re_irc> <@n​ewam:m​atrix.org> huh. Wonder why STs supply chain is worse.
<re_irc> <@f​rank_a_stevenson:m​atrix.org> Panic orders & scalping, they have their own fabs.
<re_irc> <@n​ewam:m​atrix.org> Wow, I did know they had their own fabs.
<re_irc> <@a​damgreig:m​atrix.org> you'd think them having their own fabs would mean they have _better_ availability, though I think a lot of STM32s are TSMC these days
<re_irc> <@a​damgreig:m​atrix.org> from what I've heard a factor is the larger automotive use of stm32, but, shrug
GenTooMan has quit [Ping timeout: 240 seconds]
<re_irc> <@e​ldruin:m​atrix.org> robyoung: I did something like that a while ago as well https://blog.eldruin.com/tips-hobby-embedded-development-beginners/
<re_irc> <@e​ldruin:m​atrix.org> ah, I see your post is about specifically which board to pick
GenTooMan has joined #rust-embedded
<re_irc> <@l​ulf_:m​atrix.org> eldruin: That is a useful post, and wish I had read it sooner. Thanks for writing it!
<re_irc> <@j​orgeig:m​atrix.org> this is not a Rust topic but maybe someone can help 😄 - has anyone used press-fit nuts like these? https://www.mcmaster.com/catalog/127/3469
<re_irc> <@j​orgeig:m​atrix.org> do I really need a $500 tool to use these???
<re_irc> <@j​orgeig:m​atrix.org> cause that's crazy haha
<re_irc> <@j​axter184:m​atrix.org> ive never used that particular type of nut, but i think a similar (probably more common?) option is heat-set inserts
<re_irc> <@h​enrik_alser:m​atrix.org> I just let the sheet metal house that make my enclosures insert them for me, don’t know exactly how they do it haha… If i buy enclosures off the shelf i just use standoff nuts instead, either the ones for screws in both ends or the ones with ”male” threads on one side if i can thread the hole
<re_irc> <@j​axter184:m​atrix.org> that is, assuming you're using these on plastic
<re_irc> <@j​axter184:m​atrix.org> these fellas
<re_irc> <@j​axter184:m​atrix.org> and you can just poke them in with a soldering iron
<re_irc> <@h​enrik_alser:m​atrix.org> (Then again i only use metal enclosures btw)
<re_irc> <@n​ewam:m​atrix.org> jaxter184: Just don't slip or you'll be buying yourself a new tip 😀
<re_irc> <@j​axter184:m​atrix.org> i mean if you slip, then you just have some extra plastic on there, nothing a little steel wool wont fix
<re_irc> <@j​orgeig:m​atrix.org> jaxter184: I'm using them on a board
<re_irc> <@j​axter184:m​atrix.org> also they make special soldering iron tips just for this purpose
<re_irc> <@j​orgeig:m​atrix.org> well, I am supposed to
<re_irc> <@j​axter184:m​atrix.org> oh hmm like on a pcb?
<re_irc> <@j​orgeig:m​atrix.org> yes
<re_irc> <@j​orgeig:m​atrix.org> of course I can just use a normal nut
<re_irc> <@j​orgeig:m​atrix.org> it's up to me
<re_irc> <@j​orgeig:m​atrix.org> this is just what the part manufacturer recommends for their part
<re_irc> <@j​axter184:m​atrix.org> yeah tbh if i were in your situation, id just glue a nut onto the pcb
<re_irc> <@j​axter184:m​atrix.org> threaded rivets might also be an option?
<re_irc> <@j​axter184:m​atrix.org> it still requires a tool, but its a lot less than $500
<re_irc> <@j​axter184:m​atrix.org> though ive never used them before, and idk how resistant they are to slipping
<re_irc> <@d​arthdeus:m​atrix.org> hey guys, I'm down a long path of trying to cross compile with `cross` on linux, but the problem is I need libclang 3.9 or newer, but the provided dockerfile for linux uses centos which needs to use SCL to enable newer versions of clang, but that needs to be enabled in a login shell (something like `scl enable...
<re_irc> ... llvm-toolset-7 bash`) ... but I'm not sure how to get `cross` to run commands this way 😰 I also found a related issue from someone who looks like they were down the exact same path, but didn't find a solution https://github.com/rust-embedded/cross/issues/566
<re_irc> <@d​arthdeus:m​atrix.org> any thoughts?
<re_irc> <@h​enrik_alser:m​atrix.org> jorgeig: Ahh i thought you wanted to mount the board to an enclosure, never mind then :)
<re_irc> <@c​hrysn:p​rivacytools.io> jorgeig: not sure i've got the whole discussion, but a thing for threads i like to use are [SMT spacers with internal threads](https://www.we-online.com/katalog/en/WA_SMSI_M5_STEEL_SPACER_WITH_INT_THREAD)
<re_irc> <@g​rantm11235:m​atrix.org> jorgeig: It says you can just use an arbor press, those are pretty cheap
<re_irc> <@j​orgeig:m​atrix.org> yep I'll see if I can get a cheap one, though nothing is cheap where I am XD
<re_irc> <@j​orgeig:m​atrix.org> anyway I need to convince McMaster to sell it to me
<re_irc> <@g​rantm11235:m​atrix.org> A vise or even just a hammer would probably work too
<re_irc> <@j​orgeig:m​atrix.org> last time they didn't want to bother with export regulations
<re_irc> <@j​orgeig:m​atrix.org> imagine my face when I saw that email
<re_irc> <@j​orgeig:m​atrix.org> export regs.. on nuts?
<re_irc> <@h​enrik_alser:m​atrix.org> jorgeig: Nuts!
<re_irc> <@g​rantm11235:m​atrix.org> I've even seen people use a drill press as an arbor press
<re_irc> <@j​orgeig:m​atrix.org> it could work in this case yeah
<re_irc> <@h​enrik_alser:m​atrix.org> What are you mounting?
<re_irc> <@j​orgeig:m​atrix.org> an Iridium 9603 modem
<re_irc> <@j​orgeig:m​atrix.org> those nuts are the ones they recommend on the product manual, but of course I can choose whatever I see fit
<re_irc> <@f​irefrommoonlight:m​atrix.org> I wonder if you could use those press-fit nuts with heat to set it
<re_irc> <@f​irefrommoonlight:m​atrix.org> *beaten
<re_irc> <@f​irefrommoonlight:m​atrix.org> The custom tips jaxter mentioned are good, especially paired with a dedicated iron if you're doing it at quantity. Normal tips will work too, but are tougher, and as he mentioned, if you slip, the expansion may make it tough or impossible to get the tip out
<re_irc> <@j​orgeig:m​atrix.org> thanks for the advice!
<re_irc> <@j​orgeig:m​atrix.org> let's see first if I can buy them this time 😆
<re_irc> <@n​ewam:m​atrix.org> is there a good way to handle default targets in a multi-crate workspace?
<re_irc> <@n​ewam:m​atrix.org> e.g. one crate defaults to `thumbv7em-none-eabi` and the other to `thumbv6m-none-eabi`?
fabic has quit [Ping timeout: 252 seconds]
<re_irc> <@a​lmindor:m​atrix.org> created first draft of my attempt at a generic MIPI DSI generic driver: https://github.com/almindor/mipidsi NOTE: the ili9486 requires Rgb666 which isn't in e-g master yet
<re_irc> <@r​obyoung:m​atrix.org> Thanks for all the review comments, really helpful. Thank you 🙇
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc> <@h​enrik_alser:m​atrix.org> robyoung: Thanks for producing content like that! 👍
<re_irc> <@n​ewam:m​atrix.org> Checking for prior art before I go build my own thing; does anyone have a way to pass keys at compile time?
<re_irc> <@n​ewam:m​atrix.org> I am thinking the best way would be a `build.rs` script that decodes a `.pem` certificate to bytes then the file that needs the key would do an `include_bytes!`
dcz has quit [Ping timeout: 240 seconds]
<re_irc> <@c​ome_744:c​onverser.eu> newam: Why decoding at compile-time and not keeping the decoded version on your drive? Maybe you could keep the decoded version `.gitignore`d, and let a `.pem.example` file in the folder if relevant?
<re_irc> <@n​ewam:m​atrix.org> Côme: Needs to be consumable by both the embedded device and the non-embedded server it communicates with.
<re_irc> <@n​ewam:m​atrix.org> Loading keys from raw bytes is not very well supported by rust p256 libraries, easier to keep it in a pem/der format.
<re_irc> <@c​ome_744:c​onverser.eu> newam: Ok thanks for the explanation 👍
<re_irc> <@9​names:m​atrix.org> darthdeus: Have you tried creating a script that does that and setting it as the entrypoint?
<re_irc> <@9​names:m​atrix.org> The windows dockerfile has an entrypoint set, but the linux one doesn't. Assuming it doesn't override it on the commandline it should work