This is only a preview of the August 2025 issue of Practical Electronics. You can view 0 of the 80 pages in the full issue. Articles in this series:
Articles in this series:
Articles in this series:
Articles in this series:
Articles in this series:
Items relevant to "180-230V DC Motor Speed Controller, part two":
Articles in this series:
|
Feature Article
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 I 2C
(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
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.
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.
14
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
The I2C protocol uses open-drain
drivers to achieve bidirectional signalling on the clock and data lines. Highto-low transitions are actively driven,
but low-to-high transitions rely on pullup 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.
Practical Electronics | August | 2025
The MIPI I3C Serial Bus Standard
Data transfers generally use the pushpull drivers.
As a result, the I3C bus operates at
a range of clock speeds. In push-pull
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 high-to-low
transition on SDA while SCL remains
high. A transaction is terminated with
a stop condition, a low-to-high 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.
Practical Electronics | August | 2025
15
Feature Article
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.
Single data rate transactions
I3C supports several different transaction types. Let’s first look at a simple
example where an I3C controller wishes
to write to or read from a target, as illustrated at the top and centre of Fig.3,
respectively.
SDR transactions begin from the
idle state, with the controller issuing
a start condition followed by an address header containing the special
7-bit address 0x7E and a write (zero)
bit. All I3C targets will acknowledge
(ACK) this address by pulling SDA low
on the 9th clock cycle.
The controller then emits a repeated start condition followed by a non-
arbitrable address header containing
the target’s dynamic address, along
with the read or write bit, depending on the desired data direction. The
target with a matching dynamic address will acknowledge (ACK), and
any others will ignore the rest of the
transaction.
Apart from this ACK, the whole transaction following the repeated start is
carried out in push-pull mode with a
nominal 12.5MHz clock. The controller or the target then begins 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.
For writes, the T-bit sent by the controller is a parity bit protecting the preceding byte. Odd parity is used; The
parity bit is set or cleared such that the
total number of ones in the data and
the parity bit is odd.
In the case of reads, the target sets
the T-bit to indicate that more bytes of
data will come. The last byte has its
T-bit cleared.
Fig.3 also shows a typical hybrid
write-read that might be used to address and then read a specific register in a target. The arbitrable 0x7E
header is written as before, followed
by a repeated start condition and a
write of the register address to the
target. Another repeated start condition is then issued, followed by a
read to obtain the register value; in
this case, a single byte.
Apart from the T-bit replacing the
acknowledge bit, and the clock speed,
this is all very similar to I2C.
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.
In-band interrupts
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
One elegant feature of I3C is the inband interrupt (IBI) capability. A target
may signal an interrupt by placing its
dynamic address (and the read/write
Common command codes
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.
16
Practical Electronics | August | 2025
The MIPI I3C Serial Bus Standard
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
Value
Brief Description
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
SETNEWDA
SETMWL
Direct Write 0x87
Controller assigns a Dynamic Address to a Target with a
known Static Address
Set New Dynamic Address
Direct Write 0x88
Controller assigns new Dynamic Address to a Target
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
Broadcast Write 0x0C
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
Practical Electronics | August | 2025
17
Feature Article
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
18
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 highpriority 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
Practical Electronics | August | 2025
The MIPI I3C Serial Bus Standard
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 I2C 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
bus-wide effect until it is exited via
an HDR exit pattern. Within an HDR
mode transaction, multiple messages can be separated by HDR restart
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.
Practical Electronics | August | 2025
19
Feature Article
patterns, 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.
20
I 2 C-Bus Specification and User
Manual (2021): NXP, https://pemag.
au/link/abtv
I3C and I3C Basic specifications:
MIPI, https://pemag.au/link/abgm
ICM-42688-P: TDK, https://pemag.
au/link/abtw
Bosch Sensortec BMI323 Inertial
Measurement Unit (IMU): Bosch,
https://pemag.au/link/abtx
Arm Cortex-M0+ LPC86x 60MHz
32-Bit Microcontrollers (MCUs): NXP,
https://pemag.au/link/abty
STMicroelectronics LPS22HH HighPerformance MEMS Nano Pressure
Sensor datasheet: ST, https://pemag.
au/link/abtz
PE
Practical Electronics | August | 2025
|