<bartmassey[m]>
In an unrelated matter… https://spotlight.gosim.org/ is looking for nominations for new and innovative Rust projects to be presented at Rust Week. If anybody has anything in mind they should nominate it. If they don't feel like nominating they should still send it to me and I'll look at it.
<bartmassey[m]>
Thanks much for increasing our nomination pool! We don't want to miss any good stuff.
i509vcb[m] has joined #rust-embedded
<i509vcb[m]>
On most distros, you need to add your user to the dialout group
<i509vcb[m]>
And then relog (or sometimes reboot)
Andy[m] has joined #rust-embedded
<Andy[m]>
OS error: cannot open port /dev/ttyACM0: Permission denied
<Andy[m]>
and after sudo chown user:user /dev/ttyACM0
<Andy[m]>
Hi everyone. Trying to run a simple project for an Arduino Nano Every I had sitting around my desk, and I keep getting:
<Andy[m]>
ohh, now that you mention that, I recall doing that last time a while ago
<Andy[m]>
After the sudo chown I get past that and the try again and start getting:
<Andy[m]>
mmhhhh! Interesting. I know of the "part one", but the part two, sound promessing. Thanks bartmassey!!
sauce has quit [Ping timeout: 252 seconds]
sauce has joined #rust-embedded
HumanG33k has quit [Ping timeout: 252 seconds]
HumanG33k has joined #rust-embedded
HumanG33k has quit [Excess Flood]
HumanG33k has joined #rust-embedded
HumanG33k has quit [Ping timeout: 244 seconds]
HumanG33k has joined #rust-embedded
HumanG33k has quit [Excess Flood]
HumanG33k has joined #rust-embedded
bitts[m] has joined #rust-embedded
<bitts[m]>
<RobinMueller[m]> "thejpster: Is that an option for..." <- Just be aware that rtt-target uses usize for some of the rtt data while openocd uses uint32_t, so if you are on a 64-bit platform, you might run into some problems..
kenny has quit [Ping timeout: 252 seconds]
pcs38 has joined #rust-embedded
<chrysn[m]>
<thejpster[m]> "Someone wants to change the..." <- Ariel OS is a FLOSS project where some involved are community contributors, there is at least one university involved where I find it hard to tell apart who is paid by the university to work and who pays the university to study there, and there are paid contractors.
<chrysn[m]>
chrysn[m]: I'll ask around if and who has contacts to Ferrous.
<chrysn[m]>
s/contacts/cont(r)acts/
kenny has joined #rust-embedded
<chrysn[m]>
<chrysn[m]> "I'll ask around if and who has..." <- If there is a general "yeah we'll take 916 but we don't know when to merge", that's something I could work from (Ariel OS currently has a bunch of dependencies with PRs upstream, but I prefer to do that only if there is some visible path forward)
<RobinMueller[m]>
Is there some smart way to query the host target when using cargo? My Zynq7000 crate has standard configuration for nightly and for the armv7a-none-eabihf target. I want to build a specific tool only for the host target though. I know that I can override my toolchain config using +stable, but is there something similar for building for the host target is a cross-platform manner?
<RobinMueller[m]>
AI suggested cargo build --target $(rustc -vV | grep host | cut -d ' ' -f2) which would work for me at least on Ubuntu, but feels weird/clunky that there isn´t already something available for this 😅
<RobinMueller[m]>
s/is/in/
<thejpster[m]>
Not that I know of. If you want the host, don't specify --target. This is why I often don't put a default target in the .cargo/config.toml file, because if you do, it's hard to go back to the 'native' target.
whitequark[cis] has quit [Quit: Idle timeout reached: 172800s]
ivche has joined #rust-embedded
<RobinMueller[m]>
thejpster: Are you using svd2rust for your cortex-r devices? Currently, svd2rust does not have cortex-ra support, but maybe adding support would not be that hard. If I understand correctly, some peripherals have a fixed ID in the GIC (might be wrong, I'm still reading about GIC and how to handle interrupt on cortex-a, and how to do it on the zynq), so the auto-generated code could somehow add that, but no device.x and default
<RobinMueller[m]>
handlers are not neccessary for cortex-a and cortex-r
<thejpster[m]>
No, there are no SVD files for my target chips, and I’d rather write portable drivers that work on many chips.
<thejpster[m]>
I wrote derive-mmio to make it easier to write drivers without using svd2rust.
<thejpster[m]>
The whole interrupt situation is interesting. We probably need a dispatcher crate that uses the GIC to work out what interrupt was just fired and then call the registered handler (with weak PROVIDES) like cortex-m-rt does.
<RobinMueller[m]>
thejpster: oh that is actually super interesting. Writing drivers for soft-cores was on my roadmap as well.
<RobinMueller[m]>
thejpster: maybe it would be easier for me to hand-write them using derive-mmio, instead of writing TMR register descriptions into a config file
<RobinMueller[m]>
s/TMR/TRM/
<RobinMueller[m]>
thejpster: I've looked at your GIC example code. The Zynq acutally has a GICv1 implementation, but that should be really similar to v2. I don´t have issues with writing the IRQ handler like you did for the first attempt, but an ergonomic API would probably include something like you mentioned
<RobinMueller[m]>
* drivers for FPGA soft-cores was
<thejpster[m]>
<chrysn[m]> "If there is a general "yeah we'..." <- OK, so I shouldn't post at bed time. Reading the ticket, this is just a breaking change to the decoder API, which needs to wait for decoder 1.0.
<adamgreig[m]>
you can add the cortex-r team for now if you like, and/or me, and when it's set up the new arm team
<mkj[m]>
<diondokter[m]> "They're not really using any..." <- If its lilos that's async
<diondokter[m]>
mkj[m]: Oh true! But I think that's mostly his own project. Within Oxide they only use Hubris afaik.
<mkj[m]>
yeah. "really" small made me think maybe not hubris
<mkj[m]>
anticipates
<diondokter[m]>
He's been posting about his Hubris work. I don't remember the exact numbers, but they can fit a hello world with an otherwise normal kernel in less than 5kb
<mkj[m]>
I reckon async executor per hubris task would work pretty nicely
<MrPashaPG[m]>
SirWoodyHackswel: have you try it on no_std esp board?
<MrPashaPG[m]>
on this example it uses std library!
<SirWoodyHackswel>
I was just searching the fine web. :)
lulf[m] has quit [Quit: Idle timeout reached: 172800s]
<SirWoodyHackswel>
The library itself says it's no_std. But yeah, their example uses one of the std crates. Weird.
<SirWoodyHackswel>
You might have to use embassy rather than tokio?
<SirWoodyHackswel>
Not exactly what you're looking for, but gets you up and running on esp-hal, embassy, and working with sockets. After sockets are working, you can add on the HTTP server layer, no?
<MrPashaPG[m]>
<SirWoodyHackswel> "I was just searching the fine..." <- Yeah I need to see if there's an example for it or if it can be done, but I found another module that looks really good, I hope it's as it shows XD
<DominicFischer[m>
I have used picoserve on ESP32 and it works fantastically
JulianDickert[m] has joined #rust-embedded
<JulianDickert[m]>
<MrPashaPG[m]> "have you try it on no_std esp..." <- > <@mrpashapg:matrix.org> have you try it on no_std esp board?
<JulianDickert[m]>
> on this example it uses std library!
<JulianDickert[m]>
Although it was a bit of a pain to get running back then (iirc something with the trait system had changed and make_static! wouldn't work anymore), I managed to run Pico serve on an rp2040. It works well with no_std and some people report that it works https://github.com/sammhicks/picoserve/issues/2
<MrPashaPG[m]>
<DominicFischer[m> "I have used picoserve on ESP32..." <- do have an example repo to make it work on esp (no_std) ?
<DominicFischer[m>
Not yet, was making one but haven't pushed it yet.
<DominicFischer[m>
You can copy any of the wifi + embassy examples from the esp-hal repo and then add picoserve to it
<DominicFischer[m>
* + embassy-net examples
<MrPashaPG[m]>
DominicFischer[m: send zip file 😅😂
<MrPashaPG[m]>
DominicFischer[m: ok tank you i try it
<chrysn[m]>
<thejpster[m]> "OK, so I shouldn't post at bed..." <- Thanks, that is helpful information I can act on!
<adamgreig[m]>
does anyone know if there's any cfg flag to check if i'm in a build script? i can't find any but i've got some shared code that i want to build slightly differently in the build script vs in the main crate...
<JulianDickert[m]>
<adamgreig[m]> "does anyone know if there's..." <- Maybe you can get somewhere with the env variables cargo sets in build scripts?
<adamgreig[m]>
ok, let's begin with announcements! mabez?
<adamgreig[m]>
or bartmassey, go ahead
<bartmassey[m]>
GOSIM Rust Spotlight will send a bunch of newer innovative Rust project reps to RustWeek. The goal is to expose cool work that otherwise wouldn't be so visible.
<thejpster[m]>
or similar. Ideally you'd all push the project to stablise a native way of doing that, especially as this breaks if you use a -Ctarget-feature=foo to change what a particular target does by default
<thejpster[m]>
I also published cortex-ar which is like a PAC for the inbuilt special registers in AArch32 Cortex-A and AArch32 Cortex-R processors. It's about 150 types, each reading/writing a different CP15 register.
<thejpster[m]>
I hate the code duplication, but I think I hate macros more. PRs welcome.
<thejpster[m]>
Finally I published cortex-r-rt for booting Cortex-R processors. They boot with a zero stack pointer. Actually eight stack pointers, all zero. So quite a bit of stuff has to be done to get them running Rust code. That's now in a library, with some examples that run in QEMU.
<thejpster[m]>
Your CI doesn't have QEMU 9 so you can't run the Cortex-R52 examples, sadly. Suggestions on how to put QEMU 9 into Ubuntu 24.04 without compiling it from source every time welcome. There don't appear to be any binary downloads other than what the OS gives you (which is QEMU 7 I think, or 8).
<thejpster[m]>
i'll pause here
rmsyn[m] has joined #rust-embedded
<rmsyn[m]>
thejpster[m]: you might be able to cache the built binary as an asset
<thejpster[m]>
if you know how to do that, please send a PR. If you get qemu-system-arm version 9 in the CI environment, I will happily add MPS3-AN536 machine based examples.
<rmsyn[m]>
for sure, I'll spend some cycles to try to get something working
<adamgreig[m]>
hm yea, I can't find anything for pre-built qemu, I think there was a ppa once but no more
<adamgreig[m]>
thanks for the summary, sounds good!
<adamgreig[m]>
what would you like to discuss on the team stuff?
<thejpster[m]>
so, we had a proposal. You wrote up an RFC which I appreciate. But the instructions for enaging with the RFC appear to have been ambigious. Several of the relevant members interacted with the RFC, but interacted with it wrongly.
<thejpster[m]>
They then had to be asked to interact with it again, but properly. And the whole process has taken a month at this point.
<thejpster[m]>
Perhaps some lessons to be learned there.
<thejpster[m]>
But more importantly? Are we over the line yet? You are eligible to vote Adam, but haven't. Are you for or against?
<thejpster[m]>
Also, raw-bin works at SiFive now and not Arm and probably isn't engaging much on Arm stuff.
<thejpster[m]>
I don't know what the process is for managing membership over the long term.
<thejpster[m]>
jannic[m]: Nice. I wonder if that will just install onto 24.04. Could be an easy win.
<adamgreig[m]>
I'm ambivalent on merging the teams so was hoping it wouldn't come down to my vote, and I'll double check the numbers but I think from today we're over the line regardless
<adamgreig[m]>
in terms of membership over the long term, the current process is that people can ask to retire from a team and are then removed, but afaik we're yet to remove someone for inactivity or anything like that, though we have a few times asked people who've not appeared in a while if they're still interested in being involved
<therealprof[m]>
I've just checked the box. 😉
<thejpster[m]>
The intention of merging the teams was to resolve issues around Cortex-R not getting attention. Based on the preceeding, I'm not entirely sure merging the teams will fix the issue.
<adamgreig[m]>
cool, then we're definitely over the line! I'll action the RFC tonight
<thejpster[m]>
thank you
<adamgreig[m]>
right, as I said at the time merging the teams doesn't magically make people who are the skills/interest/time to help with cortex-r crates appear
<adamgreig[m]>
but it does help simplify the team structure which is useful too
<thejpster[m]>
robamu has been doing good work on cortex-a support and has expressed interest in joining.
<adamgreig[m]>
great, sounds good
<adamgreig[m]>
what's the overlap between our aarch64-cpu crate and your new cortex-ar crate?
<thejpster[m]>
None. AArch64 has an entirely different mechanism for accessing system registers.
<thejpster[m]>
yes, we could rename the repo (as long as links from the published crates don't stop working)
<dirbaio[m]>
Cortex-arr! 🏴☠️
<adamgreig[m]>
but does it overlap in the registers it defines? would it make sense for cortex-ar to eventually also define the aarch64 registers / does it already?
<thejpster[m]>
from my initial observations, AArch64 is kind of a clean sheet. But someone is welcome to go through the 14,500 page Architecture Reference Manual and highlight any overlaps.
<adamgreig[m]>
cool, I wasn't sure if there was much overlap in the system registers that might make sense to combine
<thejpster[m]>
That will go entirely in the aarch64 crate.
DavidBrown[m] has joined #rust-embedded
<DavidBrown[m]>
Where does the R82 fit in? It implements the Aarch64 architecture.
<DavidBrown[m]>
Makes sense.
<DavidBrown[m]>
Lol: "However, many real-time operating systems (RTOS), with an emphasis on total control, have traditionally regarded the lack of an MMU as a feature, not a bug." (Wikipedia)[https://en.wikipedia.org/wiki/ARM_Cortex-R]
<DavidBrown[m]>
* Lol: "However, many real-time operating systems (RTOS), with an emphasis on total control, have traditionally regarded the lack of an MMU as a feature, not a bug." [Wikipedia](https://en.wikipedia.org/wiki/ARM_Cortex-R)
<adamgreig[m]>
thejpster: last point the agenda is yours about arm's new crates
<thejpster[m]>
Arm have been publishing Rust crates, which is great
<thejpster[m]>
but there are nine PL011 UART driver crates
<thejpster[m]>
arguably, some of these might not have existed if people had been happy to use other ones.
<thejpster[m]>
So is something going wrong here? Are people repeatedly making bad crates? Are good crates not discoverable?
<thejpster[m]>
Do people just think "I want to make a UART driver, even though there are eight already out there"?
<adamgreig[m]>
I guess it being the uart in the rpi (right?) makes it an appealing choice for a lot of people wanting to try such a thing
<thejpster[m]>
it's in a lot of things, but yes, I believe the Broadcom VideoCore SoCs include PL011 UARTs. I think the RP2040 and RP2350 also have PL011 UARTs.
<adamgreig[m]>
still, is it a problem? especially if those drivers could implement something like embedded-io then they should be reasonably interchangeable and people can pick whichever suits them best
<thejpster[m]>
Right, but how do you choose from this list?
<adamgreig[m]>
it's maybe more of an issue if people are writing all these copies of the driver crate because they can't find an existing one, but if you find so many with a crates.io search for pl011 i'm not sure there's anything we can do to make them easier to find
<adamgreig[m]>
thejpster[m]: probably I sort crates.io by most downloads, or use the official arm one, until it doesn't work for some reason and then investigate others?
<jannic[m]>
The obvious choice is looking at the awesome-embedded-rust list. But wait: It looks like none of the 9 drivers is on that list. Are they all non-awesome?
<therealprof[m]>
Yeah, crates.io can get really unwieldy...
<adamgreig[m]>
we could certainly add them to a-e-r or https://tweedegolf.github.io/drive-rs/, to help make them more discoverable, but we haven't generally made a point of recommending certain third-party crates over other similar ones in the past
<adamgreig[m]>
I suspect they're all far from the usual embedded work that no-one's added them; they're generally present on SoCs where you're more likely to be running linux
<adamgreig[m]>
not saying they don't belong on the list!
<adamgreig[m]>
just that's probably why they've not been added yet
<adamgreig[m]>
well, more directly it's because their authors haven't added them, and generally most of the crates on the list were added by their authors
<thejpster[m]>
you don't write a PL011 driver if you are running Linux. And writing a bare-metal for big SoC is still Rust Embedded.
<thejpster[m]>
perhaps there's an opportunity to widen the focus here beyond microcontrollers
<adamgreig[m]>
yea, it's definitely still rust embedded! i'd happily have those crates on the list
<adamgreig[m]>
what do you imagine is done to widen the focus beyond microcontrollers? obviously your work right now on cortex-ar stuff is relevant there too
<adamgreig[m]>
but most of the work on things like drivers and HALs and such has taken place outside of the wg; we've worked more on abstraction traits like e-h and e-io, and system/arch crates like the architecture crates, and some tooling
<thejpster[m]>
I guess the starting point is examples and run-time code.
<adamgreig[m]>
it seems a bit harder with MPUs since there's a lot less commonality and working bare-metal on them is also generally less popular
<thejpster[m]>
I've found a lot of commonality so far - the MPU is well defined by Arm. And while people do put RTOSes on them, they still boot bare metal and there's a lot to do before you start the RTOS.
<adamgreig[m]>
oh, so like rust code for the initial bootloader before the rtos?
<DavidBrown[m]>
The capabilities of the MPU differ quite drastically, though, mostly in the number of regions allowed, which general determines what is practical to do with it.
<thejpster[m]>
adamgreig[m]: yes - that's how I run ThreadX. All the start-up and drivers are in Rust. ThreadX does the task scheduling.
<thejpster[m]>
anyway, I just wanted to make the observation. I leave the WG to decide whether it can or whether it wants to change anything.
<adamgreig[m]>
great, thanks for the discussion! that's it for today's meeting, I'll sort out the team merging over this evening
cr1901_ has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
<JamesMunns[m]>
<thejpster[m]> "anyway, I just wanted to make..." <- Do you think you could write up the things that you think are missing, and we could write a call to action post to try and recruit folks interested in a/r/aarch64?
<JamesMunns[m]>
It's so far out of my lane I don't think I'd be even helpful in finding the right folks to help, honestly.
<thejpster[m]>
I don't have the words right now. Maybe words will come to me.
pcs38 has quit [Quit: leaving]
<berkus[m]>
<thejpster[m]> "Right, but how do you choose..." <- I have a PL011 uart which is not yet published as a crate :D
<berkus[m]>
But i hope it never will.
<berkus[m]>
I suspect that implementing a pl011 is so simple that it's a very nice first target for trying embedded mmio out.