Zephyr device driver model - Revision history

Ted: Add subsection to share build time diagnostic additions to IIS2DH driver header file iis2dh.h

2022-10-28T18:23:41Z

Add subsection to share build time diagnostic additions to IIS2DH driver header file iis2dh.h

Ted: /* ^ IIS2DH driver in Zephyr 3.2.0 */ - adding note on Zephyr 3.2.0 in-tree I2C API

2022-10-25T13:41:33Z

^ IIS2DH driver in Zephyr 3.2.0: - adding note on Zephyr 3.2.0 in-tree I2C API

Ted: /* ^ IIS2DH driver in Zephyr 3.2.0 */

2022-10-24T20:45:19Z

^ IIS2DH driver in Zephyr 3.2.0

Ted: /* ^ IIS2DH driver in Zephyr 3.2.0 */

2022-10-24T20:43:45Z

^ IIS2DH driver in Zephyr 3.2.0

Ted: /* ^ IIS2DH driver in Zephyr 3.2.0 */

2022-10-24T20:28:46Z

^ IIS2DH driver in Zephyr 3.2.0

Ted: /* ^ IIS2DH driver in Zephyr 3.2.0 */

2022-10-24T20:24:35Z

^ IIS2DH driver in Zephyr 3.2.0

Ted: Add new section "IIS2DH driver in Zephyr 3.2.0"

2022-10-24T20:21:28Z

Add new section "IIS2DH driver in Zephyr 3.2.0"

Ted: Minor local formatting, adding section as "grouped topics" separator.

2022-10-24T20:18:48Z

Minor local formatting, adding section as "grouped topics" separator.

Ted at 20:16, 24 October 2022

2022-10-24T20:16:10Z

Ted: Zephyr RTOS device model general API routine templates.

2022-08-19T22:06:06Z

Zephyr RTOS device model general API routine templates.

@@ Line 1,165: / Line 1,165: @@
 <pre>
 static int iis2dh_init_interface(const struct device *dev)
+{/**
          int res;
@@ Line 1,286: / Line 1,313: @@
 </pre>
 <!-- comment -->

← Older revision		Revision as of 13:41, 25 October 2022
Line 1,243:		Line 1,243:

	QUESTION: is the macro DT_ANY_INST_ON_BUS_STATUS_OKAY not returning any ok I2C bus instances in our app build process?		QUESTION: is the macro DT_ANY_INST_ON_BUS_STATUS_OKAY not returning any ok I2C bus instances in our app build process?
		+
		+	ANSWER: in our application build as of 2022-10-24 this macro evaluates to false, which is strange! We have posted to Circuit Dojo forum, at
		+
		+	On Zephyr's I2C in-tree driver side, the low level routine to perform an I2C "write read" transaction is in file `/zephyr/include/zephyr/drivers/i2c.h`. Here is an excerpt, which begins around line 991:
		+
		+	<pre>
		+
		+	/**
		+	* @brief Write then read data from an I2C device.
		+	*
		+	* This supports the common operation "this is what I want", "now give
		+	* it to me" transaction pair through a combined write-then-read bus
		+	* transaction.
		+	*
		+	* @param dev Pointer to the device structure for an I2C controller
		+	* driver configured in controller mode.
		+	* @param addr Address of the I2C device
		+	* @param write_buf Pointer to the data to be written
		+	* @param num_write Number of bytes to write
		+	* @param read_buf Pointer to storage for read data
		+	* @param num_read Number of bytes to read
		+	*
		+	* @retval 0 if successful
		+	* @retval negative on error.
		+	*/
		+	static inline int i2c_write_read(const struct device *dev, uint16_t addr,
		+	const void *write_buf, size_t num_write,
		+	void *read_buf, size_t num_read)
		+	{
		+	struct i2c_msg msg[2];
		+
		+	msg[0].buf = (uint8_t *)write_buf;
		+	msg[0].len = num_write;
		+	msg[0].flags = I2C_MSG_WRITE;
		+
		+	msg[1].buf = (uint8_t *)read_buf;
		+	msg[1].len = num_read;
		+	msg[1].flags = I2C_MSG_RESTART \| I2C_MSG_READ \| I2C_MSG_STOP;
		+
		+	return i2c_transfer(dev, msg, 2, addr);
		+	}
		+	</pre>

@@ Line 1,240: / Line 1,240: @@
 #endif /* CONFIG_IIS2DH_TRIGGER */
 };
 </pre>

← Older revision		Revision as of 20:43, 24 October 2022
Line 1,208:		Line 1,208:
	</pre>		</pre>

−	And in Zephyr 3.2.0 source tree routine `iis2dh_init()` is called from following places:	+	And in Zephyr 3.2.0 source tree routine `iis2dh_init()` is called from or referenced at the following places:

		+	<pre>
		+	ted@localhost1:~/projects-sandbox/workspace-for-nexus$ grep -nr 'iis2dh_init' ./*
		+
		+	./zephyr/drivers/sensor/iis2dh/iis2dh.c:253:static int iis2dh_init(const struct device *dev)
		+
		+	./zephyr/drivers/sensor/iis2dh/iis2dh.c:321: DEVICE_DT_INST_DEFINE(inst, iis2dh_init, NULL, \
		+	</pre>
		+
		+	And near top of iis2dh.h the structure definition for 'iis2dh_device_config' appears:
		+
		+	<pre>
		+	/**
		+	* struct iis2dh_device_config - iis2dh hw configuration
		+	* @spi: SPI bus spec.
		+	* @i2c: I2C bus spec.
		+	* @pm: Power mode (lis2dh_powermode).
		+	* @int_gpio: GPIO spec for sensor pin interrupt.
		+	*/
		+	struct iis2dh_device_config {
		+	#if DT_ANY_INST_ON_BUS_STATUS_OKAY(spi)
		+	struct spi_dt_spec spi;
		+	#endif
		+	#if DT_ANY_INST_ON_BUS_STATUS_OKAY(i2c)
		+	struct i2c_dt_spec i2c;
		+	#endif
		+	uint8_t pm;
		+	#ifdef CONFIG_IIS2DH_TRIGGER
		+	struct gpio_dt_spec int_gpio;
		+	#endif /* CONFIG_IIS2DH_TRIGGER */
		+	};
		+
		+	</pre>

← Older revision		Revision as of 20:28, 24 October 2022
Line 1,186:		Line 1,186:
	</pre>		</pre>

−	And ~~here~~ in ~~this~~ source ~~file parameter~~ `~~dev~~` is ~~defined in~~ following ~~line~~:	+	In our search for how `dev` is defined, above routine is called in same source file from routine:
		+
		+	<pre>
		+	static int iis2dh_init(const struct device *dev)
		+	{
		+	struct iis2dh_data *iis2dh = dev->data;
		+	const struct iis2dh_device_config *cfg = dev->config;
		+	uint8_t wai;
		+
		+	if (iis2dh_init_interface(dev)) {
		+	return -EINVAL;
		+	}
		+
		+	/* check chip ID */
		+	if (iis2dh_device_id_get(iis2dh->ctx, &wai) < 0) {
		+	return -EIO;
		+	}
		+	.
		+	.
		+	.
		+	</pre>
		+
		+	And in Zephyr 3.2.0 source tree routine `iis2dh_init()` is called from following places:
		+

@@ Line 1,159: / Line 1,159: @@
+}
 #endif /* DT_ANY_INST_ON_BUS_STATUS_OKAY(i2c) */
 </pre>
 <!-- comment -->

@@ Line 1,115: / Line 1,115: @@
 ted@localhost:~/projects-sandbox/workspace-for-rpi/zephyr$ find . -name ws2812_gpio.c
-./drivers/led_strip/ws2812_gpio.c
+./drivers/led_stri</pre>p/ws2812_gpio.c
 ~/projects-sandbox/workspace-for-rpi/zephyr/drivers/led_strip$ ls -l
@@ Line 1,135: / Line 1,135: @@
 In file `ws2812_gpio.c` here are telling comments and calls to nrf_ API functions, functions which may be peculiar to Nordic's nRF51 family of parts.  There are also the mentioned in-line assembly instructions which are based on this source file's targeting of an ARM Cortex-M0 running at 16MHz.  We may be able to adapt this file and use it on the RPI2040 with appropriate configuration of this other processor's higher speed clock, plus adjustments to the in-line assembly.  ( That in-line assembly code is just a series of NOP instructions, three different counts of NOP series for specific WS2812 timing requirements. )
 <!-- comment -->

← Older revision		Revision as of 20:18, 24 October 2022
Line 1,135:		Line 1,135:

	In file `ws2812_gpio.c` here are telling comments and calls to nrf_ API functions, functions which may be peculiar to Nordic's nRF51 family of parts. There are also the mentioned in-line assembly instructions which are based on this source file's targeting of an ARM Cortex-M0 running at 16MHz. We may be able to adapt this file and use it on the RPI2040 with appropriate configuration of this other processor's higher speed clock, plus adjustments to the in-line assembly. ( That in-line assembly code is just a series of NOP instructions, three different counts of NOP series for specific WS2812 timing requirements. )		In file `ws2812_gpio.c` here are telling comments and calls to nrf_ API functions, functions which may be peculiar to Nordic's nRF51 family of parts. There are also the mentioned in-line assembly instructions which are based on this source file's targeting of an ARM Cortex-M0 running at 16MHz. We may be able to adapt this file and use it on the RPI2040 with appropriate configuration of this other processor's higher speed clock, plus adjustments to the in-line assembly. ( That in-line assembly code is just a series of NOP instructions, three different counts of NOP series for specific WS2812 timing requirements. )
		+
		+	<!-- comment -->
		+
		+	== * ==
		+
		+
		+
		+	<!-- empty section to create horizontal white space, organizing document sections for possible later break -->

	<!-- comment -->		<!-- comment -->

← Older revision		Revision as of 20:16, 24 October 2022
Line 5:		Line 5:


−	~~<b>-~~ OVERVIEW ~~-</b>~~	+	== [[#top\|^]] OVERVIEW ==

	Ok roughly a year into working with Zephyr RTOS we have a better idea of Zephyr's device driver model. A good point of reference to understand this model is [https://docs.zephyrproject.org/3.1.0/kernel/drivers/index.html Zephyr's device driver model] documentation page.		Ok roughly a year into working with Zephyr RTOS we have a better idea of Zephyr's device driver model. A good point of reference to understand this model is [https://docs.zephyrproject.org/3.1.0/kernel/drivers/index.html Zephyr's device driver model] documentation page.

@@ Line 9: / Line 9: @@
 Ok roughly a year into working with Zephyr RTOS we have a better idea of Zephyr's device driver model.  A good point of reference to understand this model is [https://docs.zephyrproject.org/3.1.0/kernel/drivers/index.html Zephyr's device driver model] documentation page.
-Some important features of this device driver model include Zephyr C enumerations to support notions of sensor "channels" and sensor attributes.  One such sensor attribute detailed at [https://docs.zephyrproject.org/3.1.0/hardware/peripherals/sensor.html#c.sensor_attribute.SENSOR_ATTR_CONFIGURATION Zephyr doc page on symbol SENSOR_ATTR_CONFIGURATION].  Along with Zephyr RTOS sensor attributes, channels and triggers, there is a quintet of generalized sensor or device API routines which Zephyr's driver model employs.  These are:
+Some important features of this device driver model include Zephyr C enumerations to support notions of sensor "channels" and sensor attributes.  One such sensor attribute detailed at [https://docs.zephyrproject.org/3.1.0/hardware/peripherals/sensor.html#c.sensor_attribute.SENSOR_ATTR_CONFIGURATION Zephyr doc page on symbol SENSOR_ATTR_CONFIGURATION].  Along with Zephyr RTOS sensor attributes, channels and triggers, there is a sextet of generalized sensor or device API routines which Zephyr's driver model employs.  These are:
@@ Line 17: / Line 17: @@
 <li> [https://github.com/zephyrproject-rtos/zephyr/blob/main/include/zephyr/drivers/sensor.h#L481 sensor_trigger_set()]
 <li> [https://github.com/zephyrproject-rtos/zephyr/blob/main/include/zephyr/drivers/sensor.h#L511 sensor_sample_fetch()]
-<li> sensor_sample_fetch_chan()
+<li> [https://github.com/zephyrproject-rtos/zephyr/blob/main/include/zephyr/drivers/sensor.h#L540 sensor_sample_fetch_chan()]
-<li> sensor_sample_get()
+<li> [https://github.com/zephyrproject-rtos/zephyr/blob/main/include/zephyr/drivers/sensor.h#L573 sensor_sample_get()]
 </ul>