Accessing hardware from native .mpy code
-
- Posts: 3
- Joined: Sun Dec 26, 2021 8:48 pm
Accessing hardware from native .mpy code
Hello! I need to integrate existing C code into my MicroPython project. I`ve already determined that the most suitable option for me would be a dynamically loaded .mpy module. The C code should manage a chip via the I2C protocol, so I`m looking for any way to access I2C hardware from .mpy module. It is possible to just include port-specific .h and .c files and use the hardware directly, however, I`m wondering, if there is a way to use MicroPython built-in I2C library?
- OlivierLenoir
- Posts: 126
- Joined: Fri Dec 13, 2019 7:10 pm
- Location: Picardie, FR
Re: Accessing hardware from native .mpy code
Can you give us the i2c device reference you're using?
For i2c you can start with this documentation.
For i2c you can start with this documentation.
Olivier Lenoir
https://gitlab.com/olivierlenoir
https://gitlab.com/olivierlenoir
-
- Posts: 3
- Joined: Sun Dec 26, 2021 8:48 pm
Re: Accessing hardware from native .mpy code
I need to integrate the USB power delivery control library for the FUSB302 PHY. You can find it there:Can you give us the i2c device reference you're using?
https://github.com/ReclaimerLabs/USB_PD
This documentation link is for the Python side of MicroPython, however, I`m working with the native C code. MicroPython allows usage of native C via this feature. I`ve successfully got this example up and running, as well as other native module examples from the MicroPython SDK. However, none of them demonstrate how to access the hardware.For i2c you can start with this documentation.
Re: Accessing hardware from native .mpy code
I don't see differences between "code accessing hardware" and "code moving memory content around".
If you have working C/Assembler code already talking to your hardware - great, go ahead! Most likely you will need some interface code to micropython.
However, as your application doesn't look time critical, a few reads+writes over the I2C bus can be done in micropython as well.
This looks much simpler to me than a mixed C/Native Code/Micropython approach.
Regards,
Thomas
If you have working C/Assembler code already talking to your hardware - great, go ahead! Most likely you will need some interface code to micropython.
However, as your application doesn't look time critical, a few reads+writes over the I2C bus can be done in micropython as well.
This looks much simpler to me than a mixed C/Native Code/Micropython approach.
Regards,
Thomas
A few hours of debugging might save you from minutes of reading the documentation!
My repositories: https://github.com/karfas
My repositories: https://github.com/karfas
-
- Posts: 3
- Joined: Sun Dec 26, 2021 8:48 pm
Re: Accessing hardware from native .mpy code
Indeed, there is no difference between accessing hardware and accessing memory, and there is no barrier for me to just write the I2C module registers directly. However, it seems more reasonable to use the MicroPython's HAL, as this provides numerous benefits. The problem is, that there is little to none documentation regarding native C API, so thats why I`m asking this question on the forum, while keeping direct register shuffling as a backup plan.karfas wrote: ↑Mon Dec 27, 2021 2:09 pmI don't see differences between "code accessing hardware" and "code moving memory content around".
If you have working C/Assembler code already talking to your hardware - great, go ahead! Most likely you will need some interface code to micropython.
However, as your application doesn't look time critical, a few reads+writes over the I2C bus can be done in micropython as well.
This looks much simpler to me than a mixed C/Native Code/Micropython approach.
Regards,
Thomas
Re: Accessing hardware from native .mpy code
The HAL for I2C isn't much more than an interface for sending and receiving I2C messages.pro100vald wrote: ↑Mon Dec 27, 2021 2:26 pmit seems more reasonable to use the MicroPython's HAL, as this provides numerous benefits. The problem is, that there is little to none documentation regarding native C API, so thats why I`m asking this question on the forum, while keeping direct register shuffling as a backup plan.
You can look up the code in the micropython source (e.g. ports/esp32/machine_i2c.c).
I still don't understand why you would like to mix native code in a .mpy to get the benefits of uPy HAL abstractions.
This contradicts itself a little, I think.
Regarding the docs: these look (together with the examples) sufficient for me, provided you can read, write and understand C code.
A few hours of debugging might save you from minutes of reading the documentation!
My repositories: https://github.com/karfas
My repositories: https://github.com/karfas
Re: Accessing hardware from native .mpy code
I have been there myself, and the only advice I can give to you is to not use the native .mpy feature for this, and instead compile your custom module into the firmware, using the usual MicroPython functions as normal. Then perhaps make a pull request to include it (with an option flag) in the MicroPython itself. Just prepare to wait very patiently for any reviews on it — a couple of years at least.pro100vald wrote: ↑Mon Dec 27, 2021 2:26 pmIndeed, there is no difference between accessing hardware and accessing memory, and there is no barrier for me to just write the I2C module registers directly. However, it seems more reasonable to use the MicroPython's HAL, as this provides numerous benefits. The problem is, that there is little to none documentation regarding native C API, so thats why I`m asking this question on the forum, while keeping direct register shuffling as a backup plan.
The thing is, the native mpy code can only use the handful of functions that have been explicitly listed in a table in the compiled MicroPython firmware, and nothing else. It's useful for making functions that need to run fast, or for linking to third-party C libraries, but not for any hardware manipulation. As far as I can tell, the best you can do is to have your native function fill a buffer, that you can then send over i2c on the Python side.