[FeatureRequest] Expose HAL functions to native modules

[sjaak31367]

Greetings!

I've been messing/looking around for a while trying to get GPIO usage with a native c module, and after quite a bit of searching have only found one working solution: static linking (adding to -and recompiling with- the firmware).
And while it works, I think it could be very useful/logical if HAL functions were exposed to native c modules too, especially for libraries.
Because currently you have a different firmware, or firmware mod for each display you wish to use, or each larger component.
Or have to use the Micropython modules, which while it's great they exist, and are very readable, do often have noticeable speed drawbacks.

And besides that, I think it would simply make sense, to allow (more) hardware-related functions to also exist to non-firmware files.
Or alternatively, if it is already possible, just with a notable size-overhead, perhaps an example could be added in examples/natmod with the correct headers and makefile, to allow it to be done by people who haven't dug through source-code and know which headers go where and what.

I understand there's only a finite number of functions that can be bytecode encoded, so any additional one comes at a premium. But possibly it could be done with a single byte meaning "here comes a HAL operation" and then the next byte representing what type of operation "GPIO/SPI/UART/I2C/timing/irq/DMA/other". Essentially making HAL operations a 2byte instruction, minor speed decrease for all HAL functions, but all previous ones have no speed decrease, and HAL access gets added!

There have been a few issues/pull requests, and forum posts over the years, but they never really took off or... Well, you can guess where they got because it's still a thing that isn't.

Please, if people think this would be a useful feature to add, or reason not to. Or have additional comments, or notes on what should shouldn't be added to it, please write down below!
~Sjaak

[andrewleech]

I've often wanted access to more functions in native modules but never found a low cost way to do so. Even for things like peripheral functions like spi, adc, every port has dramatically different function names and usage for peripherals that seem like they should be generally compatible. That's the point of the machine.XYZ interfaces, they're broadly aligned to make peripherals more similar from port to port. Using these python interface from a native modules really shouldn't have much speed cost, though it's true not all features are exposed this way yet.

An alternative I've used in the past is demonstrated in #9046 which is for my native modules to itself link against the chip hal library directly.
This does result in a new copy of the used functions being included in my module, separate to the copy used by micropython, but for many peripherals this works fine and doesn't take up much extra space really.

[Josverl]

What do you mean by "Agatha"?

[robert-hh]

Spell fix fail I assume.

[andrewleech]

Hah yeah that particular sentence didn't make much sense! Autocorrect and late at night. I've edited it now to be hopefully more clear