tokomak has joined #rust-embedded
emerent has quit [Ping timeout: 256 seconds]
emerent has joined #rust-embedded
<re_irc> <@b​raincode:m​atrix.org> Is there a rust-embedded equivalent to: https://github.com/seemoo-lab/openhaystack ?
starblue2 has joined #rust-embedded
starblue1 has quit [Ping timeout: 256 seconds]
fabic has joined #rust-embedded
cr1901 has quit [Ping timeout: 256 seconds]
starblue3 has joined #rust-embedded
starblue2 has quit [Ping timeout: 272 seconds]
fabic has quit [Ping timeout: 256 seconds]
fabic has joined #rust-embedded
cr1901 has joined #rust-embedded
Shell has quit [Quit: ZNC 1.8.2 - https://znc.in]
Shell has joined #rust-embedded
<re_irc> <@l​ulf_:m​atrix.org> thalesfragoso: Speaking of TLS... https://blog.drogue.io/secure-device-to-cloud/ :)
<re_irc> <@m​athias_koch:m​atrix.org> Ulf Lilleengen: AWESOME!
<re_irc> <@k​orken89:m​atrix.org> Noijs!
<re_irc> <@l​achlansneff:m​atrix.org> Ulf Lilleengen: That's ridiculously exciting!
<cr1901> 80kB of .text is pretty good :o
<cr1901> >and can be used with any TCP stack, by implementing two traits used for I/O
<cr1901> What if I want to create an accelerator for an old computer? Can the traits just do I/O without needing the whole stack?
<cr1901> err TCP stack*
<re_irc> <@l​ulf_:m​atrix.org> I haven't tested that, but they just need to write/read the TLS records
<re_irc> <@m​athias_koch:m​atrix.org> Guess the "limitation" is, there is no way of using it without async?
<re_irc> <@l​ulf_:m​atrix.org> Not at the moment, as that haven't really been our priority, but we're certainly open to providing a blocking api in drogue tls if people are willing to help
<re_irc> <@l​ulf_:m​atrix.org> I'm hoping the community will collaborate on features they need if it looks interesting
<cr1901> I would like the option to use it blocking, I'm not too terribly excited about async being the minimal requirement to do Rust embedded
<cr1901> But I've bitched enough about that the past few days
<re_irc> <@l​ulf_:m​atrix.org> That is understandable. I don't think it would be that complicated. The places doing actual I/O are not many
<re_irc> <@m​athias_koch:m​atrix.org> Cool
<cr1901> (With all respect to embassy-rs and dirbaio)
<cr1901> It's a cool project... I'll use it at some point! Just it's not the "one size fits all" solution for me :P
<re_irc> <@m​athias_koch:m​atrix.org> Too bad TLS1.3 is not super widely adopted yet :/
<re_irc> <@l​ulf_:m​atrix.org> The future will come... I hope!
<re_irc> <@m​athias_koch:m​atrix.org> I hope so too.. We are highly relying on AWS, and they do not seem to be first movers on neither MQTTv5 nor TLS1.3
<re_irc> <@m​athias_koch:m​atrix.org> ;(
<cr1901> Anyways, I have a genuine use for a project like drogueTLS for an SSL accelerator for vintage machines lacking the multiply power (or ROM space) for TLS
<cr1901> So I'll look into it
<re_irc> <@l​achlansneff:m​atrix.org> Was able to get a CoAP + DTLS client for golioth (my employer) working on the nRF9160
<re_irc> <@l​achlansneff:m​atrix.org> https://twitter.com/lachlansneff/status/1410590085112897540
Shell has quit [Quit: ZNC 1.8.2 - https://znc.in]
tokomak has quit [Ping timeout: 256 seconds]
Shell has joined #rust-embedded
fabic has quit [Ping timeout: 258 seconds]
fabic has joined #rust-embedded
<re_irc> <@l​achlansneff:m​atrix.org> Looks like `futures-io` doesn't export `AsyncRead`, `AsyncWrite`, etc on no_std.
<re_irc> <@d​irbaio:m​atrix.org> yep because they use io::Error which has some strings and stuff
<re_irc> <@d​irbaio:m​atrix.org> :(
<re_irc> <@l​achlansneff:m​atrix.org> I'm kind of working on a crate that has a bunch of traits for net and io on no_std
<re_irc> <@l​achlansneff:m​atrix.org> Like AsyncRead/Write, AsyncReadTo, IpAddr, SocketAddr, etc
<re_irc> <@l​achlansneff:m​atrix.org> Everything abstracted so that it can use the types native to your network stack
<re_irc> <@r​yan-summers:m​atrix.org> Just a heads up, there's always a no_std_net for some of the basic types like IpAddr, SocketAddr
<re_irc> <@l​achlansneff:m​atrix.org> Definitely, but I would like to use the underlying primitives in my case, where I have a manufacturer supplied networking library
<re_irc> <@l​achlansneff:m​atrix.org> Plus, this lets you implement things like `ToSocketAddrs` in such a way that it works like it does in std, but it's generic on the network stack
<re_irc> <@r​yan-summers:m​atrix.org> Why not just impl From<X> for Y instead?
<re_irc> <@l​achlansneff:m​atrix.org> I mean I could, but this is pretty elegant
<re_irc> <@l​achlansneff:m​atrix.org> Like the crate contains an example impl for the std types when the `std` feature is enabled.
<re_irc> <@d​irbaio:m​atrix.org> embassy::io has AsyncRead, AsyncWrite
<re_irc> <@l​achlansneff:m​atrix.org> Good!
<re_irc> <@l​achlansneff:m​atrix.org> My opinion is that these things should be abstracted into a crate that can be used throughout the ecosystem
SomeWeirdAnon has joined #rust-embedded
<re_irc> <@l​achlansneff:m​atrix.org> Well, I came up with a crate that I think can fulfill that role.
<re_irc> <@l​achlansneff:m​atrix.org> https://docs.rs/coreplus
<re_irc> <@n​ewam:m​atrix.org> I am just curious, why a trait for IP addresses and not a concrete type?
<re_irc> <@n​ewam:m​atrix.org> Not criticizing, just interested in the design decision; I went a different way for https://docs.rs/w5500-ll/0.8.0/w5500_ll/net/index.html
<re_irc> <@l​achlansneff:m​atrix.org> Totally, happy to talk about that
<re_irc> <@l​achlansneff:m​atrix.org> I probably should add my reasoning to the docs
<re_irc> <@l​achlansneff:m​atrix.org> But the jist is that I think it's worthwhile to be able to use the networking types provided by your platform
<re_irc> <@l​achlansneff:m​atrix.org> E.g. go ahead and use the `std::net` types without having to convert
<re_irc> <@l​achlansneff:m​atrix.org> Or use raw libc or if you're on embedded and the vendor supplies a networking library, just use those types.
<re_irc> <@n​ewam:m​atrix.org> gotcha, makes sense, thanks!
<re_irc> <@l​achlansneff:m​atrix.org> `no-std-net` is an option too, but I didn't want to restrict people to just use that.
<re_irc> <@l​achlansneff:m​atrix.org> I might add `Ipv6Addr` and `Ipv4Addr` traits
<re_irc> <@n​ewam:m​atrix.org> it would help for sure, there's a lot of embedded devices out there that are only IPv4 :P
<re_irc> <@l​achlansneff:m​atrix.org> Good old legacy
<re_irc> <@n​ewam:m​atrix.org> legacy code is why I have a job, so I wont complain :D
<re_irc> <@d​irbaio:m​atrix.org> Isn't IP addr *traits* a bit too much?
<re_irc> <@l​ulf_:m​atrix.org> I've always thought of V4 and V6 as different enum variants of an IpAddress enum type.
<re_irc> <@l​achlansneff:m​atrix.org> It might be a bit much, but again, I think it's important to be able to use the underlying types maybe?
<re_irc> <@l​achlansneff:m​atrix.org> It's important in that I'd like people to be able to drop this into an implementation that already uses std::net without significant changes.
<re_irc> <@l​ulf_:m​atrix.org> I dunno, I think code gets unreadable quickly if everything is a trait that you need to parameterize on.
<re_irc> <@l​achlansneff:m​atrix.org> That's also true
<re_irc> <@l​achlansneff:m​atrix.org> If they were traits, they'd need to be generic on the network stack anyhow for this method to work
<re_irc> <@l​achlansneff:m​atrix.org> So, still would need a bunch of type parameters
<re_irc> <@l​achlansneff:m​atrix.org> Something which bugged me about other net libraries for no_std was that `ToSocketAddrs` didn't really work the way it works in std
<re_irc> <@l​achlansneff:m​atrix.org> So, it was important to me to make that work
<re_irc> <@f​irefrommoonlight:m​atrix.org> Ulf Lilleengen: My reaction exactly
<re_irc> <@f​irefrommoonlight:m​atrix.org> Figure out why you want that trait and if it's worth it. Making traits 'just because' leads to messy code
<re_irc> <@l​achlansneff:m​atrix.org> Well, this is pretty convincing
<re_irc> <@l​achlansneff:m​atrix.org> It seems non-optimal to add another IpAddr/SocketAddr crate, even if these would be a little different
<re_irc> <@l​achlansneff:m​atrix.org> And sadly enough, I had a full implementation of all those types yesterday, but I deleted the files cause I thought I wouldn't use them
<re_irc> <@l​achlansneff:m​atrix.org> I guess I'll go and do those again
fabic has quit [Ping timeout: 265 seconds]
<re_irc> <@l​achlansneff:m​atrix.org> Problem: Say io::Read gets into core as a separate trait. How can `std::io::Read` be automatically implemented for that if `core::io::Read` would probably be implemented for &[u8] in core?
<re_irc> <@n​ewam:m​atrix.org> Lachlan Sneff: ```rs
<re_irc> <@n​ewam:m​atrix.org> Something like that ^?
<re_irc> <@n​ewam:m​atrix.org> impl<T, E> std::io::Read for T where T: core::io::Read<Error = E> {}
<re_irc> <@l​achlansneff:m​atrix.org> It would complain about multiple implementations
<re_irc> <@n​ewam:m​atrix.org> oh, hmmm
<re_irc> <@l​achlansneff:m​atrix.org> It might need specialization :/
<re_irc> <@l​achlansneff:m​atrix.org> newam: Actually nvm, this would work
<re_irc> <@l​achlansneff:m​atrix.org> But I can't do the same thing :/
<re_irc> <@d​irbaio:m​atrix.org> why doesn't that work?
<re_irc> <@p​inkhatbeard:m​atrix.org> I'm working with the NRF9160-dk and need to be able to issue AT commands for debugging. I had trouble finding a library for reading/writing to the UART. As I wrote the code I have become convinced I had to have misunderstood something or overlooked a library. This is simultaneously too easy, trivial,...
<re_irc> ... tedious, and complex for there not to be a pre-baked solution out there. Can anyone point me in the right direction?
<re_irc> <@d​irbaio:m​atrix.org> issue AT commands from the firmware or from PC?
<re_irc> <@p​inkhatbeard:m​atrix.org> From PC over a serial connection.
<re_irc> <@d​irbaio:m​atrix.org> nrf91 doesn't do "AT over UART" like most modems do
<re_irc> <@d​irbaio:m​atrix.org> it does "AT over custom C API" that you have to call from your firmware
<re_irc> <@d​irbaio:m​atrix.org> if you want to be able to do AT comands from outside the nrf91 you have to write a firmware that reads the commands from UART and then passes them to the C api
<re_irc> <@p​inkhatbeard:m​atrix.org> Yes. That's what I'm doing. Sending commands to the modem isn't the problem. I just wondered if there wasn't a library for reading bytes from the UART instead of hand writing my own.
<re_irc> <@d​irbaio:m​atrix.org> ah, nrf-hal supports uart on the nrf9
<re_irc> <@d​irbaio:m​atrix.org> or if you mean on the PC side there's a few "serial port" crates
<re_irc> <@p​inkhatbeard:m​atrix.org> PC side is picocom or any of the others....none of that is novel. Maybe I'm not saying the correct words.
<re_irc> <@d​irbaio:m​atrix.org> 😅
<re_irc> <@d​irbaio:m​atrix.org> what do you want exactly?
<re_irc> <@d​irbaio:m​atrix.org> sendr/receive bytes on an UART from Rust firmware running in the nrf91?
<re_irc> <@p​inkhatbeard:m​atrix.org> I'm not sure how to say it differently. I have code that runs on the nrf9160. It's not doing exactly what I want right now. In order for me to debug this I have to constantly recompile and flash it. I find that tedious and would much rather connect to the board, send it some bytes over the wire that it can...
<re_irc> ... read, parse, and interpret into a command. It can take the command and then call some arbitrary function.
<re_irc> <@p​inkhatbeard:m​atrix.org> I was hoping the 'nrf9160 reading bytes over the wire' part would have a library. Right now I'm doing it in a loop, but because I need to get to "enter at command mode" I am getting loops within loops and it seemed like someone probably came up with a better way to handle all of it. I know I'm not the first...
<re_irc> ... person to ever need to send commands over the wire.
<re_irc> <@l​achlansneff:m​atrix.org> Well, I took the advice and released another version of core+: https://docs.rs/coreplus
<re_irc> <@j​amesmunns:m​atrix.org> pinkhatbeard: I think thejpster has a command line crate for no_std that you can use to make a serial port command line/shell/instrumentation interface
<re_irc> <@j​amesmunns:m​atrix.org> If you're cool with a binary protocol, my postcard crate + serde makes it super easy to write a simple cli with UART RPC commands
<re_irc> <@j​amesmunns:m​atrix.org> I also have some examples using that to "remote control" an i2c protocol over USB.
<re_irc> <@p​inkhatbeard:m​atrix.org> I gave up on finding a library and stuck with the loop for now. I think that is either to likely be good enough or backfire in some epic way eventually. I think the crate you're referring to is "menu", it appeared to have some issues when I was running a `nrf9160-demo` project.
<re_irc> <@p​inkhatbeard:m​atrix.org> I think `postcard` might be on the right track. Can you point me to one of your "remote control" examples?
<re_irc> <@p​inkhatbeard:m​atrix.org> jamesmunns: I gave up on finding a library and stuck with the loop for now. I think that is either to likely be good enough or backfire in some epic way eventually. I think the crate you're referring to is "menu", it appeared to have some issues when I was running a nrf9160-demo project.
<re_irc> <@p​inkhatbeard:m​atrix.org> I think postcard might be on the right track. Can you point me to one of your "remote control" examples?
<re_irc> <@j​osfemova:m​atrix.org> If I wanted to do some Wifi project with embedded rust, which MCU should I go with?
SomeWeirdAnon has quit []
<re_irc> <@t​hejpster:m​atrix.org> My command line menu system is in a crate called menu. docs.rs/menu
<re_irc> <@t​hejpster:m​atrix.org> If you implement "peek", "poke" and "jsr" you can load arbitrary code at runtime into memory and run it, just like on a Commodore 64 or similar. But that may not be what you want - I'm not sure.
<re_irc> <@f​irefrommoonlight:m​atrix.org> josfemova: Great question - I'm curious about the answer too. Perhaps ESP32? Rust support is WIP/active. I have a project that connects to PCs over USB, and then transmits over WIFI using Rocket, but this isn't what you're looking for
<re_irc> <@o​ddstr13:m​atrix.org> pinkhatbeard: Correct me if I'm wrong, but it sounds kinda like you're asking for the Rust equivalent of the Arduino Stream interface? https://www.arduino.cc/reference/en/language/functions/communication/stream/
<re_irc> <@o​ddstr13:m​atrix.org> If so, I'd be interested in the answer for that too!
<re_irc> <@t​hejpster:m​atrix.org> If anyone is on lobste.rs, do feel free to point out here https://lobste.rs/s/onp8qi/neotron_embedded_rust_home_computer#c_0r3iou that I *did* port Tiny BASIC. The 6502 emulator runs Enhanced BASIC, which I did because a) it was funny and b) it had floating point support.
<re_irc> <@j​osfemova:m​atrix.org> I considered the ESP32. Worked already with an esp8266 in another project (no wifi support for that one yet) so I already got the full rust-xtensa toolchain stuff ready to go, but at the same time I want to know if there is something less cumbersome/more supported than that. Controlling something like an...
<re_irc> ... esp8266 via AT commands is also fair game I guess, but I do want to know what other options are available
<re_irc> <@o​ddstr13:m​atrix.org> josfemova: I've got a Particle Argon I'm hoping to get going, it's got a nRF52840 core, and a ESP WiFi co-processor to talk to via AT commands
<re_irc> <@o​ddstr13:m​atrix.org> Last time I looked into actually getting started with it tho, I ran into dependency conflicts between embedded-hal 0.x and 1.x, so it's been on hold for a few months
<re_irc> <@f​irefrommoonlight:m​atrix.org> Please don't let a dependency conflict like that delay your work. Ever
<re_irc> <@f​irefrommoonlight:m​atrix.org> Using an external ESP as a dedicated WIFI chip sounds clunky, but isn't a bad idea
<re_irc> <@o​ddstr13:m​atrix.org> firefrommoonlight: Eh, I just got tired of messing around, kinda started porting over the nrf52-hal to the 1.0 alpha, I hit some obstacle there, but I forget what exactly
<re_irc> <@o​ddstr13:m​atrix.org> I think it was something with the UART and DMA not working quite right. Only dipped my toes a little into Rust, so working with it is quite taxing still
<re_irc> <@o​ddstr13:m​atrix.org> What I *should* do is get a mesh up and running with Arduino, and then add Rust to the mix later, when the embedded-hal stuff has matured some more (1.0 release and implemented where I need it)
<re_irc> <@j​osfemova:m​atrix.org> firefrommoonlight: Depending on the board, I feel like committing a sin haha. Got some Lolin boards around but I feel that ESP01 will be required if i want to feel good with myself