This is only a preview of the October 2024 issue of Silicon Chip. You can view 45 of the 112 pages in the full issue, including the advertisments. For full access, purchase the issue for $10.00 or subscribe for access to the latest issues. Items relevant to "3D Printer Filament Dryer, Part 1":
Items relevant to "8Ch Learning Remote Receiver":
Articles in this series:
Items relevant to "JMP012 - WiFi Relay Remote Control":
Videos relevant to "JMP015 - Analog Servo Gauge":
Articles in this series:
Items relevant to "Dual-Rail Load Protector":
Items relevant to "Micromite Explore-40":
Purchase a printed copy of this issue for $13.00. |
The MIPI I3C Bus
There is a brand-new serial bus on the block named I3C (Improved InterIntegrated Circuit). It is beginning to appear in mainstream parts; here’s what
you need to know about it.
By Andrew Levido
R
ight now, if you want to connect
a peripheral like a sensor or an
EEPROM to a microcontroller, you
would probably use either the SPI
(Serial Peripheral Interface) or I2C
(Inter-Integrated Circuit) bus. These
are tried and tested serial interfaces
that date back to the 1980s.
The new I3C standard was developed by the MIPI Alliance (www.mipi.
org) and incorporates key attributes of
the venerable I2C and SPI interfaces, as
well as some interesting new features
such as dynamic addressing, in-band
interrupts, high data rate modes and
28
Silicon Chip
hot-join capability. As the name suggests, I3C is closely aligned with I2C.
In fact, I2C devices can even be used
on an I3C bus.
Like SPI and I2C, I3C uses a controller, typically a peripheral within
a microcontroller, and one or more
targets. Fig.1 shows a comparison
between an I2C, SPI and I3C bus, each
connecting a controller (master) with
three targets (slaves) that can each
interrupt the controller. With I2C,
the targets are addressed via the bus,
whilst SPI requires a separate chip
select (CS) signal for each target.
I2C uses bidirectional data transfer on the data line (SDA), while SPI
requires two unidirectional lines
(MISO and MOSI) for bidirectional
communication. Both require separate
interrupt lines if targets are to interrupt
the processor asynchronously.
I3C uses device addressing and
bidirectional data transfers, just like
I2C, but does not require dedicated
interrupt signals, since targets can
send interrupts to the controller via
the bus.
The best of both worlds
Fig.1: compared with I2C and SPI, I3C requires fewer
data lines for bidirectional communication with interrupt
capability. Data throughput is similar to SPI, while
addressing is managed over the bus.
The I2C protocol uses open-drain
drivers to achieve bidirectional signalling on the clock and data lines.
High-to-low transitions are actively
driven, but low-to-high transitions rely
on pull-up resistors, so the signal rise
time is limited by the resistor value
and bus capacitance.
The maximum data rate that can
be achieved over I2C is therefore significantly lower than SPI, where the
bus is actively driven high and low by
push-pull drivers.
For I2C, the maximum clock speed
is typically 400kHz, or 1MHz with
Fast mode+ drivers. There is a standard allowing speeds up to 3.4MHz,
but it is not widely supported. The
SPI interface does not have standard
clock rates but can typically operate at a maximum clock speed of
10-20MHz.
I3C uses drivers that can operate in
open-drain mode when required, but
they switch to push-pull mode whenever possible to maximise the data
transfer rate. External pull-ups are not
required – these are provided by the
controller when necessary.
Besides using open-drain drivers
when communicating with legacy I2C
devices, open-drain drivers are used
whenever bus arbitration is required;
we’ll cover that in more detail later.
Australia's electronics magazine
siliconchip.com.au
Data transfers generally use the pushpull drivers.
As a result, the I3C bus operates
at a range of clock speeds. In pushpull mode, the maximum clock speed
is 12.5MHz, while in open-drain
mode, it is 2.5MHz. The clock speed
drops to 400kHz (or 1MHz for Fm+)
when communicating with legacy
I2C devices.
Address arbitration
All communications on the I3C bus
begin with the bus in the idle state,
where the SDA and SCL lines are
both high, and with open-drain drivers enabled.
The start of a transaction is indicated by a start condition, a highto-low transition on SDA while SCL
remains high. A transaction is terminated with a stop condition, a low-tohigh transition on SDA with SCL high.
All other SDA transitions occur with
SCL low. Repeated start conditions
may be issued to allow multiple messages per transaction. A target address
header follows each start or repeated
start condition.
If all this sounds familiar, that’s
because, so far, this is identical to how
I2C works. One key difference is that,
with I3C, it is possible for targets to
issue a start condition and/or to emit
the address header under certain circumstances. On an I2C bus, only the
controller can do that.
This can happen when a target
wishes to signal an interrupt to the
controller, a device wants to ‘hot join’
the bus, or a target wishes to become
the controller. It is therefore possible
that two or more devices may try to
write the address header to the bus at
the same time. We need a mechanism
to arbitrate this conflict.
The open-drain nature of the bus
during this phase provides a form of
Fig.2: address arbitration occurs if two devices simultaneously attempt to
write an address header to the bus. On the fourth clock cycle, device A’s
zero overrules device B’s one; device B recognises this and gives up. Because
zero-bits are asserted actively on the bus, while ones are passive, the device
with the lowest address always wins arbitration.
natural arbitration, ensuring that the
device with the lowest address always
‘wins’. Consider the example shown
in Fig.2. Here, devices A and B, with
hexadecimal addresses 0x26 (binary
010 0110) and 0x29 (binary 010 1001),
respectively, attempt to write their
address headers (7-bit address + read/
write bit) to the bus.
On the first clock cycle after the start
condition, each emits a logic zero by
pulling the bus down with their opendrain driver. Both A and B monitor the
bus and check that its level matches
the value they emitted. If so, they each
continue to deliver the header.
Both devices emit a logic one on
the second clock cycle, and the passive pull-up pulls the bus high. Again,
each device sees that the bus state is as
expected and moves on to the next bit.
This process continues until the 4th
bit, when device A emits a zero and
device B emits a one. The bus will be
pulled low by device A’s open-drain
driver, so device B will see a mismatch
between the logic level it emitted and
that which appeared on the bus. At this
point, device B has ‘lost’ the arbitration and ceases to participate.
Meanwhile, device A continues to
place its address on the bus unopposed, and the transaction it initiated
ensues. Under these circumstances,
device B will likely reattempt to assert
the header after the transaction concludes and the bus is idle once again.
This type of arbitration is zero-
dominant, so the device with the
lowest address always wins. For this
reason, most controller-initiated I3C
transactions don’t begin with a target
address header as they do in I2C. If
they did, it would not be possible for
the target with the highest address to
win an arbitration.
Fig.3: controller-initiated read
or write transactions on the
I3C bus look similar to their
I2C counterparts. However, I3C
transactions generally begin with
the special address 0x7E, allowing
targets to assert their addresses
if necessary. Each data byte is
followed by a T-bit rather than an ...
... acknowledge bit; it is a parity bit
for writes and a continuation bit for
reads.
siliconchip.com.au
Australia's electronics magazine
October 2024 29
Instead, they generally begin with
the special address 7E hexadecimal
(111 1110 binary). This address is
higher than any valid target address,
so it is guaranteed to lose arbitration
to any target, should there be a conflict.
sending data bytes, depending on the
value of the read/write bit.
Because the sender is in pushpull mode, it is not possible for the
receiving device to ACK each byte,
as happens in I2C. Instead, the sending device sends a ‘T-bit’ on the 9th
clock cycle.
Single data rate transactions
For writes, the T-bit sent by the conI3C supports several different trans- troller is a parity bit protecting the preaction types. Let’s first look at a sim- ceding byte. Odd parity is used; The
ple example where an I3C controller parity bit is set or cleared such that the
wishes to write to or read from a tar- total number of ones in the data and
get, as illustrated at the top and centre the parity bit is odd.
of Fig.3, respectively.
In the case of reads, the target sets
SDR transactions begin from the the T-bit to indicate that more bytes of
idle state, with the controller issu- data will come. The last byte has its
ing a start condition followed by an T-bit cleared.
address header containing the special
Fig.3 also shows a typical hybrid
7-bit address 0x7E and a write (zero) write-read that might be used to
bit. All I3C targets will acknowledge address and then read a specific reg(ACK) this address by pulling SDA low ister in a target. The arbitrable 0x7E
on the 9th clock cycle.
header is written as before, followed
The controller then emits a repeated by a repeated start condition and a
start condition followed by a non- write of the register address to the tararbitrable address header containing get. Another repeated start condition
the target’s dynamic address, along is then issued, followed by a read to
with the read or write bit, depend- obtain the register value; in this case,
ing on the desired data direction. a single byte.
The target with a matching dynamic
Apart from the T-bit replacing the
address will acknowledge (ACK), and acknowledge bit, and the clock speed,
any others will ignore the rest of the this is all very similar to I2C.
transaction.
Apart from this ACK, the whole In-band interrupts
transaction following the repeated
One elegant feature of I3C is the
start is carried out in push-pull mode in-band interrupt (IBI) capability. A
with a nominal 12.5MHz clock. The target may signal an interrupt by placcontroller or the target then begins ing its dynamic address (and the read/
write bit set to one) on the bus following a start condition. It may do this
when the controller or another target
initiates a start condition, or it may
emit the start condition itself.
Since a controller message generally begins with the 0x7E address, the
interrupting target will win the arbitration. If two or more targets interrupt
simultaneously, the lowest addressed
one will win. Fig.4 shows the typical
IBI process.
The controller may accept the interrupt by ACKing the request as shown
at the top or decline it by NACKing it
as shown below that.
If the controller accepts the interrupt, it reads in a “mandatory byte”
(MDB) sent by the interrupting target
with details of the interrupt source.
The target may optionally send additional bytes of data, indicated by the
value of the T-bit. Once finished, the
controller terminates the transaction
with a stop condition.
If the controller denies the IBI
request, the target may continue to
try interrupting until the controller
accepts. The controller may prevent a
target from interrupting by sending a
specific command to the target.
Common command codes
This introduces another feature of
the I3C standard – the ability to send
predefined common command codes
(CCC) to targets. All targets must support a subset of CCCs, but others are
Fig.4: a target may signal an In-band
Interrupt (IBI) by asserting its address
header after a start condition. The
controller accepts or rejects the IBI
request by ACKing or NACKing the
address. If accepted, the controller
reads a Mandatory Byte describing
the interrupt reason; the target may
send further data after that.
Fig.5: common command codes
(CCCs) allow the controller to put
targets in defined states (eg, by
turning IBI on or off) or to query the
target (eg, to get device ...
... characteristics). Some CCCs are broadcast to all targets on the
bus, while others are directed to one or more specific devices.
30
Silicon Chip
Australia's electronics magazine
siliconchip.com.au
optional or only required when the
target has specific features.
All CCCs are one byte long, with
those in the range 0x00 to 0x7F being
broadcast codes that all devices will
respond to, and those in the range 0x80
to 0xFF being direct codes intended
for only a specific target. The standard defines many CCCs, a selection
of which are included in Table 1.
Fig.5 shows how broadcast or
direct CCCs are used. Broadcast CCC
transmissions begin with the special
address 0x7E, followed by the command code and any associated data
bytes.
Direct CCCs begin the same way,
with a 0x7E address followed by the
CCC. This time, there may be a ‘defining byte’ associated with the CCC. A
repeated start condition is then issued,
followed by the dynamic address of the
target to which the CCC is directed,
plus a read/write bit. Additional targets may be addressed by issuing
another repeated start condition and
target address header.
Dynamic addressing
So far, we have referred to target
addresses as though they are fixed,
like I2C device addresses. In I3C, the
controller must assign each target
a 7-bit dynamic address before any
directed transactions can occur. The
target retains this address until it is
reset or the target receives a Reset
Dynamic Address Assignment (RSTDAA) CCC.
Dynamic addressing has a couple
of advantages over fixed addressing.
Firstly, since lower addresses have
higher arbitration priority, the controller can assign interrupt priorities by
appropriate dynamic address choices.
Secondly, it avoids conflicts between
devices with identical static addresses,
as occurs with I2C.
That it can happen is unsurprising
since there are only about 120 non-
reserved 7-bit addresses and many
thousands of unique devices. For
example, the site https://i2cdevices.
org/addresses suggests the address
0x44 is shared by no fewer than 19
devices, ranging from an IR temperature sensor to a high-side current monitor to a resistive touchscreen controller. Dynamic addressing avoids such
overlaps.
Table 1 – some of the more frequently used I3C Common Control Codes
CCC
Type
ENEC
Enable Events Command
Broadcast Write 0x00
Direct Write 0x80
Enable Target events such as Hot-Join and In-Band Interrupt
RSTDAA
Reset Dynamic Address
Assignment
Broadcast Write 0x06
Direct Write 0x86
Discard current Dynamic Address and wait for new
assignment
ENTDAA
Enter Dynamic Address
Assignment
Broadcast Write 0x07
Enter Controller initiation of Dynamic Address Assignment
Procedure
SETDASA
Set Dynamic Address from
Static Address
Direct Write 0x87
Controller assigns a Dynamic Address to a Target with a
known Static Address
SETNEWDA
Set New Dynamic Address
Direct Write 0x88
Controller assigns new Dynamic Address to a Target
SETMWL
Set Maximum Write Length
Broadcast Write 0x09
Direct Write 0x89
Controller sets maximum write length
SETMRL
Set Maximum Read Length
Broadcast Write 0x0A
Direct Write 0x8A
Controller sets maximum read length and IBI payload size
GETMWL
Get Maximum Write Length
Direct Read 0x8B
Controller queries Target’s maximum possible write length
SETBUSCON Set Bus Context
Value
Broadcast Write 0x0C
Brief Description
Controller specifies a higher-level protocol and/or I3C
specification version
GETMRL
Get Maximum Read Length
Direct Read 0x8C
Controller queries Target’s maximum possible read length
and IBI payload size
GETPID
Get Provisional ID
Direct Read 0x8D
Controller queries Target’s Provisional ID
GETBCR
Get Bus Characteristics
Register
Direct Read 0x8E
Controller queries Target’s Bus Characteristics Register
GETDCR
Get Device Characteristics
Register
Direct Read 0x8F
Controller queries Target’s Device Characteristics Register
ENTHDR0
Enter HDR Mode 0
Broadcast Write 0x20
Controller has entered HDR-DDR Mode
ENTHDR1
Enter HDR Mode 1
Broadcast Write 0x21
Controller has entered HDR-TSP Mode
ENTHDR2
Enter HDR Mode 2
Broadcast Write 0x22
Controller has entered HDR-TSL Mode
ENTHDR3
Enter HDR Mode 3
Broadcast Write 0x23
Controller has entered HDR-BT Mode
RSTACT
Target Reset Action
Broadcast Write 0x2A
Direct Write & Read 0x9A
Controller configures and/or queries Target Reset action
and timing
GETSTATUS Get Device Status
Direct Read 0x90
Controller queries Target’s operating status
GETMXDS
Direct Read 0x94
Controller queries Target’s maximum read/write data
speeds and maximum read turnaround time
Get Maximum Data Speed
siliconchip.com.au
Australia's electronics magazine
October 2024 31
Fig.6: dynamic addresses can be assigned
by two methods – from a static 7-bit address
using the SETDASA CCC, or via the Dynamic
Address Assignment process started by the
ENTDAA CCC. The latter is preferred; in
this case, bus arbitration is used to assign
addresses to all devices in sequence.
Fig.7: the Provisioned Identifier (PID) is a 48-bit value containing a manufacturer ID, a part ID, an Instance ID and
a 12-bit device characteristic descriptor. On some parts, the Instance ID is programmable via pins or other means to
allow multiple instances of the same device to be uniquely identified on the bus.
There are two different options
for assigning dynamic addresses.
Some early devices do have a static
7-bit address, which is used to assign
a dynamic address using the CCC
“Set Dynamic Address from Static
Address” (SETDASA), as shown at the
top of Fig.6. The static address can’t
be used for any other purpose.
The controller starts the transaction
in the usual way, sending the SETDASA CCC, followed by a restart, then
the static address of the target with
the read/write bit set. When the target ACKs the static address, the controller sends the dynamic address it
wishes to assign.
The controller can optionally set
further dynamic addresses by repeating the process after issuing a repeated
start condition.
This approach does not really help
with the problem of address duplication, so the preferred option is to assign
dynamic addresses based on a 48-bit
device identifier known as a ‘Provisioned ID’ (PID), the format of which
is shown in Fig.7.
The upper 15 bits of this are the
manufacturer ID assigned by the MIPI
Alliance. The next bit, #32, is usually
zero, while the following 16 bits are
the part identifier. Bits 12 through 15
32
Silicon Chip
are an instance ID. These may be programmed by setting device pin(s) to
specific levels, to allow the user to
deploy multiple instances of the same
device on the same bus.
The process for assigning dynamic
addresses to these targets relies on the
same bus arbitration mechanism we
saw earlier. The lower part of Fig.6
shows this in action. The CCC Enter
Dynamic Addressing Assignment
(ENTDASA) is sent, followed by a
repeated start condition and another
0x7E address.
Any targets on the bus that do not
have a dynamic address assigned
will ACK this and begin writing their
48-bit PID, followed by the contents
of two 8-bit capability registers, BCA
and DCA. This write is arbitrable, so
only the device with the lowest PID
will complete the process, at which
time the controller sends the dynamic
address it wishes to assign.
If the device acknowledges, the
dynamic address is considered
assigned. A repeated start condition
is issued, and the whole process is
repeated for the remaining targets
with unassigned dynamic addresses
until none are left. At that point, the
0x7E address is passively NACKed,
and the assignment process is terminated.
Hot-Join mechanism
Fig.8: the hot join process is
similar to the IBI process, except
that the joining device uses the
special 0x02 address. If the
controller ACKs the request, the
target waits for a dynamic address
to be assigned by the controller.
A target may join an I3C bus once
it is up and running (for example, by
being plugged in or powered up). It
does this using a mechanism similar
to the In-Band Interrupt, shown in
Fig.8. The hot-joining device emits
an address header with the special
high-priority address 0x02, guaranteeing it will be heard.
The controller may accept the hotjoin request by ACKing it or reject it by
NACKing it. If the request is accepted,
the joining device waits for the controller to assign a dynamic address via
Australia's electronics magazine
siliconchip.com.au
Fig.9: the I3C controller produces the SCL clock with a duty cycle such that the high period is 40ns or less. I2C devices
are required to have a 50ns glitch filter on their SCL and SDA inputs, so the I3C clock should be invisible to them.
Fig.10: the HDR exit and restart
patterns; the exit pattern is always
followed by a stop condition and
returns the bus to the idle state.
The restart pattern is analogous to
the repeated start condition and
delineates multiple messages within
an HDR transaction.
the ENTDAA CCC process described
above. If the controller rejects the
request, the joining device will likely
continue to make requests unless
the controller switches off hot-join
requests via the DISEC CCC.
Note that this process works if more
than one device joins simultaneously
– the 0x02 address will be emitted by
all devices simultaneously, and they
will all succeed in the arbitration. The
controller ACK will put them all in a
state awaiting dynamic address assignment, and the ENTDAA assignment
process will assign them all addresses
in order of their PIDs.
I2C compatibility
I mentioned before that I2C targets
can co-exist with I3C targets on the
same bus. It is important that these
devices don’t react to I3C messages
and potentially disrupt them. I3C uses
a couple of mechanisms to reduce the
chance of that happening. Firstly, the
special address 0xFE in the header of
I3C messages is a reserved address in
I2C and should be ignored by all complying devices.
On top of this, I3C takes advantage
of the 50ns glitch filter that is required
by the standard on the SDA and SCL
pins of I2C devices. The duty cycle of
the SCL signal is managed so that the
clock high period is always less than
or equal to 40ns, making the I3C clock
‘invisible’ to I2C targets. They should
ignore any signal on their SDA line,
because they don’t see any clock transitions on SCL.
Fig.9 shows how this works. For the
12.5MHz push-pull clock, the high and
low pulses are naturally 40ns long at
a 50% duty cycle. The 2.5Mhz opendrain clock is emitted at a duty cycle
of around 10%, leaving the high pulses
40ns long.
This behaviour is only needed if
there are legacy devices on the bus.
Most controllers allow for a 50% duty
cycle to be used on both clocks for
‘pure’ I3C buses.
When communicating with I 2C
devices, the SCL clock is reduced to
400kHz or 1MHz with a 50% duty
cycle and transactions are carried
out in open-drain mode with signalling conforming to the I2C standard.
However, I3C does not support the
I2C features of 10-bit addressing, clock
stretching or multi-master operation,
so be careful.
High data rate modes
So far, everything we have covered is occurring in ‘Single Data Rate’
(SDR) mode. The I3C protocol supports several higher data rate (HDR)
modes. I am only going to cover the
most common one of those in the
interests of brevity. Regardless of the
HDR mode chosen, the I3C bus is
always initialised and configured in
SDR mode.
Only limited extra functionality
is available in the HDR modes – you
can’t assign dynamic addresses or
receive in-band interrupts, for example.
HDR modes are always entered from
SDR mode by issuing the appropriate
Enter HDR Mode X (ENTHDRx) CCC.
Once entered, the HDR mode has a buswide effect until it is exited via an HDR
exit pattern. Within an HDR mode
transaction, multiple messages can
be separated by HDR restart patterns,
Fig.11: HDR-DDR transactions begin with an ENTHDR0
CCC, followed by a command and address word. Data
is then sent one word at a time to or from the controller,
depending on the command. The last data word is
followed by a five-bit CRC and an exit or restart pattern.
siliconchip.com.au
Australia's electronics magazine
October 2024 33
analogous to the repeated start condition in SDR mode.
The HDR exit and restart patterns
are shown in Fig.10. The exit pattern
is defined as four consecutive falling
edges on SDA while SCL is low. It is
always followed by a stop condition.
The restart pattern is defined as two
successive toggles of SDA (fall, rise,
fall, rise) followed by a rising edge
on SCL.
Fig.12 shows how the command, data
and CRC words are constructed.
The Command and CRC words
begin with the same preamble but are
distinguishable by context – the command word only ever comes immediately after entry to the HDR mode or
a restart pattern, while the CRC only
ever comes after a data word. Only a
very limited range of CCCs are supported in HDR-DDR mode.
HDR-DDR
Other features
The common HDR Double Data
Rate (HDR-DDR) mode uses the same
12.5MHz clock as SDR mode but
allows data bits to be sent on both rising and falling clock edges, effectively
doubling the data throughput.
Fig.11 shows how a typical HDRDDR transaction works. After sending
the ENTHDR0 CCC in SDR mode, the
bus switches to HDR-DDR mode. The
controller then issues a command and
address word indicating the data direction (read or write) and the intended
target’s dynamic address, followed
by one or more data words written
by either the controller or the target,
depending on the data direction.
When all the data has been sent, the
sender concludes with a five-bit CRC.
The controller then emits a restart pattern if another DDR message is to be
sent, or an exit pattern and stop condition if not.
The basic unit of transmission
(except for the CRC) is a 16-bit word
with a two-bit preamble and two trailing parity bits, for a total of 20 bits.
DDR mode can achieve an effective
data throughput of 20Mbps, comparable with SPI (but with error checking). Faster HDR modes are possible,
including some that allow for two or
four data lanes and can achieve effective data rates of up to 96Mbps. However, not all modes are supported by
all targets.
In addition to those features
described here, I3C offers some other
interesting capabilities, including
the ability to reset targets (individually or in groups) over the bus and
to send synchronising ‘ticks’ to targets to coordinate timing. It supports
group addressing, where a set of targets share a group address (alongside
their individual dynamic addresses),
so they can be sent messages simultaneously.
It is also possible for one target to
communicate directly with another via
device-to-device tunnelling. There is a
lot to this standard; it will be interesting to see what features receive support from chip vendors.
Trying it out
I have experimented with I3C over
the last couple of weeks, using an
NXP LPC865 microcontroller with an
integrated I3C controller. For targets,
I tried a Bosch BMI323 inertial measurement unit (IMU), an ST Microelectronics LPS22HH humidity sensor and a TDK ICM42688P motion
sensor.
I was able to test a lot of the SDR
functionality, and it works as advertised, but the experience was not as
smooth as it could have been. I think
these rough edges are due to the relative immaturity of the standard. The
device data sheets were a mixed bag
regarding the thoroughness of their
documentation of I3C features – I did
have to resort to a bit of trial and error
to get things going.
The MCU toolchain and the I3C
driver provided in the SDK worked
fine for my purposes. Debugging the
bus was a challenge, as my logic analysers do not currently have support for
the I3C protocol. For this reason, I had
to resort to printing out waveforms and
marking ones and zeros by hand on a
few occasions.
I am sure that all of these points
will improve as I3C becomes more
common. Right now, I3C is available
on only a limited number of devices,
which are helpfully listed at https://
binho.io/blogs/i3c-reference/i3c-
devices
I believe this list will grow, given
that the MIPI Alliance lists almost
every silicon vendor as a member,
and it has a pretty good track record
of establishing standards. Over the
next few years, I suspect we will see
I3C becoming more and more popular.
References
Fig.12: data is transmitted on both clock edges in HDR-DDR mode. For data
and command words, a two-bit preamble is followed by 16 data bits and
two parity bits. The CRC word is slightly different and is always followed
by a restart or exit pattern.
34
Silicon Chip
Australia's electronics magazine
I 2C-Bus Specification and User
Manual (2021): NXP, siliconchip.au/
link/abtv
I3C and I3C Basic specifications:
MIPI, siliconchip.au/link/abgm
ICM-42688-P: TDK, siliconchip.au/
link/abtw
Bosch Sensortec BMI323 Inertial
Measurement Unit (IMU): Bosch,
siliconchip.au/link/abtx
Arm Cortex-M0+ LPC86x 60MHz
32-Bit Microcontrollers (MCUs): NXP,
siliconchip.au/link/abty
STMicroelectronics LPS22HH
High-Performance MEMS Nano Pressure Sensor: ST, siliconchip.au/link/
abtz
SC
siliconchip.com.au
|