Skip to content

Conversation

haukepetersen
Copy link
Contributor

@haukepetersen haukepetersen commented Jun 29, 2017

EDIT
This PR is still work in progress, just wanted to put it already out there to prevent multiple people working on this...

I have not test all of the STM CPUs, yet. Especially I doubt the L1 and L4's to work, as it seems they have subtle differences in their ADC registers...

L1 works, L4 was not implemented before anyway...

@haukepetersen haukepetersen added the State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet label Jun 29, 2017
@aabadie
Copy link
Contributor

aabadie commented Jun 29, 2017

just wanted to put it already out there to prevent multiple people working on this...

good idea, I was thinking of this some times ago :)

@aabadie
Copy link
Contributor

aabadie commented Jun 29, 2017

this already needs rebase btw...

@aabadie aabadie added this to the Release 2017.10 milestone Jun 29, 2017
@aabadie aabadie added Platform: ARM Platform: This PR/issue effects ARM-based platforms Type: new feature The issue requests / The PR implemements a new feature for RIOT labels Jun 29, 2017
@aabadie aabadie self-assigned this Jun 29, 2017
@haukepetersen
Copy link
Contributor Author

rebased

@aabadie aabadie changed the title cpu/stm32: unified ADC driver implementaions cpu/stm32: unified ADC driver implementations Jun 29, 2017
Copy link
Contributor

@aabadie aabadie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couldn't resist in having a look at this one. There 2 things in this PR:

  • unified ADC
  • common configuration for some nucleo boards (as suggested in a comment that I couldn't find)

I would prefer to provide the second point in dedicated PRs (even if I like the general idea).

{GPIO_PIN(PORT_B, 1), 0, 9} \
}
static const adc_conf_t adc_config[] = {
{ .pin = GPIO_PIN(PORT_B, 0), .dev = ADC_1, .chan = 8 },
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

extra space before 8 (and 9 the line below)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will fix

Copy link
Contributor

@aabadie aabadie Nov 8, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is still this one

{ .pin = GPIO_PIN(PORT_A, 5), .dev = ADC_1, .chan = 5 },
{ .pin = GPIO_PIN(PORT_A, 6), .dev = ADC_1, .chan = 6 },
{ .pin = GPIO_PIN(PORT_A, 7), .dev = ADC_1, .chan = 7 },
{ .pin = GPIO_PIN(PORT_A, 2), .dev = ADC_1, .chan = 2 }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe move this line at third position

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nope, the way I put them here is so that the Ardunio Ax lines match RIOTs ADC_LINE(x) configuration. ST simply mapped their ADCs like this...

* @name ADC configuration
* @{
*/
#define ADC_CONFIG { \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems very different from the common part.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand, what do you mean with common part?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess @aabadie means, currently there are 5 ADC lines defined here, but in your common definition in periph_conf_nucleo32.h above you define 8 ADC lines.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, but as I see it, the existing config was incomplete and this PR fixes that...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

might be related to the fact that SPI1 and some PWM channels are on some of the ADC lines, too. But even the original ADC config does not ignore those pins and would hence collide with those, too.

@haukepetersen
Copy link
Contributor Author

I would prefer to provide the second point in dedicated PRs (even if I like the general idea).

I don't like to make this a separate PR -> IMHO it is good practice to start the config centralization in a concrete PR (as in this one), so we have already some 'meat' to put in the common files and it is clear how the centralization is intended to work...

* @name ADC configuration
* @{
*/
#define ADC_NUMOF (0)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unrelated?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nope, related: the opencm904 uses a stm cpu and the reworked adc driver does not requite 'empty' numof defs anymore... So related cleanup.

* @name ADC configuration
* @{
*/
#define ADC_NUMOF (0)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dito, seems unrelated

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here.

@smlng
Copy link
Member

smlng commented Jul 19, 2017

@haukepetersen what's your ETA on this one? Further, I think L1-L4 should be adaptable to this, too - maybe a bit more ifdef, but as there is already that much ...

@haukepetersen
Copy link
Contributor Author

ETA: as soon as possible, but not before beginning of August, as there is the Dagstuhl workshop next week...

@haukepetersen
Copy link
Contributor Author

So, finally got to this PR again - sorry for the delay.

The PR should now be ready for review/testing. All boards that had the ADC feature before should still work. Just tested with nucleo-f072, nucleo-f411, and nucleo-l152.

ADC drivers are missing for stm32l0, stm32l4, and stm32f7, but these never existed so far and merging this into the unified driver is work for another day...

@haukepetersen haukepetersen added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet labels Aug 15, 2017
@haukepetersen haukepetersen added Community: Hack'n'ACK candidate This PR is a candidate for review and discussion during one of RIOT's monthly Hack'n'ACK parties and removed CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Aug 29, 2017
@haukepetersen
Copy link
Contributor Author

Picked up work on this again, update will follow soon

#endif

/* find out which bus the ADC is connected to */
#if defined()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like there are things missing here

@haukepetersen
Copy link
Contributor Author

yes, its still work in progress. Run into trouble with some STM CPUs and never found the time to continue debugging... But I havn't forgotten about this PR :-)

@haukepetersen haukepetersen added the State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet label Nov 8, 2017
@aabadie
Copy link
Contributor

aabadie commented Nov 8, 2017

#7815 has been merged so maybe this PR could be adapted with it ?

@haukepetersen
Copy link
Contributor Author

  • addressed comment
  • rebased

{ .pin = GPIO_PIN(PORT_A, 3), .dev = ADC_1, .chan = 3 },
{ .pin = GPIO_PIN(PORT_C, 0), .dev = ADC_1, .chan = 10 },
{ .pin = GPIO_PIN(PORT_C, 3), .dev = ADC_1, .chan = 13 },
{ .pin = GPIO_PIN(PORT_F, 3), .dev = ADC_3, .chan = 9 },
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The build fails for me because of the use of ADC_3. Even if it's compliant with the board datasheet.

#if defined(CPU_MODEL_STM32F407VG) || defined(CPU_MODEL_STM32F415RG) \
|| defined(CPU_MODEL_STM32F446RE) || defined(CPU_MODEL_STM32F429ZI)
ADC_2 = 1, /**< ADC2 */
ADC_3 = 2 /**< ADC3 */
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ADC_3 is not defined for CPU_FAM_STM32F2 but is used in nucleo144-f207: the build fails. I tried to enable it for f207 but the application hangs when initializing ADC3...

{ .pin = GPIO_PIN(PORT_A, 3), .dev = ADC_1, .chan = 3 },
{ .pin = GPIO_PIN(PORT_C, 0), .dev = ADC_1, .chan = 10 },
{ .pin = GPIO_PIN(PORT_C, 3), .dev = ADC_1, .chan = 13 },
{ .pin = GPIO_PIN(PORT_F, 3), .dev = ADC_1, .chan = 9 },
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to the board datasheet, the device should be ADC_3. I tried to change that but then the application hangs when initializing it (similar issue with f207).

@haukepetersen
Copy link
Contributor Author

Hmm, seems like I did not compile-test my last fix. I don't have any of these boards here, so I couldnt test on hardware...

Will take a look again at the ADC3 situation, shouldn't be too hard to find :-)

@kaspar030 kaspar030 removed this from the Release 2018.04 milestone Apr 11, 2018
@kYc0o kYc0o removed the Community: Hack'n'ACK candidate This PR is a candidate for review and discussion during one of RIOT's monthly Hack'n'ACK parties label Aug 28, 2018
@stale
Copy link

stale bot commented Aug 10, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

@stale stale bot added the State: stale State: The issue / PR has no activity for >185 days label Aug 10, 2019
@haukepetersen haukepetersen added the State: don't stale State: Tell state-bot to ignore this issue label Aug 12, 2019
@stale stale bot removed the State: stale State: The issue / PR has no activity for >185 days label Aug 12, 2019
@MrKevinWeiss MrKevinWeiss added this to the Release 2021.07 milestone Jun 21, 2021
@MrKevinWeiss MrKevinWeiss removed this from the Release 2021.07 milestone Jul 15, 2021
@fjmolinas
Copy link
Contributor

@aabadie do you think this one is still relevant with the current stm32 structure?

@aabadie
Copy link
Contributor

aabadie commented Nov 18, 2021

Having everything in a single adc.c file is not the way to go IMHO, we should take inspiration of what was done for i2c. The shared ADC config for some nucleo64 boards is something that could be kept.
In the current state, this PR is too much out-of-date, so better split-out parts of it in new PRs.

@haukepetersen
Copy link
Contributor Author

I will not have the time to work on this any further... Please feel free to close/fork/take this PR or whatever might be useful of this :-)

@Teufelchen1
Copy link
Contributor

Closed as out-of-date.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Platform: ARM Platform: This PR/issue effects ARM-based platforms State: don't stale State: Tell state-bot to ignore this issue Type: new feature The issue requests / The PR implemements a new feature for RIOT
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants