Apologies in advance for the simplistic nature of the question. I am guessing that the information I seek already exists somewhere, and in my experience these types of forum posts are likely to generate snarky/condescending responses. I promise I have cloned and scoured the microPython directory and done tons of google searching before turning to the forum. Anyways...
Background:
I am pretty well versed in C, but I am a complete beginner when it comes to Python in embedded systems. I have gotten up to the point of writing a script and using ./pyboard.py to load it onto my STM32F446RE, where it runs successfully.
Questions:
1 - When I use ' pyb.LED(1).on() ', what python library am I accessing, and what C library does this library access? Big picture, when accessing peripherals, how is the python code linked to the underlying C code? (a lot of which is presumably taken from the STM HAL in my case)
2 - How do I write my own python libraries and link them to C libraries?
If these questions are too broad for a forum post answer, pointing me to some literature would be incredible!
microPython Code Structure Help for a Beginner
Re: microPython Code Structure Help for a Beginner
Hi,
In this case "pyb" is a built-in. In ports/stm32/mpconfigport.h it's added to MICROPY_PORT_BUILTIN_MODULES.
MICROPY_PORT_BUILTIN_MODULES is used by py/objmodule.c which is used by the builtin import handler (py/builtinimport.c).
Back to stm32 -- pyb_module is externed (in portmodules.h) to its definition at the end of stm32/modpyb.c.
It defines a globals dict, which contains the LED class, etc, (see stm32/led.c) which has a locals dict, which contains the "on" method.
LED.on uses a MICROPY_HW_LED_ON macro, because it's highly board-specific and each board can deal with in it's own way, but typically ends up using the mp_hal_pin_low() method, which on STM32 writes directly to the BSRR register.
Not at all, this is a good question and I wish there was a good reference I could point you to, but nobody has really gotten around to it yet. It's ... uhh... on my list.
Starting at the beginning -- you've got an "import pyb" somewhere in your code. Modules are either "built-in" (i.e. written in C, part of the firmware), or they're loaded dynamically from the filesystem (.py or .mpy).
In this case "pyb" is a built-in. In ports/stm32/mpconfigport.h it's added to MICROPY_PORT_BUILTIN_MODULES.
MICROPY_PORT_BUILTIN_MODULES is used by py/objmodule.c which is used by the builtin import handler (py/builtinimport.c).
Back to stm32 -- pyb_module is externed (in portmodules.h) to its definition at the end of stm32/modpyb.c.
It defines a globals dict, which contains the LED class, etc, (see stm32/led.c) which has a locals dict, which contains the "on" method.
LED.on uses a MICROPY_HW_LED_ON macro, because it's highly board-specific and each board can deal with in it's own way, but typically ends up using the mp_hal_pin_low() method, which on STM32 writes directly to the BSRR register.
Sometimes. But often (e.g. LED) it bypasses the HAL and just works with the registers directly. (Although the register definitions are provided by teh HAL header files). But yeah a lot of things do use the higher level functions in the STM HAL especially when there's a bit of variation across families (F0, F4, F7, L0, L4, H7, etc) and the higher level functions hide that.