<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]>
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.
<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]
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]>
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
<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]>
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
<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 :)
<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.