<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>
> 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>
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?
<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 https://github.com/embassy-rs/embassy
<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: https://cli.github.com/
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]>
... 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?
<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]>
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