OrgZephyr/zephyr
OrgZephyr
/
zephyr
mirror of https://github.com/zephyrproject-rtos/zephyr.git
1
0
Fork 0
Code Issues Releases Wiki Activity
zephyr/tests/drivers/i2c/i2c_slave_api/README.txt

42 lines
1.8 KiB
Plaintext
Raw Normal View History

tests: i2c_slave_api: document test requirements and design Provide a little more detail on how this test works and the fixture required to make it pass. Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
2020-08-06 00:18:11 +08:00
I2C Slave API test
##################
tests: i2c_slave_api: update to current standard terminology Zephyr does not currently allow deviation from standard terminology for a technology even if it is non-inclusive, until the corresponding standards body has confirmed intent to change that terminology. The terms used in a previous attempt to be inclusive do not match the expected forthcoming standard terms. Revert to standard terms until the new ones have been announced and the switch made throughout Zephyr. Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
2021-02-06 21:09:45 +08:00
.. note:
See :ref:`coding_guideline_inclusive_language` for information about
plans to change the terminology used in this API.
tests: i2c_slave_api: document test requirements and design Provide a little more detail on how this test works and the fixture required to make it pass. Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
2020-08-06 00:18:11 +08:00
This test verifies I2C slave driver implementations using two I2C
controllers on a common bus. The test is supported by a test-specific
tests: i2c_slave_api: update to current standard terminology Zephyr does not currently allow deviation from standard terminology for a technology even if it is non-inclusive, until the corresponding standards body has confirmed intent to change that terminology. The terms used in a previous attempt to be inclusive do not match the expected forthcoming standard terms. Revert to standard terms until the new ones have been announced and the switch made throughout Zephyr. Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
2021-02-06 21:09:45 +08:00
driver that simulates an EEPROM with an I2C bus slave interface. Data
is pre-loaded into the simulated devices outside the I2C API, and the
Zephyr application issues commands to one controller that are responded
to by the simulated EEPROM connected through the other controller.
tests: i2c_slave_api: document test requirements and design Provide a little more detail on how this test works and the fixture required to make it pass. Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
2020-08-06 00:18:11 +08:00
tests: i2c_slave_api: make dual role support optional Not all I2C controllers that support dual roles allow a controller to be used in both modes without reconfiguration: for some, registering a slave device prevents use in master mode. Refactor so that dual-role operation is opt-in, and select it for the ST devices currently in the allow list. Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
2021-01-21 00:13:04 +08:00
This test was originally designed for I2C controllers that support both
tests: i2c_slave_api: update to current standard terminology Zephyr does not currently allow deviation from standard terminology for a technology even if it is non-inclusive, until the corresponding standards body has confirmed intent to change that terminology. The terms used in a previous attempt to be inclusive do not match the expected forthcoming standard terms. Revert to standard terms until the new ones have been announced and the switch made throughout Zephyr. Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
2021-02-06 21:09:45 +08:00
master and slave behavior simultaneously. This is not true of all
tests: i2c_slave_api: make dual role support optional Not all I2C controllers that support dual roles allow a controller to be used in both modes without reconfiguration: for some, registering a slave device prevents use in master mode. Refactor so that dual-role operation is opt-in, and select it for the ST devices currently in the allow list. Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
2021-01-21 00:13:04 +08:00
I2C controllers, so this behavior is now opt-in using
CONFIG_APP_DUAL_ROLE_I2C. However, the devicetree still must provide a
second EEPROM just to identify the bus.
tests: i2c_slave_api: document test requirements and design Provide a little more detail on how this test works and the fixture required to make it pass. Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
2020-08-06 00:18:11 +08:00
In slightly more detail the test has these phases:
* Use API specific to the simulated EEPROM to pre-populate the simulated
devices with device-specific content.
tests: i2c_slave_api: update to current standard terminology Zephyr does not currently allow deviation from standard terminology for a technology even if it is non-inclusive, until the corresponding standards body has confirmed intent to change that terminology. The terms used in a previous attempt to be inclusive do not match the expected forthcoming standard terms. Revert to standard terms until the new ones have been announced and the switch made throughout Zephyr. Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
2021-02-06 21:09:45 +08:00
* Register a simulated EEPROM as a I2C slave device on a bus. If
tests: i2c_slave_api: make dual role support optional Not all I2C controllers that support dual roles allow a controller to be used in both modes without reconfiguration: for some, registering a slave device prevents use in master mode. Refactor so that dual-role operation is opt-in, and select it for the ST devices currently in the allow list. Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
2021-01-21 00:13:04 +08:00
CONFIG_APP_DUAL_ROLE_I2C is selected, register both.
tests: i2c_slave_api: update to current standard terminology Zephyr does not currently allow deviation from standard terminology for a technology even if it is non-inclusive, until the corresponding standards body has confirmed intent to change that terminology. The terms used in a previous attempt to be inclusive do not match the expected forthcoming standard terms. Revert to standard terms until the new ones have been announced and the switch made throughout Zephyr. Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
2021-02-06 21:09:45 +08:00
* Issue commands on one bus controller (operating as the bus master) and
verify that the data supplied by the other controller (slave) match
the expected values given the content known to be present on the
simulated device. If CONFIG_APP_DUAL_ROLE_I2C is selected, do this
with the roles reversed.
tests: i2c_slave_api: document test requirements and design Provide a little more detail on how this test works and the fixture required to make it pass. Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
2020-08-06 00:18:11 +08:00
Transfer of commands from one bus controller to the other is
accomplished by hardware through having the SCL (and SDA) signals
shorted to join the two buses.
Presence of this required hardware configuration is identified by the
`i2c_bus_short` fixture. If the buses are not connected as required,
or the controller driver has bugs, the test will fail one or more I2C
transactions.