[RFC] Assign driver_api at compile/link time


Daniel Leung <daniel.leung@...>
 

Problem Statement:
Shrink binary size by doing driver_api assignment at compile/link time.

Problem Description:
For some drivers, the assignment of driver_api is unconditionally done.
This is especially true for drivers that will never fail initialization,
hence there is no need to set NULL. Therefore, the assignment of
driver_api can be statically done at compile/link time, and skips
the code to do the assignment at runtime.

Proposal:
To achieve this, a new API is proposed to do the extra work of
assignment when the driver instance is declared. The current
mechanism of declaring a driver instance (via DEVICE_INIT())
remains the same, which still requires the driver init function
to do the assignment.

The code can be seen at [1]. The changes to the pinmux/dev drivers
can be seen at [2], where similar changes can be applied to other
drivers. Here is the results from sanitycheck after [2]:

galileo : tests/drivers/pinmux/test_pinmux_dev
ram_size -10, is now 33255 -0.03%
rom_size -10, is now 27075 -0.04%

quark_se_devboard : tests/drivers/pinmux/test_pinmux_dev
rom_size -7, is now 13278 -0.05%

arduino_due : tests/drivers/pinmux/test_pinmux_dev
rom_size -8, is now 5732 -0.14%

stm32_mini_a15 : tests/drivers/pinmux/test_pinmux_dev
rom_size -8, is now 7712 -0.10%

frdm_k64f : tests/drivers/pinmux/test_pinmux_dev
rom_size -8, is now 7992 -0.10%

nucleo_f103rb : tests/drivers/pinmux/test_pinmux_dev
rom_size -8, is now 7696 -0.10%

arduino_101 : tests/drivers/pinmux/test_pinmux_dev
rom_size -7, is now 13291 -0.05%

quark_d2000_crb : tests/drivers/pinmux/test_pinmux_dev
rom_size -7, is now 5219 -0.13%


[1] https://gerrit.zephyrproject.org/r/1367
[2] https://gerrit.zephyrproject.org/r/1368


Jason Rotella <jrotella@...>
 

Hi Daniel,

Are there plans for Zephyr OS to run on STM32F401 (Nucleo-64) boards?


Thanks,
Jason

On Apr 12, 2016, at 6:37 PM, Daniel Leung <daniel.leung(a)intel.com> wrote:

Problem Statement:
Shrink binary size by doing driver_api assignment at compile/link time.

Problem Description:
For some drivers, the assignment of driver_api is unconditionally done.
This is especially true for drivers that will never fail initialization,
hence there is no need to set NULL. Therefore, the assignment of
driver_api can be statically done at compile/link time, and skips
the code to do the assignment at runtime.

Proposal:
To achieve this, a new API is proposed to do the extra work of
assignment when the driver instance is declared. The current
mechanism of declaring a driver instance (via DEVICE_INIT())
remains the same, which still requires the driver init function
to do the assignment.

The code can be seen at [1]. The changes to the pinmux/dev drivers
can be seen at [2], where similar changes can be applied to other
drivers. Here is the results from sanitycheck after [2]:

galileo : tests/drivers/pinmux/test_pinmux_dev
ram_size -10, is now 33255 -0.03%
rom_size -10, is now 27075 -0.04%

quark_se_devboard : tests/drivers/pinmux/test_pinmux_dev
rom_size -7, is now 13278 -0.05%

arduino_due : tests/drivers/pinmux/test_pinmux_dev
rom_size -8, is now 5732 -0.14%

stm32_mini_a15 : tests/drivers/pinmux/test_pinmux_dev
rom_size -8, is now 7712 -0.10%

frdm_k64f : tests/drivers/pinmux/test_pinmux_dev
rom_size -8, is now 7992 -0.10%

nucleo_f103rb : tests/drivers/pinmux/test_pinmux_dev
rom_size -8, is now 7696 -0.10%

arduino_101 : tests/drivers/pinmux/test_pinmux_dev
rom_size -7, is now 13291 -0.05%

quark_d2000_crb : tests/drivers/pinmux/test_pinmux_dev
rom_size -7, is now 5219 -0.13%


[1] https://gerrit.zephyrproject.org/r/1367
[2] https://gerrit.zephyrproject.org/r/1368


Kalowsky, Daniel <daniel.kalowsky@...>
 

Hey Jason,

-----Original Message-----
From: Jason Rotella [mailto:jrotella(a)nycap.rr.com]
Sent: Tuesday, April 12, 2016 6:41 PM
To: Leung, Daniel <daniel.leung(a)intel.com>
Cc: devel(a)lists.zephyrproject.org; Fausto Hernandez
<hernandez.fausto(a)gmail.com>
Subject: [devel] Re: [RFC] Assign driver_api at compile/link time

Hi Daniel,


Are there plans for Zephyr OS to run on STM32F401 (Nucleo-64) boards?
Adding in Maciek and Yannis to make sure this is seen. We are working slowly on adding in more of the STM32 family. Currently we have the support for the Cortex-M4 processor that the STM32F4 series uses, we just need to get the basic SOC, peripheral support, and specific boards complete.