The i2c shell write command outputs the error "Failed to read from
device" while it tries to write data to device.
This fixes the error by outputting "Failed to write to device" instead.
Fixes:
uart:~$ i2c write i2c@3ff53000 23 01
Failed to read from device: 23
Signed-off-by: Gaël PORTAY <gael.portay@rtone.fr>
Possibility to configure i2c speed through I2C_SHELL
command `i2c speed`.
Signed-off-by: Andrzej Kuros <andrzej.kuros@nordicsemi.no>
Signed-off-by: Jędrzej Ciupis <jedrzej.ciupis@nordicsemi.no>
The command uses 1 optional parameter and this parameter can be at
maximum MAX_I2C_BYTES.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
The I2C shell would filter the list of devices it knows about to
ones that have a device name that starts with "I2C_". It was the
case that the majority of I2C bus controller devices happened
to be named with the "I2C_" prefix, however there is no guarantee
that is the case. With the remove of label properties from the
devicetree this is even more true.
For now remove the prefix filter and just return the full list
of devices.
Signed-off-by: Kumar Gala <galak@kernel.org>
In order to bring consistency in-tree, migrate all drivers to the new
prefix <zephyr/...>. Note that the conversion has been scripted, refer
to #45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Improve shell commands to support up to 32-bit addresses.
The check if function should use 8/16/24/32-bit address is basing
on the length of address used in function parameter. To address
registers below 256 using 16-bit, one should write them left-padded
with zeroes. Address is sent in big endian.
Signed-off-by: Michał Barnaś <mb@semihalf.com>
I2C scan and recover functions didn't have mandatory parameters
specified, which resulted in not displaying the I2C controllers in
help message. Instead, the command was executed, and argv was
dereferenced outside of the bounds, providing invalid data to
device_get_binding function.
Other functions had defined mandatory parameters without taking their
names into account, they are provided as argv[0].
Signed-off-by: Michał Barnaś <mb@semihalf.com>
When this code was moved from a standalone sample to an optional shell
feature the documentation on how this works and caveats was lost. Put
it back so it can be referenced in issue explanations.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Now that device_api attribute is unmodified at runtime, as well as all
the other attributes, it is possible to switch all device driver
instance to be constant.
A coccinelle rule is used for this:
@r_const_dev_1
disable optional_qualifier
@
@@
-struct device *
+const struct device *
@r_const_dev_2
disable optional_qualifier
@
@@
-struct device * const
+const struct device *
Fixes#27399
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
By fixing the issue: #21819 in the shell, it is no longer needed
to keep a workaround, which allows prompting i2c bus name.
Signed-off-by: Jakub Rzeszutko <jakub.rzeszutko@nordisemi.no>
Commit id a538dcd8f8 got rid of the usage of these pointers so they are
useless now and can be removed in this drivers.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Several shell modules use cloned code to iterate over all devices and
identify the nth instance that meets some criteria. The code was
repetitive and included various errors. Abstract to a helper function
that performs the check consistently.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Fixes the i2c shell to check the device name pointer is non-null before
dereferencing it.
Coverity CID: 210558
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
Add simple commands to read or write a single byte from a device
register.
i2c write_byte I2C_2 36 b0 12
i2c read_byte I2C_2 36 0
Output: 0x82
I modified Anas' version to put args in variables first so that the code
is self-documenting.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
When the device driver model got introduced, there were no concept of
SYS_INIT() which can be seen as software service. These were introduced
afterwards and reusing the device infrastructure for simplicity.
However, it meant to allocate a bit too much for something that only
required an initialization function to be called at right time.
Thus refactoring the devices structures relevantly:
- introducing struct init_entry which is a generic init end-point
- struct deviceconfig is removed and struct device owns everything now.
- SYS_INIT() generates only a struct init_entry via calling
INIT_ENTRY_DEFINE()
- DEVICE_AND_API_INIT() generates a struct device and calls
INIT_ENTRY_DEFINE()
- init objects sections are in ROM
- device objects sections are in RAM (but will end up in ROM once they
will be 'constified')
It also generate a tiny memory gain on both ROM and RAM, which is nice.
Perhaps kernel/device.c could be renamed to something more relevant.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
The build infrastructure should not be adding the drivers subdirectory
to the include path. Fix the legacy uses that depended on that
addition.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
