jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
starblue has quit [Ping timeout: 255 seconds]
starblue has joined #rust-embedded
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
sroemer has joined #rust-embedded
ska has quit [Ping timeout: 252 seconds]
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
whitequark[cis] has joined #rust-embedded
<whitequark[cis]>
the problem with the arduino ecosystem is that it's universally terrible, not just by "we want to reassure ourselves that our code will be be reliable" standard, but even by the "we want this firmware to build, and by gods we hope it will do something useful too" bar
<whitequark[cis]>
digitalWrite() and friends work reliably, the moment you need anything beyond "low throughput, questionably realtime event loop" you're screwed
<whitequark[cis]>
every major project that i'm aware of which was based on an arduino sketch (marlin, for example) came to regret it sooner or later
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
<whitequark[cis]>
but, I think one can also observe that it's only a "problem" from my perspective, and the people who want the Arduino IDE experience the most largely do not care about anything beyond "i am able to build and deploy a crude prototype of a firmware at a single point of time from my one machine"
<whitequark[cis]>
if that's all you want, then most of the features rust is built around just look like net-negative ceremony
<whitequark[cis]>
this is related to / complicated by the "Processing" library that Arduino is based on in concept (and, i think, still the implementation?) is hilariously badly designed even by the standards of the age that it comes from
<whitequark[cis]>
the two obvious groups with enough motivation to implement something like Arduino are "people who really don't want to think about their code" and "people who are satisfied with a primitive API". both of these groups is probably better served by them continuing to use Arduino
<whitequark[cis]>
s/is/are/
<whitequark[cis]>
there's also "teachers in western academia", a group i have a minimal understanding of and will not speak further
<whitequark[cis]>
thinking about it a bit more, i suspect that the solution that would serve the needs of these users the most if you make "it uses actual Rust" a fixed requirement is to rig up one of those C++ binding generators to just put all of the crap you'd normally have in scope by the time you have setup and loop inside the Rust module scope too
<whitequark[cis]>
because it means that you don't have to put in a giant chunk of your lifetime to the task of intentionally building a product you think is sub-par and then maintaining it while being inundated with support requests you can't possibly handle well
<whitequark[cis]>
s/a/software/, s/product//
<whitequark[cis]>
you could instead replace it with an intellectually challenging and demanding (and fun) task of "solving the puzzle that is embedding C++ APIs into Rust". if you define the scope of that project carefully enough you could maybe manage to not think about Arduino while building it at all, meaning it would actually get built
i509vcb[m] has joined #rust-embedded
<i509vcb[m]>
Where Arduino gets real fun is when your project hits the point of complexity to that requires something that feels (or is) an RTOS
<i509vcb[m]>
s/to//
<i509vcb[m]>
* Where Arduino gets real fun is when your project hits the point of complexity that requires something that feels like (or is) an RTOS
<whitequark[cis]>
"solving [that] within the constraints of actually-existing-arduino-library" is, to me, one of those "these are not made. these should never be made. we will not assist you in the creation of them" things
<i509vcb[m]>
I know people who work in places where it is literally company policy to use an RTOS if you don't have a Linux userspace around
<whitequark[cis]>
you cannot take a pile of code that relies on universal ambient authority and makes wild and completely unchecked assumptions about the environment it runs in, and somehow put it into a more restrictive environment
<whitequark[cis]>
i509vcb[m]: straight line ALGOL code is notoriously terrible at the handling of multiple independent streams of concurrent events. especially if you ever get input you cannot guarantee can be processed at the rate it arrives
<whitequark[cis]>
an RTOS is useful as a reasoning tool: it gives you one way to make a timer, however terrible it is, so you stop inventing bespoke, incompatible, and subtly broken ways of making a timer every time you need one
<whitequark[cis]>
this would be much less of a requirement if we routinely wrote microcontroller firmware in, say, Erlang
<whitequark[cis]>
but if you can afford to put Erlang on a microcontroller in a production design, you are probably already ready for the final evolutionary stage of this arc: simply putting an FPGA there (to be clear this message is mostly a joke)
<i509vcb[m]>
whitequark[cis]: Until you need a `Ticker` from embassy-time and some of the off the shelf RTOSes don't work like that
<whitequark[cis]>
i want to put a really heavy emphasis on "however terrible"
<whitequark[cis]>
in my opinion, the primary benefit of a "use an RTOS dummy" policy is that a singularly bad solution adds up to less engineering overhead over long timescales than ten somewhat less bad solutions. or even ten good solutions
<whitequark[cis]>
* good solutions between which you can't usefully transfer skills
<i509vcb[m]>
Massive superloops are not fun to write either
<whitequark[cis]>
well also depending on an RTOS it lets you synchronously wait for asynchronous events
<whitequark[cis]>
* well also depending on an RTOS it might also let you synchronously wait for asynchronous events
<whitequark[cis]>
which should be the job of the compiler
<i509vcb[m]>
embassy I think takes the right approach here and makes the compiler do all the funny task stuff
<i509vcb[m]>
And the resource usage is low to where I can run embassy on an MCU with 1KB of RAM
<i509vcb[m]>
(I don't think Zephyr could fit in 1KB at all)
<whitequark[cis]>
yeah
<whitequark[cis]>
you could do this with modern C++ too if you wanted, and there are (really horrible) libraries for C too
<whitequark[cis]>
(really if you wanted to do it in C you should implement emscripten's asyncify instead of piling on macro abominations, but this will fall on fear ears)
<JamesMunns[m]>
re: RTOS and async: If you want a comparison that is IMO MOST like Rust's async/await, it's "protothreads", which existed exactly to allow cooperative "async/await-like" time slicing on chips with 1-4KiB of RAM, like old AVRs and MSP430s. It's almost the same execution model, but because it's C, it uses macros and a duff's device, and all your variables have to be statics because you `goto` all over the place. Despite that, it's
<JamesMunns[m]>
incredibly similar to rust's async/await in terms of "how the cpu moves around tasks".
<whitequark[cis]>
yes, protothreads is exactly the library i didn't want to advertise
<JamesMunns[m]>
(it's an abomination, for sure, it's just funny how close we ended up to some of the niche classics, just with actual compiler support instead of horrifying macros)
<JamesMunns[m]>
I figured you would know protothreads Catherine, wasn't sure if i509vcb did :D
<thejpster[m]>
Is it me or is matrix broken today?
<thejpster[m]>
Failed posts. Failed to sync chat. Repeatedly.
<JamesMunns[m]>
Seems to be working fine for me, but I'm using the beeper client and not element
<RobWells[m]>
Fell over for me about 20 minutes ago.
<RobWells[m]>
Seems to be back now 🤷♂️
<RobWells[m]>
Without wanting to pour fuel on the Arduino fire, speaking personally in terms of learning specifically, having it take care of things so you can just, for example, write pinMode(8, OUTPUT); tone(...) to buzz a piezo speaker was helpful.
<RobWells[m]>
But then I found that level of "magic" really got in the way to understanding when it came to something like I2C, and calling Wire.begin() just magically sets up the peripheral on particular pins in the background.
<JamesMunns[m]>
Starting in about 10m (10:30 CEST), feel free to come hang out or ask questions :)
jfsimon has quit [Read error: Connection reset by peer]
jfsimon has joined #rust-embedded
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
<dngrs[m]>
<RobWells[m]> Without wanting to pour fuel on the Arduino fire, speaking personally in terms of learning specifically, having it take care of things so you can just, for example, write pinMode(8, OUTPUT); tone(...) to buzz a piezo speaker was helpful.
<dngrs[m]>
I haven't looked too deeply into it but I've heard good things about [Ariel OS](https://github.com/ariel-os/ariel-os) which could serve as a potential higher level/cross-vendor HAL like thing
<dngrs[m]>
<whitequark[cis]> but, I think one can also observe that it's only a "problem" from my perspective, and the people who want the Arduino IDE experience the most largely do not care about anything beyond "i am able to build and deploy a crude prototype of a firmware at a single point of time from my one machine"
<dngrs[m]>
to be clear I don't think there's anything particularly *good* about Arduino but I can see why it became the dominant force with "makers getting started with embedded stuff". I do think there's a lot of potential to build something similar in spirit but much higher quality in Rust, and my main focus would be tooling - IDE support that gets you off the ground quickly (I'm not a huge fan of `cargo-generate` based approaches), and
<dngrs[m]>
quickly accessible ways to interact with your board and sensors, e.g. realtime data plotting, or a UI that triggers sensor readings, actuators etc. What a coincidence, I literally [built those things and gave a talk on it](https://youtu.be/Z_8v9V2GTrg?t=1457) :D (timestamped link to the demo part) - but I haven't succeeded in nerdsniping anyone for more momentum, and as a single dev with ADHD and Long Covid I only have so much steam
<whitequark[cis]>
what i feel is that "higher quality" and "arduino" in one sentence is sort of a non-sequitur because of people's expectations of what they can do and how quickly and with what attitude
<dngrs[m]>
whitequark[cis]: I sympathize with that viewpoint; that said "think arduino but a lot better" is something I'd find acceptable as a sales pitch/explanation of `$imaginary_thing`. People are familiar with Arduino so that can help folks understand. But as a measuring stick, yeah, I don't consider it a good one either.
<whitequark[cis]>
i just mean that people don't expect to be investing the amounts of time doing something better requires
<whitequark[cis]>
it's less about arduino as a brand and more about how people actually use the thing
<dngrs[m]>
What I do find potentially useful but haven't been able to make time for myself is something along the lines of a monthly video that's "let's take this popular Arduino project and port it to Rust, keep track of both the pain points when starting the Rust project and the stuff that's a lot smoother"
<whitequark[cis]>
if your users are fundamentally uninteretsed in e.g. ever rewriting their code because the upstream API changed, you won't be able to make something radically better
<dngrs[m]>
I'm not sure I fully understand your point tbh but it sounds to me you're more focusing on the API parts whereas I'm more interested (but not exclusively - see Ariel OS I linked earlier) on the tooling
<dngrs[m]>
s/on/in/
<dngrs[m]>
ah, now I think I get it, you're talking about the hurdles of convincing people to port their existing projects?
<dngrs[m]>
that's definitely a big challenge but also not something I'd lose too much sleep over, just having an alternative one can point people to who are looking to start a new project would be a big win in my book
<dngrs[m]>
* that's definitely a big challenge but also not something I'd lose too much sleep over, just having an alternative one can point people to who are looking to start a new project would be a big win in my book
<dngrs[m]>
like, you gotta start somewhere
<dngrs[m]>
I don't think embedded Rust is "finished"
<dngrs[m]>
s/finished/done/
<dngrs[m]>
is all I'm saying really
jfsimon has quit [Read error: Connection reset by peer]
<whitequark[cis]>
no, i do not
<whitequark[cis]>
frameworks like arduino exist not just as an artifact at a moment in time, they necessarily evolve. let's say you wrote some code for rustduino release 2025.0. people will very much expect this code to work the same way, with no modifications, in rustduino release 2030.0
<whitequark[cis]>
this expectation is incompatible with making better software
<dngrs[m]>
I am unsure how much I agree with this. My gut feeling is that it's too universal a statement for me to say "yeah, that's a good counterpoint". At the same time I don't want to dismiss it. Probably need to chew on it for a while.
<dngrs[m]>
<whitequark[cis]> the two obvious groups with enough motivation to implement something like Arduino are "people who really don't want to think about their code" and "people who are satisfied with a primitive API". both of these groups is probably better served by them continuing to use Arduino
<dngrs[m]>
this one I do strongly disagree with tho. I don't think anyone should continue to use Arduino (C/C++ need to be replaced and I was extremely frustrated trying to get anything done with PlatformIO, discovering embedded Rust a few years later was *so* much better, fun and productive). And maybe I'm getting repetitive but my point was never to replicate any *specifics* of Arduino but rather to work on an ecosystem with similar
<dngrs[m]>
capabilities (quickly start a project, be as vendor agnostic as reasonable, have tooling/debugging via data viz etc)
<dngrs[m]>
* this one I do strongly disagree with tho. I don't think anyone should continue to use Arduino (C/C++ need to be replaced and personally I was extremely frustrated trying to get anything done with PlatformIO, discovering embedded Rust a few years later was so much better, fun and productive). And maybe I'm getting repetitive but my point was never to replicate any specifics of Arduino but rather to work on an ecosystem with
<dngrs[m]>
similar capabilities (quickly start a project, be as vendor agnostic as reasonable, have tooling/debugging via data viz etc)
<dngrs[m]>
case in point, I recently ported embassy's [`wifi_esp_hosted` example](https://github.com/embassy-rs/embassy/blob/main/examples/nrf52840/src/bin/wifi_esp_hosted.rs) from nrf52840 to stm32f401 and if surely wasn't *difficult* but also kinda felt like a waste of time and lots of duplicated code. This isn't meant as a criticism of any API here but I keep running into scenarios where the vendor specific part is 95% just naming
<dngrs[m]>
(yes, depending on the exact project the remaining 5% can be a deal breaker for sure)
<dngrs[m]>
s/if/it/, s/*difficult*/_difficult_/
<dngrs[m]>
* this one I do strongly disagree with tho. I don't think anyone should continue to use Arduino (C/C++ need to be replaced and personally I was extremely frustrated trying to get anything done with PlatformIO (Arduino APIs decoupled from the IDE), discovering embedded Rust a few years later was so much better, fun and productive). And maybe I'm getting repetitive but my point was never to replicate any specifics of Arduino but
<dngrs[m]>
rather to work on an ecosystem with similar capabilities (quickly start a project, be as vendor agnostic as reasonable, have tooling/debugging via data viz etc)
<thejpster[m]>
I have an opportunity to complete a survey for a University regarding some rust projects on r-e-c, and to say thank you I will get a $5 payment via PayPal.
<thejpster[m]>
Give that post a thumbs up if you’d click the link and a thumbs down if you would not.
<dngrs[m]>
that's kinda funny, I can only assume their main demographic is students where this kind of compensation is ... not super unusual?
<whitequark[cis]>
<dngrs[m]> this one I do strongly disagree with tho. I don't think anyone should continue to use Arduino (C/C++ need to be replaced and I was extremely frustrated trying to get anything done with PlatformIO, discovering embedded Rust a few years later was *so* much better, fun and productive). And maybe I'm...
<whitequark[cis]>
i think we essentially agree on views on principles but have a comparatively minor disagreement on tactics
<whitequark[cis]>
(which is fine obviously, this is just my conclusion after reflecting on the convo)
<dngrs[m]>
Oh yeah I didn't have the impression we were having a fight or anything
<dngrs[m]>
Anyway, always glad to be on the same page
ouilemur has quit [Ping timeout: 255 seconds]
ouilemur has joined #rust-embedded
therealprof[m] has joined #rust-embedded
<therealprof[m]>
Just a quick note, I won't make it to todays meeting. My apologies.
AstraKernel[m] has quit [Quit: Idle timeout reached: 172800s]
andwass[m] has quit [Quit: Idle timeout reached: 172800s]
khionu[m] has joined #rust-embedded
<khionu[m]>
Previously, I've just copied the examples as far as defmt-rtt is concerned and things just worked, but I have an example that doesn't have it built in, so I'm having to read up so I can determine if I can use it in this case. It's not clear to me if there are any device requirements in order to be able to use defmt-rtt? The chip I'm using is a CH32V006, so RISC-V, fwiw
<khionu[m]>
Someone elsewhere suggested that RISC-V devices can't use RTT
<thejpster[m]>
it relies on the debug probe being able to read/write SRAM whilst the MCU is running. Arm provided standardised debug hardware as part of every Cortex-M processor that can do this.
<khionu[m]>
Apparently it requires CPU halting by the debugger, which this chip doesn't support
explodingwaffle1 has joined #rust-embedded
<explodingwaffle1>
the ch32s don't implement some (unfortunately) optional risc-v debug feature that lets the probe access memory without halting the CPU, so RTT is basically non-viable on those. (what jp said)
<explodingwaffle1>
their SDI feature does get you a serial output over the debug connection which you can use instead (by piping it into demt-decoder), but it's kinda low-documentation and awkward because you need to enable it on the wch-link and it doesn't persist and probe-rs doesn't support it so you need to use something else like wlink... I did have it working at somepoint, but tldr good luck
<thejpster[m]>
yes, to be clear, defmt simply requires a byte pipe. knurling supplies transports for SEGGER RTT (defmt-rtt, which is built into probe-rs) or Semihosting (defmt-semihosting, which I use with QEMU), but others send it over a UART or Arm DCC.
<adamgreig[m]>
first up, welcome sgued to the libs team! 🎉
sgued[m] has joined #rust-embedded
<sgued[m]>
Glad to be here to help heapless maintainance
<adamgreig[m]>
thejpster, on your point I'm not sure what exactly you want to discuss?
<adamgreig[m]>
if I understand the problem it's that having these #[used] statics around fails when embedded targets get built for hosted platforms which didn't used to be the case but I would have thought is a fairly rare build config?
<adamgreig[m]>
in cortex-m for example we have a github ci cron build that opens an issue on failure which i would expect to catch this sort of problem, so maybe that's a suitable pattern
<zeenix[m]>
but very glad to see your application getting approved. Looking forward to working with you on this
<adamgreig[m]>
I guess jpster isn't around just now, so final agenda point is a highlight that embedded-io is ready for a 0.7 release that will hopefully become 1.0 without any further breaking changes, https://github.com/rust-embedded/embedded-hal/issues/566
<adamgreig[m]>
that's all I had, does anyone have anything else they want to discuss or mention?
chrysn[m] has joined #rust-embedded
<chrysn[m]>
just a mention:
<chrysn[m]>
TockWorld Europe is just ending, and there is some interest in moving closer to the rest of tje Rust embedded ecosystem
<chrysn[m]>
(at least in terms of providing the interfaces to applications)
<adamgreig[m]>
what do you think that would look like? the sort of embedded-hal/io/etc traits?
<chrysn[m]>
Yes, implementing the traits.
<chrysn[m]>
Of course there's some impedance mismatch, eg around passing slices between kernel and userspace
<thejpster[m]>
oh hey, sorry, was having dinner
<thejpster[m]>
yes, my specific issue is that a) rp-hal suffered a stable-to-stable breakage (arguably we were holding 'used' wrong and expecting the values to be not in fact used when compiling on Linux/macOS/Windows and now they are), but also that we didn't find out until after stable was released.
<thejpster[m]>
what's the mechanism for target maintainers being informed about potential breaking changes to their targets?
<thejpster[m]>
(fwiw I think I was pinged somewhere on an issue about #[used] but I guess I didn't think about it too hard)
<thejpster[m]>
the output here might be "every really needs to test on beta" and that's OK. But maybe there are better options to catch the next change.
<adamgreig[m]>
from the issue it doesn't look like it was foreseen that it would be a breaking change to some targets?
<adamgreig[m]>
so I think the only discovery would indeed have been testing on beta, or on latest stable and hope to catch it fairly promptly
<thejpster[m]>
and then perhaps reporting it to the world via a blog post, to avoid surprises
<thejpster[m]>
ideally in advance of the release, but at least with the release
<thejpster[m]>
there's nothing in the official release notes about changing the ABI type for a bunch of targets, or that behaviour around #[used] might cause things to break if you were doing it wrong
<adamgreig[m]>
yea, I don't think this was an expected consequence at all, it sounds like even changing the reported abi isn't expected
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
Some new compiler warnings in Rust 1.89 also broke build for nrf-hal. I question whether -D warnings in CI is a good idea, but we're doing it currently.
<thejpster[m]>
oh, no, -Dwarnings is a terrible idea unless you pin clippy
<thejpster[m]>
anyway, currently targets change and we should probably be ahead of the curve on that otherwise people will be confused. And if we're not here to solve confusions around compiler changes for embedded rust targets then .... ?
<bartmassey[m]>
Actually, just realized that this is going to suck for teaching Rust.
<adamgreig[m]>
thejpster: right, but the only way to have caught this would be to have a library that's (incorrectly?) using #[used]?
<adamgreig[m]>
possibly we should add the betas to the weekly cron runs
<thejpster[m]>
for the used issue, yes - rp-binary-info is one such library
<thejpster[m]>
for the ABI issue, you would only catch it by inspecting the ELF files that rustc generates
<thejpster[m]>
(which we should probably do as a canary)
<adamgreig[m]>
ah, gotcha
<thejpster[m]>
> possibly we should add the betas to the weekly cron runs
<thejpster[m]>
good idea. nightly too, perhaps
<thejpster[m]>
or readelf
rmsyn[m] has joined #rust-embedded
<rmsyn[m]>
thejpster[m]: could this be done with tools like objdump in a CI job?
<thejpster[m]>
with a canonical text in the repo, and a diff printed.
<thejpster[m]>
the other solution is to somehow get notifications about these changes from the project
<thejpster[m]>
(and notice their significance when they come)
ello has quit [Ping timeout: 244 seconds]
ello- has quit [Ping timeout: 244 seconds]
<rmsyn[m]>
maybe ask for a specific tag on relevant PRs / issues? then people interested could subscribe to those
<adamgreig[m]>
nightly on the cron I suspect would be a bit noisy
<adamgreig[m]>
a readelf diff of what gets generated is interesting but it seems like it would be hard to work out the false positives and significance of changes, I bet there's been a lot of changes over the versions that haven't had any impact
<sgued[m]>
<adamgreig[m]> first up, welcome sgued to the libs team! 🎉
<sgued[m]>
I haven't yet received maintainance rights on heapless, is there anything specific I should know before that ?
<thejpster[m]>
I think the workflow is: a) we update our docs, b) we send a PR to the teams repo, c) the project review it against our docs, d) automatiions update the repo permissions accordingly.
<adamgreig[m]>
yea, I've opened https://github.com/rust-lang/team/pull/1944 which should be merged soon, then various automations cause you to be added to the relevant team
ello has joined #rust-embedded
<adamgreig[m]>
the repo permissions specify the team, so being in the team gives you repo access
<sgued[m]>
Good!
ello_ has joined #rust-embedded
<khionu[m]>
What are .x files?
<khionu[m]>
And what is the --nmagic flag for?
<sgued[m]>
khionu[m]: They are called linker scripts
<khionu[m]>
sgued[m]: Thanks!
firefrommoonligh has quit [Quit: Idle timeout reached: 172800s]
GuineaWheek[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
<khionu[m]> And what is the --nmagic flag for?
<thejpster[m]>
It tells the linker that sections might not be aligned to 64K boundaries. Or something like that.
<thejpster[m]>
You tell the linker to use link.x which is shipped in cortex-m-rt. This then imports an MCU specific fragment called memory.x which says how much RAM and Flash you have.
<thejpster[m]>
Perhaps the foundation can donate something to Matrix. This WG would be much poorer without this (free! Rust based! Open source!) chat platform
cr1901 has quit [Read error: Connection reset by peer]