stmhal: ADC class only uses ADC1 hardware
This issue appears not to be very minor for the pyboard or any board using 64- or 100-pin versions of the STM32F405, so it could be low-priority or 'won't fix'. However, I encountered this running MicroPython on an Olimex STM32-E407 dev board, which uses a 144-pin STM32F407. On this board, much of the GPIO from ports A, B, and C are connected to / utilized by on-board peripherals (like an Ethernet PHY). Most of the ADC input pins that are broken out to headers are on Port F, but those ADC pins are only connected internally to ADC3, so not accessible via the current ADC class:
>>> pf6 = pyb.ADC('PF6')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: pin F6 does not have ADC capabilities
>>>
Since I am already customizing the firmware a bit to get it running on the Olimex board, I think that I can solve my immediate problem by hacking a few lines in adc.c to use ADC3 instead of ADC1. I don't have a more generic solution yet, so I just wanted to raise the issue before I forgot about it.
The biggest potential benefit that I could see in enabling the ADC2 and ADC3 hardware for lower pin-count chips would be to enable high-speed interleaved ADC reads on those pins connected to all three instances, but it would take some serious recoding to allow this, for an application that may see relatively little use.
[ESP32] machine.ADC should be able to be initialised with pin numbers as well as machine.Pin
See the Documentation for ESP32 forum post. It appears that for at least the PyBoard/STM32 and ESP8266 ports machine.ADC can be initialized by either a pin number (int) or from an instance of machine.Pin. The ESP32 port only allows an instance of machine.Pin for ADC init.
I suggest we allow the ESP32 port to also accept pin numbers:
>>> import machine
>>> a = machine.ADC(35) # Currently fails. Instead must use:
>>> a = machine.ADC(machine.Pin(35))
Either of those last two lines should operate correctly.
(Incidentally I prefer the ESP32 behaviour of only accepting machine.Pin but consistency is more important in this case.)
Note that there are efforts to overhaul the ADC interface (See #3943 and #4213). The proposed change above could be introduced in a shorter time frame, maybe even for v1.10 (see #4356) and ought to complement the upcoming overhaul.