what will be a good practice for expending a driver's API ?

[ziv123]

hello Nordic

i am working with ncs 1.7.1 (soon we are moving to zephyr 2.9)

i want to add a driver self test functionality for some of my drivers so in my application part of the code i can just go over devices from the sevice tree and bind to each one and call on the same 'self test' functionality for each one that implement such 

1. what is the best way to do that on the driver level

2. what is the best way to add some kind of sign in the device tree to know which drivers in the device tree implement that 'self_test' functionality

(i need this option cause my application works with several boards and i want the self test functionality in the application section will look the same for all boards)

hope to read from you soon

best regards

Ziv  

[Sigurd]

i want to add a driver self test functionality for some of my drivers

I believe you typically have such functionality in the init function of the sensor driver. See e.g. this code on how adxl362_init() is implemented: https://github.com/nrfconnect/sdk-zephyr/blob/main/drivers/sensor/adxl362/adxl362.c#L705 , and if something went goes wrong during init, and you in your app check if it's ready with device_is_ready(), you will get an error returned.

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.1.0/zephyr/kernel/drivers/index.html#

[ziv123]

hi Sigurd

Sigurd said:

believe you typically have such functionality in the init function

this is not what i asked, i know i can write some tests in the init and if it fails then there is no driver instance.

this is not good for me since i want to be able to use our log event to broadcast the bist (built in self test) results via ble, also i want to be able to call the bist on demand (again via ble, after application is already running) and third i want to know what is the fail reason. 

the bist implementation in the application level should be able to scan for the devices in the dts that implement the desired functionality (it does not have to be self test it can be any functionality required) in a way that the application code does not change if i build with another board which has other devices on it

something like this maybe :

int run_bist(..)

{

      for each device (with api:augu property for example) call sensor_run_bist(the dev, result struct)

}

hope to read from you soon

best regards

Ziv

[Sigurd]

ziv123 said:

this is not good for me since i want to be able to use our log event to broadcast the bist (built in self test) results via ble, also i want to be able to call the bist on demand (again via ble, after application is already running) and third i want to know what is the fail reason. 

the bist implementation in the application level should be able to scan for the devices in the dts that implement the desired functionality (it does not have to be self test it can be any functionality required) in a way that the application code does not change if i build with another board which has other devices on it

As far as I know, this kind of functionality does not currently exist. 

Maybe you can describe your idea as a Feature reqeust to the Zephyr community, and get some input on it there. You can open a Feature request here: https://github.com/zephyrproject-rtos/zephyr/issues/new/choose