DFSDM for l4x6
jonathanherbst opened this issue · comments
Get DFSDM working for l4x6. One of the discovery kits for the L4, 32L496GDISCOVERY, uses an L496 and has some onboard mics attached to the dfsdm, but it's disabled in lib.rs for l4x6. Looks like the register layout is not the same as the l4x5 so it's not super straight forward.
I'd like to work on this next, looking for input and to see if anyone has tried it yet.
Yea - it looks like rather than breaking the PAC commands down by channel (dfsdm.ch0. etc), it's set up in the same namespace. Rust docs hasn't built the L4 PAC for L4x6, but I'd bet it's similar to the L5 impl here. It's a matter of feature-gating using that PAC syntax.
Ideally, the fix would be consolidation on the PAC side, but I'm happy with a bandaid here.
Thanks for the input David.
I think it would be better to have a consistent implementation between l4 variants at least and the current pac is even missing registers for filter1 on l4x6. I made a bug over at stm32_rs stm32-rs/stm32-rs#760 and put in a PR so we'll see what happens.
I'm working the bandaid. This will make the code a lot more verbose and messy, but worth it IMO.
Just pushed a change that should hopefully get this tarted. The good news: I got it working on L5. The bad: it doesn't yet work on L4 (Other than x5). Any ideas?
I built the docs for L4x6, L4x5, and L552. L4x6 uses dfsdm1 for the module and the channel regs look like chcfg0r1, L552 uses dfsdm1 for the module and the channel regs look like ch0cfgr1, and L4x5 uses dfsdm for the module and has the channels separated like you have already. 😵💫
I made a topic branch that almost compiles for L4x6, but I ran into the problem where the pac crate doesn't have registers for filter 1.
Great finds re the details. Long term solution is to make all the PACs the same, ideally with the channel-based indexing we see on H7.
Some further notes:
- It turns out it was never working properly with L4x5; I had feature gated out some sections
- The only family I've actually tested DFSDM with on hardware is H7, but I think it's likely it'll work on other families once we sort through these compile/PAC differences and errors
- I'm going to take a stab on working around the l4x6 compatibility with the current PAC, as I did with L5, thanks you your clarification on the reg name format - without filter 1.
- This module is rapidly turning into a mess with these verbose feature-gates; there might be a cleaner way to consolidate them, but I'm going with quick+dirty now
Could you post the L4x6 register names for all the relevant DFSDM regs? Like you did for cfgr1. Maybe a screenshot of the docs you built?
Sorry, I've been busy lately. Here are the docs: https://drive.google.com/file/d/1Xq-w1swOkWfiuLY3aT9OrzUZ8TOLLZkX/view?usp=sharing
You can also build them from this repo, but only if everything builds ex: cargo doc --features l4x6 --open
Thank you. From looking at that, I'm assuming the filter x regs are called dfsdmx_ on L4x6, but haven't tested. My current plan is to wait until the PAC gets fixed with the work you've done there. Might try to patch in these reg names for L4x6 as an alternative, but I'm not sure if it's viable, even ignoring filter 1. With the L5 addition, the module's already a mess of repeated code with feature-gates. Perhaps there's a better way to organize the feature-gates; the quick+dirty approach I did here for L5 is repeating the gate each time to satisfy the type check. Thoughts?
You're correct about the filter regs on L4x6. I'm fine waiting for the PAC, but I don't know how active they are, I haven't had any feedback on my pr yet. In my branch that I linked above I made separate register access structs for each different register config (L4x6, and L4x5) I think it makes the driver code cleaner, but I'm pretty new to rust so there may be better tools to do that.
Implemented on l4x6 in latest commit; give it a shot
Released in 1.5.2
Closing as fixed. If you have any issues getting DFSDM to work with those mics, please open another issue.
I hope the PAC eventually unifies; I'm not happy with how long the DFSDM module here got addressing this, but it was IMO worth it.