I2c Tools For Mac

2020. 3. 22. 21:31카테고리 없음

Not to be confused with. I²C Type Production history Designer, known today as Designed 1982; 36 years ago ( 1982) Data Data signal or Width data line (SDA) + clock line (SCL) Bitrate 0.1 / 0.4 / 1.0 / 3.4 / 5.0 (depending on mode) Protocol, I²C ( Inter-Integrated Circuit), pronounced I-squared-C, is a, invented in 1982 by (now ).

I2c-tools Mac

It is widely used for attaching lower-speed peripheral to processors and in short-distance, intra-board communication. Alternatively I²C is spelled I2C (pronounced I-two-C) or IIC (pronounced I-I-C). Since October 10, 2006, no licensing fees are required to implement the I²C protocol. However, fees are required to obtain I²C slave addresses allocated by NXP. Several competitors, such as Siemens AG (later Infineon Technologies AG, now Intel mobile communications), NEC, Texas Instruments, STMicroelectronics (formerly SGS-Thomson), Motorola (later Freescale, now merged with NXP), Nordic Semiconductor and Intersil, have introduced compatible I²C products to the market since the mid-1990s., defined by Intel in 1995, is a subset of I²C, defining a stricter usage.

One purpose of SMBus is to promote robustness and interoperability. Accordingly, modern I²C systems incorporate some policies and rules from SMBus, sometimes supporting both I²C and SMBus, requiring only minimal reconfiguration either by commanding or output pin use. 24C08: Serial with I²C bus I²C is appropriate for peripherals where simplicity and low manufacturing cost are more important than speed. Common applications of the I²C bus are:. Describing connectable devices via small ROM configuration tables to enable ' operation, such as. (SPD) EEPROMs on (DIMMs), and. (EDID) for monitors via, and connectors.

System management for PC systems via;. SMBus pins are allocated in both and connectors. Accessing and chips that keep user settings. Accessing low-speed. Changing contrast, hue, and color balance settings in monitors (via ).

Changing sound volume in intelligent speakers. Controlling small (e.g. ) or displays. Reading hardware monitors and diagnostic sensors, e.g. A fan's speed. Turning on and turning off the power supply of system components. A particular strength of I²C is the capability of a to control a network of device chips with just two pins and software.

Many other bus technologies used in similar applications, such as (SPI), require more pins and signals to connect multiple devices. Revisions The history of I²C specification releases:. In 1982, the original 100 kHz I²C system was created as a simple internal bus system for building control electronics with various Philips chips. In 1992, Version 1 added 400 kHz Fast-mode (Fm) and a 10-bit addressing mode to increase capacity to 1008 nodes. This was the first standardized version. In 1998, Version 2 added 3.4 MHz High-speed mode (Hs) with power-saving requirements for electric voltage and current.

In 2000, Version 2.1 clarified version 2, without significant functional changes. In 2007, Version 3 added 1 MHz Fast-mode plus (Fm+) (using 20 mA drivers), and a device ID mechanism. In 2012, Version 4 added 5 MHz Ultra Fast-mode (UFm) for new USDA (data) and USCL (clock) lines using logic without, and added an assigned manufacturer ID table. It is only a bus. In 2012, Version 5 corrected mistakes. In 2014, Version 6 corrected two graphs. This is the most recent standard.

An example schematic with one master (a ), three slave nodes (an, a, and a microcontroller), and R p I²C uses only two bidirectional or lines, Serial Data Line (SDA) and Serial Clock Line (SCL), with. Typical voltages used are +5 V or +3.3 V, although systems with other voltages are permitted. The I²C has a 7-bit, with a rarely-used 10-bit extension. Common I²C bus speeds are the 100 standard mode and the 400 kbit/s Fast mode. There is also a 10 kbit/s low-speed mode, but arbitrarily low clock frequencies are also allowed. Recent revisions of I²C can host more nodes and run at faster speeds (400 kbit/s Fast mode, 1 Mbit/s Fast mode plus or Fm+, and 3.4 High Speed mode).

These speeds are more widely used on embedded systems than on PCs. Note the bit rates are quoted for the transfers between master and slave without clock stretching or other hardware overhead.

Protocol overheads include a slave address and perhaps a register address within the slave device, as well as per-byte ACK/NACK bits. Thus the actual transfer rate of user data is lower than those peak bit rates alone would imply.

For example, if each interaction with a slave inefficiently allows only 1 byte of data to be transferred, the data rate will be less than half the peak bit rate. The number of nodes which can exist on a given I²C bus is limited by the address space and also by the total bus of 400, which restricts practical communication distances to a few meters. The relatively high impedance and low noise immunity requires a common ground potential, which again restricts practical use to communication within the same PC board or small system of boards. Reference design The aforementioned reference design is a bus with a (SCL) and data (SDA) lines with 7-bit addressing. The bus has two roles for nodes: master and slave:. Master node – node that generates the clock and initiates communication with slaves. Slave node – node that receives the clock and responds when addressed by the master.

The bus is a, which means that any number of master nodes can be present. Additionally, master and slave roles may be changed between messages (after a STOP is sent). There may be four potential modes of operation for a given bus device, although most devices only use a single role and its two modes:. master – master node is sending data to a slave,.

Usb tools for mac

Audio Tools For Mac

Usb Tools For Mac

master receive – master node is receiving data from a slave,. slave transmit – slave node is sending data to the master,. slave receive – slave node is receiving data from the master. In addition to 0 and 1 data bits, the I²C bus allows special START and STOP signals which act as message delimiters and are distinct from the data bits. (This is in contrast to the and used in, which are distinguished from data bits only by their timing.) The master is initially in master transmit mode by sending a START followed by the 7-bit address of the slave it wishes to communicate with, which is finally followed by a single bit representing whether it wishes to write (0) to or read (1) from the slave. If the slave exists on the bus then it will respond with an bit (active low for acknowledged) for that address.

The master then continues in either transmit or receive mode (according to the read/write bit it sent), and the slave continues in the complementary mode (receive or transmit, respectively). The address and the data bytes are sent first.

The start bit is indicated by a high-to-low transition of SDA with SCL high; the stop bit is indicated by a low-to-high transition of SDA with SCL high. All other transitions of SDA take place with SCL low.

If the master wishes to write to the slave, then it repeatedly sends a byte with the slave sending an ACK bit. (In this situation, the master is in master transmit mode, and the slave is in slave receive mode.) If the master wishes to read from the slave, then it repeatedly receives a byte from the slave, the master sending an ACK bit after every byte except the last one.

Mac

(In this situation, the master is in master receive mode, and the slave is in slave transmit mode.) An I²C transaction may consist of multiple messages. The master terminates a message with a STOP condition if this is the end of the transaction or it may send another START condition to retain control of the bus for another message (a 'combined format' transaction). Message protocols I²C defines basic types of transactions, each of which begins with a START and ends with a STOP:. Single message where a master writes data to a slave. Single message where a master reads data from a slave. Combined format, where a master issues at least two reads or writes to one or more slaves.

In a combined transaction, each read or write begins with a START and the slave address. The START conditions after the first are also called repeated START bits. Repeated STARTs are not preceded by STOP conditions, which is how slaves know that the next message is part of the same transaction. Any given slave will only respond to certain messages, as specified in its product documentation.

Pure I²C systems support arbitrary message structures. Is restricted to nine of those structures, such as read word N and write word N, involving a single slave. Extends SMBus with a Group protocol, allowing multiple such SMBus transactions to be sent in one combined message.

The terminating STOP indicates when those grouped actions should take effect. For example, one PMBus operation might reconfigure three power supplies (using three different I²C slave addresses), and their new configurations would take effect at the same time: when they receive that STOP.

With only a few exceptions, neither I²C nor SMBus define message semantics, such as the meaning of data bytes in messages. Message semantics are otherwise product-specific. Those exceptions include messages addressed to the I²C general call address (0x00) or to the SMBus Alert Response Address; and messages involved in the SMBus Address Resolution Protocol (ARP) for dynamic address allocation and management. In practice, most slaves adopt request-response control models, where one or more bytes following a write command are treated as a command or address. Those bytes determine how subsequent written bytes are treated or how the slave responds on subsequent reads.

Most SMBus operations involve single-byte commands. Messaging example: 24C32 EEPROM One specific example is the 24C32 type, which uses two request bytes that are called Address High and Address Low.

(Accordingly, these EEPROMs are not usable by pure SMBus hosts, which only support single-byte commands or addresses.) These bytes are used for addressing bytes within the 32 (or 4 ) EEPROM address space. The same two-byte addressing is also used by larger EEPROMs, like the 24C512 which stores 512 kbits (or 64 kB). Writing and reading data to these EEPROMs uses a simple protocol: the address is written, and then data is transferred until the end of the message. The data transfer part protocol can cause trouble on the SMBus, since the data bytes are not preceded by a count, and more than 32 bytes can be transferred at once. I²C EEPROMs smaller than 32 kbit, like the 2 kbit 24C02, are often used on the SMBus with inefficient single-byte data transfers to overcome this problem. A single message writes to the EEPROM.

After the START, the master sends the chip's bus address with the direction bit clear ( write), then sends the two-byte address of data within the EEPROM and then sends data bytes to be written starting at that address, followed by a STOP. When writing multiple bytes, all the bytes must be in the same 32-byte page. While it is busy saving those bytes to memory, the EEPROM will not respond to further I²C requests. (That is another incompatibility with SMBus: SMBus devices must always respond to their bus addresses.) To read starting at a particular address in the EEPROM, a combined message is used. After a START, the master first writes that chip's bus address with the direction bit clear ( write) and then the two bytes of EEPROM data address. It then sends a (repeated) START and the EEPROM's bus address with the direction bit set ( read). The EEPROM will then respond with the data bytes beginning at the specified EEPROM data address — a combined message: first a write, then a read.

The master issues an ACK after each read byte except the last byte, and then issues a STOP. The EEPROM increments the address after each data byte transferred; multi-byte reads can retrieve the entire contents of the EEPROM using one combined message. Physical layer At the, both SCL and SDA lines are of design, thus are needed.

A logic '0' is output by pulling the line to ground, and a logic '1' is output by letting the line float (output ) so that the pull-up resistor pulls it high. A line is never actively driven high. This wiring allows multiple nodes to connect to the bus without short circuits from signal contention. High-speed systems (and some others) may use a instead of a resistor to pull-up on SCL or both SCL and SDA, to accommodate higher bus capacitance and enable faster rise times. An important consequence of this is that multiple nodes may be driving the lines simultaneously.

If any node is driving the line low, it will be low. Nodes that are trying to transmit a logical one (i.e. Letting the line float high) can detect this and conclude that another node is active at the same time. When used on SCL, this is called clock stretching and used as a flow-control mechanism for slaves. When used on SDA, this is called and ensures that there is only one transmitter at a time. When idle, both lines are high. To start a transaction, SDA is pulled low while SCL remains high.

It is illegal: 14 to transmit a stop marker by releasing SDA to float high again (although such a 'void message' is usually harmless), so the next step is to pull SCL low. Except for the start and stop signals, the SDA line only changes while the clock is low; transmitting a data bit consists of pulsing the clock line high while holding the data line steady at the desired level.

While SCL is low, the transmitter (initially the master) sets SDA to the desired value and (after a small delay to let the value propagate) lets SCL float high. The master then waits for SCL to actually go high; this will be delayed by the finite rise time of the SCL signal (the of the and the of the bus) and may be additionally delayed by a slave's clock stretching.

Once SCL is high, the master waits a minimum time (4 μs for standard-speed I²C) to ensure that the receiver has seen the bit, then pulls it low again. This completes transmission of one bit. After every 8 data bits in one direction, an 'acknowledge' bit is transmitted in the other direction. The transmitter and receiver switch roles for one bit, and the original receiver transmits a single '0' bit (ACK) back.

If the transmitter sees a '1' bit (NACK) instead, it learns that:. (If master transmitting to slave) The slave is unable to accept the data. No such slave, command not understood, or unable to accept any more data. (If slave transmitting to master) The master wishes the transfer to stop after this data byte. Only the SDA line changes direction during acknowledge bits; the SCL is always controlled by the master. After the acknowledge bit, the clock line is low and the master may do one of three things:. Begin transferring another byte of data: the transmitter sets SDA, and the master pulses SCL high.

Send a 'Stop': Set SDA low, let SCL go high, then let SDA go high. This releases the I²C bus. Send a 'Repeated start': Set SDA high, let SCL go high, then pull SDA low again. This starts a new I²C bus message without releasing the bus. Clock stretching using SCL One of the more significant features of the I²C protocol is clock stretching.

An addressed slave device may hold the clock line (SCL) low after receiving (or sending) a byte, indicating that it is not yet ready to process more data. The master that is communicating with the slave may not finish the transmission of the current bit, but must wait until the clock line actually goes high. If the slave is clock-stretching, the clock line will still be low (because the connections are ). The same is true if a second, slower, master tries to drive the clock at the same time. (If there is more than one master, all but one of them will normally lose arbitration.) The master must wait until it observes the clock line going high, and an additional minimal time (4 μs for standard 100 kbit/s I²C) before pulling the clock low again. Although the master may also hold the SCL line low for as long as it desires (this is not allowed in newest Rev. 6 of the protocol – subsection 3.1.1), the term 'clock stretching' is normally used only when slaves do it.

Although in theory any clock pulse may be stretched, generally it is the intervals before or after the acknowledgment bit which are used. For example, if the slave is a, its I²C interface could stretch the clock after each byte, until the software decides whether to send a positive acknowledgment or a NACK. Clock stretching is the only time in I²C where the slave drives SCL. Many slaves do not need to clock stretch and thus treat SCL as strictly an input with no circuitry to drive it. Some masters, such as those found inside custom may not support clock stretching; often these devices will be labeled as a 'two-wire interface' and not I²C. To ensure a minimal bus, places limits on how far clocks may be stretched. Hosts and slaves adhering to those limits cannot block access to the bus for more than a short time, which is not a guarantee made by pure I²C systems.

Arbitration using SDA Every master monitors the bus for start and stop bits and does not start a message while another master is keeping the bus busy. However, two masters may start transmission at about the same time; in this case, arbitration occurs. Slave transmit mode can also be arbitrated, when a master addresses multiple slaves, but this is less common. In contrast to protocols (such as ) that use random back-off delays before issuing a retry, I²C has a deterministic arbitration policy.

Each transmitter checks the level of the data line (SDA) and compares it with the levels it expects; if they do not match, that transmitter has lost arbitration and drops out of this protocol interaction. If one transmitter sets SDA to 1 (not driving a signal) and a second transmitter sets it to 0 (pull to ground), the result is that the line is low. The first transmitter then observes that the level of the line is different from that expected and concludes that another node is transmitting. The first node to notice such a difference is the one that loses arbitration: it stops driving SDA. If it is a master, it also stops driving SCL and waits for a STOP; then it may try to reissue its entire message. In the meantime, the other node has not noticed any difference between the expected and actual levels on SDA and therefore continues transmission.

It can do so without problems because so far the signal has been exactly as it expected; no other transmitter has disturbed its message. If the two masters are sending a message to two different slaves, the one sending the lower slave address always 'wins' arbitration in the address stage. Since the two masters may send messages to the same slave address, and addresses sometimes refer to multiple slaves, arbitration must continue into the data stages.

Arbitration occurs very rarely, but is necessary for proper multi-master support. As with clock stretching, not all devices support arbitration. Those that do, generally label themselves as supporting 'multi-master' communication. One case which must be handled carefully in multi-master I²C implementations is that of the masters talking to each other. One master may lose arbitration to an incoming message, and must change its role from master to slave in time to acknowledge its own address.

In the extremely rare case that two masters simultaneously send identical messages, both will regard the communication as successful, but the slave will only see one message. For this reason, when a slave can be accessed by multiple masters, every command recognized by the slave either must be or must be guaranteed never to be issued by two masters at the same time.

(For example, a command which is issued by only one master need not be idempotent, nor is it necessary for a specific command to be idempotent when some mutual exclusion mechanism ensures that only one master can be caused to issue that command at any given time.) Arbitration in SMBus While I²C only arbitrates between masters, uses arbitration in three additional contexts, where multiple slaves respond to the master, and one gets its message through. Although conceptually a single-master bus, a slave device that supports the 'host notify protocol' acts as a master to perform the notification.

It seizes the bus and writes a 3-byte message to the reserved 'SMBus Host' address (0x08), passing its address and two bytes of data. When two slaves try to notify the host at the same time, one of them will lose arbitration and need to retry. An alternative slave notification system uses the separate SMBALERT# signal to request attention. In this case, the host performs a 1-byte read from the reserved 'SMBus Alert Response Address' (0x0C), which is a kind of broadcast address. All alerting slaves respond with a data bytes containing their own address. When the slave successfully transmits its own address (winning arbitration against others) it stops raising that interrupt. In both this and the preceding case, arbitration ensures that one slave's message will be received, and the others will know they must retry.

SMBus also supports an 'address resolution protocol', wherein devices return a 16-byte 'universal device ID'. Multiple devices may respond; the one with the lowest UDID will win arbitration and be recognized. Arbitration in PMBus version 1.3 extends the SMBus alert response protocol in its 'zone read' protocol. Slaves may be grouped into 'zones', and all slaves in a zone may be addressed to respond, with their responses masked (omitting unwanted information), inverted (so wanted information is sent as 0 bits, which win arbitration), or reordered (so the most significant information is sent first). Arbitration ensures that the highest priority response is the one first returned to the master. PMBus reserves I²C addresses 0x28 and 0x37 for zone reads and writes, respectively. Differences between modes There are several possible operating modes for I²C communication.

All are compatible in that the 100 kbit/s standard mode may always be used, but combining devices of different capabilities on the same bus can cause issues, as follows:. Fast mode is highly compatible and simply tightens several of the timing parameters to achieve 400 kbit/s speed. Fast mode is widely supported by I²C slave devices, so a master may use it as long as it knows that the bus capacitance and pull-up strength allow it. Fast mode plus achieves up to 1 Mbit/s using more powerful (20 mA) drivers and pull-ups to achieve faster rise and fall times. Compatibility with standard and fast mode devices (with 3 mA pull-down capability) can be achieved if there is some way to reduce the strength of the pull-ups when talking to them. High speed mode (3.4 Mbit/s) is compatible with normal I²C devices on the same bus, but requires the master have an active pull-up on the clock line which is enabled during high speed transfers. The first data bit is transferred with a normal open-drain rising clock edge, which may be stretched.

For the remaining seven data bits, and the ACK, the master drives the clock high at the appropriate time and the slave may not stretch it. All high-speed transfers are preceded by a single-byte 'master code' at fast/standard speed. This code serves three purposes:.

it tells high-speed slave devices to change to high-speed timing rules,. it ensures that fast/normal speed devices will not try to participate in the transfer (because it does not match their address), and. because it identifies the master (there are eight master codes, and each master must use a different one), it ensures that arbitration is complete before the high-speed portion of the transfer, and so the high-speed portion need not make allowances for that ability. Ultra-Fast mode is essentially a write-only I²C subset, which is incompatible with other modes except in that it is easy to add support for it to an existing I²C interface hardware design. Only one master is permitted, and it actively drives both clock and data lines at all times to achieve a 5 Mbit/s transfer rate. Clock stretching, arbitration, read transfers, and acknowledgements are all omitted. It is mainly intended for animated where a transmission error would only cause an inconsequential brief visual.

The resemblance to other I²C bus modes is limited to:. the start and stop conditions are used to delimit transfers,. I²C addressing allows multiple slave devices to share the bus without style slave select signals, and. a ninth clock pulse is sent per byte transmitted marking the position of the unused acknowledgement bits. In all modes, the clock frequency is controlled by the master(s), and a longer-than-normal bus may be operated at a slower-than-nominal speed. Circuit interconnections I²C is popular for interfacing peripheral circuits to prototyping systems, such as the.

I²C does not employ a standardized connector, however, and board designers have created various wiring schemes for I²C interconnections. To minimize the possible damage due to plugging 0.1-inch headers in backwards, some developers have suggested using alternating signal and power connections of the following wiring schemes: (GND, SCL, VCC, SDA) or (VCC, SDA, GND, SCL). The vast majority of applications use I²C in the way it was originally designed - peripheral ICs directly wired to a processor on the same printed circuit board, and therefore over relatively short distances of less than a foot, without a connector. However a few applications use I²C to communicate between two boards, in some cases over a dozen meters apart, using pairs of I²C bus buffers to boost the signal or re-encode it as a differential signal traveling over CAT5 or other cable. Several standard connectors carry I²C signals.

For example, the connector carries I²C; the 10-pin iPack connector carries I²C; the carries I²C; a few people use the 8P8C connectors and CAT5 cable normally used for to instead carry differential-encoded I²C signals or boosted single-ended I²C signals; and every and most and carry data over I²C. Buffering and multiplexing When there are many I²C devices in a system, there can be a need to include bus or to split large bus segments into smaller ones. This can be necessary to keep the capacitance of a bus segment below the allowable value or to allow multiple devices with the same address to be separated by a multiplexer. Many types of multiplexers and buffers exist and all must take into account the fact that I²C lines are specified to be bidirectional. Multiplexers can be implemented with analog switches, which can tie one segment to another. Analog switches maintain the bidirectional nature of the lines but do not isolate the capacitance of one segment from another or provide buffering capability.

Buffers can be used to isolate capacitance on one segment from another and/or allow I²C to be sent over longer cables or traces. Buffers for bi-directional lines such as I²C must use one of several schemes for preventing latch-up.

I²C is open-drain, so buffers must drive a low on one side when they see a low on the other. One method for preventing latch-up is for a buffer to have carefully selected input and output levels such that the output level of its driver is higher than its input threshold, preventing it from triggering itself. For example, a buffer may have an input threshold of 0.4 V for detecting a low, but an output low level of 0.5 V. This method requires that all other devices on the bus have thresholds which are compatible and often means that multiple buffers implementing this scheme cannot be put in series with one another.

Alternatively, other types of buffers exist that implement current amplifiers or keep track of the state (i.e. Which side drove the bus low) to prevent latch-up. The state method typically means that an unintended pulse is created during a hand-off when one side is driving the bus low, then the other drives it low, then the first side releases (this is common during an I²C acknowledgement). Sharing SCL between multiple busses When having a single master, it is possible to have multiple I²C busses share the same SCL line. The packets on each bus are either sent one after the other or at the same time. This is possible, because the communication on each bus can be subdivided in alternating short periods with high SCL followed by short periods with low SCL.

And the clock can be stretched, if one bus needs more time in one state. Advantages are using slaves devices with the same address at the same time and saving connections or a faster throughput by using several data lines at the same time. Line state table These tables show the various atomic states and bit operations that may occur during a I²C message. Data transfer is initiated with a start bit (S) signaled by SDA being pulled low while SCL stays high. SCL is pulled low, and SDA sets the first data bit level while keeping SCL low (during blue bar time). The data are sampled (received) when SCL rises for the first bit (B1). For a bit to be valid, SDA must not change between a rising edge of SCL and the subsequent falling edge (the entire green bar time).

This process repeats, SDA transitioning while SCL is low, and the data being read while SCL is high (B2.Bn). The final bit is followed by a clock pulse, during which SDA is pulled low in preparation for the stop bit. A stop bit (P) is signaled when SCL rises, followed by SDA rising. In order to avoid false marker detection, there is a minimum delay between the SCL falling edge and changing SDA, and between changing SDA and the SCL rising edge. Note that an I²C message containing N data bits (including acknowledges) contains N+1 clock pulses. Example of bit-banging the I²C master protocol Below is an example of the I²C protocol as an I²C master. The example is written in.

It illustrates all of the I²C features described before (clock stretching, arbitration, start/stop bit, ack/nack). (PDF) from the original on 2017-01-10. Retrieved 2018-04-29. Retrieved 2018-04-29. Aegis Power Systems, Inc. Aegis Power Systems, Inc. From the original on 2015-12-21.

Retrieved 2015-12-21. (PDF) from the original on 2013-05-11. From the original on 2013-06-01. Retrieved 2018-04-29. (PDF) (Application Note). Revision 1.0.1.

System Management Interface Forum. (PDF) from the original on 2017-09-22.

(PDF), 2017-08-16, archived from (PDF) on 2017-08-16. Vasquez, Joshua (2017-08-16), archived from on 2017-08-16., 2017-08-19, archived from on 2017-08-19. Ferrari, Mario; Ferrari, Giulio (2018-04-29). Archived from on 2018-04-29. Gasperi, Michael; Hurbain, Philippe (2010), Extreme NXT: Extending the LEGO MINDSTORMS NXT to the Next Level. Philo. 2017-08-20 at the.

Sivan Toledo. 2017-08-12 at the. 2006. 2017-08-18 at the. 2017-08-18 at the. (PDF) (Selection Guide). Archived from (PDF) on 2017-10-16.

Retrieved 2017-10-01. Data Handbook IC12: I2C Peripherals, Philips ordering code 9397 750 00306. (PDF). System Management Interface Forum.

(PDF) from the original on 2016-01-29. Retrieved 2017-12-01. Version 1.1. (PDF) from the original on 2016-09-09.

Retrieved 2017-12-01. Document Revision 1.1. Intel, NEC, Hewlett-Packard & Dell. (PDF) from the original on 2016-03-27. Retrieved 2017-12-01. The 7-bit portion of the slave address for the BMC is 0010000b.

2017-03-29 at the. 2011-07-24 at the. For AmigaOS 4.x. 2017-08-09 at the. Has two pins for address selection, each of which can be tied high or low or left unconnected, offering 9 different addresses. 2017-07-13 at the.

Has a single pin for address selection to be tied high or low or connected to SDA or SCL, offering 4 different addresses. 2017-11-07 at the. Uses two ADC channels discriminating twelve levels each to select any valid 7-bit address. Delvare, Jean (2005-08-16). Linux-kernel (Mailing list).

From the original on 2016-08-17. 2007-05-27 at the. Retrieved 2018-04-29. Thornton, Scott (2017-11-29). Microcontroller Tips. From the original on 2018-02-03.

Further reading. Himpe, Vincent (2011). Mastering the I²C Bus.

(248 pages). Paret, Dominique (1997). The I2C Bus: From Theory to Practice. (314 pages) External links Wikimedia Commons has media related to., NXP.