ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
<firefrommoonligh> Update: Was able to get a working solution with most messages passing by doing this:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/EecVHQWtNIPPoosSQnDqkjxR>)
<firefrommoonligh> I think I was wrong about Putty showing full packets; the Putty packets were clipped and I didn't notice
<firefrommoonligh> Long-term I'm going to manually program the LoRa radios to overcome a different limitation (Commanding multiple vehicles from same transmitter)
<dirbaio[m]> building a drone army?
<firefrommoonligh> Navy
starblue has quit [Ping timeout: 246 seconds]
starblue has joined #rust-embedded
starblue has quit [Ping timeout: 240 seconds]
crabbedhaloablut has joined #rust-embedded
emerent_ has joined #rust-embedded
emerent has quit [Killed (osmium.libera.chat (Nickname regained by services))]
emerent_ is now known as emerent
lehmrob has joined #rust-embedded
<sourcebox[m]> firefrommoonlight: I also use egui as my default solution for GUI applications, e.g. my DFU flash tool: https://github.com/sourcebox/dfu-buddy
<sourcebox[m]> For my latest project I routed the output of the embedded-graphics-simulator to egui so that I can build controls around it to simulate the device.
RobertJrdens[m] has joined #rust-embedded
<RobertJrdens[m]> <firefrommoonligh> "image.png" <- 👍️ to using egui for dashboards and rapid frontend sketches!
<RobertJrdens[m]> * for dashboards (if they need to be faster than influxdb/grafana et al.) and rapid
pbsds has quit [Ping timeout: 248 seconds]
pbsds has joined #rust-embedded
juliand[m] has joined #rust-embedded
<juliand[m]> <RobertJrdens[m]> "image.png" <- Looks very good! Is this done with egui directly? Or is it something like plotters etc.?
<juliand[m]> Having something like Arduino IDE's serial monitor would be pretty handy...
M9names[m] has quit [Quit: Idle timeout reached: 172800s]
<RobertJrdens[m]> The plotting stuff in that screenshot is straight egui. It's somewhat limited and opinionated plotting support but likely sufficient for many things.
IlPalazzo-ojiisa has joined #rust-embedded
<juliand[m]> Cool, I'll give that a try.
<juliand[m]> It would only need zu be somewhat fast, I guess. Used iced+plotters a while ago to plot SDR measurements and that could get very laggy. But even that should work with serial plotting for debugging purposes.
notgull has quit [Ping timeout: 240 seconds]
notgull has joined #rust-embedded
<JamesMunns[m]> Hey, the Berlin Firmware Meetup run by Interrupt/Memfault is planning to have another event in mid-November, if anyone is looking for somewhere to talk about something, I'd love to see another Rust talk there!
<JamesMunns[m]> Meetup info: https://www.meetup.com/de-DE/berlin-firmware-embedded-systems-meetup/, you should be able to message the organizer there, or dm me and I can get you in touch with them.
<JamesMunns[m]> I'm not actively affiliated, but gave a talk about MnemOS a couple of weeks ago, and it was a surprisingly good meetup, folks were pretty open to Rust stuff.
harishkumaran[m] has joined #rust-embedded
<harishkumaran[m]> <FreeKill[m]> "But again the language side..." <- > <@larunite:matrix.org> But again the language side really isn't that hard. An embedded C codebase looks pretty simple most of the time.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/HIQxuYCcdrJglYRFzkOUSgDR>)
S3cr3tDeV[m] has joined #rust-embedded
<S3cr3tDeV[m]> stm32 nucleo
<S3cr3tDeV[m]> stm32 101
lehmrob has quit [Ping timeout: 252 seconds]
<S3cr3tDeV[m]> * stm32 103
<S3cr3tDeV[m]> beaglebone pocket
diondokter[m] has joined #rust-embedded
<diondokter[m]> HarishKumaran[m]: > <@harishkumaran:tchncs.de> If you're new to embedded I would recommend getting a dev kit or at least MCU that is popular and convenient to work with, and then just start trying to make it do stuff.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/LePQWnRmlUFaoukjHzRYTRkW>)
<FreeKill[m]> Any stm 32 nucleo board is more than good though to learn with
<FreeKill[m]> Good enough*
s7rul[m] has joined #rust-embedded
<s7rul[m]> The raspberry pico with its rp2040 is a good bang for your buck and can be programmed without a debugger or with there cheap debugger.
<diondokter[m]> You want to be able to do more than *just programming* the device, especially as a beginner.
<diondokter[m]> IMO, a debugger is required for a beginner (and even for me now). Either integrated or an external one
<FreeKill[m]> Nucleo boards also usually come with some fun peripherals you can learn with
<S3cr3tDeV[m]> Rust is at 3rd place in Energy saving next to c++
<S3cr3tDeV[m]> S3cr3tDeV[m]: Lemme know your thoughts on it guys
<diondokter[m]> A specific nucleo board that is at least cheap in the netherlands is: STMICROELECTRONICS
<diondokter[m]> Plenty fast and a nice chunk of flash space
<diondokter[m]> NUCLEO-L452RE-P
<s7rul[m]> <diondokter[m]> "You want to be able to do more..." <- > <@diondokter:matrix.org> You want to be able to do more than *just programming* the device, especially as a beginner.
<s7rul[m]> > IMO, a debugger is required for a beginner (and even for me now). Either integrated or an external one
<s7rul[m]> That is true. Wanted to show that a raspberry pi pico for 6 eur and ther debuger for 16 eur (or a secound pico used as a debugger) is around the same price as a nucleo (or lower).
<JamesMunns[m]> S3cr3tDeV[m]: This study is very specific to one snapshot (benchmarks game), and probably isn't reasonable to extrapolate hugely from
lehmrob has joined #rust-embedded
<s7rul[m]> s7rul[m]: You do miss out on potential fun peripherals thou but dualcore so depends on what you want to do.
<JamesMunns[m]> it generally shows (iirc) that "aot compiled, optimized builds" of a couple benchmark-game runs ends up being more efficient. It's an interesting observation! But I don't know how hugely meaningful it ends up being to most organizations, and in nearly every case that matters, the total system design is going to matter a lot as well
lehmrob has quit [Remote host closed the connection]
<firefrommoonligh> <RobertJrdens[m]> "image.png" <- I am filing this idea away re plotting. Good to know about that cap
<firefrommoonligh> <sourcebox[m]> "firefrommoonlight: I also use..." <- > <@sourcebox:matrix.org> firefrommoonlight: I also use egui as my default solution for GUI applications, e.g. my DFU flash tool: https://github.com/sourcebox/dfu-buddy
<firefrommoonligh> > For my latest project I routed the output of the embedded-graphics-simulator to egui so that I can build controls around it to simulate the device.
<firefrommoonligh> Very interesting. I've been bundling version-specific standalone CLI executables that wrap dfu-util; I like your approach better
yruama_lairba[m] has quit [Quit: Idle timeout reached: 172800s]
<dngrsspookyvisio> time for me to plug https://github.com/spookyvision/embedded-web-ui/ again :D
<dngrsspookyvisio> (haven't updated it in a while though…)
<dngrsspookyvisio> should probably at least add the [video](https://www.youtube.com/watch?v=OVQCu2fmVps) where it charts data sent from the device
Guest7221 has left #rust-embedded [Error from remote client]
Guest7221 has joined #rust-embedded
K900 has quit [Quit: Idle timeout reached: 172800s]
pbsds has quit [Ping timeout: 245 seconds]
<adamgreig[m]> hi @room, meeting time again! agenda is https://hackmd.io/sIs7_1McSAS6WzR6iIri7w, please add anything you'd like to discuss or announce and we'll start in a few mins
<JamesMunns[m]> <JamesMunns[m]> "Hey, the Berlin Firmware..." <- > <@jamesmunns:beeper.com> Hey, the Berlin Firmware Meetup run by Interrupt/Memfault is planning to have another event in mid-November, if anyone is looking for somewhere to talk about something, I'd love to see another Rust talk there!... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/UWxUzGKdwcswZkEOmLOhOlaC>)
<adamgreig[m]> ok, let's start
<adamgreig[m]> couple of release announcements: svdtools 0.3.1 is out, its first release since moving to rewg, with the new html generation tool built in
<adamgreig[m]> and aarch64-cpu 9.4.0 (I keep writing 0.9.4...) with a bunch of new registers added
<adamgreig[m]> and as a follow-on from last week, the moderation bot ( Ruma Moderation ) is running here now, please send feedback if you notice it misbehaving but hopefully it will just ban spammers before they can spam
<adamgreig[m]> (it is the same one used in #rust:matrix.org and other places)
<adamgreig[m]> any other announcements from anyone?
<adamgreig[m]> the other thing to mention then is the rustc target support list effort in https://github.com/rust-lang/rust/pull/116004, rustc is still missing maintainers for a lot of the embedded targets (thumbv6/7 bare-metal, riscv32/64 bare-metal, others), which will probably one day lead to them being demoted to tier 3 if no one can be found
<adamgreig[m]> we already discussed suggesting the cortex-m team maintain the thumbv6/7 bare-metal targets; perhaps i'll open an issue on the wg repo and tag the riscv and other teams to see if they're interested in those other targets
therealprof[m] has joined #rust-embedded
<therealprof[m]> I think part of the lack of volunteering here is that it's not quite clear what maintaining a target entails...
<adamgreig[m]> ctrl-f "maintainers"
<adamgreig[m]> so, be available to consult on target-specific build-breaking issues, if necessary develop target-specific language or library details, at least 2 developers, fix any test failures in rustc test suite for that target "in a timely fashion"
<adamgreig[m]> (some of that is for tier 3)
jessebraham[m] has joined #rust-embedded
<jessebraham[m]> I have sent a message in our (Espressif) internal chats, as we obviously need `riscv32` support. Obviously not making any guarantees, but we'll see if I can find somebody to volunteer there
<jessebraham[m]> Or wait, did I misread your message
<adamgreig[m]> s/3/2 only/
<jessebraham[m]> Haha
<adamgreig[m]> the riscv32imc-esp-espidf targets are already marked as having a maintainer
<adamgreig[m]> (I guess you :P)
<jessebraham[m]> Ahh yeah I see the bare-metal targets are not though
<adamgreig[m]> but I suppose you also use the bare-metal ones for non-idf?
<jessebraham[m]> Yes
<therealprof[m]> Doesn't the document say each target needs at least 2 maintainers?
<adamgreig[m]> presumably if the esp-espidf targets are working the bare-metal ones probably are too but I guess there might be some weird differences...
<adamgreig[m]> therealprof[m]: for tier 2, though I presume "the wg cortex-m team" would count since it contains >2 people...
<jessebraham[m]> Yeah, not sure. Not my department 😁 Will discuss internally and report back if there's any news
<therealprof[m]> adamgreig[m]: Sure thing.
<adamgreig[m]> jessebraham[m]: thanks!
mabez[m] has joined #rust-embedded
<mabez[m]> Myself and Ivan Markov and the maintainers for espidf upstream
andodeki2[m] has joined #rust-embedded
<andodeki2[m]> hey guys
<andodeki2[m]> which rust crate is awesome to use to create asynchronous TCP server
K900 has joined #rust-embedded
<K900> On embedded?
<adamgreig[m]> final point probably worth briefly mentioning, someone asked about volatile_register in cortex-m here https://github.com/rust-embedded/cortex-m/issues/485
<adamgreig[m]> and I guess they're right, volatile_register's RW struct is not marked repr(C) or repr(transparent), even though the vcell::volatile_cell it contains was updated to be repr(transparent) eventually
<therealprof[m]> Aah, the gift that keeps on giving...
<adamgreig[m]> present-day rustc probably won't reorder a single field or add padding but yea
phaseonx11[m] has joined #rust-embedded
<phaseonx11[m]> Hello everyone! Anybody know of any crates to parse J1939 frames? I found CANParse...but it seems to be STD only.
<adamgreig[m]> I think that's all for this week's meeting anyway, thanks everyone!
<JamesMunns[m]> adamgreig[m]: thank you adamgreig
<JamesMunns[m]> s//!/
<phaseonx11[m]> Oh shoot, sorry guys. I didn't know I was interrupting :/ Apologies.
jannic[m] has joined #rust-embedded
<jannic[m]> Don't worry, it wasn't a particularly busy meeting this time.
<adamgreig[m]> we were finished anyway :P
<adamgreig[m]> sigh, clone volatile_register, quick PR https://github.com/japaric/volatile-register/pull/12, notice the PR tab says (2) now
<adamgreig[m]> the other PR is from april 2019 and is identical to mine lol
<dirbaio[m]> we should "just" move off vcell/volatile-register :P
<mabez[m]> <adamgreig[m]> "but I suppose you also use the..." <- Okay, at my PC now and can read back the whole meeting. I'd be happy to volunteer for to maintain the imc or imac rv32 target, if that's helpful
<adamgreig[m]> oh, thanks! davidtwco is organising it in https://github.com/rust-lang/rust/pull/116004 which has instructions for volunteering
<mabez[m]> adamgreig[m]: Oops, didn't scroll to the bottom :D, will submit a PR tomorrow
<therealprof[m]> Huh, wasn't aware that davidtwco was here.
xiretza[cis] has quit [Quit: Idle timeout reached: 172800s]
davidtwco[m] has joined #rust-embedded
<davidtwco[m]> Happy to answer any questions people have about being a target maintainer, I can update our documentation to note down any common questions. In practice, it’s just being able to respond to a very very occasional ping with a question about the target or maybe a request to test something if the compiler team cannot. Generally only comes up if there’s an issue we’re trying to solve with the platform.
Noah[m] has joined #rust-embedded
<Noah[m]> happy to take on something for the embedded-wg if it's for lack of volunteers, but I do not feel as qualified as many folks here would be :)
<Noah[m]> * happy to take on a target for the embedded-wg if it's for lack of volunteers, but I do not feel as qualified as many folks here would be :)
<phaseonx11[m]> Just putting this at the top of the stack agai; Anybody know of any crates to parse J1939 frames? I found CANParse...but it seems to be STD only. Thanks in advance for your help :)
<phaseonx11[m]> s/agai/again/
GenTooMan has quit [Ping timeout: 248 seconds]
GenTooMan has joined #rust-embedded
pbsds has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
lightningwright has quit [Quit: ZNC - https://znc.in]
lightningwright has joined #rust-embedded
ChristianHeussy[ has joined #rust-embedded
<ChristianHeussy[> <phaseonx11[m]> "Just putting this at the top..." <- I'd recommend you grab a j1939 dbc file and use the dbc-codegen crate.
crabbedhaloablut has quit []
M9names[m] has joined #rust-embedded
<M9names[m]> davidtwco: how would a person be pinged in this instance? Zulip/email/GitHub?
<therealprof[m]> M9names[m]: The project is quite GH centric but we're already recording team members by GH account and email, so I guess one of the two.
<ChristianHeussy[> * dbc-codegen crate. You can find dbc files that contain all the standard j1939 messages floating around (https://github.com/nberlette/canbus/blob/main/dbc/j1939.dbc).
<ChristianHeussy[> * dbc-codegen crate. You can find dbc files that contain all the standard j1939 messages floating around ([exmaple](https://github.com/nberlette/canbus/blob/main/dbc/j1939.dbc)).
<ChristianHeussy[> * dbc-codegen crate. You can find dbc files that contain all the standard j1939 messages floating around ([example](https://github.com/nberlette/canbus/blob/main/dbc/j1939.dbc)).