WO2020160868A1 - Systemkomponente mit konfigurierbarem kommunikationsverhalten und verfahren zum betreiben einer solchen systemkomponente - Google Patents

Systemkomponente mit konfigurierbarem kommunikationsverhalten und verfahren zum betreiben einer solchen systemkomponente Download PDF

Info

Publication number
WO2020160868A1
WO2020160868A1 PCT/EP2020/050417 EP2020050417W WO2020160868A1 WO 2020160868 A1 WO2020160868 A1 WO 2020160868A1 EP 2020050417 W EP2020050417 W EP 2020050417W WO 2020160868 A1 WO2020160868 A1 WO 2020160868A1
Authority
WO
WIPO (PCT)
Prior art keywords
system component
register
data
bus
communication
Prior art date
Application number
PCT/EP2020/050417
Other languages
English (en)
French (fr)
Inventor
Rainer Dorsch
Dorde Cvejanovic
Original Assignee
Robert Bosch Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch Gmbh filed Critical Robert Bosch Gmbh
Priority to JP2021546252A priority Critical patent/JP7241191B2/ja
Priority to US17/289,526 priority patent/US11556493B2/en
Priority to CN202080013088.4A priority patent/CN113424498B/zh
Priority to KR1020217028461A priority patent/KR20210123386A/ko
Publication of WO2020160868A1 publication Critical patent/WO2020160868A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40169—Flexible bus arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/42—Bus transfer protocol, e.g. handshake; Synchronisation
    • G06F13/4282—Bus transfer protocol, e.g. handshake; Synchronisation on a serial bus, e.g. I2C bus, SPI bus
    • G06F13/4291—Bus transfer protocol, e.g. handshake; Synchronisation on a serial bus, e.g. I2C bus, SPI bus using a clocked protocol
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/36—Handling requests for interconnection or transfer for access to common bus or bus system
    • G06F13/362—Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/40—Bus structure
    • G06F13/4004—Coupling between buses
    • G06F13/4022—Coupling between buses using switching circuits, e.g. switching matrix, connection or expansion network
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/403—Bus networks with centralised control, e.g. polling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2213/00—Indexing scheme relating to interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F2213/0016—Inter-integrated circuit (I2C)
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40208—Bus networks characterized by the use of a particular bus standard

Definitions

  • the present invention relates to a system component with configurable communication behavior and a method for operating such a system component.
  • the present invention relates to systems that include several
  • System components which communicate over a data bus, i. Exchange data via the data bus.
  • a master i. Exchange data via the data bus.
  • system components acts as what is known as a master, in that it
  • System components exchange data between at least two
  • At least one other system component functions as a so-called slave by participating in a data communication that is coordinated by the master.
  • Examples of such systems are sensor systems in consumer electronic applications, such as smartphones, wearables, etc., loT systems,
  • MIPI Alliance is a Mobile Industry Processor Interface Alliance
  • the I3C standard is based on the I2C standard, the de facto most widespread 2-pin serial bus protocol standard for low-speed peripheral devices and sensors.
  • the I3C bus protocol offers some significant features compared to the I2C bus protocol
  • Each system component 1 comprises a first register, a bus characteristic register (BCR) and a device characteristic register (DCR).
  • BCR bus characteristic register
  • DCR device characteristic register
  • System component 1 is a sensor and possibly other sensor-specific ones
  • the Bus Characteristic Register includes defines the role of system component 1, i.e. whether the system component 1 acts as a master or as a slave. Furthermore, the communication behavior of the
  • System component 1 defined. In particular, it is stored in the bus characteristic register whether the system component 1 supports an in-band interrupt (I Bl) function with or without payload.
  • I Bl in-band interrupt
  • the I3C bus protocol provides that the master queries the communication behavior of the slave stored in the bus characteristic register in order to then adapt its own communication behavior accordingly.
  • the master queries the communication behavior of the slave stored in the bus characteristic register in order to then adapt its own communication behavior accordingly.
  • the master queries the communication behavior of the slave stored in the bus characteristic register in order to then adapt its own communication behavior accordingly.
  • the master can support both IBI without payload and IBI with payload.
  • a master that only supports IBI without payload can therefore not communicate with slaves for their
  • Communication behavior IBI is specified with payload.
  • the subject matter of the present invention is a system component with configurable communication behavior according to claim 1 and a method for operating such a system component according to claim 9.
  • the present invention creates a system component with at least one interface for a data bus for communication with at least one further system component.
  • Communication protocol used for sending and receiving data and bus commands. Furthermore, the communication protocol provides that the at least one further system component queries the communication behavior of the system component via the data bus for its own
  • the system component includes a register for configuration data that define the communication behavior of the system component on the data bus.
  • the register of the system component is connected to the data bus so that the configuration data stored in the register are available on the data bus or are made available for further system components via the data bus.
  • the system component is characterized by the fact that the functional scope of the system component is different
  • Communication behavior enables. Furthermore, the communication behavior of the system component can be selected within the scope of the functional scope in that the configuration data corresponding to the selected communication behavior can be loaded into the register.
  • the communication behavior describes the behavior of a
  • System component in relation to other system components that are connected to the same data bus.
  • the communication behavior of a system component according to the invention can be within the scope of its
  • Communication behavior includes the definition of the system component as master or slave.
  • the communication behavior describes whether the system component in the role of a slave provides the IBI function with or without payload.
  • the IBI function with payload means that the master is obliged to read out the payload (data, e.g. measurement data from a sensor).
  • the master is obliged to reserve the data bus for the corresponding slave as long as until it has sent the data.
  • the data are therefore always sent as soon as a slave has received approval for the data bus. This can be disadvantageous in the case of very large data packets, for example with data from a
  • the IBI function without payload means that the slave sends a request to the master that, for example, data is available for transmission via the data bus and the master has control over the start of the data transmission.
  • the present invention also provides a method for operating a system component.
  • the system component is for communication with at least one further system component via at least one
  • a defined communication protocol is used on the data bus for sending and receiving data and bus commands.
  • the communication protocol provides that the at least one further system component queries the communication behavior of the system component via the data bus for its own
  • the system component also includes at least one register for
  • Configuration data The configuration data define that
  • the system component is connected to the data bus, so that the configuration data stored in the register are available on the data bus or are made available for other system components via the data bus.
  • the functionality of the system component enables
  • the method is characterized in that the
  • Communication behavior of the system component is configured by the corresponding to a selected communication behavior
  • Configuration data are loaded into the register.
  • a preferred field of application of the present invention are
  • Sensor components for acquiring and converting measured variables into electrical sensor signals that act as system components of a higher-level system.
  • this can be, for example, a navigation system or a mobile device that evaluates the sensor data for higher-level applications, such as for a pedometer.
  • the idea on which the present invention is based is to design a system component in such a way that its communication behavior can be configured within the scope of its functional scope, so that it alternatively supports IBI with payload or IBI without payload.
  • the system component can thus advantageously be used in any system, regardless of the variant (with or without IBI payload) for which the system was designed by a developer.
  • the functional scope of the system component can advantageously be adapted to the requirements of the system by configuring the bus characteristic register.
  • system component I2C and / or I3C is compatible.
  • This embodiment is advantageous in that the system components can be used both in a system in accordance with the I2C bus protocol or the I3C
  • the I3C bus protocol standard is advantageously downward compatible.
  • the functional scope of the system component according to the invention enables operation alternatively as a master or as a slave.
  • system component can communicate with other system components via the data bus both as a slave and as a master.
  • the scope of functions includes an in-band interrupt capability, alternatively with or without payload.
  • the in-band interrupt capability with payload includes sending the payload, for example sensor data, with the interrupt set by the slave.
  • a master In the case of the in-band interrupt capability without payload, a master must determine in advance how the payload
  • a slave can advantageously be configured for the corresponding application or for the corresponding system and for use in it.
  • At least one internal or external memory device is provided for configuration data, in particular a non-volatile memory.
  • the chosen communication behavior Corresponding configuration data can be loaded into the register from this memory device.
  • This embodiment is advantageous in that, for example, the IBI value (with or without payload) can be read from the memory and loaded into the register in order to adapt the communication behavior of the system component functioning as a slave to the requirements of the master
  • the IBI value in the BCR register of a system component is usually defined in advance by the manufacturer of the system component.
  • the IBI behavior of the system component can be configured by taking an IBI value from an internal or external storage device at the beginning of the initialization of the
  • Communication behavior register s the bus component on the data bus and informs the master how it communicates.
  • the IBI value written in the register remains during the entire operation of the
  • the system component By configuring the register before or after initializing the system component and before or after logging on to the data bus, the system component can be used in any system, regardless of the communication behavior of the master.
  • the communication behavior can be selected on the basis of bus commands and / or data received via the data bus and corresponding configuration data are in the
  • Storage device loadable and loadable from the storage device into the register.
  • a BCR value can advantageously be agreed between a master and a slave using an I3C Custom Command Code (CCC).
  • CCC I3C Custom Command Code
  • custom command codes are available or custom command codes can be defined in the protocol. With these, the value in the register can be changed or adapted according to the requirements of the system.
  • Command code should be predefined and device-specific via a private protocol.
  • a BCR value can be agreed between the master and slave using a private I3C protocol.
  • the private I3C protocol used for this function is either predefined or device-specific. This
  • Embodiment has the advantage that a custom command code does not first have to be defined in consultation with the MIPI Alliance. Rather, a private protocol can be defined internally with which the BCR register can be accessed directly without CCC in order to change the value of the BCR register.
  • the configuration data are loaded into the register each time the system component is switched on, but before the first interrogation of the communication behavior by the further system component.
  • the system component is advantageously initialized to the value stored in the BCR register before the system component is initialized by the master on the data bus.
  • the system component can thus be initialized accordingly for each system and can be used in this.
  • the value of the BCR register is provided with a default value, for example IBI without payload.
  • the system component is used during its
  • Initialization reconfigured accordingly so that it can also be used in the system.
  • the value for IBI with payload is stored in the memory device. This is read out and the value in the BCR register is
  • the configuration data are loaded into the register from an internal or external storage device for configuration data, in particular from a non-volatile memory.
  • the communication behavior is configured on the basis of at least one predefined and / or device-specific bus command and corresponding configuration data are loaded into the register or the storage device.
  • the communication behavior is configured on the basis of at least one predefined and / or device-specific data communication and corresponding configuration data are loaded into the register or the storage device.
  • Fig. 1 is a schematic illustration to explain a
  • FIG. 2 shows a schematic illustration to explain an I3C bus system
  • 3 shows a schematic illustration to explain the in-band interrupt capability with payload
  • 4 shows a schematic illustration to explain the in-band interrupt capability without payload
  • Fig. 5 is a schematic illustration to explain a
  • FIG. 6 is a schematic illustration to explain a
  • Fig. 1 is a schematic diagram for explaining a
  • reference numeral 1 designates a system component comprising an interface 5.
  • the system component 1 is connected to the data bus 3 (not shown) via the interface 5.
  • the data bus 3 comprises a serial clock line 6 and a serial data line 7. Furthermore, the
  • System component 1 a processor unit 8, a register 4 and a
  • the storage device 11 is designed
  • the storage device 11 is formed in Fig. 1 as an internal storage device, i. it is part of the
  • the configuration data can, however, also be loaded into the register 4 from an external storage device, for example a non-volatile memory, an electrical switch, an electrically conductive pin.
  • the external storage device is not limited to the examples given here.
  • further versions of devices can be used which are designed to store data and to load them into the register 4.
  • the register 4, in particular the BCR register receives from the Storage device 11 stores a value prior to the initialization of system component 1.
  • the communication behavior of system component 1 is configured via this value.
  • the I Bl function is configured with or without a payload and thus how the system component 1 communicates via the data bus 3.
  • the processor unit 8 is configured to form a CCC machine 9 and a CCC I3C core 10.
  • the CCC machine 9 and the CCC I3C core 10 can also be on two separate ones
  • the CCC machine 9 is part of the slave in the I3C protocol and is used for normal reading and writing of data.
  • the CCC machine 9 provides direct access to the data. Further communication with the slave according to the I3C bus protocol can take place via custom command codes CCC.
  • custom command codes for example, the PowerModi and the data protocol can be changed to "single data rate” and "double data rate”.
  • the CCC I3C core 10 receives the custom command codes via the interface 5 and decodes them and accordingly implements the instructions or reacts to them.
  • An exemplary custom command code sent by the master of the data bus 3 is the reading of the BCR register of the system component 1 while the system component 1 is logged on to the data bus 3.
  • the system component 1 receives the CCC and the CCC I3C core 10 decodes the received command and gives corresponding instructions to the CCC machine 9, which reads out the register 4.
  • Register 4 is transmitted via the interface 5 of the system component 1 via the data bus 3 to the further system component 2, for example in the function of a master.
  • Fig. 2 is a schematic illustration to explain an I3C bus system.
  • the I3C bus system 10 comprises a system component 1 which is connected to further via a data bus 3
  • System components 2 is connected for communication.
  • System component 1 can be a slave or a Master's degree. If the system component 1 functions as a slave, then one of the further components 2 is designed as a master.
  • 3 is a schematic illustration to explain the in-band interrupt capability with payload.
  • the in-band interrupt 12 is a possibility for the system component 1 functioning as a slave to inform the master via the data bus 3 that communication is to be established between the master and the slave.
  • the slave has no way of starting communication or sending data via the bus without receiving a clock from the master.
  • the slave can inform the master that, for example, data is available that is to be sent via the data bus 3.
  • the master reacts to the IBI according to a prioritization and controls the communication of the slave by sending the master to the corresponding clocks
  • a start bit “Start (S)” is sent from the master to system component 1 via data bus 3.
  • the IBI slave sends its address to the master via the bus when the master provides a clock.
  • the master With the "Master_ACK”, the master signals to the slave that it has recognized that a slave wants to access the bus.
  • the in-band interrupt 12 is designed with a payload. The master is therefore obliged to provide the slave with further clocks for at least one byte and to send data via the data bus 3 as long as the slave is providing data.
  • the data bus 3 is only released again after the communication has been completed.
  • FIG. 4 is a schematic illustration to explain the in-band interrupt capability without payload.
  • the master can decide which one after sending the "Master_ACK" Function is to be performed. For example, the master can start reading the data from the slave or establish communication with another slave, since this slave may have a higher priority. The master is not bound to the slave's request.
  • Fig. 5 is a schematic diagram for explaining a
  • reference numeral 1 designates a system component comprising an interface 5.
  • the system component 1 is connected to the data bus 3 (not shown) via the interface 5.
  • the data bus 3 comprises a serial clock line 6 and a serial data line 7. Furthermore, the
  • System component 1 a processor unit 8 and a register 4.
  • Processor unit 8 is configured to form a CCC machine 9 and a CCC I3C core 10.
  • the CCC machine 9 and the I3C core 10 can also be formed on two separate processor units.
  • the CCC machine 9 is part of the slave in the I3C protocol and is used for normal reading and writing of data.
  • the CCC machine 9 provides direct access to the data. Another
  • Custom command codes for example, the PowerModi
  • the data protocol for example, can be changed to “single data rate” and “double data rate”.
  • the CCC I3C core 10 receives the custom command codes via the interface 5 and decodes them and accordingly implements the instructions or reacts to them.
  • An exemplary custom command code sent by the master of the data bus 3 is the reading of the BCR register of the system component 1 during the registration of the bus component on the data bus 3.
  • the system component 1 receives the CCC and the CCC I3C core 10 decodes the received command and issues the appropriate Instruction to the CCC machine 9, which reads out register 4.
  • the read out value of the register 4 is transmitted via the interface 5 of the System component 1 via the data bus 3 to the further system component 2, for example in the function of a master.
  • the value of register 4 is changed via a received custom command code (CCC) and thus the communication behavior of system component 1.
  • CCC custom command code
  • Device-specific CCCs are provided in the I3C bus protocol that can be used for this purpose. With these the values of the BCR register 4 can be configured. Furthermore, new CCC can be defined and the I3C bus protocol can be expanded. With the newly defined CCC, the values of the BCR register 4 can be configured.
  • the I3C CCC core 10 has a connection to the register 4.
  • the register 4 is not configured using the custom command codes of the I3C bus protocol.
  • write and read requests are provided via the direct connection of the I3C CCC core 10 to the register 4.
  • the communication between the master and the slave is defined in a private protocol that is executed on the I3C CCC core 10.
  • the master can thus write to the BCR register 4 and read from it.
  • the address of register 4 and commands for reading and writing register 4 are defined in the private protocol.
  • Fig. 7 a combination of the variants of Figures 1, 4 and 5 is shown.
  • the system component 1 shown in FIG. 7 comprises a
  • Storage device 11 via which the register 4 can be configured. Besides, that is Register 4 can be configured using custom command codes and a private protocol.
  • the memory device 11 also has a connection to the processor 8. Via this connection, the value stored in the storage device 11 can be configured and loaded using custom command codes and a private protocol.
  • the memory device 11 is designed to provide the register 4 with corresponding configuration data for the configuration of the functional scope of the system component 1.

Abstract

Die vorliegende Erfindung schafft eine Systemkomponente mit konfigurierbarem Kommunikationsverhalten und ein Verfahren zum Betreiben einer solchen Systemkomponente. Die Systemkomponente (1) umfasst mindestens eine Schnittstelle (5) für einen Datenbus (3) zur Kommunikation mit mindestens einer weiteren Systemkomponente (2). Auf dem Datenbus (3) wird ein definiertes Kommunikationsprotokoll für das Senden und Empfangen von Daten und Busbefehlen verwendet. Das Kommunikationsprotokoll sieht vor, dass die mindestens eine weitere Systemkomponente (2) das Kommunikationsverhalten der Systemkomponente (1) über den Datenbus (3) abfragt, um ihr eigenes Kommunikationsverhalten an das der Systemkomponente (1) anzupassen. Zudem umfasst die Systemkomponente (1) ein Register (4) für Konfigurationsdaten, die das Kommunikationsverhalten der Systemkomponente (1) auf dem Datenbus (3) definieren, wobei das Register (4) mit dem Datenbus (3) verbunden ist, so dass die im Register (4) abgespeicherten Konfigurationsdaten auf dem Datenbus (3) zur Verfügung stehen. Der Funktionsumfang der Systemkomponente (1) ermöglicht unterschiedliche Kommunikationsverhalten und das Kommunikationsverhalten der Systemkomponente (1) ist im Rahmen des Funktionsumfangs auswählbar, indem jeweils die dem ausgewählten Kommunikationsverhalten entsprechenden Konfigurationsdaten in das Register (4) ladbar sind.

Description

Systemkomponente mit konfigurierbarem Kommunikationsverhalten und
Verfahren zum Betreiben einer solchen Systemkomponente
Die vorliegende Erfindung betrifft eine Systemkomponente mit konfigurierbarem Kommunikationsverhalten und ein Verfahren zum Betreiben einer solchen Systemkomponente.
Die vorliegende Erfindung bezieht sich auf Systeme, die mehrere
Systemkomponenten umfassen, welche über einen Datenbus kommunizieren, d.h. Daten über den Datenbus austauschen. In der Regel fungiert mindestens eine der Systemkomponenten als sogenannter Master, indem diese
Systemkomponente den Datenaustausch zwischen mindestens zwei
Systemkomponenten koordiniert. Mindestens eine andere Systemkomponente fungiert als sogenannter Slave, indem sie an einer Datenkommunikation teilnimmt, die durch den Master koordiniert ist.
Beispiele für derartige Systeme sind Sensorsysteme in Consumer electronic- Anwendungen, wie Smartphones, Wearables, etc., loT-Systeme,
Navigationssysteme und auch Sensorsysteme in Kfz-Anwendungen.
Stand der Technik
Unter der Mobile Industry Processor Interface Allicance, kurz MIPI Alliance wurde eine neue Schnittstelle I3C entwickelt. Die MIPI Alliance ist ein
Unternehmensverband mit dem Ziel, Hard- und Softwareschnittstellen zwischen einem Chipsatz und peripheren Baugruppen, wie beispielsweise Sensoren und Displays zu entwickeln und zu propagieren. Der I3C Standard baut auf dem I2C Standard auf, der de facto am weitesten verbreitete 2- Pin serielle Busprotokoll- Standard für Niedriggeschwindigkeit Peripheriegeräte und Sensoren. Das I3C Busprotokoll bietet im Vergleich zum I2C Busprotokoll einige signifikante
Verbesserungen, wie beispielsweise dynamisches Aushandeln von
Busadressen, höhere Datenraten, vereinfachte elektrische Anforderungen an den Master und Slave, In-Band-Interrupts, Hot-Join Mechanismus. In der Fig. 2 ist ein I3C Bus System 10 dargestellt. Jede Systemkomponente 1 umfasst ein erstes Register, Bus Characteristic Register (BCR) und ein Device Characteristic Register (DCR). In dem Device Characteristic Register ist die Art der Systemkomponente 1 beschrieben, beispielsweise dass die
Systemkomponente 1 ein Sensor ist und ggf. weitere sensorspezifische
Informationen. In dem Bus Characteristic Register sind u.a. die Rolle der Systemkomponente 1 definiert, d.h. ob die Systemkomponente 1 als Master oder als Slave fungiert. Ferner ist das Kommunikationsverhalten der
Systemkomponente 1 definiert. Insbesondere ist in dem Bus Characteristic Register hinterlegt, ob die Systemkomponente 1 eine In-Band-Interrupt (I Bl) - Funktion mit Payload oder ohne Payload unterstützt.
Bei konventionellen I3C Systemkomponenten (Slave und/oder Master) ist das Kommunikationsverhalten im Voraus definiert und entsprechend im Bus
Characteristic Register hinterlegt.
Das I3C Busprotokoll sieht vor, dass der Master das im Bus Characteristic Register hinterlegte Kommunikationsverhalten des Slaves abfragt, um dann sein eigenes Kommunikationsverhalten entsprechend anzupassen. Im Fall der IBI- Funktion ist dies aber nur möglich, wenn der Master sowohl IBI ohne Payload als auch IBI mit Payload unterstützen kann. Ein Master, der nur IBI ohne Payload unterstützt, kann demnach nicht mit Slaves kommunizieren, für deren
Kommunikationsverhalten IBI mit Payload festgelegt ist.
Die Verwendung des I3C Busprotokolls zur Kommunikation zwischen
Systemkomponenten ist beispielsweise aus der WO 2017 155897 Al bekannt.
Offenbarung der Erfindung
Gegenstand der vorliegenden Erfindung ist eine Systemkomponente mit konfigurierbarem Kommunikationsverhalten nach Anspruch 1 und ein Verfahren zum Bertreiben einer solchen Systemkomponente nach Anspruch 9. Die vorliegende Erfindung schafft eine Systemkomponente mit mindestens einer Schnittstelle für einen Datenbus zur Kommunikation mit mindestens einer weiteren Systemkomponente. Auf dem Datenbus wird ein definiertes
Kommunikationsprotokoll für das Senden und Empfangen von Daten und Busbefehlen verwendet. Ferner sieht das Kommunikationsprotokoll vor, dass die mindestens eine weitere Systemkomponente das Kommunikationsverhalten der Systemkomponente über den Datenbus abfragt, um ihr eigenes
Kommunikationsverhalten an das der Systemkomponente anzupassen. Zudem umfasst die Systemkomponente ein Register für Konfigurationsdaten, die das Kommunikationsverhalten der Systemkomponente auf dem Datenbus definieren. Das Register der Systemkomponente ist mit dem Datenbus verbunden, so dass die im Register abgespeicherten Konfigurationsdaten auf dem Datenbus zur Verfügung stehen, bzw. für weitere Systemkomponenten über den Datenbus zur Verfügung gestellt werden. Die Systemkomponente ist gekennzeichnet dadurch, dass der Funktionsumfang der Systemkomponente unterschiedliche
Kommunikationsverhalten ermöglicht. Ferner ist das Kommunikationsverhalten der Systemkomponente im Rahmen des Funktionsumfangs auswählbar, indem jeweils die dem ausgewählten Kommunikationsverhalten entsprechenden Konfigurationsdaten in das Register ladbar sind.
Das Kommunikationsverhalten beschreibt das Verhalten einer
Systemkomponente in Bezug auf andere Systemkomponenten, die mit dem gleichen Datenbus in Verbindung stehen. Das Kommunikationsverhalten einer erfindungsgemäßen Systemkomponente kann im Rahmen ihres
Funktionsumfangs geändert bzw. angepasst werden. Das
Kommunikationsverhalten umfasst die Definition der Systemkomponente als Master oder Slave. Zudem beschreibt das Kommunikationsverhalten, ob die Systemkomponente in der Rolle eines Slaves die IBI Funktion mit Payload oder ohne Payload zur Verfügung stellt.
Die IBI Funktion mit Payload besagt, dass der Master verpflichtet ist den Payload (Daten, beispielsweise Messdaten eines Sensors) auszulesen. Der Master ist verpflichtet den Datenbus für den entsprechenden Slave so lange zu reservieren, bis dieser die Daten gesendet hat. Die Daten werden somit, sobald ein Slave Freigabe zum Datenbus erhalten hat, immer mitgeschickt. Dies kann nachteilig bei sehr großen Datenpaketen sein, beispielsweise bei Daten eines
Touchdisplays, da der Datenbus für die Zeit der Datenübertragung von keiner anderen Systemkomponente genutzt werden kann.
Die IBI Funktion ohne Payload besagt, dass der Slave einen Request an den Master sendet, dass beispielsweise Daten zur Übertragung über den Datenbus bereitstehen und der Master die Kontrolle über den Beginn der Datenübertragung hat.
Weiterhin schafft die vorliegende Erfindung ein Verfahren zum Betreiben einer Systemkomponente. Die Systemkomponente ist zur Kommunikation mit mindestens einer weiteren Systemkomponente über mindestens eine
Schnittstelle mit einem Datenbus verbunden. Auf dem Datenbus wird ein definiertes Kommunikationsprotokoll für das Senden und Empfangen von Daten und Busbefehlen verwendet. Das Kommunikationsprotokoll sieht vor, dass die mindestens eine weitere Systemkomponente das Kommunikationsverhalten der Systemkomponente über den Datenbus abfragt, um ihr eigenes
Kommunikationsverhalten an das der Systemkomponente anzupassen. Ferner umfasst die Systemkomponente mindestens ein Register für
Konfigurationsdaten. Die Konfigurationsdaten definieren das
Kommunikationsverhalten der Systemkomponente. Das Register der
Systemkomponente ist mit dem Datenbus verbunden, so dass die im Register abgespeicherten Konfigurationsdaten auf dem Datenbus zur Verfügung stehen, bzw. für weitere Systemkomponenten über den Datenbus zur Verfügung gestellt werden. Der Funktionsumfang der Systemkomponente ermöglicht
unterschiedliche Kommunikationsverhalten der Systemkomponente auf dem Datenbus. Das Verfahren ist dadurch gekennzeichnet, dass das
Kommunikationsverhalten der Systemkomponente konfiguriert wird, indem die einem ausgewählten Kommunikationsverhalten entsprechenden
Konfigurationsdaten in das Register geladen werden. Ein bevorzugtes Einsatzgebiet der vorliegenden Erfindung sind
Sensorkomponenten zum Erfassen und Umwandeln von Messgrößen in elektrische Sensorsignale, die als Systemkomponente eines übergeordneten Systems fungieren. Dabei kann es sich - je nach Art der Sensoren - beispielsweise um eine Navigationssystem handeln oder ein mobiles Gerät, das die Sensordaten für übergeordnete Anwendungen auswertet, wie z.B. für einen Schrittzähler.
Vorteile der Erfindung
Die der vorliegenden Erfindung zugrunde liegende Idee besteht darin, eine Systemkomponente derart auszubilden, dass deren Kommunikationsverhalten im Rahmen ihres Funktionsumfangs konfigurierbar ist, so dass diese beispielsweise alternativ IBI mit Payload oder IBI ohne Payload unterstützt. In vorteilhafter Weise ist die Systemkomponente somit in jedem System verwendbar, unabhängig davon, für welche Variante (mit oder ohne IBI Payload) das System von einem Entwickler ausgelegt wurde.
In vorteilhafter Weise kann der Funktionsumfang der Systemkomponente durch das Konfigurieren des Bus Characteristic Registers an die Anforderungen des Systems angepasst werden.
In vorteilhafter Weise müssen somit nicht zwei Systemkomponenten mit dem gleichen Einsatzspektrum für die Verwendung in einem IBI mit Payload oder ohne Payload ausgelegten System von einem Hersteller bereitgestellt werden. Die Systemkomponente wird für das System entsprechend konfiguriert. Ein Ausstauch von Systemkomponenten ist somit nicht nötig, auch wenn
unterschiedliche Kommunikationsverhalten gefordert werden.
Bevorzugte Weiterbildungen sind Gegenstand der Unteransprüche.
Gemäß einer bevorzugten Ausführungsform ist die Systemkomponente I2C und/oder I3C kompatibel. Diese Ausführungsform ist dahingehend vorteilhaft, dass die Systemkomponente sowohl in einem System gemäß dem I2C Busprotokoll oder dem I3C
Busprotokoll mit weiteren Systemkomponenten über den Datenbus
kommunizieren kann. In vorteilhafter Weise ist der I3C Busprotokoll Standard abwärts kompatibel.
Gemäß einer bevorzugten Ausführungsform ermöglicht der Funktionsumfang der erfindungsgemäßen Systemkomponente einen Betrieb alternativ als Master oder als Slave.
In diesem Fall kann die Systemkomponente sowohl als Slave als auch als Master mit weiteren Systemkomponenten über den Datenbus kommunizieren.
Gemäß einer bevorzugten Ausführungsform umfasst der Funktionsumfang eine In-Band-Interrupt - Fähigkeit alternativ mit Payload oder ohne Payload.
In vorteilhafter Weise kann je nach gewähltem Kommunikationsverhalten die Datenlast auf dem Datenbus entsprechend den Anforderungen des Systems angepasst werden. Die In-Band-Interrupt - Fähigkeit mit Payload umfasst ein Mitschicken des Payload, beispielsweise von Sensordaten mit dem durch den Slave gestellten Interrupt. Bei der In-Band-Interrupt - Fähigkeit ohne Payload muss durch einen Master im voraus bereits festgelegt werden, wie die
Kommunikation bzw. der Datenaustausch erfolgen. Beide Varianten werden durch das I3C Busprotokoll vorgesehen. Allerdings sind die Systeme, die dem I3C Busprotokoll entsprechen, auf eine Variante, entweder IBI mit Payload oder ohne Payload beschränkt. In vorteilhafter Weise kann ein Slave für den entsprechenden Anwendungsfall bzw. auf das entsprechende System und für die Verwendung in diesem konfiguriert werden.
Gemäß einer bevorzugten Ausführungsform ist mindestens eine interne oder externe Speichervorrichtung für Konfigurationsdaten vorgesehen, insbesondere ein nicht-flüchtiger Speicher. Die dem gewählten Kommunikationsverhalten entsprechenden Konfigurationsdaten sind von dieser Speichervorrichtung in das Register ladbar.
Diese Ausführungsform ist dahingehend vorteilhaft, dass beispielsweise der IBI Wert (ohne oder mit Payload) aus dem Speicher ausgelesen werden und in das Register geladen werden kann, um das Kommunikationsverhalten der als Slave fungierenden Systemkomponente an die Anforderungen des Masters
anzupassen. Der IBI Wert im BCR Register einer Systemkomponente wird in der Regel im Voraus vom Hersteller der Systemkomponente definiert. Bei der hier in Rede stehenden Ausführungsform der Erfindung ist das IBI Verhalten der Systemkomponente konfigurierbar, indem ein IBI Wert von einer internen oder externen Speichervorrichtung am Anfang der Initialisierung der
Systemkomponente ausgelesen wird. Nach dem Auslesen wird der vorhandene IBI Wert in dem Register überschrieben, wodurch die Systemkomponente mit dem neuen Kommunikationsverhalten initialisiert wird. Mit diesem
Kommunikationsverhalten meldet sich die Buskomponente auf dem Datenbus an und gibt dem Master bekannt wie sie kommuniziert. Der in das Register geschriebene IBI Wert bleibt währende der gesamten Operation der
Systemkomponente unverändert.
Durch das Konfigurieren des Registers vor oder nach dem Initialisieren der Systemkomponente und vor oder nach dem Anmelden an den Datenbus, kann die Systemkomponente unabhängig des Kommunikationsverhaltens des Masters in einem System, in jedem System eingesetzt werden.
Gemäß einer bevorzugten Ausführungsform ist das Kommunikationsverhalten auf der Basis von Busbefehlen und/oder über den Datenbus empfangenen Daten auswählbar und entsprechende Konfigurationsdaten sind in die
Speichervorrichtung ladbar und von der Speichervorrichtung in das Register ladbar.
In vorteilhafter Weise kann ein BCR Wert zwischen einem Master und einem Slave durch ein I3C Custom Command Code (CCC) vereinbart werden. Über das I3C Protokoll stehen Custom Command Codes zur Verfügung bzw. können Custom Command Codes in dem Protokoll definiert werden. Mit diesen kann der Wert in dem Register entsprechend den Anforderungen des Systems geändert bzw. angepasst werden. Der für diese Funktion verwendete I3C Custom
Command Code sollte hierbei über ein privates Protokoll vordefiniert und gerätespezifisch sein.
Ferner kann ein BCR Wert zwischen dem Master und Slave über ein privates I3C Protokoll vereinbart werden. Das private I3C Protokoll, das für diese Funktion angewendet wird, ist entweder vordefiniert oder gerätespezifisch. Diese
Ausführungsform weist den Vorteil auf, dass nicht erst ein Custom Command Code unter Rücksprache mit der MIPI Alliance definiert werden muss. Vielmehr kann intern ein privates Protokoll definiert werden, mit dem auf das BCR Register ohne CCC direkt zugegriffen werden kann, um den Wert des BCR Registers zu ändern.
Gemäß einer bevorzugten Ausführungsform werden die Konfigurationsdaten jeweils nach dem Einschalten der Systemkomponente in das Register geladen, aber noch vor der ersten Abfrage des Kommunikationsverhaltens durch die weitere Systemkomponente.
In vorteilhafter Weise erfolgt das Initialisieren der Systemkomponente auf den im BCR Register hinterlegten Wert bevor die Systemkomponente durch den Master auf den Datenbus initialisiert wird. Somit kann die Systemkomponente für jedes System entsprechend initialisiert werden und ist in diesem einsetzbar.
In einer Ausführungsform ist der Wert des BCR Registers mit einem Default Wert versehen, beispielsweise IBI ohne Payload. Für die Verwendung in einem I3C System mit IBI mit Payload wird die Systemkomponente während ihrer
Initialisierung entsprechend umkonfiguriert, so dass diese auch in dem System verwendbar ist. Hierfür ist in der Speichervorrichtung der Wert für IBI mit Payload abgelegt. Dieser wird ausgelesen und der Wert im BCR Register wird
überschrieben. Gemäß einer bevorzugten Ausführungsform werden die Konfigurationsdaten von einer internen oder externen Speichervorrichtung für Konfigurationsdaten in das Register geladen, insbesondere von einem nicht-flüchtigen Speicher.
Gemäß einer bevorzugten Ausführungsform wird das Kommunikationsverhalten auf der Basis mindestens eines vordefinierten und/oder gerätespezifischen Busbefehls konfiguriert und entsprechende Konfigurationsdaten werden in das Register oder die Speichervorrichtung geladen.
Gemäß einer bevorzugten Ausführungsform wird das Kommunikationsverhalten auf der Basis mindestens einer vordefinierten und/oder gerätespezifischen Datenkommunikation konfiguriert und entsprechende Konfigurationsdaten werden in das Register oder die Speichervorrichtung geladen.
Weitere Merkmale und Vorteile von Ausführungsformen der Erfindung ergeben sich aus der nachfolgenden Beschreibung mit Bezug auf die beigefügten Zeichnungen.
Kurze Beschreibung der Zeichnungen
Die vorliegende Erfindung wird nachfolgend anhand von Ausführungsbeispielen in Verbindung mit den Figuren 1 bis 7 näher erläutert.
Es zeigen:
Fig. 1 eine schematische Darstellung zur Erläuterung einer
Systemkomponente gemäß einer Ausführungsform der vorliegenden Erfindung;
Fig. 2 eine schematische Darstellung zur Erläuterung eines I3C Bussystems; Fig. 3 eine schematische Darstellung zur Erläuterung der In-Band-Interrupt Fähigkeit mit Payload; Fig. 4 eine schematische Darstellung zur Erläuterung der In-Band-Interrupt Fähigkeit ohne Payload;
Fig. 5 eine schematische Darstellung zur Erläuterung einer
Systemkomponente gemäß einer zweiten Ausführungsform der vorliegenden Erfindung;
Fig. 6 eine schematische Darstellung zur Erläuterung einer
Systemkomponente gemäß einer dritten Ausführungsform der vorliegenden Erfindung;
Fig. 7 eine schematische Darstellung zur Erläuterung einer
Systemkomponente gemäß einer vierten Ausführungsform.
In den Figuren sind gleiche bzw. funktionsgleiche Elemente mit denselben Bezugszeichen versehen.
Fig. 1 ist eine schematische Darstellung zur Erläuterung einer
Systemkomponente gemäß einer Ausführungsform der vorliegenden Erfindung.
In Fig. 1 bezeichnet Bezugszeichen 1 eine Systemkomponente umfassend eine Schnittstelle 5. Die Systemkomponente 1 ist über die Schnittstelle 5 mit dem Datenbus 3 (nicht dargestellt) verbunden. Der Datenbus 3 umfasst eine serielle Taktleitung 6 und eine serielle Datenleitung 7. Ferner umfasst die
Systemkomponente 1 eine Prozessoreinheit 8, ein Register 4 und eine
Speichervorrichtung 11. Die Speichervorrichtung 11 ist ausgebildet,
Konfigurationsdaten zum Konfigurieren des Kommunikationsverhaltens der Systemkomponente 1 bereitzustellen. Die Speichervorrichtung 11 ist in Fig. 1 als interne Speichervorrichtung ausgebildet, d.h. sie ist Bestandteil der
Systemkomponente 1. Die Konfigurationsdaten können aber auch von einer externen Speichervorrichtung in das Register 4 geladen werden, beispielsweise einem nichtflüchtigen Speicher, einem elektrischen Schalter, einem elektrisch leitfähigen Pin. Die externe Speichervorrichtung ist nicht auf die hier genannten Beispiele beschränkt. Ferner sind weitere Ausführungen von Vorrichtungen verwendbar, die ausgebildet sind, Daten zu speichern und diese in das Register 4 zu laden. Das Register 4, insbesondere das BCR Register empfängt von der Speichereinrichtung 11 einen Wert vor der Initialisierung des Systemkomponente 1. Über diesen Wert wird das Kommunikationsverhalten der Systemkomponente 1 konfiguriert. Insbesondere wird die I Bl- Funktion mit oder ohne Payload und somit, wie die Systemkomponente 1 über den Datenbus 3 kommuniziert, konfiguriert. Die Prozessoreinheit 8 ist konfiguriert, eine CCC Maschine 9 und eine CCC I3C Kern 10 auszubilden. In einer alternativen Ausführungsform kann die CCC Maschine 9 und der CCC I3C Kern 10 auch auf zwei separaten
Prozessoreinheiten ausgebildet werden. Die CCC Maschine 9 ist ein Teil des Slave in dem I3C Protokoll und dient dem normalen Lesen und Schreiben von Daten. Durch die CCC Maschine 9 wird ein direkter Zugriff auf die Daten bereitgestellt. Eine weitere Kommunikation mit dem Slave gemäß dem I3C Busprotokoll kann über Custom Command Codes CCC erfolgen. Mittels Custom Command Codes kann beispielsweise der PowerModi, das Datenprotokoll beispielsweise in„single data rate“ und„double data rate“ geändert werden. Der CCC I3C Kern 10 empfängt die Custom Command Codes über die Schnittstelle 5 und dekodiert diese und setzt entsprechend die Anweisungen um bzw. reagiert auf diese. Ein beispielhafter Custom Command Code, gesendet von dem Master des Datenbusses 3, ist das Auslesen des BCR Registers der Systemkomponente 1 während des Anmeldens der Systemkomponente 1 auf dem Datenbus 3. Die Systemkomponente 1 empfängt den CCC und der CCC I3C Kern 10 dekodiert das empfangene Kommando und gibt entsprechende Anweisung an die CCC Maschine 9, welche das Register 4 ausliest. Der ausgelesene Wert des
Registers 4 wird über die Schnittstelle 5 der Systemkomponente 1 über den Datenbus 3 an die weitere Systemkomponente 2, beispielsweise in der Funktion eines Masters, übertragen.
Fig. 2 ist eine schematische Darstellung zur Erläuterung eines I3C Bussystems.
In Fig. 2 ist ein I3C Bussystem 10 dargestellt. Das I3C Bussystem 10 umfasst eine Systemkomponente 1 die über einen Datenbus 3 mit weiteren
Systemkomponenten 2 zur Kommunikation verbunden ist. Die
Systemkomponente 1 kann durch ihren Funktionsumfang als ein Slave oder ein Master ausgebildet sein. Wenn die Systemkomponente 1 als Slave fungiert, dann ist eine der weiteren Komponenten 2 als Master ausgebildet.
Fig. 3 ist eine schematische Darstellung zur Erläuterung der In-Band-Interrupt Fähigkeit mit Payload.
In Fig. 3 ist der In-Band-Interrupt 12 mit Payload darstellt. Der In-Band-Interrupt 12 ist eine Möglichkeit der als Slave fungierenden Systemkomponente 1, den Master über den Datenbus 3 zu informieren, dass eine Kommunikation zwischen dem Master und dem Slave aufgebaut werden soll. Der Slave hat in dem I3C Protokoll keine Möglichkeit eine Kommunikation zu beginnen bzw. Daten über den Bus zu senden, ohne einen Takt von dem Master zu erhalten. Der Slave kann mit dem Senden eines IBI den Master informieren, dass beispielsweise Daten zur Verfügung stehen, die über den Datenbus 3 gesendet werden sollen. Der Master reagiert entsprechend einer Priorisierung auf den IBI und steuert die Kommunikation des Slaves, indem der Master entsprechend Takte zur
Verfügung stellt.
Von dem Master wird ein Start - Bit„Start (S)“ über den Datenbus 3 an die Systemkomponente 1 gesendet. Das IBI Slave schickt seine Adresse über den Bus an den Master, wenn dieser einen Takt bereitstellt. Mit dem„Master_ACK“ signalisert der Master dem Slave, dass dieser erkannt hat, dass ein Slave auf den Bus zugreifen möchte. Der In-Band-Interrupt 12 ist mit Payload ausgebildet. Der Master ist somit verpflichtet, dem Slave weitere Takte für mindestens ein Byte zur Verfügung zu stellen und Daten über den Datenbus 3 zu senden, so lange das Slave Daten bereitstellt. Erst nach Abschluss der Kommunikation wird der Datenbus 3 wieder frei gegeben.
Fig. 4 ist eine schematische Darstellung zur Erläuterung der In-Band-Interrupt Fähigkeit ohne Payload.
In Fig. 4 ist der In-Band-Interrupt 13 ohne Payload dargestellt. In diesem Fall kann der Master nach dem Senden des„Master_ACK“ entscheiden, welche Funktion ausgeführt werden soll. Beispielsweise kann der Master ein Lesen der Daten aus dem Slave starten oder eine Kommunikation zu einem weiteren Slave aufbauen, da dieser Slave eventuell eine höhere Priorität aufweist. Der Master ist nicht an den Request des Slave gebunden.
Fig. 5 ist eine schematische Darstellung zur Erläuterung einer
Systemkomponente gemäß einer zweiten Ausführungsform der vorliegenden Erfindung.
In Fig. 5 bezeichnet Bezugszeichen 1 eine Systemkomponente umfassend eine Schnittstelle 5. Die Systemkomponente 1 ist über die Schnittstelle 5 mit dem Datenbus 3 (nicht dargestellt) verbunden. Der Datenbus 3 umfasst eine serielle Taktleitung 6 und eine serielle Datenleitung 7. Ferner umfasst die
Systemkomponente 1 eine Prozessoreinheit 8 und ein Register 4. Die
Prozessoreinheit 8 ist konfiguriert, eine CCC Maschine 9 und eine CCC I3C Kern 10 auszubilden. In einer alternativen Ausführungsform kann die CCC Maschine 9 und der I3C Kern 10 auch auf zwei separaten Prozessoreinheiten ausgebildet werden. Die CCC Maschine 9 ist ein Teil des Slave in dem I3C Protokoll und dient dem normalen Lesen und Schreiben von Daten. Durch die CCC Maschine 9 wird ein direkter Zugriff auf die Daten bereitgestellt. Eine weitere
Kommunikation mit dem Slave gemäß dem I3C Busprotokoll besteht über Custom Command Codes. Mittels Custom Command Codes kann beispielsweise der PowerModi, das Datenprotokoll beispielsweise in„single data rate“ und „double data rate“ geändert werden. Der CCC I3C Kern 10 empfängt die Custom Command Codes über die Schnittstelle 5 und dekodiert diese und setzt entsprechend die Anweisungen um bzw. reagiert auf diese. Ein beispielhafter Custom Command Code gesendet von dem Master des Datenbusses 3 ist das Auslesen des BCR Registers der Systemkomponente 1 während des Anmeldens der Buskomponente auf dem Datenbus 3. Die Systemkomponente 1 empfängt den CCC und der CCC I3C Kern 10 dekodiert das empfangene Kommando und gibt entsprechende Anweisung an die CCC Maschine 9, welche das Register 4 ausliest. Der ausgelesene Wert des Registers 4 wird über die Schnittstelle 5 der Systemkomponente 1 über den Datenbus 3 an die weitere Systemkomponente 2, beispielsweise in der Funktion eines Masters, übertragen.
In der Ausführungsform der vorliegenden Erfindung wird der Wert des Registers 4 über einen empfangenen Custom Command Code (CCC) geändert und somit das Kommunikationsverhalten der Systemkomponente 1. Im I3C Busprotokoll sind gerätespezifische CCC vorgesehen, die hierfür verwendet werden können. Mit diesen können die Werte des BCR Registers 4 konfiguriert werden. Ferner können neue CCC definiert und das I3C Busprotokoll erweitert werden. Mit den neu definierten CCC können die Werte das BCR Registers 4 konfiguriert werden.
Fig. 6 ist eine schematische Darstellung zur Erläuterung einer
Systemkomponente gemäß einer dritten Ausführungsform der vorliegenden Erfindung.
In Fig. 6 weist der I3C CCC Kern 10 eine Verbindung zu dem Register 4 auf. In der Ausführungsform der vorliegenden Erfindung erfolgt keine Konfiguration des Register 4 über die Custom Command Codes des I3C Busprotokolls. In der Ausführungsform dargestellt in der Fig. 6 werden über die direkte Verbindung des I3C CCC Kerns 10 zum Register 4 Schreiben und Lesen Anforderungen bereitgestellt. In einem privaten Protokoll, dass auf dem I3C CCC Kern 10 ausgeführt wird, ist die Kommunikation zwischen dem Master und dem Slave definiert. Der Master kann somit auf das BCR Register 4 schreiben und von diesem Lesen. Hierfür sind in dem privaten Protokoll entsprechend die Adresse des Registers 4, als auch Befehle für das Lesen und Schreiben des Register 4 definiert.
Fig. 7 ist eine schematische Darstellung zur Erläuterung einer
Systemkomponente gemäß einer vierten Ausführungsform.
In Fig. 7 ist eine Kombination der Varianten der Figuren 1, 4 und 5 dargestellt.
Die in der Fig. 7 dargestellte Systemkomponente 1, umfasst eine
Speichervorrichtung 11, über die das Register 4 konfigurierbar ist. Zudem ist das Register 4 über Custom Comand Codes als auch über ein privates Protokoll konfigurierbar. Ferner weist die Speichervorrichtung 11 eine Verbindung mit dem Prozessor 8 auf. Über diese Verbindung kann der in der Speichervorrichtung 11 gespeicherte Wert über Custom Command Codes und über ein privates Protokoll konfiguriert und geladen werden. Die Speichervorrichtung 11 ist ausgebildet, entsprechende Konfigurationsdaten für die Konfiguration des Funktionsumfangs der Systemkomponente 1 dem Register 4 bereitzustellen.

Claims

Ansprüche
1. Systemkomponente (1), mindestens umfassend
a. eine Schnittstelle (5) für einen Datenbus (3) zur Kommunikation mit mindestens einer weiteren Systemkomponente (2), wobei auf dem Datenbus (3) ein definiertes Kommunikationsprotokoll für das Senden und Empfangen von Daten und Busbefehlen vorhanden ist, und das Kommunikationsprotokoll vorsieht, dass die mindestens eine weitere Systemkomponente (2) das Kommunikationsverhalten der
Systemkomponente (1) über den Datenbus (3) abfragt, um ihr eigenes Kommunikationsverhalten an das der Systemkomponente (1) anzupassen; und
b. ein Register (4) für Konfigurationsdaten, die das
Kommunikationsverhalten der Systemkomponente (1) auf dem Datenbus (3) definieren, wobei das Register (4) mit dem Datenbus (3) verbunden ist, so dass die im Register (4) abgespeicherten Konfigurationsdaten auf dem Datenbus (3) zur Verfügung stehen, dadurch gekennzeichnet,
• dass der Funktionsumfang der Systemkomponente (1) unterschiedliche Kommunikationsverhalten ermöglicht, und
• dass das Kommunikationsverhalten der Systemkomponente (1) im Rahmen des Funktionsumfangs auswählbar ist, indem jeweils die dem ausgewählten Kommunikationsverhalten entsprechenden Konfigurationsdaten in das Register (4) ladbar sind.
2. Systemkomponente (1) nach Anspruch 1, dadurch gekennzeichnet, dass sie I2C und/oder I3C kompatibel ist.
3. Systemkomponente (1) nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass der Funktionsumfang einen Betrieb alternativ als Master oder als Slave ermöglicht.
4. Systemkomponente (1) nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass der Funktionsumfang eine In-Band-Interrupt - Fähigkeit alternativ mit Payload (12) oder ohne Payload (13) umfasst.
5. Systemkomponente (1) nach einem der Ansprüche 1 bis 4, dadurch
gekennzeichnet, dass mindestens eine interne oder externe
Speichervorrichtung (11) für Konfigurationsdaten vorgesehen ist, insbesondere ein nicht-flüchtiger Speicher, und dass die dem gewählten
Kommunikationsverhalten entsprechenden Konfigurationsdaten von dieser Speichervorrichtung (11) in das Register (4) ladbar sind.
6. Systemkomponente (1) nach einem der Ansprüche 1 bis 5, dadurch
gekennzeichnet, dass das Kommunikationsverhalten auf der Basis von Busbefehlen und/oder über den Datenbus empfangenen Daten auswählbar ist und entsprechende Konfigurationsdaten in das Register (4) ladbar sind.
7. Systemkomponente (1) nach einem der Ansprüche 5 oder 6, dadurch
gekennzeichnet, dass das Kommunikationsverhalten auf der Basis von Busbefehlen und/oder über den Datenbus empfangenen Daten auswählbar ist und entsprechende Konfigurationsdaten in die Speichervorrichtung (11) ladbar sind und von der Speichervorrichtung (11) in das Register (4) ladbar sind.
8. Systemkomponente (1) nach einem der Ansprüche 1 bis 7, wobei es sich um eine Sensorkomponente zum Erfassen und Umwandeln von Messgrößen in elektrische Sensorsignale handelt.
9. Verfahren zum Betreiben einer Systemkomponente (1), die zur Kommunikation mit mindestens einer weiteren Systemkomponente (2) über mindestens eine Schnittstelle (5) mit einem Datenbus (3) verbunden ist, auf dem ein definiertes Kommunikationsprotokoll für das Senden und Empfangen von Daten und Busbefehlen verwendet wird,
• wobei das Kommunikationsprotokoll vorsieht, dass die mindestens eine weitere Systemkomponente (2) das Kommunikationsverhalten der
Systemkomponente (1) über den Datenbus (3) abfragt, um ihr eigenes Kommunikationsverhalten an das der Systemkomponente (1) anzupassen,
• wobei die Systemkomponente (1) mindestens ein Register (4) für
Konfigurationsdaten umfasst, die das Kommunikationsverhalten der Systemkomponente (1) definieren,
• wobei das Register (4) mit dem Datenbus (3) verbunden ist, so dass die im Register (4) abgespeicherten Konfigurationsdaten auf dem Datenbus (3) zur Verfügung stehen, und
• wobei der Funktionsumfang der Systemkomponente (1) unterschiedliche Kommunikationsverhalten auf dem Datenbus (3) ermöglicht;
dadurch gekennzeichnet, dass das Kommunikationsverhalten der
Systemkomponente (1) konfiguriert wird, indem die einem ausgewählten Kommunikationsverhalten entsprechenden Konfigurationsdaten in das Register (4) geladen werden.
10. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass die
Konfigurationsdaten jeweils nach dem Einschalten der Systemkomponente (1) in das Register (4) geladen werden, aber noch vor der ersten Abfrage des Kommunikationsverhaltens durch die weitere Systemkomponente (2).
11. Verfahren nach einem der Ansprüche 9 oder 10, dadurch gekennzeichnet, dass die Konfigurationsdaten von einer internen oder externen Speichervorrichtung (11) für Konfigurationsdaten in das Register (4) geladen werden, insbesondere von einem nicht-flüchtigen Speicher.
12. Verfahren nach einem der Ansprüche 9 bis 11, dadurch gekennzeichnet, dass das Kommunikationsverhalten auf der Basis mindestens eines vordefinierten und/oder gerätespezifischen Busbefehls konfiguriert wird und entsprechende Konfigurationsdaten in das Register (4) oder die Speichervorrichtung (11) geladen werden.
13. Verfahren nach einem der Ansprüche 9 bis 11, dadurch gekennzeichnet, dass das Kommunikationsverhalten auf der Basis mindestens einer vordefinierten und/oder gerätespezifischen Datenkommunikation konfiguriert wird und entsprechende Konfigurationsdaten in das Register (4) oder die
Speichervorrichtung (11) geladen werden.
PCT/EP2020/050417 2019-02-07 2020-01-09 Systemkomponente mit konfigurierbarem kommunikationsverhalten und verfahren zum betreiben einer solchen systemkomponente WO2020160868A1 (de)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2021546252A JP7241191B2 (ja) 2019-02-07 2020-01-09 通信動作を設定可能なシステムコンポーネントおよびそのようなシステムコンポーネントの作動方法
US17/289,526 US11556493B2 (en) 2019-02-07 2020-01-09 System component having a configurable communication behavior, and method for operating such a system component
CN202080013088.4A CN113424498B (zh) 2019-02-07 2020-01-09 具有可配置通信行为的系统部件和用于运行这种系统部件的方法
KR1020217028461A KR20210123386A (ko) 2019-02-07 2020-01-09 구성 가능한 통신 거동을 갖는 시스템 컴포넌트 및 그러한 시스템 컴포넌트의 작동 방법

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102019201533.6 2019-02-07
DE102019201533.6A DE102019201533A1 (de) 2019-02-07 2019-02-07 Systemkomponente mit konfigurierbarem Kommunikationsverhalten und Verfahren zum Betreiben einer solchen Systemkomponente

Publications (1)

Publication Number Publication Date
WO2020160868A1 true WO2020160868A1 (de) 2020-08-13

Family

ID=69165361

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2020/050417 WO2020160868A1 (de) 2019-02-07 2020-01-09 Systemkomponente mit konfigurierbarem kommunikationsverhalten und verfahren zum betreiben einer solchen systemkomponente

Country Status (7)

Country Link
US (1) US11556493B2 (de)
JP (1) JP7241191B2 (de)
KR (1) KR20210123386A (de)
CN (1) CN113424498B (de)
DE (1) DE102019201533A1 (de)
TW (1) TWI810430B (de)
WO (1) WO2020160868A1 (de)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100205326A1 (en) * 2005-04-29 2010-08-12 Nxp B.V. Programming parallel i2c slave devices from a single i2c data stream
WO2017155897A1 (en) 2016-03-07 2017-09-14 Qualcomm Incorporated Multiprotocol i3c common command codes
US20180225251A1 (en) * 2013-11-14 2018-08-09 Qualcomm Incorporated System and method of sending data via additional secondary data lines on a bus
US20180357194A1 (en) * 2017-06-09 2018-12-13 Qualcomm Incorporated Configuring optimal bus turnaround cycles for master-driven serial buses

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
NL233967A (de) * 1957-12-09
US5737524A (en) * 1995-05-22 1998-04-07 International Business Machines Corporation Add-in board with programmable configuration registers for use in PCI bus computers
GB2373595B (en) * 2001-03-15 2005-09-07 Italtel Spa A system of distributed microprocessor interfaces toward macro-cell based designs implemented as ASIC or FPGA bread boarding and relative common bus protocol
US7421478B1 (en) * 2002-03-07 2008-09-02 Cisco Technology, Inc. Method and apparatus for exchanging heartbeat messages and configuration information between nodes operating in a master-slave configuration
JP3835459B2 (ja) * 2004-03-09 2006-10-18 セイコーエプソン株式会社 データ転送制御装置及び電子機器
US20060284876A1 (en) * 2005-06-15 2006-12-21 Low Yun S Method and apparatus for programming an input/output device over a serial bus
US7896564B2 (en) * 2006-11-16 2011-03-01 Datamax-O'neil Corporation Portable printer
US8139430B2 (en) * 2008-07-01 2012-03-20 International Business Machines Corporation Power-on initialization and test for a cascade interconnect memory system
US9904652B2 (en) * 2013-11-14 2018-02-27 Qualcomm Incorporated System and method of sending data via additional secondary data lines on a bus
WO2016027421A1 (ja) * 2014-08-21 2016-02-25 パナソニックＩｐマネジメント株式会社 記録媒体、アダプタおよび情報処理装置
US20160105320A1 (en) * 2014-10-14 2016-04-14 Cisco Technology, Inc. Automated network configuration in a closed network topology
US10140242B2 (en) * 2015-09-10 2018-11-27 Qualcomm Incorporated General purpose input/output (GPIO) signal bridging with I3C bus interfaces and virtualization in a multi-node network
US9727506B2 (en) * 2015-10-01 2017-08-08 Sony Corporation Communication system, communication system control method, and program
US10031882B2 (en) * 2016-03-31 2018-07-24 Intel Corporation Sensor bus communication system
US20180181532A1 (en) * 2016-12-22 2018-06-28 Qualcomm Incorporated Data transfer ending in phase differential modes
KR102554978B1 (ko) * 2017-02-14 2023-07-14 소니 세미컨덕터 솔루션즈 가부시키가이샤 통신 장치, 통신 방법, 프로그램, 및, 통신 시스템
US20180285292A1 (en) * 2017-03-28 2018-10-04 Qualcomm Incorporated System and method of sending data via additional secondary data lines on a bus
US10482055B2 (en) * 2017-05-10 2019-11-19 Qualcomm Incorporated Hardware event priority sensitive programmable transmit wait-window for virtual GPIO finite state machine
JP6983542B2 (ja) * 2017-06-08 2021-12-17 ソニーセミコンダクタソリューションズ株式会社 通信装置、通信方法、プログラム、および、通信システム
US20180357067A1 (en) * 2017-06-09 2018-12-13 Qualcomm Incorporated In-band hardware reset for virtual general purpose input/output interface
US11132323B2 (en) * 2017-06-20 2021-09-28 Intel Corporation System, apparatus and method for extended communication modes for a multi-drop interconnect
JP7031961B2 (ja) * 2017-08-04 2022-03-08 ソニーセミコンダクタソリューションズ株式会社 通信装置、通信方法、プログラム、および、通信システム
US20190095273A1 (en) * 2017-09-27 2019-03-28 Qualcomm Incorporated Parity bits location on i3c multilane bus
US10515044B2 (en) * 2017-11-01 2019-12-24 Qualcomm Incorporated Communicating heterogeneous virtual general-purpose input/output messages over an I3C bus
CN107967230A (zh) * 2017-11-30 2018-04-27 广东高云半导体科技股份有限公司 I3c电路设备、系统和通信方法
US20190171609A1 (en) * 2017-12-05 2019-06-06 Qualcomm Incorporated Non-destructive outside device alerts for multi-lane i3c
US10693674B2 (en) * 2018-01-29 2020-06-23 Qualcomm Incorporated In-datagram critical-signaling using pulse-count-modulation for I3C bus
US10579581B2 (en) * 2018-02-28 2020-03-03 Qualcomm Incorporated Multilane heterogeneous serial bus
US20200097434A1 (en) * 2018-09-26 2020-03-26 Qualcomm Incorporated Enhanced high data rate technique for i3c

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100205326A1 (en) * 2005-04-29 2010-08-12 Nxp B.V. Programming parallel i2c slave devices from a single i2c data stream
US20180225251A1 (en) * 2013-11-14 2018-08-09 Qualcomm Incorporated System and method of sending data via additional secondary data lines on a bus
WO2017155897A1 (en) 2016-03-07 2017-09-14 Qualcomm Incorporated Multiprotocol i3c common command codes
US20180357194A1 (en) * 2017-06-09 2018-12-13 Qualcomm Incorporated Configuring optimal bus turnaround cycles for master-driven serial buses

Also Published As

Publication number Publication date
CN113424498A (zh) 2021-09-21
US20210397579A1 (en) 2021-12-23
JP7241191B2 (ja) 2023-03-16
JP2022520057A (ja) 2022-03-28
KR20210123386A (ko) 2021-10-13
TWI810430B (zh) 2023-08-01
CN113424498B (zh) 2023-07-04
TW202046134A (zh) 2020-12-16
DE102019201533A1 (de) 2020-08-13
US11556493B2 (en) 2023-01-17

Similar Documents

Publication Publication Date Title
DE10315490B4 (de) Verfahren und System zum Wechsel zwischen zwei oder mehreren Firmwareabbildungen auf einer Hostvorrichtung
DE102004057756B4 (de) USB-Steuerungseinrichtung mit OTG-Steuerungseinheit
DE10026918A1 (de) Virtueller Netzwerkadapter
EP2836912B1 (de) Teilnehmerstation für ein bussystem und verfahren zur übertragung von nachrichten zwischen teilnehmerstationen eines bussystems
EP2423887A1 (de) Portable Vorrichtung zur Veränderung von Betriebsparameterwerten und/oder Firmware von elektronischen Steuerungseinrichtungen von Kraftfahrzeugen
EP1590737B1 (de) Steuergerät für ein kraftfahrzeug und kommunikationsverfahren dafür
EP3080950B1 (de) Verfahren und system zur deterministischen autokonfiguration eines gerätes
WO2006069763A1 (de) Verfahren zur konfiguration von feldgeräten
WO2020160868A1 (de) Systemkomponente mit konfigurierbarem kommunikationsverhalten und verfahren zum betreiben einer solchen systemkomponente
DE102020205765A1 (de) Systemkomponente und Verwendung einer Systemkomponente
DE102016008957B4 (de) Direkter Zugriff auf Bussignale in einem Kraftfahrzeug
BE1026569B1 (de) Steuer- und Datenübertragungsanlage zur Unterstützung verschiedener Kommunikationsprotokolle und ein Adaptermodul
EP2618114B1 (de) Abrufen von messwerten, diagnoseinformationen oder geräteparametern
DE102004033761A1 (de) Vorrichtung und Verfahren zum Datenaustausch auf mehreren Bussystemen
EP2287691A1 (de) Vorrichtung zum Zugriff auf elektronische Fahrzeugkomponenten
DE102018214015A1 (de) SPI-Vorrichtungen mit Multi-Master-Fähigkeiten
DE102016008587B4 (de) Zugriff auf ein über einen Datenbus eines Kraftfahrzeugs übermittelbares Steuersignal
EP1642422B1 (de) Anpassung eines fahrzeugnetzwerks an geänderte anforderungen
DE102020208367A1 (de) Elektronische steuereinheit
DE10101974B4 (de) Elektronisches Steuergerät zur Integration in mechanische Systeme
AT504735B1 (de) Verfahren zum betrieb eines mit einem hostsystem verbundenen peripheriegerät, system und peripheriegerät
DE102015115727A1 (de) Computersystem, Anordnung mit einem Computersystem und einem externen Management-Gerät, sowie Verwendung einer Speichereinheit in einem Computersystem
DE102017222798A1 (de) AS-i Feldbusgerät und Verfahren zum Anschließen eines AS-i Feldbusgeräts
DE102012218665A1 (de) Applikationssystem für Steuergeräte
WO2019238395A1 (de) Verfahren zum betreiben einer sensoranordnung in einem kraftfahrzeug auf basis eines dsi-protokolls

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20700664

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021546252

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 20217028461

Country of ref document: KR

Kind code of ref document: A

122 Ep: pct application non-entry in european phase

Ref document number: 20700664

Country of ref document: EP

Kind code of ref document: A1