-
Notifications
You must be signed in to change notification settings - Fork 2.1k
cpu/stm32: unified ADC driver implementations #7277
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
good idea, I was thinking of this some times ago :) |
this already needs rebase btw... |
00ce143
to
51e0ad4
Compare
rebased |
There was a problem hiding this 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).
boards/msbiot/include/periph_conf.h
Outdated
{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 }, |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will fix
There was a problem hiding this comment.
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 } |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 { \ |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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.
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) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unrelated?
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dito, seems unrelated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same here.
@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 ... |
ETA: as soon as possible, but not before beginning of August, as there is the Dagstuhl workshop next week... |
ce3c701
to
8456356
Compare
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 ADC drivers are missing for |
8456356
to
ac3597a
Compare
Picked up work on this again, update will follow soon |
cpu/stm32_common/periph/adc.c
Outdated
#endif | ||
|
||
/* find out which bus the ADC is connected to */ | ||
#if defined() |
There was a problem hiding this comment.
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
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 :-) |
#7815 has been merged so maybe this PR could be adapted with it ? |
644dd46
to
817d14e
Compare
|
{ .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 }, |
There was a problem hiding this comment.
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 */ |
There was a problem hiding this comment.
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 }, |
There was a problem hiding this comment.
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).
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 :-) |
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. |
@aabadie do you think this one is still relevant with the current stm32 structure? |
Having everything in a single |
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 :-) |
Closed as out-of-date. |
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...