DAC API

[se-bi]

Maybe someone also missing that and implemented it?
@chris-durand ;-)

[W-M-D]

Ever make any progress on this? I'm about to start implementing it if not.

[rleh]

Ping @chris-durand 😉

[W-M-D]

Well starting now. I'm going to at least do the stm32.

[gueldenstone]

Hi, I'm a new modm user and I would like to try it on a project using a DAC I see some Code for the mcp4922 in the repository but no way to use it currently @W-M-D is that what you're working on?

[salkinium]

This issue is about the STM32 integrated DAC unfortunately.

The MCP4922 was part of xpcc.io but I didn't port it to modm, due to running out of motivation and not having the hardware to test it.
If you want to port it, you can have a look at the DRV832x driver, which uses the non-blocking, multiple-access API: https://github.com/modm-io/modm/blob/develop/src/modm/driver/motor/drv832x_spi_impl.hpp#L125-L176

[gueldenstone]

Oh, I'm sorry anyway thank you for the fast answer! I will look into it and share it if I come up with something :)

[mcbridejc]

I wrote a simple synchronous driver for the STM32 DAC. I'm using it on the STM32F413, but I haven't done any looking into how similar/dissimilar the DAC is on other parts/families.

It's here: develop...mcbridejc:stm32-dac

[salkinium]

Great! Do you want to merge it regardless? lbuild lets you enable the driver only for the F413, so that you don't need to deepdive into other devices. But this way your work won't be lost, and other's can expand it at a later time.

[mcbridejc]

I'd be happy to! Then I can get my project off of my fork and back on the main modm repo.

I'll take a pass at getting the doc comments up to par. Let me know if you have any issues with the API as is.

At what point do you recommend enabling for other parts? I suspect it will work on many or even all F4s; perhaps other families. I can look over some datasheets to see if I can find any differences, but I'm not about to do an exhaustive search of all parts. Do you prefer to enable drivers only for parts that are tested to work, or if its "expected" to work everywhere do you enable for everything and risk possible exceptions being found later?

The ST HAL drivers don't have any variations at least, so I expect the DAC is the same for all F4 parts anyway: https://github.com/STMicroelectronics/STM32CubeF4/blob/master/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_dac.c#L223

[salkinium]

Do you prefer to enable drivers only for parts that are tested to work, or if its "expected" to work everywhere do you enable for everything and risk possible exceptions being found later?

We usually enable a driver for an entire family, since they only very rarely differ. The CI may complain about missing defines sometimes, if it does not, the risk is very small.

I expect the DAC is the same for all F4 parts anyway

Yeah, me too. You may also additionally check this comparison tool, which shows it's the same DAC across the entire F4: https://agg.io/u/stm32/stm32f/stm32f4/DAC_0x40007400.html
There also this, but not good for comparisons: https://stm32-rs.github.io/stm32-rs/STM32F410.html#DAC

[salkinium]

It looks like F0, F1 (partially), F2, F3 (partially), F4, F7 share this DAC implementation. You can simply opportunistically enable it for all and then check the CI what families "survive" without any changes. Then you can decide whether to fix it, or simply disable that family, perhaps with a comment for someone else to fix later. There's nothing bad about delegating this, that was a large motivation for lbuild.

[salkinium]

Let me know if you have any issues with the API as is.

Clean and simple, I like it!