ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
<cr1901> Of course, porting to atsamd-hal 0.16, now the USB peripheral examples don't work even tho I _know_ I have the pins correct
* cr1901 can't win...
<cr1901> ("The specified I/O operation on %hs was not completed before the time-out period expired.
<cr1901> "... what?)
M762spr[m] has quit [Quit: Idle timeout reached: 172800s]
sajattack[m]1 has joined #rust-embedded
<sajattack[m]1> 😭
<sajattack[m]1> #atsamd-rs_community:gitter.im Some discussion about usb issues here in the past week or so
<cr1901> But I'm kinda between a rock and a hard place rn... can't use v0.14 b/c EIC pins are missing e-hal trait impls. Can't use v0.16 because USB won't reliably enumerate
<sajattack[m]1> it's on my list to merge the ehal 1.0 pr
<cr1901> >EIC pins are missing e-hal trait impls. <-- oh, and not enough of the internals are exposed for me to make a newtype
<cr1901> sajattack[m]1: Nope, 0.2.* e-hal. Nobody* has written drivers for 1.0
<sajattack[m]1> oh ok
<cr1901> (* Obviously not true, but I'm not charitable tonight.)
<sajattack[m]1> We're pretty low on maintainer energy. I passed ownership on to bradleyharden then he got preoccupied and now it's defacto passed back to me while I have lots of other stuff going on. Sorry for the difficulty.
<sajattack[m]1> atsamd-rs is a bit of a hot potato :/
<cr1901> It's not just one thing, it's a cascade of things I can't fix... in v0.14, I can't even tell the polarity of EIC events if I'm using Sense::BOTH
<cr1901> If I could, I would have a workaround that would've made me not even look at v0.16 lol
<cr1901> (Basically I want to do event-driven IR remote receiver without polling 40,000 ints per sec: https://github.com/jkristell/infrared/blob/b0cb9e341c862b2f60286e938c6d6dda308ce790/examples/bluepill/src/bin/receiver-event-driven.rs#L78)
<cr1901> > I can't even tell the polarity of EIC events if I'm using Sense::BOTH <-- AFAICT, in v0.14, EIC wraps the GPIO pin and does not provide a way to get the GPIO pin back even via a ref
<cr1901> sajattack[m]1: How do I use into_floating_interrupt?
<sajattack[m]1> pins.d3.into_floating_interrupt() ?
<sajattack[m]1> depends what hal you're using
<cr1901> the one that trinket_m0 uses, so atsamde, v0.14
<cr1901> How do I set that up into_floating_interrupt() for interrupts on both edges, and which interrupt vector name should I use?
<cr1901> or is the idea that "only the EIC is capable of generating GPIO interrupts"?
<cr1901> (in which case, Idk what into_floating_interrupt is intended to do)
<sajattack[m]1> into_floating_interrupt just sets the pin mode
<cr1901> Oh, I guess I don't understand what Floating<Interrupt> pin mode is
<sajattack[m]1> there are some interrupt examples using rtic for atsame54_xpro https://github.com/atsamd-rs/atsamd/blob/master/boards/atsame54_xpro/examples/mcan.rs
<sajattack[m]1> xiao is probably more applicable
<sajattack[m]1> pin mode is just the concept of pin multiplexing really
<cr1901> sajattack[m]1: Okay, thank you, this will most likely get me unstuck
<sajattack[m]1> yw we do our best
<cr1901> This is a stupid question, but why does EIC and each EXTINT have their own separate interrupts?
<sajattack[m]1> I think extint is per-pin in the hal and eic is the whole peripheral in the pac
<sajattack[m]1> tbh I got handed this crate after haphazardly porting a bunch of dodgy arduino code to it lol. I'm not a professional embedded developer and have limited experience with interrupts and I rely on other maintainers and contributors I trust for most of this stuff
* cr1901 nods
<cr1901> It looks like I'm going to have to initialize the EIC using the PAC instead of HAL; I assume the EIC consuming a Pin is more of a lint than anything
<cr1901> the HAL* EIC
<sajattack[m]1> yeah that's one area others have commented on - other hals have more flexibility to return peripherals. It's probably just an oversight on our end
<cr1901> The v1/v2 stuff also doesn't give great error messages (you have to convert to the _exact_ corresponding v1 type you need before you can convert with into() to v2, but the error msgs don't make that obvious)
<sajattack[m]1> issues and prs welcome ;)
<cr1901> that's a rustc issue, not a HAL issue :P
<sajattack[m]1> I thought there was a macro for custom error messages?
<sajattack[m]1> but yeah maybe it needs to react to stuff only rustc knows
<sajattack[m]1> just spitballin
<cr1901> https://github.com/atsamd-rs/atsamd/blob/master/hal/src/gpio/pin.rs#L517-L526 "violating this requirement is unsafe". Does that mean "insta-UB" or just "potential UB"?
<sajattack[m]1> 🤷‍♂️ bradleyharden ?
<cr1901> In v0.14, the EIC owns the Pin, but doesn't use it at all (AFAICT): https://docs.rs/atsamd-hal/0.14.0/src/atsamd_hal/thumbv6m/eic/pin.rs.html#295-302
<cr1901> err wrong src lines
<sajattack[m]1> maybe. There were some issues around eic in that time frame I believe
<cr1901> Basically, my current plan is to create an EIC, drop it, and then unsafely get the Pin() back somehow
<cr1901> Actually, it's not clear to me how to conjure up a Pin, even unsafely
<cr1901> >It is not possible for users to create new instances of a Pin- aaaaaaaaaaaaaaaaaaaaahhhhh
<cr1901> sajattack[m]1: This is what I've ended on for the night. I welcome any attempts to make this safer: http://gopher.wdj-consulting.com:70/paste/3c583cab-2e3a-436a-a9b6-81ba577d4782.txt
roofi[m] has joined #rust-embedded
<roofi[m]> Hi.. I compiled embassy basic example and got 6.6MB. I use ESP32C3 which only has 4MB flash.
<roofi[m]> Is there a way forward?
<M9names[m]> how are you measuring 6.6MB? are you doing a release build?
<M9names[m]> if you just check the output file, that is not the size that is flashed to the device because it includes debug information and other metadata that isn't necessary to run the program.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/nNgPiFbOCXTdivisoRqgyvdf>)
<danielb[m]> that is the size of the .elf file which is not what gets written to the device
<M9names[m]> jinx :P
<danielb[m]> M9names[m]: i was slow and you were more detailed :)
GuineaWheek[m] has quit [Quit: Idle timeout reached: 172800s]
cr1901 has quit [Ping timeout: 260 seconds]
RobertJrdens[m] has quit [Quit: Idle timeout reached: 172800s]
sourcebox[m] has joined #rust-embedded
<sourcebox[m]> ryan-summers: FYI, you suggested it: https://github.com/btrepp/usbd-midi/issues/14
bradleyharden[m] has joined #rust-embedded
<bradleyharden[m]> @cr1901, if the API isn't sufficient for some reason or the documentation isn't clear, please create an issue. I can't promise any fixes, as we're short on maintainer time right now. But we could probably at least help guide you to a solution. Also, you might have better luck finding help in the atsamd-hal room, rather than here.
<bradleyharden[m]> s/,/:/
<bradleyharden[m]> s/,/:/
<M9names[m]> they're on here through the IRC channel, don't know if they even have a matrix account