STM32F373 SDADC lld

[beause]

Hello,

I've been tasked with getting the SDADC's working on the STM 32373eval board.

I noticed Giovanni, that you submitted some code for the 32F37x and also a demo program for the 32373eval board on Sunday Mar. 3rd 2013.

Is there any SDADC lld driver code that is a work in progress that hasn't been submitted? I don't want to duplicate any work that you are doing, and would like to be able to merge cleanly.

I have taken the adc_lld.[ch] from the os/hal/platforms/STM32F4xx code and modified it so that it works with the STM32F37x. I have a demo program that samples the analog POT on the 32373eval board, as well as the internal temp sensor.

I'm in the process of pushing my changes up to a github repo. Hope that is of interest to you.

[Giovanni]

Hi,

Thanks for the head up. It is definitely planned, I know there are also other persons waiting for that driver so please go ahead while I do the re-validation of all the other drivers on that platform.

Giovanni

[beause]

Hi Giovanni,

I've finished my changes for the STM32F373 SDADC. I have a fork of mabl/ChibiOS with my changes on github, but was wondering in what form do you want code contributions?

[Giovanni]

Hi,

Just post the files zipped here in the forum.

Giovanni

[beause]

Please find attached a zip file with contributions for the STM32F373 SDADC support. There is also a demo program that uses the STM 32373eval board's PT100 temperature sensor. This was ported from the STM 32373 eval board software.

Please look in particular at the os/hal/platforms/STM32F37x/adc_lld.[ch] files.

[Giovanni]

Hi,

Thanks, I will review it for inclusion.

Giovanni

[Giovanni]

Hi,

Sorry but the driver is not mature enough for inclusion as-is. I'll have to do some rework on it. I am committing the code on the repository but it is not meant to be used yet.

The main problem is that apparently you tried to start from the STM32F4 driver whose configuration settings are very different because it has to deal with the "advanced" DMA, the STM32F37x uses the normal DMA unit.

Except for problems with the configuration the code looks good, I liked how you interfaced both ADC types using a single structure.

Giovanni

[jgobuyan]

Hi,

I am looking at the latest SDADC code in mabl and there seems to be a type conflict with adcsample_t. For regular ADC conversions, uint16_t is appropriate, but for all other conversion types (injected ADC, regular and injected SDADC), the type should really be signed. I realize that you are only supporting regular ADC conversions and injected SDADC conversions with the current, but the conflict does exist between these two conversion types. Do you have any thoughts on how this could be resolved? I would like to avoid casting between signed and unsigned types if at all possible.

[Giovanni]

Hi,

You could just cast to int16_t, another solution could be to make that type an union of a signed and an unsigned but this would break code compatibility.

Giovanni