目录
示例： stty -F /dev/ttyHS0 115200 cs8 -cstopb -parenb
示例 ： spidbgr -d 0 -M 0x2608 -f 10000000 -m 3 -w -l 1 -o 0xaa
示例 spidev_test -D /dev/spidev1.0 -H 1 -p '\x7c\x50'
一：IIC测试方法
QNX侧：
测试命令：i2cdbgr
命令代码位置：
/SD-QNX4.5.6.0/apps/qnx_ap/AMSS/platform/services/applications/i2cdbgr/i2cdbgr.c
使用示例说明：
/SD-QNX4.5.6.0/apps/qnx_ap/AMSS/platform/services/applications/i2cdbgr/i2cdbgr.use
%C : Application to perform i2c read / write
Usage: i2cdbgr -D [node] -s [slave addr] -r -b [byte size] -o [offset] -i [# bytes to read] -n [speed in KHz (100/400/1000)]
i2cdbgr -D [node] -s [slave addr] -w -b [byte size] -o [offset] -x [value] -n [speed in KHz (100/400/1000)]
where
[node] is of form "/dev/i2cX".
[byte size] is 1, or 2. The value has no effect for read. For write, if the
byte size is 1, then the offset is ignored, and only [value] is written.
If the byte size if 2, then i2cdbgr will write [offset value].
The i2cdbgr uses 8-bit addressing, 8-bit data to read or write from
/dev/i2cX (fd) using i2c_client.h using default frequency.
Examples:
For read:
i2cdbgr -D /dev/i2c1 -s 0x77 -r -b 1 -o 0x4 -i 1 <- read 1 byte from slave addr 0x77
offset 0x4
i2cdbgr -D /dev/i2c1 -s 0x77 -r -b 1 -o 0x4 -i 5 <- read 5 bytes from slave addr
0x77 offset 0x4
For write:
i2cdbgr -D /dev/i2c1 -s 0x77 -w -b 1 -o 0x0 -x 0xa <- write 1 byte to slave addr
0x77 with no offset due to 1 byte size value 0xa
i2cdbgr -D /dev/i2c1 -s 0x77 -w -b 2 -o 0x1 -x 0xb <- write 2 bytes to slave addr
0x77 with offset + value bytes [0x1 0xb]
For Aardvark:
[Setup aardvark in slave mode with address 0x40]
i2cdbgr -D /dev/i2c3 -s 0x40 -r -b 1 -i 1 -n 100 -v //Speed set to 100KHz
i2cdbgr -D /dev/i2c3 -s 0x40 -r -b 1 -i 1 -n 400 -v //Speed set to 400KHz
i2cdbgr -D /dev/i2c3 -s 0x40 -r -b 1 -i 1 -n 1000 -v //Speed set to 1000KHz
示例：i2cdbgr -D /dev/i2c6 -s 0x68 -r -b 1 -o 0x0 -i 0x1 -n 100
Android侧
工具网址：
I2C Tools - Linux i2c Wiki (kernel.org)
Manpages of i2c-tools in Debian unstable — Debian Manpages
高通相关路径：
/SD-HQX4.5.6.0/lagvm/LINUX/android/kernel_platform/msm-kernel/Documentation/i2c/i2c-sysfs.rst
.. SPDX-License-Identifier: GPL-2.0
===============
Linux I2C Sysfs
===============
Overview
========
I2C topology can be complex because of the existence of I2C MUX
(I2C Multiplexer). The Linux
kernel abstracts the MUX channels into logical I2C bus numbers. However, there
is a gap of knowledge to map from the I2C bus physical number and MUX topology
to logical I2C bus number. This doc is aimed to fill in this gap, so the
audience (hardware engineers and new software developers for example) can learn
the concept of logical I2C buses in the kernel, by knowing the physical I2C
topology and navigating through the I2C sysfs in Linux shell. This knowledge is
useful and essential to use ``i2c-tools`` for the purpose of development and
debugging.
Target audience
---------------
People who need to use Linux shell to interact with I2C subsystem on a system
which the Linux is running on.
Prerequisites
-------------
1. Knowledge of general Linux shell file system commands and operations.
2. General knowledge of I2C, I2C MUX and I2C topology.
Location of I2C Sysfs
=====================
Typically, the Linux Sysfs filesystem is mounted at the ``/sys`` directory,
so you can find the I2C Sysfs under ``/sys/bus/i2c/devices``
where you can directly ``cd`` to it.
There is a list of symbolic links under that directory. The links that
start with ``i2c-`` are I2C buses, which may be either physical or logical. The
other links that begin with numbers and end with numbers are I2C devices, where
the first number is I2C bus number, and the second number is I2C address.
Google Pixel 3 phone for example::
blueline:/sys/bus/i2c/devices $ ls
0-0008 0-0061 1-0028 3-0043 4-0036 4-0041 i2c-1 i2c-3
0-000c 0-0066 2-0049 4-000b 4-0040 i2c-0 i2c-2 i2c-4
``i2c-2`` is an I2C bus whose number is 2, and ``2-0049`` is an I2C device
on bus 2 address 0x49 bound with a kernel driver.
Terminology
===========
First, let us define some terms to avoid confusion in later sections.
(Physical) I2C Bus Controller
-----------------------------
The hardware system that the Linux kernel is running on may have multiple
physical I2C bus controllers. The controllers are hardware and physical, and the
system may define multiple registers in the memory space to manipulate the
controllers. Linux kernel has I2C bus drivers under source directory
``drivers/i2c/busses`` to translate kernel I2C API into register
operations for different systems. This terminology is not limited to Linux
kernel only.
I2C Bus Physical Number
-----------------------
For each physical I2C bus controller, the system vendor may assign a physical
number to each controller. For example, the first I2C bus controller which has
the lowest register addresses may be called ``I2C-0``.
Logical I2C Bus
---------------
Every I2C bus number you see in Linux I2C Sysfs is a logical I2C bus with a
number assigned. This is similar to the fact that software code is usually
written upon virtual memory space, instead of physical memory space.
Each logical I2C bus may be an abstraction of a physical I2C bus controller, or
an abstraction of a channel behind an I2C MUX. In case it is an abstraction of a
MUX channel, whenever we access an I2C device via a such logical bus, the kernel
will switch the I2C MUX for you to the proper channel as part of the
abstraction.
Physical I2C Bus
----------------
If the logical I2C bus is a direct abstraction of a physical I2C bus controller,
let us call it a physical I2C bus.
Caveat
------
This may be a confusing part for people who only know about the physical I2C
design of a board. It is actually possible to rename the I2C bus physical number
to a different number in logical I2C bus level in Device Tree Source (DTS) under
section ``aliases``. See ``arch/arm/boot/dts/nuvoton-npcm730-gsj.dts``
for an example of DTS file.
Best Practice: **(To kernel software developers)** It is better to keep the I2C
bus physical number the same as their corresponding logical I2C bus number,
instead of renaming or mapping them, so that it may be less confusing to other
users. These physical I2C buses can be served as good starting points for I2C
MUX fanouts. For the following examples, we will assume that the physical I2C
bus has a number same as their I2C bus physical number.
Walk through Logical I2C Bus
============================
For the following content, we will use a more complex I2C topology as an
example. Here is a brief graph for the I2C topology. If you do not understand
this graph at first glance, do not be afraid to continue reading this doc
and review it when you finish reading.
::
i2c-7 (physical I2C bus controller 7)
`-- 7-0071 (4-channel I2C MUX at 0x71)
|-- i2c-60 (channel-0)
|-- i2c-73 (channel-1)
| |-- 73-0040 (I2C sensor device with hwmon directory)
| |-- 73-0070 (I2C MUX at 0x70, exists in DTS, but failed to probe)
| `-- 73-0072 (8-channel I2C MUX at 0x72)
| |-- i2c-78 (channel-0)
| |-- ... (channel-1...6, i2c-79...i2c-84)
| `-- i2c-85 (channel-7)
|-- i2c-86 (channel-2)
`-- i2c-203 (channel-3)
Distinguish Physical and Logical I2C Bus
----------------------------------------
One simple way to distinguish between a physical I2C bus and a logical I2C bus,
is to read the symbolic link ``device`` under the I2C bus directory by using
command ``ls -l`` or ``readlink``.
An alternative symbolic link to check is ``mux_device``. This link only exists
in logical I2C bus directory which is fanned out from another I2C bus.
Reading this link will also tell you which I2C MUX device created
this logical I2C bus.
If the symbolic link points to a directory ending with ``.i2c``, it should be a
physical I2C bus, directly abstracting a physical I2C bus controller. For
example::
$ readlink /sys/bus/i2c/devices/i2c-7/device
../../f0087000.i2c
$ ls /sys/bus/i2c/devices/i2c-7/mux_device
ls: /sys/bus/i2c/devices/i2c-7/mux_device: No such file or directory
In this case, ``i2c-7`` is a physical I2C bus, so it does not have the symbolic
link ``mux_device`` under its directory. And if the kernel software developer
follows the common practice by not renaming physical I2C buses, this should also
mean the physical I2C bus controller 7 of the system.
On the other hand, if the symbolic link points to another I2C bus, the I2C bus
presented by the current directory has to be a logical bus. The I2C bus pointed
by the link is the parent bus which may be either a physical I2C bus or a
logical one. In this case, the I2C bus presented by the current directory
abstracts an I2C MUX channel under the parent bus.
For example::
$ readlink /sys/bus/i2c/devices/i2c-73/device
../../i2c-7
$ readlink /sys/bus/i2c/devices/i2c-73/mux_device
../7-0071
``i2c-73`` is a logical bus fanout by an I2C MUX under ``i2c-7``
whose I2C address is 0x71.
Whenever we access an I2C device with bus 73, the kernel will always
switch the I2C MUX addressed 0x71 to the proper channel for you as part of the
abstraction.
Finding out Logical I2C Bus Number
----------------------------------
In this section, we will describe how to find out the logical I2C bus number
representing certain I2C MUX channels based on the knowledge of physical
hardware I2C topology.
In this example, we have a system which has a physical I2C bus 7 and not renamed
in DTS. There is a 4-channel MUX at address 0x71 on that bus. There is another
8-channel MUX at address 0x72 behind the channel 1 of the 0x71 MUX. Let us
navigate through Sysfs and find out the logical I2C bus number of the channel 3
of the 0x72 MUX.
First of all, let us go to the directory of ``i2c-7``::
~$ cd /sys/bus/i2c/devices/i2c-7
/sys/bus/i2c/devices/i2c-7$ ls
7-0071 i2c-60 name subsystem
delete_device i2c-73 new_device uevent
device i2c-86 of_node
i2c-203 i2c-dev power
There, we see the 0x71 MUX as ``7-0071``. Go inside it::
/sys/bus/i2c/devices/i2c-7$ cd 7-0071/
/sys/bus/i2c/devices/i2c-7/7-0071$ ls -l
channel-0 channel-3 modalias power
channel-1 driver name subsystem
channel-2 idle_state of_node uevent
Read the link ``channel-1`` using ``readlink`` or ``ls -l``::
/sys/bus/i2c/devices/i2c-7/7-0071$ readlink channel-1
../i2c-73
We find out that the channel 1 of 0x71 MUX on ``i2c-7`` is assigned
with a logical I2C bus number of 73.
Let us continue the journey to directory ``i2c-73`` in either ways::
# cd to i2c-73 under I2C Sysfs root
/sys/bus/i2c/devices/i2c-7/7-0071$ cd /sys/bus/i2c/devices/i2c-73
/sys/bus/i2c/devices/i2c-73$
# cd the channel symbolic link
/sys/bus/i2c/devices/i2c-7/7-0071$ cd channel-1
/sys/bus/i2c/devices/i2c-7/7-0071/channel-1$
# cd the link content
/sys/bus/i2c/devices/i2c-7/7-0071$ cd ../i2c-73
/sys/bus/i2c/devices/i2c-7/i2c-73$
Either ways, you will end up in the directory of ``i2c-73``. Similar to above,
we can now find the 0x72 MUX and what logical I2C bus numbers
that its channels are assigned::
/sys/bus/i2c/devices/i2c-73$ ls
73-0040 device i2c-83 new_device
73-004e i2c-78 i2c-84 of_node
73-0050 i2c-79 i2c-85 power
73-0070 i2c-80 i2c-dev subsystem
73-0072 i2c-81 mux_device uevent
delete_device i2c-82 name
/sys/bus/i2c/devices/i2c-73$ cd 73-0072
/sys/bus/i2c/devices/i2c-73/73-0072$ ls
channel-0 channel-4 driver of_node
channel-1 channel-5 idle_state power
channel-2 channel-6 modalias subsystem
channel-3 channel-7 name uevent
/sys/bus/i2c/devices/i2c-73/73-0072$ readlink channel-3
../i2c-81
There, we find out the logical I2C bus number of the channel 3 of the 0x72 MUX
is 81. We can later use this number to switch to its own I2C Sysfs directory or
issue ``i2c-tools`` commands.
Tip: Once you understand the I2C topology with MUX, command
`i2cdetect -l
<https://manpages.debian.org/unstable/i2c-tools/i2cdetect.8.en.html>`_
in
`I2C Tools
<https://i2c.wiki.kernel.org/index.php/I2C_Tools>`_
can give you
an overview of the I2C topology easily, if it is available on your system. For
example::
$ i2cdetect -l | grep -e '\-73' -e _7 | sort -V
i2c-7 i2c npcm_i2c_7 I2C adapter
i2c-73 i2c i2c-7-mux (chan_id 1) I2C adapter
i2c-78 i2c i2c-73-mux (chan_id 0) I2C adapter
i2c-79 i2c i2c-73-mux (chan_id 1) I2C adapter
i2c-80 i2c i2c-73-mux (chan_id 2) I2C adapter
i2c-81 i2c i2c-73-mux (chan_id 3) I2C adapter
i2c-82 i2c i2c-73-mux (chan_id 4) I2C adapter
i2c-83 i2c i2c-73-mux (chan_id 5) I2C adapter
i2c-84 i2c i2c-73-mux (chan_id 6) I2C adapter
i2c-85 i2c i2c-73-mux (chan_id 7) I2C adapter
Pinned Logical I2C Bus Number
-----------------------------
If not specified in DTS, when an I2C MUX driver is applied and the MUX device is
successfully probed, the kernel will assign the MUX channels with a logical bus
number based on the current biggest logical bus number incrementally. For
example, if the system has ``i2c-15`` as the highest logical bus number, and a
4-channel MUX is applied successfully, we will have ``i2c-16`` for the
MUX channel 0, and all the way to ``i2c-19`` for the MUX channel 3.
The kernel software developer is able to pin the fanout MUX channels to a static
logical I2C bus number in the DTS. This doc will not go through the details on
how to implement this in DTS, but we can see an example in:
``arch/arm/boot/dts/aspeed-bmc-facebook-wedge400.dts``
In the above example, there is an 8-channel I2C MUX at address 0x70 on physical
I2C bus 2. The channel 2 of the MUX is defined as ``imux18`` in DTS,
and pinned to logical I2C bus number 18 with the line of ``i2c18 = &imux18;``
in section ``aliases``.
Take it further, it is possible to design a logical I2C bus number schema that
can be easily remembered by humans or calculated arithmetically. For example, we
can pin the fanout channels of a MUX on bus 3 to start at 30. So 30 will be the
logical bus number of the channel 0 of the MUX on bus 3, and 37 will be the
logical bus number of the channel 7 of the MUX on bus 3.
I2C Devices
===========
In previous sections, we mostly covered the I2C bus. In this section, let us see
what we can learn from the I2C device directory whose link name is in the format
of ``${bus}-${addr}``. The ``${bus}`` part in the name is a logical I2C bus
decimal number, while the ``${addr}`` part is a hex number of the I2C address
of each device.
I2C Device Directory Content
----------------------------
Inside each I2C device directory, there is a file named ``name``.
This file tells what device name it was used for the kernel driver to
probe this device. Use command ``cat`` to read its content. For example::
/sys/bus/i2c/devices/i2c-73$ cat 73-0040/name
ina230
/sys/bus/i2c/devices/i2c-73$ cat 73-0070/name
pca9546
/sys/bus/i2c/devices/i2c-73$ cat 73-0072/name
pca9547
There is a symbolic link named ``driver`` to tell what Linux kernel driver was
used to probe this device::
/sys/bus/i2c/devices/i2c-73$ readlink -f 73-0040/driver
/sys/bus/i2c/drivers/ina2xx
/sys/bus/i2c/devices/i2c-73$ readlink -f 73-0072/driver
/sys/bus/i2c/drivers/pca954x
But if the link ``driver`` does not exist at the first place,
it may mean that the kernel driver failed to probe this device due to
some errors. The error may be found in ``dmesg``::
/sys/bus/i2c/devices/i2c-73$ ls 73-0070/driver
ls: 73-0070/driver: No such file or directory
/sys/bus/i2c/devices/i2c-73$ dmesg | grep 73-0070
pca954x 73-0070: probe failed
pca954x 73-0070: probe failed
Depending on what the I2C device is and what kernel driver was used to probe the
device, we may have different content in the device directory.
I2C MUX Device
--------------
While you may be already aware of this in previous sections, an I2C MUX device
will have symbolic link ``channel-*`` inside its device directory.
These symbolic links point to their logical I2C bus directories::
/sys/bus/i2c/devices/i2c-73$ ls -l 73-0072/channel-*
lrwxrwxrwx ... 73-0072/channel-0 -> ../i2c-78
lrwxrwxrwx ... 73-0072/channel-1 -> ../i2c-79
lrwxrwxrwx ... 73-0072/channel-2 -> ../i2c-80
lrwxrwxrwx ... 73-0072/channel-3 -> ../i2c-81
lrwxrwxrwx ... 73-0072/channel-4 -> ../i2c-82
lrwxrwxrwx ... 73-0072/channel-5 -> ../i2c-83
lrwxrwxrwx ... 73-0072/channel-6 -> ../i2c-84
lrwxrwxrwx ... 73-0072/channel-7 -> ../i2c-85
I2C Sensor Device / Hwmon
-------------------------
I2C sensor device is also common to see. If they are bound by a kernel hwmon
(Hardware Monitoring) driver successfully, you will see a ``hwmon`` directory
inside the I2C device directory. Keep digging into it, you will find the Hwmon
Sysfs for the I2C sensor device::
/sys/bus/i2c/devices/i2c-73/73-0040/hwmon/hwmon17$ ls
curr1_input in0_lcrit_alarm name subsystem
device in1_crit power uevent
in0_crit in1_crit_alarm power1_crit update_interval
in0_crit_alarm in1_input power1_crit_alarm
in0_input in1_lcrit power1_input
in0_lcrit in1_lcrit_alarm shunt_resistor
For more info on the Hwmon Sysfs, refer to the doc:
../hwmon/sysfs-interface.rst
Instantiate I2C Devices in I2C Sysfs
------------------------------------
Refer to section "Method 4: Instantiate from user-space" of instantiating-devices.rst
测试命令：
1 i2cdetect
NAME
i2cdetect - detect I2C chips
SYNOPSIS
i2cdetect [-y] [-a] [-q|-r] i2cbus [first last]
i2cdetect -F i2cbus
i2cdetect -V
i2cdetect -l
DESCRIPTION
i2cdetect is a userspace program to scan an I2C bus for devices. It outputs a table with the list of detected devices on the specified bus. i2cbus indicates the number or name of the I2C bus to be scanned, and should correspond to one of the busses listed by i2cdetect -l. The optional parameters first and last restrict the scanning range (default: from 0x08 to 0x77).
As there is no standard I2C detection command, i2cdetect uses arbitrary SMBus commands (namely SMBus quick write and SMBus receive byte) to probe for devices. By default, the command used is the one believed to be the safest for each address. See options -q and -r to change this behavior.
i2cdetect can also be used to query the functionalities of an I2C bus (see option -F.)
WARNING
This program can confuse your I2C bus, cause data loss and worse!
INTERPRETING THE OUTPUT
Each cell in the output table will contain one of the following symbols:
"--". The address was probed but no chip answered.
"UU". Probing was skipped, because this address is currently in use by a driver. This strongly suggests that there is a chip at this address.
An address number in hexadecimal, e.g. "2d" or "4e". A chip was found at this address.
OPTIONS
-y
Disable interactive mode. By default, i2cdetect will wait for a confirmation from the user before messing with the I2C bus. When this flag is used, it will perform the operation directly. This is mainly meant to be used in scripts.
-a
Force scanning of non-regular addresses. Not recommended.
-q
Use SMBus "quick write" command for probing. Not recommended. This is known to corrupt the Atmel AT24RF08 EEPROM found on many IBM Thinkpad laptops.
-r
Use SMBus "receive byte" command for probing. Not recommended. This is known to lock SMBus on various write-only chips (most notably clock chips at address 0x69).
-F
Display the list of functionalities implemented by the adapter and exit.
-V
Display the version and exit.
-l
Output a list of installed busses.
EXAMPLES
List all available I2C busses:
# i2cdetect -l
Immediately scan the standard addresses on I2C bus 9 (i2c-9), using the default method for each address (no user confirmation):
# i2cdetect -y 9
Query the functionalities of I2C bus 1 (i2c-1):
# i2cdetect -F 1
Scan addresses 0x10 to 0x17 on the I2C bus named "SMBus I801 adapter at efa0", using the "receive byte" method, after user confirmation:
# i2cdetect -r "SMBus I801 adapter at efa0" 0x10 0x17示例 i2cdetect -l
示例 i2cdetect -y -r 6
2 i2cdump
NAME¶
i2cdump - examine I2C registers
SYNOPSIS
i2cdump [-f] [-r first-last] [-y] [-a] i2cbus address [mode [bank [bankreg]]]
i2cdump -V
DESCRIPTION
i2cdump is a small helper program to examine registers visible through the I2C bus.
OPTIONS
-V
Display the version and exit.
-f
Force access to the device even if it is already busy. By default, i2cdump will refuse to access a device which is already under the control of a kernel driver. Using this flag is dangerous, it can seriously confuse the kernel driver in question. It can also cause i2cdump to return invalid results. So use at your own risk and only if you know what you're doing.
-r first-last
Limit the range of registers being accessed. This option is not available with mode s. For mode W, first must be even and last must be odd.
-y
Disable interactive mode. By default, i2cdump will wait for a confirmation from the user before messing with the I2C bus. When this flag is used, it will perform the operation directly. This is mainly meant to be used in scripts.
-a
Allow using addresses between 0x00 - 0x07 and 0x78 - 0x7f. Not recommended.
At least two options must be provided to i2cdump. i2cbus indicates the number or name of the I2C bus to be scanned. This number should correspond to one of the busses listed by i2cdetect -l. address indicates the address to be scanned on that bus, and is an integer between 0x08 and 0x77.
The mode parameter, if specified, is one of the letters b, w, s, or i, corresponding to a read size of a single byte, a 16-bit word, an SMBus block, an I2C block, respectively. The c mode is a little different, it reads all bytes consecutively, and is useful for chips that have an address auto-increment feature, such as EEPROMs. The W mode is also special, it is similar to w except that a read command will only be issued on even register addresses; this is again mainly useful for EEPROMs.
A p can also be appended to the mode parameter (except for i and W) to enable PEC. If the mode parameter is omitted, i2cdump defaults to byte access without PEC.
The bank and bankreg parameters are useful on the W83781D and similar chips (at the time of writing, all Winbond and Asus chips). bank is an integer between 0 and 7, and bankreg is an integer between 0x00 and 0xFF (default value: 0x4E). The W83781D data sheet has more information on bank selection.
WARNING
i2cdump can be dangerous if used improperly. Most notably, the c mode starts with WRITING a byte to the chip. On most chips it will be stored in the address pointer register, which is OK, but some chips with a single register or no (visible) register at all will most likely see this as a real WRITE, resulting in possible misbehavior or corruption. Do not use i2cdump on random addresses. Anyway, it is of little use unless you have good knowledge of the chip you're working with and an idea of what you are looking for.
EXAMPLES
Dump the whole contents of I2C device at 7-bit address 0x50 on bus 9 (i2c-9), using the default read method (byte mode), after user confirmation:
# i2cdump 9 0x50
Immediately dump the whole contents of I2C device at 7-bit address 0x50 on bus 9 (i2c-9), using I2C block read transactions (no user confirmation):
# i2cdump -y 9 0x50 i
If the device is an EEPROM, the output would typically be the same as output of the previous example.
Dump registers 0x00 to 0x3f of the I2C device at 7-bit address 0x2d on bus 1 (i2c-1), using the default read method (byte mode), after user confirmation:
# i2cdump -r 0x00-0x3f 1 0x2d示例 i2cdump -f -y 6 0x0c
二：Uart测试方法
QNX侧：
TBD
Android侧：
1 stty 命令
首先使用此命令配置端口属性
用法：stty [-F 设备 | --file=设备] [设置]...
或：stty [-F 设备 | --file=设备] [-a|--all]
或：stty [-F 设备 | --file=设备] [-g|--save]
输出或修改终端参数。
-a, --all 以可读性较好的方式输出全部当前设置
-g, --save 以stty 可读取的格式输出当前全部设置
-F, --file=设备 打开并使用指定设备代替标准输入
--help 显示此帮助信息并退出
--version 显示版本信息并退出
可选- 在设置前的指示中，* 标记出了非POSIX 标准的设置。以下系
统定义象征了哪些设置是有效的。
特殊字符：
* dsusp 字符 每当输入刷新时会发送一个用于终端阻塞信号的字符
eof 字符 表示文件末尾而发送的字符(用于终止输入)
eol 字符 为表示行尾而发送的字符
* eol2 字符 为表示行尾而发送的另一个可选字符
erase 字符 擦除前一个输入文字的字符
intr 字符 用于发送中断信号的字符
kill 字符 用于擦除当前终端行的字符
* lnext 字符 用于输入下一个引用文字的字符
quit 字符 用于发送退出信号的字符
* rprnt 字符 用于重绘当前行的字符
start 字符 在停止后重新开启输出的字符
stop 字符 停止输出的字符
susp 字符 发送终端阻断信号的字符
* swtch 字符 在不同的shell 层次间切换的字符
* werase 字符 擦除前一个输入的单词的字符
特殊设置：
N 设置输入输出速度为N 波特
* cols N 统治内核终端上有N 栏
* columns N 等于cols N
ispeed N 设置输入速度为N 波特
* line N 设置行约束规则为N
min N 和 -icanon 配合使用，设置每次一完整读入的最小字符数为<N>
ospeed N 设置输出速度为N 波特
* rows N 向内核通告此终端有N 行
* size 根据内核信息输出当前终端的行数和列数
speed 输出终端速度(单位为波特)
time N 和-icanon 配合使用，设置读取超时为N 个十分之一秒
控制设置：
[-]clocal 禁用调制解调器控制信号
[-]cread 允许接收输入
* [-]crtscts 启用RTS/CTS 握手
csN 设置字符大小为N 位，N 的范围为5 到8
[-]cstopb 每个字符使用2 位停止位 (要恢复成1 位配合"-"即可)
[-]hup 当最后一个进程关闭标准终端后发送挂起信号
[-]hupcl 等于[-]hup
[-]parenb 对输出生成奇偶校验位并等待输入的奇偶校验位
[-]parodd 设置校验位为奇数 (配合"-"则为偶数)
输入设置：
[-]brkint 任务中断会触发中断信号
[-]icrnl 将回车转换为换行符
[-]ignbrk 忽略中断字符
[-]igncr 忽略回车
[-]ignpar 忽略含有奇偶不对称错误的字符
* [-]imaxbel 发出终端响铃但不刷新字符的完整输入缓冲
[-]inlcr 将换行符转换为回车
[-]inpck 启用输入奇偶性校验
[-]istrip 剥除输入字符的高8 位比特
* [-]iutf8 假定输入字符都是UTF-8 编码
* [-]iuclc 将大写字母转换为小写
* [-]ixany 使得任何字符都会重启输出，不仅仅是起始字符
[-]ixoff 启用开始/停止字符传送
[-]ixon 启用XON/XOFF 流控制
[-]parmrk 标记奇偶校验错误 (结合255-0 字符序列)
[-]tandem 等于[-]ixoff
输出设置：
* bsN 退格延迟的风格，N 的值为0 至1
* crN 回车延迟的风格，N 的值为0 至3
* ffN 换页延迟的风格，N 的值为0 至1
* nlN 换行延迟的风格，N 的值为0 至1
* [-]ocrnl 将回车转换为换行符
* [-]ofdel 使用删除字符代替空字符作填充
* [-]ofill 延迟时使用字符填充代替定时器同步
* [-]olcuc 转换小写字母为大写
* [-]onlcr 将换行符转换为回车
* [-]onlret 使得换行符的行为表现和回车相同
* [-]onocr 不在第一列输出回车
[-]opost 后续进程输出
* tabN 水平制表符延迟的风格，N 的值为0 至3
* tabs 等于tab0
* -tabs 等于tab3
* vtN 垂直制表符延迟的风格，N 的值为0 至1
本地设置：
[-]crterase 擦除字符回显为退格符
* crtkill 依照echoprt 和echoe 的设置清除所有行
* -crtkill 依照echoctl 和echol 的设置清除所有行
* [-]ctlecho 在头字符中输出控制符号("^c")
[-]echo 回显输入字符
* [-]echoctl 等于[-]ctlecho
[-]echoe 等于[-]crterase
[-]echok 在每清除一个字符后输出一次换行
* [-]echoke 等于[-]crtkill 意义相同
[-]echonl 即使没有回显任何其它字符也输出换行
* [-]echoprt 在"\"和"/"之间向后显示擦除的字符
[-]icanon 启用erase、kill、werase 和rprnt 等特殊字符
[-]iexten 允许POSIX 标准以外的特殊字符
[-]isig 启用interrupt、quit和suspend 等特殊字符
[-]noflsh 在interrupt 和 quit 特殊字符后禁止刷新
* [-]prterase 等于[-]echoprt
* [-]tostop 中止尝试向终端写入数据的后台任务
* [-]xcase 和icanon 配合使用，用转义符"\"退出大写状态
综合设置：
* [-]LCASE 等于[-]lcase
cbreak 等于-icanon
-cbreak 等于icanon
cooked 等于brkint ignpar istrip icrnl ixon opost isig icanon eof eol 等的默认值
-cooked 等于-raw
crt 等于echoe echoctl echoke
dec 等于echoe echoctl echoke -ixany intr ^c erase 0177 kill ^u
* [-]decctlq 等于[-]ixany
ek 清除所有字符，将它们回溯为默认值
evenp 等于parenb -parodd cs7
-evenp 等于-parenb cs8
* [-]lcase 等于xcase iuclc olcuc
litout 等于-parenb -istrip -opost cs8
-litout 等于parenb istrip opost cs7
nl 等于-icrnl -onlcr
-nl 等于icrnl -inlcr -igncr onlcr -ocrnl -onlret
oddp 等于parenb parodd cs7
-oddp 等于-parenb cs8
[-]parity 等于[-]evenp
pass8 等于-parenb -istrip cs8
-pass8 等于parenb istrip cs7
raw 等于-ignbrk -brkint -ignpar -parmrk -inpck -istrip
-inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany
-imaxbel -opost -isig -icanon -xcase min 1 time 0
-raw 等于cooked
sane 等于cread -ignbrk brkint -inlcr -igncr icrnl -iutf8
-ixoff -iuclc -ixany imaxbel opost -olcuc -ocrnl onlcr
-onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh
-xcase -tostop -echoprt echoctl echoke，所有特殊字符均
使用默认值
处理连接到标准输入的tty 终端行设置。当不附加参数时，程序会输出波特率、行约束
规则以及与标准stty 设置间的偏差。在设置中，字符会被逐字读取或是被编码为^c、
0x37、0177 或127 这样的字符，其中有特殊值^- 或undef 被用于禁止特殊字符。示例： stty -F /dev/ttyHS0 115200 cs8 -cstopb -parenb
115200是波特率，cs8表示8位数据位，-cstopb表示1位停止位，-parenb表示禁止校验位。
2 echo 命令
然后使用echo 命令输出数据
示例： echo "123" > /dev/ttyHS0
输出结果：
三：SPI测试方法
QNX侧：
测试命令： spidbgr
命令代码位置：
/SD-QNX4.5.6.0/apps/qnx_ap/AMSS/platform/services/applications/spidbgr/spidbgr.c
使用示例说明：
/SD-QNX4.5.6.0/apps/qnx_ap/AMSS/platform/services/applications/spidbgr/spidbgr.use
%C :
Usage: spidbgr -m [master_node] -d [slave_id] -M [mode] -f [freqency] -w -l [master_wlen] -o [master_wmsg] //write only
spidbgr -s [slave_node] -d [slave_id] -M [mode] -f [freqency] -R -B [slave_rlen] //read only
spidbgr -m [master_node] -d [slave_id] -M [mode] -f [freqency] -w -l [master_wlen] -o [master_wmsg] -s [slave_node] -R -B [slave_rlen] //master write and slave read
spidbgr -m [master_node] -d [slave_id] -M [mode] -f [freqency] -x -l [master_wlen] -o [master_wmsg] -s [slave_node] -X -L [slave_wlen] -O [slave_wmsg] //exchange between master and slave
cmd list:
-m --master master portid (range is 1-12)
-s --slave slave portid (range is 1-12)
-d --device slaveid (default 0, range is 0-3)
-G --setcfg set config
-M --mode mode (default 0x2608)
-f --freq freq (default 1000000HZ)
-w --master_write master write
-W --slave_write slave write
-r --master_read master read
-R --slave_read slave read
-x --master_xchange master xchange
-X --slave_xchange slave xchange
-c --master_cmdread master cmdread
-C --slave_cmdread slave cmdread
-i --master_cmdwrite master cmdwrite
-I --slave_cmdwrite slave cmdwrite
-g --get_info get info
-l --master_wlen master write msg len (default 0)
-b --master_rlen master read msg len (default 0)
-L --slave_wlen slave write msg len (default 0)
-B --slave_rlen slave read msg len (default 0)
-o --master_wmsg master write message
-O --slave_wmsg slave write message
-v --verbose verbose (default disable)
-t --timeout_value_set_sec timeout value set sec(default 5s)
-T --timeout_value_set_nsec timeout value set nsec(default 0ns)
-n --timeout_value_get timeout value get
-p --random_data_padding random data padding
-z --iteration_count iteration_count(default 1)
-h --help help
The meaning of each bit of the mode parameter:
0-7 bit the number of bits in a data frame
8 bit CPOL, 0:SCLK is low when idle, 1:SCLK is high when idle
9 bit CPHA, 0:input bit is shifted in first transition edge, 1:output bit is shifted in first transition edge
10 bit spi bit order, 0:LSB first 1:MSB first
11 bit spi cs polarity, 0:active low 1:active high
13 bit cs mode, 0:CS is deasserted after transferring data for N clock cycles 1:CS is asserted as long as the core is in Run state
22-25 bit inter-word delay(1-15 cycles)
30 bit SW loopback enable, 0:disable 1:enable
Eg. Get SPI configuration
spidbgr -m 2 -g
This will read back something like :
device info, name-A2B SPI / Mercu:mode-0x00002608:clock-5000000Hz
driver info, name-QCOM SPI Master:version-1:feature--2147483648
Eg. hw loopback between spi2 and spi9(spi2 write spi9 read)
spidbgr -d 0 -M 0x2608 -f 2000000 -m 2 -w -l 2 -o 0x55 0xaa -s 9 -R -B 2
Eg. spi master write(spi_write)
spidbgr -d 0 -M 0x2608 -f 2000000 -m 2 -w -l 2 -o 0x55 0xaa
Eg. spi master read(spi_read)
spidbgr -d 0 -M 0x2608 -f 2000000 -m 2 -r -b 2
Eg. spi master xchange(spi_xchange)
spidbgr -d 0 -M 0x2608 -f 2000000 -m 2 -x -l 2 -o 0x55 0xaa
Eg. spi master write and read(spi_cmdread)
spidbgr -d 0 -M 0x2608 -f 2000000 -m 2 -c -l 2 -o 0x55 0xaa -b 2
Eg. spi cmdwrite:
spidbgr -d 0 -M 0x2608 -f 2000000 -m 2 -i -l 2 -o 0x55 0xaa
Notes:
- Port ID range is 1-12. Slave ID range is 0-3.
- This debugger can handle at max 64K bytes per transaction.
- It can use the random data padding mode through the -p flag, specify the wlen is enough, no need to manually input wmsg in the cmd, such as:
spidbgr -m 2 -d 0 -M 0x40002608 -f 1000000 -x -l 500 -p
- It can log the transfer info through the -v flag, such as:
# spidbgr -m 2 -d 0 -M 0x40002608 -f 1000000 -x -l 10 -p -v
=========spi transfer info=========
iteration_times: 1
master_portid: 2 slave_portid: 0
cs_num: 0
mode: 0x40002608
freq: 1000000HZ
master_wlen: 10 master_rlen: 10
slave_wlen: 0 slave_rlen: 0
master_cmd: SPI_XCHANGE
slave_cmd: None
master_wmsg: 0x28 0xac 0x87 0xda 0x70 0x19 0x9d 0x8c 0xb1 0x1
===================================
- It can set the timeout value with the -t & -T flags, -t is sec, -T is nsec , such as:
spidbgr -m 2 -d 0 -M 0x40002608 -f 100000 -x -l 2 -p -t 10 -T 1000000
- It can get the timeout value with the -n flag, such as:
spidbgr -m 2 -d 0 -M 0x40002608 -f 100000 -x -l 2 -p -t 10 -T 1000000 -n
/dev/spi2 timeout_sec is 10s, timeout_nsec is 1000000ns
- The iteration count can be specified with the -z flag, such as
spidbgr -m 2 -d 0 -M 0x40002608 -f 100000 -x -l 2 -p -z 5
示例 ： spidbgr -d 0 -M 0x2608 -f 10000000 -m 3 -w -l 1 -o 0xaa
Android侧：
测试命令： spidev_test
高通相关路径：
/SD-HQX4.5.6.0/lagvm/LINUX/android/kernel_platform/msm-kernel/tools/spi/spidev_test.c
static void print_usage(const char *prog)
{
printf("Usage: %s [-DsbdlHOLC3vpNR24SI]\n", prog);
puts(" -D --device device to use (default /dev/spidev1.1)\n"
" -s --speed max speed (Hz)\n"
" -d --delay delay (usec)\n"
" -b --bpw bits per word\n"
" -i --input input data from a file (e.g. \"test.bin\")\n"
" -o --output output data to a file (e.g. \"results.bin\")\n"
" -l --loop loopback\n"
" -H --cpha clock phase\n"
" -O --cpol clock polarity\n"
" -L --lsb least significant bit first\n"
" -C --cs-high chip select active high\n"
" -3 --3wire SI/SO signals shared\n"
" -v --verbose Verbose (show tx buffer)\n"
" -p Send data (e.g. \"1234\\xde\\xad\")\n"
" -N --no-cs no chip select\n"
" -R --ready slave pulls low to pause\n"
" -2 --dual dual transfer\n"
" -4 --quad quad transfer\n"
" -8 --octal octal transfer\n"
" -S --size transfer size\n"
" -I --iter iterations\n");
exit(1);
}示例 spidev_test -D /dev/spidev1.0 -H 1 -p '\x7c\x50'
PS ：
高通某些test工具组入需要 更改Android.dp文件
可参考路径 /SD-HQX4.5.6.0/lagvm/LINUX/android/kernel_platform/msm-kernel/Android.bp
1358
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
