HAL Driver for STM32 DFSDM driver

[tecnologic]

Hi all,

has anybody already written a hal driver for the DFSDM peripheral in the newer STMs? If not i will share my work here.

I started with the ADCv3 driver as a base and i am willing to implement nearly the same api as an ADC. The custom board that i am writing this for is based on a STM32F767VI so this will be my hardware under test.

@Giovanni: shall i supply a patch file? cause i started routing the clock configuration through the various headers and modified quite alot actual chibios files already.

regards

Tec

[Giovanni]

Hi,

It is not supported currently. I need to understand the nature of those changes, it is a bit late for this cycle anyway, I need to close it and release.

Edit: Is it a dedicated STM32 driver or a new driver model in the portable HAL? Post it here as patch or files and lets discuss.

Giovanni

[tecnologic]

Hi Giovanni,

i would say it could be a new HAL component, cause XMC4xxx have nearly the same peripheral called DSD. Basicly both supply digital SINC filters, inputs and output clock for delta sigma modulators, which are basicly ADCs supplying a 1Bit datastream at up to 20MHz samplerate.
In the C2000 cores even TI has such a peripheral.

So maybe the DFSDM term from ST is not a general name for this Component. What do u think is a better name? DSD= Delta Sigma Demodulator from Infineon is quite a short and meaningful name.

This is nothing for the comming release! I just started, and wanted to check if someone is already working on this.

At first i wanted to setup the clock for the peripheral. In the STM32L4 Port there are already the defines for this:

Code: Select all

#define STM32_DFSDMSEL_MASK     (1 << 31)   /**< DFSDMSEL mask.             */
#define STM32_DFSDMSEL_PCLK1    (0 << 31)   /**< DFSDM source is PCLK1.     */
#define STM32_DFSDMSEL_SYSCLK   (1 << 31)   /**< DFSDM source is SYSCLK.    */

and

/**
 * @brief   DFSDMSEL value (DFSDM clock source).
 */
#if !defined(STM32_DFSDMSEL) || defined(__DOXYGEN__)
#define STM32_DFSDMSEL                      STM32_DFSDMSEL_PCLK1
#endif

and

/**
 * @brief   DFSDM clock frequency.
 */
#if (STM32_DFSDMSEL == STM32_DFSDMSEL_PCLK1) || defined(__DOXYGEN__)
#define STM32_DFSDMCLK              STM32_PCLK1
#elif STM32_DFSDMSEL == STM32_DFSDMSEL_SYSCLK
#define STM32_DFSDMCLK              STM32_SYSCLK
#else
#error "invalid source selected for DFSDM clock"
#endif


These are all missing in the F7 port. and there will be a lot more to add.


regards

Tec

[Giovanni]

Hi,

Ah OK, so additions to the clock tree, not the huge changes I imagined

I agree on making this a generic DSD driver, let's discuss the API first, it could go in HAL6.

Giovanni

[tecnologic]

Yes i only changed the clock tree configuration and according defines. Next will be the registry.

in terms of api the ADC api fits quite good. Events like short circuit or analog watchdog can be handled by custom callbacks.

maybe it is useful to configure and handle each Filter (stm has 4 of them, as xmc and ti have) seperatly. So to have 4 Filter devices with seperate Filter configurations. The connected hardware input channel or software input can be configured by this filter configuration.

@edit: according to stm ref man they consider channel and filter confuration registers. But as i under stood only channels 0- 1 are connected to filter 0 and so on. So in the filter config could be a separete channel config, just as the sequence config in ADC driver.

The rest is start and stop conversion single conversion (software triggered) and start and stop continous conversion (hardware triggered)

The STM has some specials like seperate small Filters for the AWD on each hardware channel (8 for the STM32F767) which can also be read. So u get 2 measurements, one Fast not so accurate from the AWD and a slower max 24Bit measurement. For this i would only supply stm specific funktions.

DMA i would not use (makes only sens for the AWD value and this is custom), cause normal measurement will be done with control frequency so just a callback at the end of the sampling cycle is sufficient. This callback will be for each channel and will have the alread read measurement value as parameter. So the sampling can be restarted right away by a timer or software, without data overrun condition.

What du u think about this?

regards

Tec

[Giovanni]

I don't know the peripheral good enough to make meaningful suggestions.

The ADC idea is OK for storing data in a buffer, how do you feed the filter? if it is fed in SW then I could imagine some kind of stream where you write data.

Giovanni

[tecnologic]

The normal and standard use case is to feed a 1 Bit datastream via the IO Pins from a 2. order Delta sigma modulator, such as AMC1204.
But ST has the option to feed the Filter with a 16Bit wide stream via DMA, but XMC and TI don't support this kind of usage, so i consider the software input to the filter as some sort of custom.

The hole thing is then just an SADC but devided in two parts an external modulator and the internal hardware digital filter. Is there a HAL driver for the SADC of the STM32F37x devices? Then i can basicly reuse this one.

regards

Tec

[tecnologic]

The STM32F37 was the right idea. But this driver is written for the adc and sdadc. The STM32F7 has 3 standard ADCv1 i think and the DFSDM supplying 4 "addtional ADCs" just making a new revision of the ADC driver just to add this, is not the right way think. Cause the DFSDM needs a different configuration structure.

In my application i need the normal ADCs and the DFSDM at the same time. though I like the idea of using the normal adc api and supplying a different DFSDM config when using a DFSDM instance. In C++ this would be no problem but in plain C. i have no idea other then void pointers to achieve this and that is crap.

[Giovanni]

Wait, ADC-like API is OK, not using the very same ADC API, that would be problematic for a series of reasons.

Giovanni

[tecnologic]

Hi all,

i got i little further and now i'am struck in the general driver arragement. STM32F767 does have one DFSDM unit with 4 Filters und 8 Input Channels. At first i thought to define 4 Driver instances for the 4 Filters cause these are the main parts of the peripheral. But turns out that ST defined hardware structures for every channel and every filter. And to top that all the channel 0 has some global bits used for the hole DFSDM unit.

So what do u think is the best approch?

1: define one DSDDriver instance for the hole DFSDM unit and place an array of channel and filter configurations in the driver config structure.
2: think of a hole new init api. seperated for the filters and channels but this will not be portable cause at least the XMC DSD unit has only 4 Filters each with a dedicated input channel.

regards

Tec