Any reason behind make_new -> init -> init_helper ?

C programming, build, interpreter/VM.
Target audience: MicroPython Developers.
Post Reply
ExXec
Posts: 71
Joined: Sat Oct 20, 2018 4:02 pm

Any reason behind make_new -> init -> init_helper ?

Post by ExXec » Sat Apr 27, 2019 3:49 pm

Hi,

as the title says, I was wondering if there is a reason behind the existence of the init_helper functions of the modules?
It seems very redundant to call the init function, that itself only calls the init_helper function.
Could I just put the initialization directly inside the make_new function? (theoretically speaking, I know that the function will become bloated)

Thanks
-ExXec

User avatar
Roberthh
Posts: 1513
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: Any reason behind make_new -> init -> init_helper ?

Post by Roberthh » Sat Apr 27, 2019 4:09 pm

The reason is, that there are two paths to initialize a module, first in make_new, which is called when you create the instance of the object (e.g. uart = machine.UART(0)), second in the init call (e.g. uart.init()).
And the sequence you mention is not always (if ever) used. machine_uart.c for instance does not call machine_uart_init() within machine_uart_make_new(). And that is more the scheme i recall.

ExXec
Posts: 71
Joined: Sat Oct 20, 2018 4:02 pm

Re: Any reason behind make_new -> init -> init_helper ?

Post by ExXec » Sun Apr 28, 2019 2:34 pm

Ok that makes more sense I guess.

You mentioned "machine_uart_make_new", in the 1.9.4 version(the one I'm working on) this is still called "pyb_uart_make_new".

Is this just a naming difference?

User avatar
Roberthh
Posts: 1513
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: Any reason behind make_new -> init -> init_helper ?

Post by Roberthh » Sun Apr 28, 2019 3:35 pm

Your're right. For the stm32 ports, even when the file is called machine_uart.c, the functions is called pyb_uart_make_new(). I had looked into the esp32 port.

Post Reply