tokomak has joined #rust-embedded
emerent has quit [Ping timeout: 256 seconds]
emerent has joined #rust-embedded
<re_irc> <@b​raincode:m​> Is there a rust-embedded equivalent to: ?
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 -]
Shell has joined #rust-embedded
<re_irc> <@l​ulf_:m​> thalesfragoso: Speaking of TLS... :)
<re_irc> <@m​athias_koch:m​> Ulf Lilleengen: AWESOME!
<re_irc> <@k​orken89:m​> Noijs!
<re_irc> <@l​achlansneff:m​> 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​> I haven't tested that, but they just need to write/read the TLS records
<re_irc> <@m​athias_koch:m​> Guess the "limitation" is, there is no way of using it without async?
<re_irc> <@l​ulf_:m​> 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​> 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​> 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​> 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​> Too bad TLS1.3 is not super widely adopted yet :/
<re_irc> <@l​ulf_:m​> The future will come... I hope!
<re_irc> <@m​athias_koch:m​> 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​> ;(
<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​> Was able to get a CoAP + DTLS client for golioth (my employer) working on the nRF9160
<re_irc> <@l​achlansneff:m​>
Shell has quit [Quit: ZNC 1.8.2 -]
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​> Looks like `futures-io` doesn't export `AsyncRead`, `AsyncWrite`, etc on no_std.
<re_irc> <@d​irbaio:m​> yep because they use io::Error which has some strings and stuff
<re_irc> <@d​irbaio:m​> :(
<re_irc> <@l​achlansneff:m​> 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​> Like AsyncRead/Write, AsyncReadTo, IpAddr, SocketAddr, etc
<re_irc> <@l​achlansneff:m​> Everything abstracted so that it can use the types native to your network stack
<re_irc> <@r​yan-summers:m​> 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​> 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​> 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​> Why not just impl From<X> for Y instead?
<re_irc> <@l​achlansneff:m​> I mean I could, but this is pretty elegant
<re_irc> <@l​achlansneff:m​> Like the crate contains an example impl for the std types when the `std` feature is enabled.
<re_irc> <@d​irbaio:m​> embassy::io has AsyncRead, AsyncWrite
<re_irc> <@l​achlansneff:m​> Good!
<re_irc> <@l​achlansneff:m​> 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​> Well, I came up with a crate that I think can fulfill that role.
<re_irc> <@l​achlansneff:m​>
<re_irc> <@n​ewam:m​> I am just curious, why a trait for IP addresses and not a concrete type?
<re_irc> <@n​ewam:m​> Not criticizing, just interested in the design decision; I went a different way for
<re_irc> <@l​achlansneff:m​> Totally, happy to talk about that
<re_irc> <@l​achlansneff:m​> I probably should add my reasoning to the docs
<re_irc> <@l​achlansneff:m​> 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​> E.g. go ahead and use the `std::net` types without having to convert
<re_irc> <@l​achlansneff:m​> 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​> gotcha, makes sense, thanks!
<re_irc> <@l​achlansneff:m​> `no-std-net` is an option too, but I didn't want to restrict people to just use that.
<re_irc> <@l​achlansneff:m​> I might add `Ipv6Addr` and `Ipv4Addr` traits
<re_irc> <@n​ewam:m​> it would help for sure, there's a lot of embedded devices out there that are only IPv4 :P
<re_irc> <@l​achlansneff:m​> Good old legacy
<re_irc> <@n​ewam:m​> legacy code is why I have a job, so I wont complain :D
<re_irc> <@d​irbaio:m​> Isn't IP addr *traits* a bit too much?
<re_irc> <@l​ulf_:m​> I've always thought of V4 and V6 as different enum variants of an IpAddress enum type.
<re_irc> <@l​achlansneff:m​> 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​> 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​> I dunno, I think code gets unreadable quickly if everything is a trait that you need to parameterize on.
<re_irc> <@l​achlansneff:m​> That's also true
<re_irc> <@l​achlansneff:m​> 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​> So, still would need a bunch of type parameters
<re_irc> <@l​achlansneff:m​> 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​> So, it was important to me to make that work
<re_irc> <@f​irefrommoonlight:m​> Ulf Lilleengen: My reaction exactly
<re_irc> <@f​irefrommoonlight:m​> 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​> Well, this is pretty convincing
<re_irc> <@l​achlansneff:m​> It seems non-optimal to add another IpAddr/SocketAddr crate, even if these would be a little different
<re_irc> <@l​achlansneff:m​> 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​> I guess I'll go and do those again
fabic has quit [Ping timeout: 265 seconds]
<re_irc> <@l​achlansneff:m​> 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​> Lachlan Sneff: ```rs
<re_irc> <@n​ewam:m​> Something like that ^?
<re_irc> <@n​ewam:m​> impl<T, E> std::io::Read for T where T: core::io::Read<Error = E> {}
<re_irc> <@l​achlansneff:m​> It would complain about multiple implementations
<re_irc> <@n​ewam:m​> oh, hmmm
<re_irc> <@l​achlansneff:m​> It might need specialization :/
<re_irc> <@l​achlansneff:m​> newam: Actually nvm, this would work
<re_irc> <@l​achlansneff:m​> But I can't do the same thing :/
<re_irc> <@d​irbaio:m​> why doesn't that work?
<re_irc> <@p​inkhatbeard:m​> 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​> issue AT commands from the firmware or from PC?
<re_irc> <@p​inkhatbeard:m​> From PC over a serial connection.
<re_irc> <@d​irbaio:m​> nrf91 doesn't do "AT over UART" like most modems do
<re_irc> <@d​irbaio:m​> it does "AT over custom C API" that you have to call from your firmware
<re_irc> <@d​irbaio:m​> 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​> 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​> ah, nrf-hal supports uart on the nrf9
<re_irc> <@d​irbaio:m​> or if you mean on the PC side there's a few "serial port" crates
<re_irc> <@p​inkhatbeard:m​> 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​> 😅
<re_irc> <@d​irbaio:m​> what do you want exactly?
<re_irc> <@d​irbaio:m​> sendr/receive bytes on an UART from Rust firmware running in the nrf91?
<re_irc> <@p​inkhatbeard:m​> 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​> 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​> Well, I took the advice and released another version of core+:
<re_irc> <@j​amesmunns:m​> 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​> 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​> I also have some examples using that to "remote control" an i2c protocol over USB.
<re_irc> <@p​inkhatbeard:m​> 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​> 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​> 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​> 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​> 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​> My command line menu system is in a crate called menu.
<re_irc> <@t​hejpster:m​> 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​> 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​> pinkhatbeard: Correct me if I'm wrong, but it sounds kinda like you're asking for the Rust equivalent of the Arduino Stream interface?
<re_irc> <@o​ddstr13:m​> If so, I'd be interested in the answer for that too!
<re_irc> <@t​hejpster:m​> If anyone is on, do feel free to point out here 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​> 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​> 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​> 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​> Please don't let a dependency conflict like that delay your work. Ever
<re_irc> <@f​irefrommoonlight:m​> Using an external ESP as a dedicated WIFI chip sounds clunky, but isn't a bad idea
<re_irc> <@o​ddstr13:m​> 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​> 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​> 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​> 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