ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
<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> 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:
<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
<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> "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):
<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:
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 <>)
<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:
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
bomb has joined #rust-embedded
<sourcebox[m]> A bit OT: what are people here using for the GitHub workflow, e.g. PRs, syncing branches, etc? Just the web interface, the official client (no Linux yet)?
<Lumpio-> What's "syncin branches" and is that something you can't do with, you know, just git
<Lumpio-> +g
<sourcebox[m]> Sorry, I meant the local forks.
<sourcebox[m]> Motivation for my question is mainly that I think I do it too complicated.
<Lumpio-> Local forks being the copy on your personal github account or
<sourcebox[m]> Yep.
<Lumpio-> I think you can do it with just git push/pull and remotes
<sourcebox[m]> E.g. I want to do a PR for a project, so I'm forking it, make a new branch, edit code, then push, then crate the PR. So far so good, but when I want to do some more things later, I first go into the GH web interface, manually sync all branches (because upstream may have changed in the meantime). Then pull all branches.
<sourcebox[m]> Don't know if there's an easier way to do it.
<vollbrecht[m]> you can have different remotes and can all fetch them all together to your host if you wish so. So you can locally update to upstream than just push to your remote where you have push access to?
<sourcebox[m]> But you have to configure them manually, don't you?
<sourcebox[m]> E.g. when I fork embassy, there's no upstream remote by default.
<vollbrecht[m]> well you push currently against your fork right? so your current "origin" is your fork right? You can just create something like git remote add upstream
<vollbrecht[m]> if you than git fetch --all it will visit all remotes
<sourcebox[m]> Ok, that makes sense.
<sourcebox[m]> Especially on large repos like embassy that are updated a lot, this makes everything much easier.
<vollbrecht[m]> Next logical step now is to get into a spiritual flamewar fight -> "rebase vs merge" 🔥
<vollbrecht[m]> to call yourself a professional git user :p
<sourcebox[m]> My knowlegde of git is really not that good. It has also to do with the fact that most of the people I'm working with only know the bare minimum, so it's mostly a commit-only workflow.
<vollbrecht[m]> there is nothing wrong with that. If you can do all the things you need to do than its fine. If you feel you need to do more than its the right time to dive deeper.
<sourcebox[m]> This whole community thing here has teached me more about professional workflows than anything I did with jobs for 10 years.
<sourcebox[m]> I just saw there is a CLI, don't know how useful that is:
cr1901_ has joined #rust-embedded
Lumpio[m] has quit [Quit: Idle timeout reached: 172800s]
dngrs[m] has quit [Quit: Idle timeout reached: 172800s]
feerless[m] has quit [Quit: Idle timeout reached: 172800s]
Benn[m] has quit [Quit: Idle timeout reached: 172800s]
LiamRosenfeld[m] has quit [Quit: Idle timeout reached: 172800s]
bomb has quit [Remote host closed the connection]
bomb_ has joined #rust-embedded
bomb_ is now known as bomb
bomb has quit [Remote host closed the connection]
bomb has joined #rust-embedded
<blaine[m]> I'm having a heck of a time trying to get an SPI device working – it definitely works on Arduino/C++, so it's not a hardware issue. I've peeled everything back to as bare a config as I can manage to replicate what's happening with the arduino, but one of the big questions / things I can't quite replicate with embedded_hal's SPI implementation is that the arduino driver sets the CS pin to low and then waits 2ms just to "wake up"
<blaine[m]> the device. I think that's the thing that's required to talk to my SPI device, but I can't figure out how to do it.
<blaine[m]> I can do something like this:... (full message at <>)
<blaine[m]> ... but of course that moves ownership of the pin and it's no longer available to pass to the SpiDriver. Since the pins are singletons... I'm not sure how to get ownership back?
Lumpio[m] has joined #rust-embedded
<Lumpio[m]> The "Operation" type supports a delay
<Lumpio[m]> You could use that as the first thing to delay for a bit
<blaine[m]> <Lumpio[m]> "You could use that as the..." <- Yup! I've tried that, and no luck. Even if it did work, though, the notes for the embedded_hal implementation for esp explicitly say that driver implementations shouldn't do that:
<blaine[m]> Sadly, the docs allude to providing a configuration parameter, but don't say how to do that, exactly. I'm hoping I'm missing something obvious...
slabity[m] has quit [Quit: Idle timeout reached: 172800s]
barnabyw[m] has joined #rust-embedded
<barnabyw[m]> that looks like docs for the trait, not the implementation though? I’d expect config params to be documented in the docs for the actual implementation
<barnabyw[m]> never worked with esp myself, but is the the impl you’re using?
<barnabyw[m]> that takes a Config struct which has some fields which miiiight be related to your issue?
<barnabyw[m]> (also hi, not sure if you remember me from the indieweb community, fun to see you here too!)
<blaine[m]> barnabyw[m]: yup – I've tried the input_delay_ns config option, but no luck there, either. 🙈
<barnabyw[m]> this driver has a cs_pre_delay_us method?
<blaine[m]> barnabyw[m]: we get around! :D :D good to see you, too!
<barnabyw[m]> I’m just looking here btw, it’s a little hidden but rustdocs do show you a list of known implementors for any given trait
<barnabyw[m]> I think there’s a dedicated esp-rs room, you might get better answers for these very esp-specific questions there
<blaine[m]> barnabyw[m]: Huh, interesting. My rust is ... very basic. If Im using the SpiDeviceDriver, is it already a SpiSoftCsDeviceDriver, or do I need to do something extra/different to get one of those?
<barnabyw[m]> tbh I have no idea, as I said I’ve never used ESP so I’m just trying to make helpful guesses until someone who actually knows what they’re doing shows up
<barnabyw[m]> and am too tired to look into it further right now 😴
<blaine[m]> barnabyw[m]: They're very helpful in there, too! 😊 I'd love for whatever I end up with to be reusable across devices, and from other implementations I've found it does seem like this delay is probably specific to the SPI device I'm using, so something that will work generically for embedded_hal would be ideal.
<barnabyw[m]> hmm yeah if it’s something which isn’t possible to represent using the embedded_hal traits then making it interoperable might be tricky
<blaine[m]> barnabyw[m]: Appreciate the help! I'm very new to embedded stuff (and rust!). Someone on mastodon suggested a logic analyzer, which is in the post. In the meantime just having fun torturing myself with random guesses. ;-)
<blaine[m]> barnabyw[m]: It'd be a super bummer if embedded_hal's spi implementation doesn't support generic implementations of very common devices (I'm using a pn532 rfid board). 😢 There is a separate rust implementation for the pn532 (a few, actually) but they're all for old versions of embedded_hal. 🙈
<barnabyw[m]> it might just be that these delays are implementation-specific for some good reason, and that the better approach would be to write the driver without them, document that they’re necessary and leave it to the user to get the config right
bomb has quit [Quit: 💣]
cr1901_ is now known as cr1901
<vollbrecht[m]> <blaine[m]> "I'm having a heck of a time..." <- in esp-idf-hal we have two types of SpiDrivers, one that is using the hardware chipselect, and one that is using a software chipselect. The hardware chipselect is faster and lets the spi-peripheral do the complete job of managing everything, but does not allow for bigger post/pre delays between cs assertion and first clk_out.
<vollbrecht[m]> So in your case you can use the SoftCSDeviceDriver, it totaly manages all for you but essentially toggles cs pin manually for you, but also accepts a big pre/post delay before and after clockout starts.
<vollbrecht[m]> The other option would be to just use an SpiBus and not a SpiDevice. On a SpiBus by definition you would always yourself manage the CS line