This commit adds support for the dual-analog-pads on STM32H7 parts. These
pads/pins are called PA0_C/PA1_C/PC2_C/PC3_C in the datasheet. They each
have an analog switch that can optionally connect them to their normal pin
(eg PA0). When the switch is open, the normal and _C pin are independent
pins/pads.
The approach taken in this commit to make these _C pins available to Python
is:
- put them in their own, independent row in the stm32h7_af.csv definition
file, with only the ADC column defined (they are separate machine.Pin
entities, and doing it this way keeps make-pins.py pretty clean)
- allow a board to reference these pins in the board's pins.csv file by the
name PA0_C etc (so a board can alias them, for example)
- these pins (when enabled in pins.csv) now become available like any other
machine.Pin through both machine.Pin.board and machine.Pin.cpu
- BUT these _C pins have a separate pin type which doesn't have any
methods, because they don't have any functionality
- these _C pins can be used with machine.ADC to construct the appropriate
ADC object, either by passing the string as machine.ADC("PA0_C") or by
passing the object as machine.ADC(machine.Pin.cpu.PA0_C)
- if a board defines both the normal and _C pin (eg both PA0 and PA0_C) in
pins.csv then it must not define the analog switch to be closed (this is
a sanity check for the build, because it doesn't make sense to close the
switch and have two separate pins)
Signed-off-by: Damien George <damien@micropython.org>
The STATIC macro was introduced a very long time ago in commit
d5df6cd44a433d6253a61cb0f987835fbc06b2de. The original reason for this was
to have the option to define it to nothing so that all static functions
become global functions and therefore visible to certain debug tools, so
one could do function size comparison and other things.
This STATIC feature is rarely (if ever) used. And with the use of LTO and
heavy inline optimisation, analysing the size of individual functions when
they are not static is not a good representation of the size of code when
fully optimised.
So the macro does not have much use and it's simpler to just remove it.
Then you know exactly what it's doing. For example, newcomers don't have
to learn what the STATIC macro is and why it exists. Reading the code is
also less "loud" with a lowercase static.
One other minor point in favour of removing it, is that it stops bugs with
`STATIC inline`, which should always be `static inline`.
Methodology for this commit was:
1) git ls-files | egrep '\.[ch]$' | \
xargs sed -Ei "s/(^| )STATIC($| )/\1static\2/"
2) Do some manual cleanup in the diff by searching for the word STATIC in
comments and changing those back.
3) "git-grep STATIC docs/", manually fixed those cases.
4) "rg -t python STATIC", manually fixed codegen lines that used STATIC.
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
This is now consistent with other ports.
Also renamed `pin_{board/cpu}_pins_locals_dict` to
`machine_pin_{board/cpu}_pins_locals_dict`.
This work was funded through GitHub Sponsors.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
Instead of being an explicit field, it's now a slot like all the other
methods.
This is a marginal code size improvement because most types have a make_new
(100/138 on PYBV11), however it improves consistency in how types are
declared, removing the special case for make_new.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
The keyword "af" has been deprecated for some time and "alt" should be used
instead (but "af" still works).
Signed-off-by: Damien George <damien@micropython.org>
With this and previous patches the stm32 port can now be compiled using
object representation D (nan boxing). Note that native code and frozen mpy
files with float constants are currently not supported with this object
representation.
Newer versions of the HAL use names which are cleaner and more
self-consistent amongst the HAL itself. This patch switches to use those
names in most places so it is easier to update the HAL in the future.
Header files that are considered internal to the py core and should not
normally be included directly are:
py/nlr.h - internal nlr configuration and declarations
py/bc0.h - contains bytecode macro definitions
py/runtime0.h - contains basic runtime enums
Instead, the top-level header files to include are one of:
py/obj.h - includes runtime0.h and defines everything to use the
mp_obj_t type
py/runtime.h - includes mpstate.h and hence nlr.h, obj.h, runtime0.h,
and defines everything to use the general runtime support functions
Additional, specific headers (eg py/objlist.h) can be included if needed.
This is to keep the top-level directory clean, to make it clear what is
core and what is a port, and to allow the repository to grow with new ports
in a sustainable way.
