zephyr/tests/drivers/i2c/i2c_target_api
Gerard Marull-Paretas 79e6b0e0f6 includes: prefer <zephyr/kernel.h> over <zephyr/zephyr.h>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.

The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.

NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.

Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-09-05 16:31:47 +02:00
..
boards
common
src includes: prefer <zephyr/kernel.h> over <zephyr/zephyr.h> 2022-09-05 16:31:47 +02:00
CMakeLists.txt
Kconfig
README.txt
prj.conf tests: drivers: i2c: move the eeprom target test to new ztest API 2022-08-31 21:54:28 +00:00
testcase.yaml

README.txt

I2C Target API test
##################

.. note:
   See :ref:`coding_guideline_inclusive_language` for information about
   plans to change the terminology used in this API.

This test verifies I2C target 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 target 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.

This test was originally designed for I2C controllers that support both
controller and target behavior simultaneously.  This is not true of all
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.

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 a simulated EEPROM as a I2C target device on a bus.  If
  CONFIG_APP_DUAL_ROLE_I2C is selected, register both.

* Issue commands on one bus controller (operating as the bus controller) and
  verify that the data supplied by the other controller (target) 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.

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.