cpu/stm32: unified ADC driver implementations#7277
cpu/stm32: unified ADC driver implementations#7277haukepetersen wants to merge 9 commits intoRIOT-OS:masterfrom
Conversation
good idea, I was thinking of this some times ago :) |
|
this already needs rebase btw... |
00ce143 to
51e0ad4
Compare
|
rebased |
aabadie
left a comment
There was a problem hiding this comment.
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.
extra space before 8 (and 9 the line below)
| { .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.
Maybe move this line at third position
There was a problem hiding this comment.
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.
This seems very different from the common part.
There was a problem hiding this comment.
I don't understand, what do you mean with common part?
There was a problem hiding this comment.
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.
yes, but as I see it, the existing config was incomplete and this PR fixes that...
There was a problem hiding this comment.
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 | ||
| * @{ | ||
| */ |
There was a problem hiding this comment.
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 | ||
| * @{ | ||
| */ |
|
@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.
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.
The build fails for me because of the use of ADC_3. Even if it's compliant with the board datasheet.
| #endif | ||
| #if defined(CPU_MODEL_STM32F407VG) || defined(CPU_MODEL_STM32F415RG) \ | ||
| || defined(CPU_MODEL_STM32F446RE) || defined(CPU_MODEL_STM32F429ZI) | ||
| ADC_2 = 1, /**< ADC2 */ |
There was a problem hiding this comment.
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.
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...