bartoszek/zephyr
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
c6bb8b191d
zephyr/tests/drivers/i2c/i2c_slave_api
History
Peter Bigot 6ecfe3eba1 tests: i2c_slave_api: overhaul test implementation 
Make the expected data buffers immutable to ensure that the test isn't
modifying them.

Improve clarity by using defines for the two devicetree nodes rather
than repeating the DT_INST() retrieval.

Clean up the naming and diagnostics to more clearly associate the
device label, I2C bus, and I2C address with either EEPROM instance 0
or 1.  Replace the base 1 numbering in some diagnostics.

Document why a device nominally on one bus is being accessed from
another bus.  Return error values from helper functions rather than
invoking ztest failure code so the calling context can provide a
better description of what went wrong.

Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
2020-08-13 11:49:12 +02:00
..
boards tests: i2c_slave_api: add nucleo_l476rg as supported test platform 2020-08-13 11:49:12 +02:00
common device: Apply driver_api/data attributes rename everywhere 2020-08-11 19:30:53 +02:00
src tests: i2c_slave_api: overhaul test implementation 2020-08-13 11:49:12 +02:00
CMakeLists.txt tests: make find_package(Zephyr...) REQUIRED 2020-05-29 10:47:25 +02:00
Kconfig license: cleanup: add SPDX Apache-2.0 license identifier 2019-04-07 08:45:22 -04:00
prj.conf drivers: move eeprom_slave driver to tests directory 2020-08-13 11:49:12 +02:00
README.txt tests: i2c_slave_api: document test requirements and design 2020-08-13 11:49:12 +02:00
testcase.yaml tests: i2c_slave_api: document test requirements and design 2020-08-13 11:49:12 +02:00

README.txt 

I2C Slave API test
##################

This test verifies I2C slave driver implementations using two I2C
controllers on a common bus.  The test is supported by a test-specific
driver that simulates an EEPROM with an I2C bus follower ("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.

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.
* Register each simulated EEPROM as a I2C follower device on a bus.
* Issue commands on one bus controller (operating as the bus leader
  (master)) and verify that the data supplied by the other controller
  (as bus follower) match the expected values given the content known to
  be present on the simulated device.

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.