ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
Rahix has quit [Quit: ZNC -]
Rahix has joined #rust-embedded
emerent has quit [Ping timeout: 260 seconds]
emerent has joined #rust-embedded
starblue has quit [Ping timeout: 272 seconds]
starblue has joined #rust-embedded
jackneilll has joined #rust-embedded
jackneill has quit [Ping timeout: 240 seconds]
lowq has quit [Ping timeout: 256 seconds]
Socke has quit [Ping timeout: 240 seconds]
gsalazar_ has joined #rust-embedded
gsalazar has quit [Ping timeout: 246 seconds]
gsalazar_ has quit [Quit: Leaving]
gsalazar has joined #rust-embedded
starblue has quit [Ping timeout: 246 seconds]
starblue has joined #rust-embedded
Socke has joined #rust-embedded
<Lumpio-> Anyone know what these weird traits with the entire namespace in their name is?
<Lumpio-> Is it just the doc website being confused or is it a re-export I can't find in the source code
<Lumpio-> Oh they come all the way from embedded_hal
<Lumpio-> ah
<Lumpio-> I get the feeling a lot of people are misunderstanding those re-exports and using them to actually implement things instead of what they're meant for
<re_irc> <dirbaio> yeah it's the prelude in EH0.2
<re_irc> <dirbaio> the weird names is because they'd collide otherwise
<re_irc> <dirbaio> the prelude is gone in 1.0
<re_irc> <nihal.pasham> _(its one of those things where I'm sure I'm doing something wrong.)_
<re_irc> I cant seem to get this trait working - "DecodePrivateKey". I get a "no-method named from_pkcs8_der found for ecdsa::sign::SigningKey in the current scope" error. From what I have been able to gather from "SigningKey"'s generic implementation, I do see an impl for "DecodePrivateKey". But I just cant seem to get this to work. Any pointers on what I'm missing ?
<re_irc> [package]
<re_irc> edition = "2021"
<re_irc> <dirbaio> the impl ( says "This is supported on crate feature pkcs8 only.", maybe you need to enable feature "pkcs8" in "ecdsa"? doesn't look like "p256" enables it
<Lumpio-> Just out of curiosity - excuse the dumb question
<Lumpio-> why does this require type_alias_impl_trait but doesn't?
<Lumpio-> What's so fundamentally different that they have to be implemented in different ways
<re_irc> <dirbaio> TAIT is required for "type X = impl Future" here
<re_irc> <dirbaio> which is needed for returning the type of an "async{}" block
<re_irc> <dirbaio> so SPI requires it because it has that impl
<re_irc> <dirbaio> in current Rust nightly:
<re_irc> defining async trait -> requires GAT
<re_irc> implementing async trait with a handwritten Future -> requires GAT
<re_irc> implementing async trait with a "async{}" or "async fn" Future -> requires GAT+TAIT
<re_irc> <pwychowaniec> looks like just "passes through" all the operations, while additionally wraps stuff with "self.transaction()":
<re_irc> self.transaction(move |bus| async move {
<re_irc> let res = bus.write(buf).await;
<re_irc> (bus, res)
<Lumpio-> I imagine this would be possible, although cumbersome, to write without using an async block and get rid of the requirement?
<re_irc> <pwychowaniec> (does the emoji-scissors reaction mean something special in here? 😄)
<Lumpio-> (Not that you should, but I was just wondering what was so fundamentally different about the two buses)
<re_irc> <dirbaio> Lumpio-: yeah, that'd work
<re_irc> <dirbaio> it might be worth it when GATs get stabilized, so the whole thing works on stable
<re_irc> <dirbaio> for now there's no benefit since it requires nightly anyway
<Lumpio-> Alright, that's what I wanted to know
<re_irc> <dirbaio> it wouldn't be pretty, it requires unsafe due to Pin (or pin_project...(
<re_irc> <dirbaio> * pin_project...)
<re_irc> <ryan-summers> pwychowaniec: It's something to do with the IRC bridge, I think it means that the code has been copied over to IRC as well or made a pastebin or something
<Lumpio-> Yep, shows up as a link here
<re_irc> <pwychowaniec> > it wouldn't be pretty, it requires unsafe due to Pin (or pin_project...)
<re_irc> hmm, wouldn't that just require using ".and_then()" (or some similar combinator) from futures-rs?
<re_irc> self.transaction(move |bus| async move {
<re_irc> so that instead of:
<re_irc> <pwychowaniec> it ain't pretty or maintanable in the long run (good-old tokio 0.1 days), but should do without any usafe
<re_irc> <dirbaio> oh hm, maybe!
<re_irc> <nihal.pasham> dirbaio: Do you mean enable the feature ("pkcs8") in p256's "ecdsa" dependency? How would I go about doing that.
<Lumpio-> type WriteFuture = AndThen<AndThen<AndThen<AndThen<...
<re_irc> <nihal.pasham> or do I add it ecdsa as a separate dependency and then enable the feature
<re_irc> <nihal.pasham> * "ecdsa"
<re_irc> <nihal.pasham> ok, so, tried this and it seems to work now.
<re_irc> edition = "2021"
<re_irc> [package]
<re_irc> name = "rbSigner"
explore has joined #rust-embedded
Amadiro has joined #rust-embedded
vancz_ has quit [Quit: vancz_]
vancz has joined #rust-embedded
vancz has quit [Quit: vancz]
vancz has joined #rust-embedded
lowq has joined #rust-embedded
vancz has quit [Quit: vancz]
vancz has joined #rust-embedded
<re_irc> <shamchak> Hey All, I've got a question on the behavior of "cortex-m" pending interrupts and timing.
<re_irc> What I see in the "cortex-m-rtic" examples, and seems heavily implied in "cortex-m-rtic" documentation, is that "pend"ing a higher priority interrupt _seems_ immediate.
<re_irc> In other words, if I have "fn_low_prio" which calls "cortex_r::peripheral::NVIC::pend( highPrioFnNum)", is it guaranteed by the ArmV7-M spec that the line after pend won't be called, and the higher priority interrupt will immediately pre-empt?
<re_irc> context: I'm forking cortex-m crates to work with cortex-r-r5, and finding there is differing behavior likely coming from my cortex-r-r5 board's external gic adding latency.
<re_irc> <shamchak> * "cortex_m::peripheral::NVIC::pend(
<re_irc> <shamchak> As a bonus code design question. Is generally considered a okay or a code smell to do something like this?
<re_irc> fn_low_prio() {
<re_irc> cortex_m::peripheral::NVIC::pend(highPrioTaskNumber);
<re_irc> ...
<re_irc> <ryan-summers> This may be something you need to dive into arm architecture manuals for confirmation on. Some interrupt controllers might have some latency before the actual ISR gets invoked
<re_irc> <ryan-summers> If the architecture manual indicates that the interrupt will be serviced immediately, you're fine, but if it doesn't, there's likely some upper limit on the number of cycles before a pending interrupt is invoked
<re_irc> <ryan-summers> Also, keep in mind that if your low priority task executes in some critical section, the high priority task won't be able to interrupt until the critical section ends as well
<re_irc> <ryan-summers> From my experience, there's likely some number of CPU cycles that will elapse before a pending interrupt is actually serviced
<re_irc> <ryan-summers> But it's very device and implementation dependent, which is why I recommend looking at the architecture manual
<re_irc> <shamchak> That last part I'm definitely tracking. I'm currently going through the weeds of the cortex-m3 manual and blogs. This blog ( shows the cortex-m3 takes up to 12 cycles to service an ISR (6 with tail chaining).
<re_irc> <newam> shamchak: There's a table on wikipedia I like to reference which has all the Cortex-M interrupt latencies:
<re_irc> <ryan-summers> You mentioned cortex-r though
<re_irc> <ryan-summers> Why are you looking at blogs for cortex-m at all?
<re_irc> <newam> oh, yeah, GIC is very different from NVIC
<re_irc> <shamchak> I think what I'm more interested in than the number of cycles to service an ISR is how many cycles before the cpu starts the work to transfer over to an ISR. Figure 5 in this blog ( shows 2/3 cycles at the beginning before clearing registers
<re_irc> <shamchak> and the work I'm doing is an MPSoC with cortex M3s and a cortex R5 on the device
<re_irc> <shamchak> So thought it would be cool to make everything RTIC :)
<re_irc> <ryan-summers> Gotcha. In general, I wouldn't ever assume anything unless you can prove it, or you may bite yourself later on
<re_irc> <ryan-summers> Where it works like 99% of the time
<re_irc> <ryan-summers> If you need to guarantee a task is called first, just call it directly
<re_irc> <ryan-summers> Instead of pending an ISR
<re_irc> <ryan-summers> it's going to be faster as well since you have no ISR entrance overhead
<re_irc> <newam> Like all good answers "it depends", RAM access cycles can increase the number of cycles it takes to do stack operations for an ISR.
<re_irc> <shamchak> ryan-summers: Yeah that makes sense. And it's what I would do in an application where something specific needs to be guaranteed.
<re_irc> <shamchak> newam: "it depends" is my favorite kind of answer :D
<re_irc> <shamchak> newam: This table is going to be really handy! Thanks!
<re_irc> <shamchak> Yeah, I think this is enough info on the embedded arch side of things. I'll probably pop up in the RTIC channel to ask them more about expected behavior there while I continue porting cortex-r-rtic. Thanks all!
<re_irc> <shamchak> To tie a ribbon on this, I found the following in the Cortex-M3 spec under "Pre-emption"
<re_irc> > The NVIC indicates to the processor core, in the cycle after INTISR[2] was received,
<re_irc> > that an interrupt has been received, and the processor initiates the stack push and vector
<re_irc> > So it makes the claim that the NVIC signals to the processor in a single cycle that an interrupt signal has been received. This is very different from the external GIC on my cortex-r which states the delay is "up to 10 cycles" to notify a cpu about an interrupt.
<re_irc> > fetch in the following cycle
<re_irc> <shamchak> ->
<re_irc> <adamgreig> hi room, meeting time again! agenda's, please add anything you'd like to discuss or announce and we'll start in 5min
<re_irc> <adamgreig> ok, let's start!
<re_irc> <adamgreig> I just have one quick announcement which is that cortex-m-semihosting and panic-semihosting have had new releases, taking advantage of the new stable asm!() macro to do inline semihosting
<re_irc> <adamgreig> so cortex-m/cortex-m-rt will be next in line for a new version, the semihosting crates were the easy targets
<re_irc> <adamgreig> hm, that's it for announcements from me, did anyone have anything else?
<re_irc> <adamgreig> I enjoyed this blog post about rust+hubris on a pinetime watch though I already linked it earlier,
<re_irc> <therealprof> Newsletter was published last week (after the meeting I think?).
<re_irc> <adamgreig> otherwise I think it's been a fairly quiet week on the rust-embedded github; the cortex-m HIL PR is ready to review/merge (thanks newam!) so we'll hopefully that get in within the next couple days
<re_irc> <allexoll> not an announcement per say but over at lpc-rs we have setup a similar workflow as there is for stm32-rs, so contributors might be more familiar with the process. Hopefully that might open the embedded-rust to one more manufacturer than the existing STM and NRF. I'd like to do an article for a-e-r at some point but i did not have the time yet:
<re_irc> <adamgreig> cool, nice work!
<re_irc> <therealprof> allexoll: and atsam and rpi you mean? 😅
<re_irc> <allexoll> adamgreig: all thanks to the work that was done for stm to be fair
<re_irc> <allexoll> therealprof: 😅 fair enough but stm & nrf still has the most extensive support no?
<re_irc> <therealprof> All good, the more the merrier.
<re_irc> <adamgreig> I'm pretty much still drowned by moving house so haven't had time to really catch up on anything, is there anything else we should/someone would like to talk about this week?
<re_irc> <therealprof> I failed to summon the core team to get the team PR with the big restructuring approved. I'll keep on trying.
<re_irc> <allexoll> regarding the CI questions for cortex-m, if at some point the question arises for riscv-rt it could be run trough verilator since there isn't the licensing issue from arm ISA but that's for another time probably
<re_irc> <adamgreig> ooh, yea, no shortage of cores you could run in simulation I guess
<re_irc> <adamgreig> therealprof: thanks... hopefully it doesn't take too much more effort, there has been some recent activity on the repo
<re_irc> <jessebraham> Well, just since it's quiet this week I'm going to plug our org 😁 We've been making some really good progress over at "esp-rs", and recently have been putting some effort into developing the "no_std" HALs on top of our current "std" support. We recently got a "no_std" proof-of-concept working for WiFi on the ESP32-C3 which is very exciting!
<re_irc> <jessebraham> Always looking for more contributors if people are interested!
<re_irc> <newam> jessebraham: Got a link to the proof-of-concept? I would like to see :D
<re_irc> <jessebraham> Sure, keep in mind it's in the _very_ early stages:
<re_irc> <adamgreig> I still think it's cool you were able to start with std support and then work towards no_std
<re_irc> <jessebraham> Yeah I'm really glad to be able to offer both options!
<re_irc> <eldruin> pretty cool! if you write an article make sure to announce it here and add it to our newsletter as well
<re_irc> <mabez> Whilst on the topic, feel free to join our matrix chat if Rust on esp's is in your interest:).
<cr1901> Good stuff- love seeing esp get some love
<re_irc> <therealprof> Since it's so quiet: let me put this out... 😉
<re_irc> <adamgreig> > I'm settling in for a long bikeshed. EvenUnsaferCell, anyone?
<re_irc> > 🤣
<re_irc> <adamgreig> ->
<cr1901> UnsafeCell20ElectricBoogalo
<re_irc> <adamgreig> HighlyUnsafeCell, VeryUnsafeCell, UltraUnsafeCell, SuperUnsafeCell, ExtremelyUnsafeCell, TremendouslyUnsafeCell, etc
<cr1901> UtterlyAccursedUnsafeCell
<re_irc> <adamgreig> CursedCell?
<re_irc> <GrantM11235> Two (or maybe three?) weeks ago, I suggested creating an "official" shared-bus crate, but I haven't put much thought into it since then. Does everyone still think it is a good idea? What is the next step?
<re_irc> <adamgreig> I guess it would be part of the embedded-hal team, perhaps even just living in the same repository (but as a separate crate, like we do in cortex-m etc)? in that case you could just PR it to embedded-hal
<re_irc> <eldruin> maybe it would be easiest to start with a discussion issue detailing the plan and implementation
<re_irc> <newam> GrantM11235: I don't have anything more to contribute other than saying I think it is a good idea. This is one of the more frequent questions I see asked about embedded-rust, I think it is a good idea to have an at least one official solution.
<re_irc> <newam> -an
<re_irc> <jessebraham> I missed the previous conversation, is there some deficiency with the current "shared-bus" crate?
<re_irc> <adamgreig> what will it provide for the new e-h 1.0 spi traits that make it easier to share already?
<re_irc> <eldruin> a refcell-based impl for spi device for example
<re_irc> <eldruin> maybe another with some mutex impl
<re_irc> <GrantM11235> For reference, splits up the spi traits into bus traits and device traits, and it includes a simple wrapper that allows you use a bus with a single device
<re_irc> <GrantM11235> I would like to move that wrapper outside of the main embedded-hal crate (for semver related concerns), and also include some new wrappers that use refcells, mutexes, etc
<re_irc> <GrantM11235> It would also be a good place to put an i2c refcell impl
<re_irc> <eldruin> yeah, it would be interesting to explain what the intersection with shared-bus is, why do we need a new crate and so on
<re_irc> <GrantM11235> The main difference is that shared-bus uses the 0.2 traits, which don't actually work to share an spi bus
<re_irc> <GrantM11235> Another difference is that previously, sharing was optional. Now, HALs impl the bus traits and device drivers require the device traits, so you will always need _some_ way of converting between them
<re_irc> <GrantM11235> Because everyone who uses spi will need a way to turn a bus into one or more devices, it would be nice to have some "official" ways to do so
<re_irc> <eldruin> Sorry I need to leave now. I would suggest putting everything in the issue so that we can discuss it thoroughly and everyone can have their say. It would be also good to detail what place shared-bus would have after such a crate
<re_irc> <jessebraham> newam: Hah! I never realized you were from Vancouver too, small world
<re_irc> <firefrommoonlight> What do y'all think are the biggest weaknesses / areas-for-improvement for embedded on Rust? Technical obstacles to wider adoption?
<re_irc> <firefrommoonlight> Posing this question, I don't have any good answers, other than the obvious "Support more non-ARM platforms." Speaking of which, the ESP32-C3 news is wonderful
<re_irc> <firefrommoonlight> RTOS land is a big WIP, with Hubris maybe being viable soon (?)
<re_irc> <firefrommoonlight> RTIC is in a good spot for slightly-above-baremetal interrupt handling.
<re_irc> <K900> Async in traits will be big
<re_irc> <K900> Whenever and however that happens
<re_irc> <firefrommoonlight> Although I'm not crazy about RTIC's internals being behind a macro-wall, I don't know if that's solveable. It's also interesting how it's a mix of a few somewhat unrelated features. Ie, you could completely ignore the Monotomic mechanic
<re_irc> <firefrommoonlight> I haven't found Rust to be limiting at all on a range of projects using a spectrum of STM32 and nRF peripherals
<re_irc> <firefrommoonlight> After getting used to teh quirks
<re_irc> <firefrommoonlight> More open-source, practical examples and/or guides would definitely help people new to Rust, and/or embedded
<re_irc> <K900> Also, are non-ARM platforms really relevant at this point?
<re_irc> <K900> I guess RISC-V
<re_irc> <K900> But I don't think people really miss AVR much
<re_irc> <K900> Or PIC8
<re_irc> <firefrommoonlight> Haha I don't know. I'm happy on Arm since it gets the job done, eg with STM32's HUGE product lineup
<re_irc> <firefrommoonlight> The big missing spot is WiFi
<re_irc> <K900> Oh yeah, I guess Xtensa _kind of_ because Espressif is the only way to get low cost WiFi
<re_irc> <K900> (and only because they are in China and therefore don't give a shit)
<re_irc> <firefrommoonlight> In practice, RTIC requires a bit of DRY and verbose syntax in its ISRs. More of an annoyance, but adds inertia to early code
<re_irc> <firefrommoonlight> Ie, you have to list resources #1: In the task descriptor. #2: In the lock call. #3: In the lock closure params
<re_irc> <firefrommoonlight> If you screw this up, the compiler will tell you, but still; not idea for readability/writability
<re_irc> <firefrommoonlight> When I brought this up in the RTIC chat, no one agreed it was a problem or should be addressed, so I'm curious if others have noticed
<re_irc> <firefrommoonlight> More open-source, practical examples and/or guides would help people new to Rust, and/or embedded
<re_irc> <caspinol> I'm actiually fine with the listing of the resources in RTIC. I kinda accept this as a natural extension of verbosity that is there anyway in Rust
<re_irc> <dirbaio> Rust is quite unverbose IMO
<re_irc> <dirbaio> its type inference is top notch
<re_irc> <firefrommoonlight> I've done a lot of comparing Rust to C code lately (translating latter to former). I mostly agree
<re_irc> <dirbaio> so I'd say macros that force you to be verbose in stuff that rust could otherwise infer are not very idiomatic..
<re_irc> <firefrommoonlight> DRY between headers/source files, and naming_as_namespacing along makes C verbose
<re_irc> <firefrommoonlight> -along
bjc has quit [Remote host closed the connection]
<re_irc> <firefrommoonlight> Worse than the usual Rust offenses like volatile writes
<re_irc> <firefrommoonlight> I've seen some verbose Rust embedded code, eg excessive use of generics, but this is more code style than Rust itself
<cr1901> Why is "DRY between headers/source" a form of verbosity? I thought the entire point of DRY was to reduce verbosity
<re_irc> <firefrommoonlight> *DRY violation
<cr1901> ahhh
<re_irc> <heksa> firefrommoonlight: Haha, naming_as_namespacing... Our lab has tooling to read memory maps into C headers, and due to the inherent hierarchy in our chip designs, those names became really long e.g., CHIP_SUBSYS_INTERRUPT_UNIT_INTERRUPT_SET. As it happens that tool also has an SVD frontend so we made the Rust PACs from it and let me say those PACs are easier both on the fingers and the eyes.
<Lumpio-> Type inference is unverbose until you're forced to write the type of something in full (e.g. in statics)
<re_irc> <caspinol> dirbaio: It is when you navigate witin a function. But declaration of types at the API level or generics make it quite verbose
<re_irc> <heksa> I've found it not too fun to have to figure out what each of the generic parameters means for a given driver.
<re_irc> <dirbaio> ... if you use crates that abuse generics, like many HALs out there :P
<Lumpio-> mmmm generics
<re_irc> <caspinol> +i.e.
<re_irc> <dirbaio> also async allows you to keep a LOT more stuff in local variables
<re_irc> <dirbaio> stuff that RTIC forces you to stick in a resource, which forces you to spell out the full type
<re_irc> <dirbaio> you can just keep in a local variable and hold across ".await"s
<re_irc> <dirbaio> without spelling the whole type
<re_irc> <chemicstry> talking about abusing generics, take a look at this ( uavcan library :D although, the library itself is quite decent
<re_irc> <firefrommoonlight> Lumpio-: It doesn't save you there, but it's a push
<re_irc> <dirbaio> // what the fuck
<re_irc> type TheClient = Client<
<re_irc> EmptyAdditionalClaims,
<re_irc> CoreAuthDisplay,
<re_irc> <firefrommoonlight> heksa: I've seen that too - more of an issue of the libs that create those APIs, and don't document them
<re_irc> <firefrommoonlight> Ie, you can write embedded rust without those APIs
<re_irc> <firefrommoonlight> I guess this is about where you draw the line between a language, and how people use it
<re_irc> <heksa> I mean people don't necessarily always document ordinary parameters either, but you can usually follow the symbol in the docs. And if it quacks like a duck... but generics can be left quite underspecified, and they're usually just one letter. I think longer generic identifiers are even discouraged?
<re_irc> <dirbaio> "Client<AC, AD, GC, JE, JS, JT, JU, K, P, TE, TR, TT, TIR, RT, TRE>" 👌
<re_irc> <firefrommoonlight> I treat generics as something to use in specific circumstances
<re_irc> <chemicstry> also, don't generics cause large binary sizes due to monomorphization if different instances are used? Pretty big deal for embedded. Or can the compiler somehow optimize multiple instances into a single function?
<re_irc> it can if they're 100% identical. If you use a generic struct with, say, pins PA5 and PA6, then BOOM 2x code size
<re_irc> <dirbaio> > can the compiler somehow optimize multiple instances into a single function?
<re_irc> <firefrommoonlight> I didn't bring this up initially since I think it's more of an ecosystem issue than fundamental
<re_irc> <dirbaio> the fix is for HALs to offer a type-erased "AnyPin" struct
<re_irc> <dirbaio> so you can call the same code with 2 different pins
<Lumpio-> Having different types is cool in that the compiler can check that you're using the correct pin for the correct peripheral (on devices where a peripheral cannot be mapped onto any pin)
<re_irc> <dirbaio> yeah, embassy has both
<re_irc> <dirbaio> you get the pins as typed singletons
<re_irc> <dirbaio> to create spi/uart/etc you need to pass the typed singletons so that it can check
<re_irc> <dirbaio> you get the pins as typed singletons, like "PA5"
<re_irc> <dirbaio> but you can also .degrade() to convert a "PA5" to an "AnyPin"
<re_irc> <dirbaio> * ".degrade()"
<re_irc> <dirbaio> so if you ".degrade()" in the right places you avoid the monomorphization bloat
<re_irc> struct shared {
<re_irc> // ...
<re_irc> manual_inputs: CtrlInputs,
<re_irc> <firefrommoonlight> I've been using patterns like this:
bjc has joined #rust-embedded
bjc has quit [Ping timeout: 252 seconds]
bjc has joined #rust-embedded
bjc` has joined #rust-embedded
bjc has quit [Ping timeout: 260 seconds]
bjc` has quit [Quit: ERC 5.4.1 (IRC client for GNU Emacs 29.0.50)]
bjc has joined #rust-embedded