crabbedhaloablut has quit [Ping timeout: 268 seconds]
loki_val has joined #rust-embedded
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
<re_irc>
<bradhesson> Hello! I am trying to compile a project for the esp32-c3 chip. It was working fine, but now I am trying to use a crate I wrote that uses a C library. Now the linker fails at the end of compilation with the following:c:/users/brad-hesson/desktop/code/esp-idf/.embuild/espressif/tools/riscv32-esp-elf/esp-2021r2-patch3-8.4.0/riscv32-esp-elf/bin/../lib/gcc/riscv32-esp-elf/8.4.0/../../../../riscv32-esp-elf/bin/ld.exe:...
<re_irc>
... C:\Users\brad-hesson\Desktop\code\esp-idf\target\riscv32imc-esp-espidf\release\deps\libvl53l3cx_driver-df7f7abefb0c4200.rlib: error adding symbols: file format not recognized
<re_irc>
<bradhesson> hoping someone can point me in the right direction
<Darius>
check the file isn't just empty
<Darius>
if the build craps out you can end up with a runt file that the make process thinks is there but is roken
<re_irc>
<bradhesson> the rlib file is not empty, it starts with "!<arch>" and is about 3Mb
explore has quit [Quit: Connection closed for inactivity]
<re_irc>
<bradhesson> this is a link to the crate I am trying to use: https://github.com/Brad-Hesson/vl53l3cx-driver/tree/fixes-for-esp32c3 The branch I linked includes some things that I needed to change in order to get this far into compilation. I have to use a local clone of the CC crate repository rather than the crates.io version for some reason. I also need to manually set the target in the build script for bindgen, because it...
<re_irc>
... does not correctly change the target triple from "riscv32imc-esp-espidf" to "riscv32-esp-espidf"
emerent_ has joined #rust-embedded
emerent_ is now known as emerent
emerent has quit [Killed (zinc.libera.chat (Nickname regained by services))]
loki_val has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
explore has joined #rust-embedded
brazuca has quit [Ping timeout: 252 seconds]
Amadiro_ has joined #rust-embedded
Amadiro__ has quit [Ping timeout: 268 seconds]
starblue has quit [Quit: WeeChat 3.0]
explore has quit [Quit: Connection closed for inactivity]
gsalazar has quit [Quit: Leaving]
gsalazar has joined #rust-embedded
dc740 has joined #rust-embedded
<re_irc>
<mabez> bradhesson: riscv32-esp-espidf is a Rust target, clang doesn't know what that is. I'm surprised doesn't fail here. Try setting CC to "riscv32" instead
explore has joined #rust-embedded
<re_irc>
<nikx> Hey there, I was wondering if maybe someone would have an example for using BLE on the stm32wb with Rust?
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
Guest14 has joined #rust-embedded
Guest14 is now known as brazuca
brazuca has quit [Quit: Client closed]
explore has quit [Quit: Connection closed for inactivity]
Guest14 has joined #rust-embedded
Guest14 is now known as brazuca
gsalazar has quit [Quit: Leaving]
gsalazar has joined #rust-embedded
Amadiro__ has joined #rust-embedded
Amadiro_ has quit [Ping timeout: 240 seconds]
gsalazar has quit [Ping timeout: 240 seconds]
<re_irc>
<explodingwaffle101> been procrastinating driver design again recently- was thinking about ways to "split up" a driver so it can be used in multiple places- found port-expander described here, and i must say the way it internally used shared_bus is pretty clever https://blog.rahix.de/port-expander/ if slightly convoluted. nice work rahix
<re_irc>
<rahix> :)
gsalazar has joined #rust-embedded
gsalazar has quit [Ping timeout: 240 seconds]
gsalazar has joined #rust-embedded
rardiol has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<adamgreig> room meeting time again! agenda's https://hackmd.io/BY5dOM9tSxqo_d095EoSUQ, please add anything you'd like to announce or discuss and we'll start in 5min
<re_irc>
<adamgreig> finally a quick shoutout to the efm32-rs project which I think started back in june but just dropped onto the awesome-embedded-rust list last week, https://github.com/efm32-rs
<re_irc>
<chrysn (@chrysn:matrix.org)> Nice to see EFM32 being picked up. I started something on these years ago at https://github.com/em32-rs/wg and shamefully let it slide. Happy to transfer anything I've left unfinished if there is any interest.
<re_irc>
<adamgreig> I couldn't see any central coordinating/collaborating repo on the new efm32-rs org
<re_irc>
<adamgreig> i2c is so widely used that it would be nice to get some feedback from driver and hal authors and end users on what it looks like, I think; hopefully this new design is a lot nicer to use especially for multiple devices on a bus
<cr1901>
So this is for alpha 9?
<re_irc>
<eldruin> yep
<re_irc>
<almindor> I'm for the "impl<T: I2cBus> I2cDevice for T" for I2C
<cr1901>
I can't test these until someone ports the new traits to linux-embedded-hal and embedded-hal-mock
<cr1901>
And last month, alpha-8 for either of those wasn't merged yet
<cr1901>
And embedded-hal-compat isn't merged for alpha-8 either
<re_irc>
<adamgreig> at this stage it's more about what the design looks like than testing specific implementations
<re_irc>
<adamgreig> they're not even merged into embedded-hal
<cr1901>
I'll take a look, but I'm sure it's fine
<cr1901>
I'll have to build the docs locally tho- kinda not fun to read them on GH XD
<re_irc>
<adamgreig> last week we also discussed splitting out the "nb" traits into their own crate, https://github.com/rust-embedded/embedded-hal/pull/394, though I think we basically said everything that needed saying last week
<re_irc>
<adamgreig> hmm, I'm also not sure what exactly there was to discuss about whether the blocking CAN trait should specify blocking receive vs "is there a new frame ready to read"
<re_irc>
<adamgreig> if any other CAN users are around... it seems like almost always the CAN frame is buffered locally and the user probably just wants to check if one's available or not, rather than blocking on receiving it
<re_irc>
<Chris [pwnOrbitals]> yeah, I feel like the current CAN implementations are fine tbh
<re_irc>
<adamgreig> as in, you think it should only provide a way to do a blocking receive?
<re_irc>
<Chris [pwnOrbitals]> blocking receive + peek are good
<re_irc>
<adamgreig> currently the blocking trait doesn't have a peek()/available() etc method
<re_irc>
<adamgreig> the "nb" based trait has receive()->nb::Result, but the blocking one is just receive() that blocks until a frame is available
<re_irc>
<dirbaio> the discussion about blocking CAN receive was as an argument for "it's not ready for 1.0"
<re_irc>
<dirbaio> if it's getting split into its own crate then it's no longer blocking
<re_irc>
<dirbaio> +(heh) the 1.0 release
<re_irc>
<adamgreig> indeed
<re_irc>
<dirbaio> but it's the same "underlying issue" as blocking UART receive :)
<re_irc>
<dirbaio> we don't have blocking (or async) uart rx yet because of the same reason
<re_irc>
<dirbaio> so I'd say whatever we decide should be applied to both equally
<re_irc>
<adamgreig> I think a difference is that UARTs often don't have significant receive buffer, while CAN peripherals usually do
<re_irc>
<adamgreig> but perhaps both should have a blocking receive() and a non-blocking available() or peek() or something
<re_irc>
<adamgreig> I guess a HAL could choose to implement their own buffer or use dma or something or other
<re_irc>
<dirbaio> sounds like "nb" 😆
<re_irc>
<adamgreig> heh
<re_irc>
<adamgreig> I guess blocking receive plus an available() method is a bit of a different concept than nb's "ask for it, maybe get something"
<re_irc>
<adamgreig> last point is what's left for e-h 1.0 then
<re_irc>
<adamgreig> open from that note is iopin, dealt with above, i2c, same, a note about CAN, same...
<re_irc>
<adamgreig> and then basically migration page and docs
<re_irc>
<adamgreig> is it missing anything?
<re_irc>
<dirbaio> AFAICT 1.0 will be ready to go after these PRs are done (split, i2c bus, remove iopin)
<re_irc>
<almindor> could we update done items? it seems the issue description is quite behind?
<re_irc>
<eldruin> we should get an alpha 9 out first and use it broadly to make sure we did not screw up
<re_irc>
<eldruin> the changes are really significant from 0.2
<re_irc>
<dirbaio> yeah, the i2c changes are a bit risky
<re_irc>
<adamgreig> yea, defo alpha.9 with the new PRs
<re_irc>
<adamgreig> or maybe call it beta.1?
<re_irc>
<adamgreig> almindor: as in delete them, or..?
<re_irc>
<adamgreig> the issue has two lists, the first is everything that's done, the second is everything still-open
<re_irc>
<dirbaio> beta sounds good, at this point it's quite likely there won't be more big changes
<re_irc>
<adamgreig> some of the things that are done are also struck through for some reason
<cr1901>
I'm for beta.1
<re_irc>
<almindor> adamgreig: Ah sorrry I misunderstood. I thought the crossed-over ones were "done"
<re_irc>
<adamgreig> same every time I open that issue, lol
<re_irc>
<adamgreig> I think we can strike them all out actually, just put tildes around the issue reference
<re_irc>
<dirbaio> I think "strike out" means issue is still open, but no longer a blocker for 1.0 (most likely because the affected trait was removed, heh)
<re_irc>
<therealprof> Hah!
<re_irc>
<eldruin> yeah stroke out means dismissed to me
<re_irc>
<adamgreig> aah ok, makes sense
starblue has joined #rust-embedded
<re_irc>
<dirbaio> perhaps the milestone is a better overview?
<re_irc>
<dirbaio> I always assumed the current traits were SPI master only, I thought it was obvious
<re_irc>
<dirbaio> but it seems it maybe isn't, so we should document it
<cr1901>
SPI/I2c peripheral traits are harder AFAIU
<re_irc>
<dirbaio> yeah I don't think we should have traits for spi/i2c slave
<re_irc>
<dirbaio> not for now at least, there's not been much demand
<re_irc>
<almindor> dirbaio: needs changelog but I think we can push this one today?
<re_irc>
<adamgreig> yea, even if it turned out the traits were textually identical it probably doesn't make sense to allow the normal spi traits be used for peripherals
<re_irc>
<eldruin> what is the politically correct terminology? master/peripheral? controller/peripheral seems misleading in our context
<re_irc>
<therealprof> dirbaio: Well, demand is there but coming up with a useful API is close to impossible.
<re_irc>
<newam> eldruin: main/secondary at intel
<cr1901>
controller/peripheral
<cr1901>
COPI/CIPO for SPI
<re_irc>
<jannic> Not that I care too much about that (I'm bad at naming things anyways), but: Is there some consensus on the use of the terms "master" and "slave"?
<re_irc>
<almindor> we should stick to technical terminology from documentation
<re_irc>
<adamgreig> controller/peripheral is being promoted as a new wording (see https://www.sparkfun.com/spi_signal_names) but i agree peripheral is a bit confusing in this context
<re_irc>
<dirbaio> 99% of the industry is still using master/slave, IMO we should stick to that
<re_irc>
<almindor> most documents for chips call it master/slave
<re_irc>
<adamgreig> well yea, because most of them are old and predate these suggestions for changing it
<re_irc>
<James Munns> also didin't they change it to poci/pico for obscenity reasons?
<cr1901>
It was wrong then and it's wrong now
<cr1901>
obscenity?
<re_irc>
<James Munns> one of them was slang for something in (spanish?)
<re_irc>
<newam> There's no clear winner yet for terms to replace master/slave, I think master/slave makes sense until there is more consensus.
<re_irc>
<therealprof> I also find controller rather dubious. I think it's the classical case of changing something for the sake of change. 🤷🏻♂️
<re_irc>
<James Munns> (to be clear, I'm very supportive of getting rid of the "master" and "slave" terms)
<re_irc>
<James Munns> > [2022 Editor’s Note: The OSHWA changed its recommended naming to PICO/POCI for “Peripheral In, Controller Out” and “Peripheral Out, Controller In”. Fine by us! I’ve updated this throughout the rest of the article because it doesn’t change Mike’s original argument at all.]
<re_irc>
<adamgreig> yea, I don't think this is a "for the sake of change" and I'm not convinced by "well my datasheet from the 90s says it" arguments, but hopefully we can still clearly convey what we need to for these traits
<re_irc>
<newam> James Munns: me too, it's a hard to balance with technical clarity sadly :/ (especially for non-native speakers).
<re_irc>
<almindor> that's funny coz PICO is a Czech slur :P
<re_irc>
<almindor> should I open an issue? hah
<cr1901>
^Yes, unironically
<re_irc>
<James Munns> tbf it's also a SI prefix
<re_irc>
<almindor> we might have to come up with numerical codes then, there's bound to be a bad meaning behind any ascii name that's < 8
<re_irc>
<James Munns> (zero is also a french slang, tbh I'm pro-anything-but-master-and-slave)
<re_irc>
<dirbaio> 1. It's safe to say the attempt to rename it to "controller, peripheral" has failed. It's been years since it started, and still no major vendor has adopted it. Chips released in 2021 (esp32c3, rp2040) keep using master/slave names in their datasheet and SDKs.
<re_irc>
2. It's very debatable whether random rust opensource libraries changing some names helps with social issues, while it very obviously hurts usability of the libraries.
<re_irc>
3. Out of all the names, "controller/peripheral" are THE WORST POSSIBLE CHOICE. "controller" and "peripheral" already have very established meanings. Just google "i2c slave controller" or similar.
<re_irc>
<therealprof> adamgreig: If you look hard enough any term is offensive to someone somewhere.
<cr1901>
Anyways, I will continue to use alternative, and ppl here know what I mean
<re_irc>
<James Munns> therealprof: yeah, but orders of magnitude less than "slave", IMO
<re_irc>
<adamgreig> there's a big, big gulf between "offensive to someone somewhere" and "slave" lol
<cr1901>
and if users don't know, they can ask
<re_irc>
<adamgreig> it might be we can more or less avoid this issue since we don't actually need to talk about peripheral/slave-mode devices, though
<re_irc>
<dirbaio> Literally anything else would have been better, such as "clocker/clockee", "host/device", "initiator/responder", but nooooooooo
<re_irc>
<newam> I like
<re_irc>
<newam> I like main/secondary, maintains the MOSI/MISO naming
<cr1901>
Yes, secondary is also what I use in docs sometimes
<cr1901>
I'll add main to the list
<re_irc>
<dirbaio> and a library using A THIRD set of names would be even worse, even more confusing
<re_irc>
<explodingwaffle101> dirbaio: point 1 is the big one imo. tried and failed- i don't want to say it was a fad, but if even rpi won't bother...
<re_irc>
<dirbaio> exactly! if it's esp32 or nordic or whatever you might say "they didn't rename because they didn't want to be inconsistent with their previous chips". But RP2040 was from scratch, no naming legacy, and they didn't.
<cr1901>
I'm not going to stop you, but if someone contributes to my library, I will ask you to change master/slave and/or do it myself
<cr1901>
in docs
<re_irc>
<therealprof> adamgreig: fair point. But people were equally keen on changing master.
<re_irc>
<dirbaio> also
<re_irc>
<adamgreig> not that they couldn't have, but rp2040 docs are just copied from Arm's IP docs
<re_irc>
<dirbaio> is anyone here actually offended by the term "i2c slave"?
<re_irc>
<dirbaio> or has anyone here seen first-hand someone offended by it?
<re_irc>
<James Munns> I don't think that's a fair question
<cr1901>
Ppl being upset w/ master/slave goes back to the IDE drive days
<re_irc>
<James Munns> considering even embedded rust skews heavily to not be a representative sample of the world
<cr1901>
It's NOT a new "snowflake Ess Jay Doubleu" thing
<re_irc>
<James Munns> and, I would say I would like Rust to be MORE inclusive than the current status quo of hardware/firmware dev
<re_irc>
<James Munns> anyway
<re_irc>
<James Munns> probably WAY off topic now.
<re_irc>
<dirbaio> using confusing nonstandard names is doing a disservice to our users
<re_irc>
<dirbaio> people use libraries to get their stuff done
<cr1901>
Users are smart and can learn a few new words
<re_irc>
<therealprof> dirbaio: I do think the proposal from newam offers a good middle ground.
<re_irc>
<dirbaio> "I want to use the i2c peripheral in my mcu, so I should use the i2c peripheral traits" -> boom, wrong
<re_irc>
<jannic> I'm not offended because English is not my native language - so when I hear "slave" I think of the IT term first. But I can fully understand that it may be offensive to a native speaker, especially to somebody who doesn't use IT terms on a daily basis.
<re_irc>
<dirbaio> adamgreig: we'll maybe want it in the future, and also apparently even just "master" is offensive now
<cr1901>
(I think master is bad too)
<re_irc>
<dirbaio> and using a third set of names like "main/secondary" is even more confusing IMO
<cr1901>
But I also didn't expect this meeting to get so derailed either. But that's okay. The convo needs to be had
<re_irc>
<explodingwaffle101> i was about to say- it doesn't seem to matter anyway
<re_irc>
<dirbaio> I've literally NEVER seen "main/secondary" used in the spi/i2c context
<re_irc>
<therealprof> By keeping MISO/MOSI in place anyone should be able to get the right idea and find the information.
<re_irc>
<adamgreig> I don't think anything in embedded-hal even refers to the signal names, though?
<re_irc>
<explodingwaffle101> the docs don't use the words, just a few acronyms for pin names. backronym whatever meaning you want
<re_irc>
<adamgreig> ah, it does refer to them, in fact
<re_irc>
<explodingwaffle101> (from a quick skim, but nothing stopping you from writing around it)
<re_irc>
<therealprof> Iff you need to spell it out, you can explain once that main was formerly referred to as master and secondary formerly known as slave so people can make the connection.
<re_irc>
<caemor> nxp is renaming its stuff to controller/target
<re_irc>
<newam> would it be enough to use master/slave and acknowledge that doing so is incorrect, and it is only used in the pursuit of clarity?
<re_irc>
<newam> I think most people agree that master/slave should change, and also agree that changing it makes the intent less clear. The real decision is how to balance those two goals.
<re_irc>
<dirbaio> I honestly think anything other than "here's what the traits do and how to use them" is out of scope in the docs
<re_irc>
<therealprof> newam: Well, if you need to spell it out I'd rather clarify once what the M&S used to mean and redefine it.
<re_irc>
<newam> therealprof: good point... nevermind my idea then 😅
<re_irc>
<TimSmall> I'd be in favour of "main/subordinate" or "main/secondary" personally FWIW.
<re_irc>
<dirbaio> the thing is *we don't get to decide the naming*
<re_irc>
<adamgreig> we do get to decide what we call things, and are responsible for that
<re_irc>
<adamgreig> but the issue at hand is just how to clarify the scope of the current SPI traits
<re_irc>
<dirbaio> no, we don't
<re_irc>
<dirbaio> we're writing libraries to use existing chips
<re_irc>
<adamgreig> not in embedded-hal we're not, though
<re_irc>
<adamgreig> and we do - we literally write it and publish it
<re_irc>
<adamgreig> I don't think this is the time or place to litigate the terminology
<re_irc>
<adamgreig> (and we're out of time for the meeting)
<re_irc>
<jannic> Can we agree that we should avoid those terms in symbol names of any kind (which can't be changed later without breakage?). For documentation, we can decide later, if we can't agree now.
<re_irc>
<adamgreig> yea, luckily we already avoid them in symbol names afaik
<re_irc>
<explodingwaffle101> +1 for dancing around. most... neutral option
<re_irc>
<caemor> so the current i2c specification names it controller/target if we want to use the generic spec
<re_irc>
<adamgreig> sadly motorola is long gone to issue an updated SPI spec, heh
<re_irc>
<therealprof> adamgreig: Seems like a change for changes sake though... target is almost as bad as slave IMHO.
<re_irc>
<James Munns> adamgreig: they are slowly converging back together, baby-bell style
<re_irc>
<antoinevg> I just wish they'd gone with something like eg “Controller Out Peripheral In” COPI/CIPO rather than SDI/SDO because everyone implements those differently and you have to break out a scope to see which is which.
<re_irc>
<dirbaio> therealprof: "controller" is what makes me angry, it already has a meaning!
<re_irc>
<dirbaio> means roughly "IP block"
<re_irc>
<dirbaio> so you can have an "i2c master controller", an "i2c slave controller", or an "i2c controller that supports master and slave modes"
<re_irc>
<adamgreig> and so does "peripheral" D:
<re_irc>
<therealprof> Well, controller also makes me angry but for different reasons. 😉
<re_irc>
<dirbaio> so now you have an "i2c controller controller", "i2c peripheral controller"...?? "i2c peripheral supporting peripheral and controller modes"???
<re_irc>
<explodingwaffle101> let's just go back to rx and tx. no one ever got confused by that
<re_irc>
<James Munns> dropping off now. have a good week y'all.
<re_irc>
<dirbaio> explodingwaffle101: no one ever, no :D
<re_irc>
<dirbaio> that's so very exciting and awesome :D
<re_irc>
<dirbaio> +ip addr in core,
<re_irc>
<zip1203> Cheap VPS/VDS, Storage Slabs, Shared Hosting. Starting from 2$ a month. Coin Payments allowed, privacy focused law of the land host. Tor allowed -> https://my.frantech.ca/aff.php?aff=5862
<re_irc>
<explodingwaffle101> > SocketAddrV4 only occupies 6 bytes instead of 16 bytes.
<re_irc>
> this is wild to me. what was c doing?? (not a network guy, but this feels like it would be important?)
<re_irc>
<explodingwaffle101> > SocketAddrV4 only occupies 6 bytes instead of 16 bytes. this is wild to me. what was c doing?? (not a network guy, but this feels like it would be important?)
<re_irc>
<explodingwaffle101> > SocketAddrV4 only occupies 6 bytes instead of 16 bytes.
<re_irc>
this is wild to me. what was c doing?? (not a network guy, but this feels like it would be important?)
<re_irc>
<dirbaio> lol arduino RTOS?
<re_irc>
<adamgreig> explodingwaffle101: 2 bytes port, 4 bytes IP address, 8 bytes of zero, 2 bytes of "i'm ipv4 btw"
<re_irc>
<adamgreig> it's only 16 bytes in memory, doesn't change what's on the wire or anything
<re_irc>
<explodingwaffle101> true true. benefits of having a type system i suppose
<re_irc>
The PR to change from libc was also an interesting technical read.
<re_irc>
Lots of crates were unsafely casting to the libc type.
<re_irc>
<diondokter> newam: Yeah I saw, and they weren't little used crates...
<re_irc>
<explodingwaffle101> crates.io/crater must be real nice to have when working on rustc. sort of lets you cheat breaking changes by fixing them in advance
<re_irc>
<explodingwaffle101> * crates.io and crater
<re_irc>
<eldruin> nice, I just got a git commit whose short id is all numbers: 2297008
<cr1901>
(10/16)^7 = 0.03 probability
<re_irc>
<adamgreig> I'm still waiting for 0000000 which I assume will be worth a fortune
<cr1901>
3.7252903e-9 probability :P
<re_irc>
<explodingwaffle101> it's sha1, right? could probably write a bru- oh someone already did that
<re_irc>
<eldruin> still more than winning the lottery probably
<re_irc>
<newam> explodingwaffle101: I know this is a joke, but git uses a hardened sha1, it's a bit more resistant, but still a problem
<re_irc>
<newam> if you're using github/gitlab at work and have any influence over that talk to your rep about getting sha256 in their service, git has it, but github/gitlab don't :(
<re_irc>
<explodingwaffle101> does it matter when all people look at is the short, anyway? (not sure what the consequences of a collision are. probably nothing good?)
<re_irc>
<adamgreig> git itself doesn't just look at the short, is the main reason
<re_irc>
<newam> explodingwaffle101: it's not so much a collision as forging a git object (file, commit, ect) in an existing repo.
<re_irc>
<newam> > If SHA-1 and its variants were to be truly broken, Git’s hash function could not be considered cryptographically secure any more. This would impact the communication of hash values because we could not trust that a given hash value represented the known good version of content that the speaker intended.
<re_irc>
<newam> > If SHA-1 and its variants were to be truly broken, Git’s hash function could not be considered cryptographically secure any more. This would impact the communication of hash values because we could not trust that a given hash value represented the known good version of content that the speaker intended.
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
rardiol has quit [Ping timeout: 252 seconds]
dc740 has quit [Remote host closed the connection]
explore has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<James Munns> Hey, here's a _really_ niche question for folks familiar with Cortex-M and RISC-V platforms:
<re_irc>
If I want something _like_ "PendSV" on RISC-V, e.g. an interrupt invocation that happens automatically or can be triggered on the exit of every other interrupt (or at least the External/PLIC one), and runs with the lowest priority level, what would I want to use on RISC-V?
<re_irc>
<almindor> no idea what PendSV is but if you want a "catchall" interrupt handler you should be able to just use "mtvec" in "DIRECT" mode and add the "exit" handler yourself
<re_irc>
<James Munns> pendsv in cortex-m is typically used as the "last step" in the interrupt handling process, e.g. if you process a few interrupts in a row, you can "fall through" back to pendsv, which is typically used for context switching
<re_irc>
<James Munns> so if I had three interrupts "pend" at the same time, I want to handle all three of those, then I want to run the "exit" ONCE, after all other interrupts have been processed (instead of at the exit of EACH interrupt)
<re_irc>
<James Munns> (I'm not sure if this is possible with the PLIC? I have no idea how back-to-back interrupts or pre-empting interrupts work with the PLIC 😅)
<re_irc>
<almindor> hmm, not sure if there's something like that. You can delegate interrupt handling directly to lower levels via mideleg/medeleg registers, but I don't know if there's an "aggregation" possibility
<re_irc>
<James Munns> can I just keep "claim"ing PLIC interrupts in a loop one one External interrupt trigger?
<re_irc>
<James Munns> I think I need to just read more about how the PLIC works, and interrupt handling in RISC-V in general :D
<re_irc>
<almindor> yeah I never used interrupts much yet myself :) I just know you can handle them either as vector of handlers (e.g. handler per type) or direct with delegation possibilities for machine -> supervisor -> user, but that's about it
<re_irc>
<James Munns> Gotcha! Right now I have one very dumb "do manual dispatch of PLIC interrupts using the claim interface", but I'm looking at how to do context switching for userspace
<re_irc>
<almindor> while we're on the risc-v topic... anyone knows why llvm/rustc seems to not want to use registers too much? I see stack pointer/memory usage even on primitive functions in disassembly. I'd expect more use of s0-7 registers directly to store things?
<re_irc>
<James Munns> > The RISC-V architecture is not optimised for context switches, like, for example the Cortex-M architecture, which directly calls C/C++ handlers, and delegates the context switching to a single PendSV handler
<re_irc>
awwww
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
explore has quit [Quit: Connection closed for inactivity]
<re_irc>
<almindor> hmm, I think maybe my stack pointer usage question is invalid, I now see the compiler calls some odd div function called "__udivdi3@plt" in the middle, so I guess it has to save the state