SNIS133E September   2003  – February 2024 LM95010

PRODUCTION DATA  

  1.   1
  2. 1 Features
  3. 2 Applications
  4. 3 Description
  5. 4 Pin Configuration and Functions
  6. 5 Specifications
    1. 5.1 Absolute Maximum Ratings
    2. 5.2 Operating Ratings
    3. 5.3 DC Electrical Characteristics
    4. 5.4 AC Electrical Characteristics
    5. 5.5 Typical Performance Characteristics
  7. 6 Detailed Description
    1. 6.1 Overview
    2. 6.2 Functional Block Diagram
    3. 6.3 Feature Description
      1. 6.3.1  SensorPath BUS SWD
      2. 6.3.2  SensorPath BIT SIGNALING
      3. 6.3.3  Bus Inactive
      4. 6.3.4  Data Bit 0 and 1
      5. 6.3.5  Start Bit
      6. 6.3.6  Attention Request
      7. 6.3.7  Bus Reset
      8. 6.3.8  SensorPath BUS TRANSACTIONS
      9. 6.3.9  Bus Reset Operation
      10. 6.3.10 Read Transaction
      11. 6.3.11 Write Transaction
      12. 6.3.12 Read and Write Transaction Exceptions
      13. 6.3.13 Attention Request Transaction
  8. 7 Register Set
    1. 7.1  Fixed Number Setting
    2. 7.2  Register Set Summary
    3. 7.3  Device Reset Operation
    4. 7.4  Device Number (Addr 00o)
    5. 7.5  Manufacturer ID (Addr 01o)
    6. 7.6  Device ID (Addr 02o)
    7. 7.7  Capabilities Fixed (Addr 03o)
    8. 7.8  Device Status (Addr 04o)
    9. 7.9  Device Control (Addr 05o)
    10. 7.10 Temperature Measurement Function (TYPE - 0001)
    11. 7.11 Operation
    12. 7.12 Temperature Capabilities (Addr 10o)
    13. 7.13 Temperature Data Readout (Addr 11o)
    14. 7.14 Temperature Control (Addr 12o)
    15. 7.15 Conversion Rate (Addr 40o)
  9. 8 Application and Implementation
    1. 8.1 Application Information
      1. 8.1.1 Mounting Considerations
  10. 9 Device and Documentation Support
    1. 9.1 Documentation Support
    2. 9.2 Receiving Notification of Documentation Updates
    3. 9.3 Support Resources
    4. 9.4 Trademarks
    5. 9.5 Electrostatic Discharge Caution
    6. 9.6 Glossary
  11. 10Revision History
  12. 11Mechanical, Packaging, and Orderable Information

Package Options

Mechanical Data (Package|Pins)
Thermal pad, mechanical data (Package|Pins)
Orderable Information

6.3.13 Attention Request Transaction

Attention Request is generated by the LM95010 when it needs the attention of the master. The master and all LM95010s must monitor the Attention Request to allow bit re-sending in case of simultaneous start with a Data Bit or Start Bit transfer. Refer to Section 6.3.6 of the data sheet.

The LM95010 will generate an Attention Request using the following rules:

  1. A Function event that sets the Status Flag has occurred and Attention Request is enabled and
  2. The "physical" condition for an Attention Request is met (i.e., the bus is inactive), and
  3. At the first time 2 is met after 1 occurred, there has not been an Attention request on the bus since a read of the Device Status register, or since a Bus Reset.

OR

  1. A bus error event occurred, and
  2. the "physical" condition for an Attention Request is met (i.e., the bus is inactive), and
  3. At the first time 2. is met after 1 occurred, there has not been a Bus Reset.

All devices (master or slave) must monitor the bus for an Attention Request signal. The following notes clarify the intended system operation that uses the Attention Request Indication.

  • Masters are expected to use the attention request as a trigger to read results from the LM95010. This is done in a sequence that covers all LM95010s. This sequence is referred to as "master sensor read sequence".
  • After an Attention Request is sent by an LM95010 until after the next read from the Device Status register the LM95010 does not send Attention Requests for a function event since it is ensured that the master will read the Status register as part of the master sensor read sequence. Note that the LM95010 will send an attention for BER, regardless of the Status register read, to help the master with any error recovery operations and prevent deadlocks.
  • A master must record the Attention Request event. It must then scan all slave devices in the system by reading their Device Status register and must handle any pending event in them before it may assume that there are no more events to handle.
Note:

There is no indication of which slave has sent the request. The requirement that multiple requests are not sent allows the master to know within one scan of register reads that there are no more pending events.