<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 ?
<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>
<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>
<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> 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 https://hackmd.io/1zzyF60eTOa2ILa5i0u9xw, 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> 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: https://github.com/lpc-rs
<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>
<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, https://github.com/rust-embedded/embedded-hal/pull/351 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> 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>
<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>
<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> 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: