<re_irc>
<@jamesmunns:beeper.com> Just published the first version of `defmt-bbq`, which is a defmt global logger that shoves the messages into a `BBQueue`: https://crates.io/crates/defmt-bbq
<re_irc>
<@jamesmunns:beeper.com> The idea is you would use this with pretty much any sort of transport, like serial, or USB-serial, or packets, or whatever, in order to have non-RTT transport
<re_irc>
<@jamesmunns:beeper.com> I uh, haven't tested it yet, but I guess I'm gunna go write a serial port implementation to test it out :D
<re_irc>
<@jamesmunns:beeper.com> (the docs are still in the queue, but you're not missing much, it only has a single `init()` function as an interface.
<re_irc>
<@jamesmunns:beeper.com> Would it be interesting to have a generic blocking embedded-hal serial implementation? I feel like there isn't much to it, basically a `drain` function that just loops over the available logs and writes them out...
richardeoin has quit [Ping timeout: 245 seconds]
richardeoin has joined #rust-embedded
<re_irc>
<@jamesmunns:beeper.com> Hah! One bug, but now it works :D
<re_irc>
<@mriise:matrix.org> do interrupts enabled in the NVIC that doesnt has that slot reserved/unusesd break things?
<re_irc>
<@mriise:matrix.org> im wondering if my issues with the lpc55x2 and interrupts has to do with using the lpc55x6 pac with its vector table
<re_irc>
<@mriise:matrix.org> its the same vectors mostly, with 2 extra added in places where the x2 doesn't have any
<re_irc>
<@tholmie:matrix.org> Did it shift the interrupt you care about? That would be a problem
<re_irc>
<@mriise:matrix.org> it does not :\
<re_irc>
<@mriise:matrix.org> I did a test project a while back trying to go though where it goes wrong, but I wasnt able to get any valuable information other than it usually goes into 0xefffffe (however many fs that is) and that it always fails at asm calls, usually CPSIE inside of critical sections or interrupt enable.
<re_irc>
<@mriise:matrix.org> grated this is software triggered interrupt, though this still fails with interrupts like USB and external pins
procton_ has joined #rust-embedded
procton__ has quit [Ping timeout: 256 seconds]
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter has joined #rust-embedded
<re_irc>
<@josfemova:matrix.org> Talking about interrupts...what about some traits in e-hal to attach handlers?
<re_irc>
<@josfemova:matrix.org> I think I saw an issue about that but seems...dead(?
<re_irc>
<@eldruin:matrix.org> please feel free to participate in whatever e-h issues. Sometimes there are long-standing issues where a good solution has not been found yet or nobody has shown enough interest to present a proposal.
procton__ has joined #rust-embedded
inara has joined #rust-embedded
kehvo1 has joined #rust-embedded
procton_ has quit [*.net *.split]
mightypork has quit [*.net *.split]
nexgen2 has quit [*.net *.split]
kehvo has quit [*.net *.split]
inara` has quit [*.net *.split]
mightypork has joined #rust-embedded
nexgen2 has joined #rust-embedded
kehvo1 is now known as kehvo
kehvo has quit [Changing host]
kehvo has joined #rust-embedded
gsalazar has joined #rust-embedded
gsalazar has quit [Ping timeout: 240 seconds]
gsalazar has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> What would the API look like?
<re_irc>
<@jamesmunns:beeper.com> I know oli-obk had a class where he implemented interrupt handlers as something you could bind to using a heap-allocated closure for some of his student courses
<re_irc>
<@jamesmunns:beeper.com> It did require nightly though (for the allocator)
<re_irc>
<@jamesmunns:beeper.com> Basically you use a trampoline that holds something like a `Box<Option<Fn()>>`, and dispatches to that
<re_irc>
<@dirbaio:matrix.org> an e-h trait requiring alloc will be controversial
<re_irc>
<@jamesmunns:beeper.com> Not suggesting it *should* be the solution, just listing prior art :)
<re_irc>
<@dirbaio:matrix.org> it's very cortex-m-specific and implementation-specific though
<re_irc>
<@firefrommoonlight:matrix.org> EH is mainly for device drivers. I tend to think of interrupts as something the application needs control of
<re_irc>
<@firefrommoonlight:matrix.org> Ie, if I'm using a library to add hardware support for a sensor etc, I don't want to consider if it will interfere with my interrupts. This could be mitigated by explicit documentation of what interrupts etc a given device uses
<Lumpio->
Then again it would be pretty cool if a device driver could transparently take control of an interrupt and "just work"
<Lumpio->
But that's really hard to do in the "zero cost" world. It's getting closer to an operating system than unrelated drivers.
<re_irc>
<@dirbaio:matrix.org> many off-chip devices want a "pin interrupt" though, which is not the same as a "cortex-m interrupt"
<re_irc>
<@firefrommoonlight:matrix.org> Overall, I can't comment more without seeing an example application that uses this
gsalazar has quit [Ping timeout: 240 seconds]
gsalazar has joined #rust-embedded
<re_irc>
<@josfemova:matrix.org> firefrommoonlight:matrix.org: As soon as I'm able to get into my computer I will draft something
<re_irc>
<@josfemova:matrix.org> But basically I wouldn't eant something overly complex
<re_irc>
<@josfemova:matrix.org> Something simple like that
<re_irc>
<@josfemova:matrix.org> An attach interrupt function and some marke trait that indicates wether it is periodic or event driven
<re_irc>
<@dirbaio:matrix.org> yeah but why do you need that in a trait?
<re_irc>
<@josfemova:matrix.org> The periodic or event stuff?
<re_irc>
<@josfemova:matrix.org> To constraint the type of interrupt a driver receives in case the driver wants to
<re_irc>
<@josfemova:matrix.org> I.e. a distance sensor that only wants to have an event reported (pin interrupt) indtead of having to check periodically if something happened
<re_irc>
<@josfemova:matrix.org> It being a trait is not like a core part of the idea, but there should be a way to have that info
<re_irc>
<@josfemova:matrix.org> So a driver can constraint the type of interrupts it receives
<re_irc>
<@josfemova:matrix.org> I might write something more complete lates but atm I'm away from my pc
<re_irc>
<@josfemova:matrix.org> josfemova:matrix.org: By the way, this is the uart example for the esp8266, not an implementation of mine or sumthing
<re_irc>
<@jamesmunns:beeper.com> Huh, when did `singleton!` get the ability to use non-const constructors? Forever? It's way more convenient than I remember :D
<re_irc>
<@jamesmunns:beeper.com> ```rust
<re_irc>
<@jamesmunns:beeper.com> let usb_bus = Usbd::new(UsbPeripheral::new(periphs.USBD, clocks));
<re_irc>
<@jamesmunns:beeper.com> let usb_bus = unwrap!(singleton!(:UsbBusAllocator<Usbd<UsbPeripheral>> = usb_bus));
<re_irc>
<@jamesmunns:beeper.com> At least four years ago. Huh.
gsalazar has quit [Quit: Leaving]
gsalazar has joined #rust-embedded
gsalazar has quit [Ping timeout: 256 seconds]
<re_irc>
<@firefrommoonlight:matrix.org> I josfemova I think the best way to approach this is to come up with (Or apply to an existing) project where you think it would help. Write the library / EH fork, the application, and see how it works in practice
<re_irc>
<@firefrommoonlight:matrix.org> And compare with managing the interrupt in the application only
<re_irc>
<@dirbaio:matrix.org> one problem with "pin interrupts" is many chips have a single irq for all pin interrupts
<re_irc>
<@dirbaio:matrix.org> for example nrf's GPIOTE
<re_irc>
<@firefrommoonlight:matrix.org> if !gpio::event_triggered(GpioteChannel::C1) {
<re_irc>
<@firefrommoonlight:matrix.org> let mut btn_pressed = 0;
<re_irc>
<@josfemova:matrix.org> Sounds good
<re_irc>
<@josfemova:matrix.org> On the driver side I think is quite straight forward with the ones that already expect you to poll in an interrupt. In the hal side, I will have to tinker a little bit more.
<re_irc>
<@dirbaio:matrix.org> I mean you can have max one pin interrupt in (PA0, PB0, PC0..)
<re_irc>
<@firefrommoonlight:matrix.org> not ideal, but also, not a big deal
<re_irc>
<@firefrommoonlight:matrix.org> Yea. ST GPIO interrupt handling is awkward since it depends on which pins you're using, and if they share ISRs with others
<re_irc>
<@josfemova:matrix.org> The idea behind my proposal is to leave the implementation details to the hal /crate /whatever. The trait shouldn't require anything related to enabling or doing anything else with the interrupt, it should only be able to assign a handler. I will try to test in as many platforms as I have available
<re_irc>
<@josfemova:matrix.org> It's a deep rabbit hole I guess. Wish me luck haha
<re_irc>
<@dirbaio:matrix.org> a rather bottomless rabbit hole :D
<re_irc>
<@firefrommoonlight:matrix.org> Good luck
rardiol has quit [Quit: No Ping reply in 180 seconds.]
<re_irc>
<@tholmie:matrix.org> might be hard to get to an e-h consensus, but if nothing else a separate crate could be useful!
<re_irc>
<@josfemova:matrix.org> dirbaio:matrix.org: Bottomless = fun right?
rardiol has joined #rust-embedded
rardiol has quit [Read error: Connection reset by peer]
rardiol has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> room meeting time again! agenda is https://hackmd.io/mUIsUCW-TFq3OLnY_t-4ZQ, please add anything you'd like to discuss and we'll start in 5 minutes. not much new on the agenda for this week besides those two open RFCs.
<re_irc>
<@adamgreig:matrix.org> ok, let's start! no announcements from me this week, anyone have anything?
<re_irc>
<@therealprof:matrix.org> I'm empty.
<re_irc>
<@adamgreig:matrix.org> ok, let's get right into it. first up is the cortex-m team rfc for moving the `itm` crate on crates.io: https://github.com/rust-embedded/wg/pull/589
<re_irc>
<@adamgreig:matrix.org> it's just been updated to address the review feedback
<re_irc>
<@therealprof:matrix.org> I think we're all good on this one. I can execute it later.
<re_irc>
<@adamgreig:matrix.org> there's a few open points of discussion there which I think I've replied to, but maybe could do with updating the text to clarify
<re_irc>
<@adamgreig:matrix.org> mostly I don't know exactly what the answer is and hope we'll find out by doing, though...
<re_irc>
<@therealprof:matrix.org> Isn't it ironic how the only WG member who pretty much never shows up to meetings suggests we add more people to the WG? 😉
<re_irc>
<@adamgreig:matrix.org> I think quite a few WG members can't make the meeting since it's only really convenient for people near EU timezones...
<re_irc>
<@adamgreig:matrix.org> hence keeping lots of discussion on PRs/issue threads
<re_irc>
<@adamgreig:matrix.org> well, anyway, probably not much more to say about that RFC at the moment
<re_irc>
<@adamgreig:matrix.org> I think we'll have another meeting next week but probably then take the usual two week break?
<re_irc>
<@therealprof:matrix.org> I haven't checked the calendar yet.
<re_irc>
<@therealprof:matrix.org> Tuesdays are outside of the usual holidays but either way would be fine for me.
<re_irc>
<@adamgreig:matrix.org> 👍️, any other business?
<re_irc>
<@thejpster:matrix.org> I got a free board from Solder Party to write an RP2040 BSP for. Interested in chatting about any luck the other HALs are having with hardware or chip vendors.
<re_irc>
<@thejpster:matrix.org> Or what those HALs are doing to grow and get more interest. Like Twitter, or blog posts and stuff.
rardiol has quit [Quit: No Ping reply in 180 seconds.]
rardiol has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> I saw, good of them! I've not heard of anything similar on the stm32 side
<re_irc>
<@therealprof:matrix.org> Getting hardware is not the problem. Finding interested people working with them is.
<re_irc>
<@ryankurte:matrix.org> and finding the time alongside doing the $things that need to be done 😅
<re_irc>
<@therealprof:matrix.org> Before the pandemic I would just hand out hardware to random people in person in the hopes they'd use it to do something interesting.
<re_irc>
<@thejpster:matrix.org> therealprof: do you mean people at the vendor, or people in the HAL team?
Foxyloxy has joined #rust-embedded
<re_irc>
<@therealprof:matrix.org> I'd say we have quite good contacts to a number of vendors. Nordic, STM, NXP, RasPi Foundation...
<re_irc>
<@therealprof:matrix.org> (we == individuals from the community)
<re_irc>
<@therealprof:matrix.org> Ignoring the ongoing chip crisis, getting development hardware is not a big problem.
<re_irc>
<@adamgreig:matrix.org> I guess it's more being gifted the hardware unprompted in exchange for adding BSP support
<re_irc>
<@thejpster:matrix.org> We're quite lucky, the rp-rs team seems to have about six or so regular contributors. What do the other teams have?
<re_irc>
<@thejpster:matrix.org> I know the tm4c stuff is basically just me.
<re_irc>
<@therealprof:matrix.org> Well, the Nordic team also has many regular contributors, STM is a bit more tricky due to many different families.
<re_irc>
<@therealprof:matrix.org> F4 has 3 or 4 regular contributors, F0 0-1, F1 1-2.
<re_irc>
<@therealprof:matrix.org> Don't know about the others but I'd say it's probably similar.
<re_irc>
<@jamesmunns:beeper.com> If hardware in hand is a blocker, I know Nordic has been pretty open in the past to send out dev kits
<re_irc>
<@tholmie:matrix.org> ATSAMD has a handful of regular contributors that vary depending on availability
<re_irc>
<@thejpster:matrix.org> Of course! I always forget atsam. Even though we stole your GPIO driver.
<re_irc>
<@thejpster:matrix.org> Have we heard much from the Espressif lot, since they hired someone from the community?
<re_irc>
<@adamgreig:matrix.org> #esp-rs:matrix.org is huge
<re_irc>
<@thejpster:matrix.org> 689 people
<re_irc>
<@thejpster:matrix.org> Rp-rs is 141
<re_irc>
<@newam:matrix.org> 169 for stm32-rs
<re_irc>
<@newam:matrix.org> That is huge
<re_irc>
<@thejpster:matrix.org> Nrf is about the same
<re_irc>
<@thejpster:matrix.org> (as rp-rs)
<re_irc>
<@tholmie:matrix.org> 83 for atsamd-rs/community
<re_irc>
<@thejpster:matrix.org> I don't feel like I hear a lot about xtensa and RISC-V - mostly cortex-m. Is that because they are happy? Or because they don't need us? Or both?
<re_irc>
<@newam:matrix.org> RISC-V I think is just because there are very few chips that can be purchased right now. I expect it will grow
<re_irc>
<@thejpster:matrix.org> I mean it's basically the ESP32 C series and and Gigadevice stuff, right?
<re_irc>
<@adamgreig:matrix.org> they even have a std-compatible esp risc-v target in rustc, `riscv32imc-esp-espidf`
<re_irc>
<@therealprof:matrix.org> Yeah, RISC-V are a bit dangling.
<re_irc>
<@therealprof:matrix.org> thejpster:matrix.org: No, there's a lot more. Is ESP32 C even out?
<re_irc>
<@adamgreig:matrix.org> there's #gd32v-rust:matrix.org but I think in general those chips are less widely used at the moment and maybe a lot of rust-on-riscv is softcores?
<re_irc>
<@josfemova:matrix.org> thejpster:matrix.org: Ah yes, the class division of those who have their arquitecture supported by llvm and those who not
<re_irc>
<@adamgreig:matrix.org> aw, there's #avr-rust_Lobby:gitter.im for that :P
<re_irc>
<@newam:matrix.org> One of the rust GCC's will eventually bring more avenues to support other architectures.
<re_irc>
<@tholmie:matrix.org> Can’t wait to see gcc codegen get to a good state
<re_irc>
<@josfemova:matrix.org> Does anyone here have an EOS S3 devkit?
<re_irc>
<@josfemova:matrix.org> Idk how popular it is. Sure a little niche but like...how niche?
<re_irc>
<@adamgreig:matrix.org> it seems neat, don't sparkfun have some boards with that on? shame the fpga part is so tiny
<re_irc>
<@thejpster:matrix.org> Hey, atmega328 is a Tier 3!
<re_irc>
<@josfemova:matrix.org> adamgreig: Yup. I bought one to play around with it, official dev kits are out of stock
<re_irc>
<@josfemova:matrix.org> Only the sparkfun ones are available, at least in digikey
<re_irc>
<@thejpster:matrix.org> Yeah the EOS looked cool
<re_irc>
<@thejpster:matrix.org> Maybe it's worth a "State of the Union" blog post, either for Christmas or the New Year.
<re_irc>
<@thejpster:matrix.org> This Year in Embedded Rust.
<re_irc>
<@thejpster:matrix.org> No I'm not volunteering.
<re_irc>
<@thejpster:matrix.org> I have ideas, not time.
<re_irc>
<@adamgreig:matrix.org> would you be interested in putting some bullet points or subheadings or whatever together for such a thing?
<re_irc>
<@adamgreig:matrix.org> in some ways I'm more interested in a sort of wishlist or new year goals than state of the union per se
<re_irc>
<@thejpster:matrix.org> It's good to look forwards and not just back
<re_irc>
<@adamgreig:matrix.org> but a summary of the current state sounds nice too, even if it was a bunch of numbers and some highlights
<re_irc>
<@thejpster:matrix.org> But hey the RP2040 isn't even a year old
<re_irc>
<@thejpster:matrix.org> Ok, fine. I'll get my laptop and do some digging.
<re_irc>
<@adamgreig:matrix.org> :D
<re_irc>
<@therealprof:matrix.org> Who knows, maybe you'll hit a gold vein...
<re_irc>
<@thejpster:matrix.org> Where do you edit these sorts of things? HackMD? Or in a PR?
<re_irc>
<@therealprof:matrix.org> I like HackMD for that.
<re_irc>
<@adamgreig:matrix.org> hackmd seems like a reasonable start, maybe followed by a PR to the blog
<re_irc>
<@thejpster:matrix.org> I think your RSS is broken
<re_irc>
<@thejpster:matrix.org> Feedly says the last was issue 22
<re_irc>
<@therealprof:matrix.org> Huh? Works fine for me.
<re_irc>
<@adamgreig:matrix.org> hmm, maybe it's outdated since the URL changed? it's wfm
<re_irc>
<@thejpster:matrix.org> Oh no, that might just need me
<re_irc>
<@thejpster:matrix.org> I need to sort by latest, not popular
<re_irc>
<@jacobrosenthal:matrix.org> The above the fold experience for the 'blog' view is pretty bad, its all boilerplate all the way down
<re_irc>
<@jacobrosenthal:matrix.org> first graph should maybe be an tldr instead of boilerplate
<re_irc>
<@jacobrosenthal:matrix.org> Either change the template somehow to fold after Highlights, or remove the boilerplate and let Highlights be the first graph
<re_irc>
<@thejpster:matrix.org> I'm sure they'd love a PR :)
<re_irc>
<@jamesmunns:beeper.com> jacobrosenthal: what do think about keeping the first line above the fold? The rest looks good!
<re_irc>
<@jamesmunns:beeper.com> I don't feel strongly, so "no" is an okay answer :)
<re_irc>
<@jacobrosenthal:matrix.org> Eh, its just such boilerplate. The title says the number. In fact I snuck the numbering out of the template so it doesnt even say what number it is anymore.