CN109656844B

CN109656844B - AT24xx EEPROM driving method and device

Info

Publication number: CN109656844B
Application number: CN201811463769.1A
Authority: CN
Inventors: 王鹏
Original assignee: Zhengzhou Yunhai Information Technology Co Ltd
Current assignee: Zhengzhou Yunhai Information Technology Co Ltd
Priority date: 2018-12-03
Filing date: 2018-12-03
Publication date: 2022-02-22
Anticipated expiration: 2038-12-03
Also published as: CN109656844A

Abstract

The invention provides an AT24xx EEPROM driving method, which comprises the following steps: instantiating an I2C driven core structure and registering the structure into an I2C core; the method comprises the steps of realizing packaging of a local private structure body, calling a device enumeration function defined in a core structure body to initialize and store the local private structure body so as to prepare relevant software and hardware resources; and registering an operation function set facing the upper layer through a device enumeration function, and calling a read-write function through the operation function set facing the upper layer to perform read-write operation on the I2C interface of the AT24xx EEPROM. The invention realizes the universal drive aiming AT the AT24xx series EEPROM and simultaneously supports a plurality of matching modes, thereby having better adaptability.

Description

AT24xx EEPROM driving method and device

Technical Field

The present invention relates generally to the field of computers, and more particularly to an AT24xx EEPROM (electrically erasable programmable read only memory) driving method and apparatus.

Background

The AT24xx series has many EEPROM models and wide application scenarios. However, the I2C interface driver of each model of the chip is independently programmed, and when different models of chips are adopted in our product, the chip driver of the specified model needs to be adapted. Moreover, from the perspective of software design, the AT24xx series EEPROM has great similarity in hardware design, and driving separate independent writing tends to bring about code redundancy design. In addition, since the EEPROM of the AT24xx series has been put on the market from the beginning to the present, and Linux has changed greatly in the meantime, especially after an ARM (Advanced RISC Machine) architecture is introduced into a Device Tree, a matching manner of drivers has shifted to DTS (Device Tree Source), and earlier chip drivers still adopt a legacy manner, which causes the AT24xx EEPROM of the same series to be non-uniform in a driver programming manner.

Disclosure of Invention

In view of this, the present invention is directed to provide a general driver software for adapting to all AT24xx series, so that when the product is iterated, if the AC24xx chip with different model is replaced, there is no concern about the problem of drive mismatch; moreover, the driver code is written to support a plurality of matching modes, i2c _ table matching, DTS matching and ACPI (Advanced Configuration and Power Management Interface) matching, so that the driver code has wider universality and can be used in both an ARM platform and an X86 platform.

In view of the above, an aspect of the embodiments of the present invention provides an AT24xx EEPROM driving method, including the following steps:

instantiating an I2C driven core fabric (I2c _ driver) and registering the fabric into an I2C core;

the method comprises the steps of realizing packaging of a local private structure body, calling a device enumeration function defined in a core structure body to initialize and store the local private structure body so as to prepare relevant software and hardware resources; and

registering an operation function set facing an upper layer through a device enumeration function, and calling a read-write function through the operation function set facing the upper layer to perform read-write operation on an I2C interface of the AT24xx EEPROM.

In some embodiments, further comprising: before instantiating the I2C driven core fabric, board level information of the AT24xx EEPROM is added to a board level file of the system.

In some embodiments, adding the board level information of the AT24xx EEPROM in a board level file of a system includes: in the case of an ARM platform supporting a device tree, board level information for the AT24xx EEPROM is added to the DTS file.

In some embodiments, adding the board-level information of the AT24xx EEPROM in a board-level file of a system further comprises: in the case of the X86 platform, board level information of the AT24xx EEPROM is added in the DSDT (Differentiated System Description Table).

In some embodiments, the instantiating I2C drives the core fabric and registering the fabric into the I2C core includes: an array of the type of _ device _ id which represents a DTS matching mode supported by an ARM platform and an array of the type of ACPI _ device _ id which represents an ACPI matching mode supported by an X86 platform are defined in the I2C driving core structure.

In some embodiments, the instantiating I2C drives a core fabric and registering the fabric into an I2C core further comprises: calling the I2C driven core structure registration function in the driven entry function completes the registration of the I2C driven core structure.

In some embodiments, invoking the I2C driven core fabric offload function in the egress function may complete the offload of the I2C driven core fabric.

In some embodiments, the local private structure includes i2c _ client and the exclusive lock, wait queue, and temporary buffer software resources required in the hardware access engineering.

In some embodiments, the implementing encapsulation of the local private structure and invoking a device enumeration function defined in the core structure to initialize and save the local private structure to prepare the relevant software and hardware resources includes: the device enumeration function firstly judges whether the matching mode of the platform device is the DTS of ARM or the ACPI of X86, and carries out a series of initialization actions based on the matching mode.

In some embodiments, the I2C interface of the AT24xx EEPROM is read and written in units of I2c msg.

Another aspect of the embodiments of the present invention provides an AT24xx EEPROM driving apparatus, including:

at least one processor; and

a memory storing program code executable by the processor, the program code implementing the method of any one of the preceding claims when executed by the processor.

The invention has the following beneficial technical effects: the AT24xx EEPROM driving method and the device provided by the embodiment of the invention adapt to a full series of AT24xx series chips according to the design idea of separating the host drive from the peripheral drive, support multi-platform and multi-form device/driver matching modes, are applicable to both an ARM platform and an X86 platform, have better adaptability, simplify the realization of equipment drive and provide maximum convenience for the maintenance and upgrading of the drive.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art that other embodiments can be obtained by using the drawings without creative efforts.

Fig. 1 is a flow chart of an AT24xx EEPROM driving method according to an embodiment of the present invention;

fig. 2 is a schematic diagram of a hardware structure of an AT24xx EEPROM driving apparatus according to an embodiment of the present invention.

Detailed Description

Embodiments of the present disclosure are described below. However, it is to be understood that the disclosed embodiments are merely examples and that other embodiments may take various and alternative forms. The figures are not necessarily to scale; certain features may be exaggerated or minimized to show details of particular components. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the present invention. As one of ordinary skill in the art will appreciate, various features illustrated and described with reference to any one of the figures may be combined with features illustrated in one or more other figures to produce embodiments that are not explicitly illustrated or described. The combination of features shown provides a representative embodiment for a typical application. However, various combinations and modifications of the features consistent with the teachings of the present disclosure may be desirable for certain specific applications or implementations.

In order to make the objects, technical solutions and advantages of the present invention more apparent, the following embodiments of the present invention are described in further detail with reference to the accompanying drawings.

The I2C protocol is a type of communication protocol widely used in embedded systems, mainly for low-speed data communication between the CPU and various peripherals. The Linux kernel abstracts and manages corresponding resources using an I2C frame (I2C framework), and provides an API (Application Program Interface) to various users in various forms. In addition, as a kind of bus (bus), the implementation of the I2C framework embodies the essence of the Linux device model, and is worthy of research and study. The I2C architecture of Linux is divided into 3 components:

(1) I2C core: the I2C core provides I2C bus driver and device driver registration and logout methods, code independent of specific adapter on the upper layer of I2C communication method (i.e. Algorithm) and upper layer code for detecting device, detecting device address, etc.;

(2) I2C bus driver: the I2C bus driver is the implementation of the adapter end in the I2C hardware architecture, and the adapter can be controlled by the CPU or even be directly integrated in the CPU. The I2C bus driver mainly contains I2C adapter data structure I2c _ adapter, Algorithm data structure I2c _ Algorithm of I2C adapter, and a function for controlling the I2C adapter to generate communication signals. Via the code driven by the I2C bus, we can control the I2C adapter to generate start bits, stop bits, read and write cycles in a master manner, and to be read and written, generate ACKs in a slave manner, etc.

(3) I2C device driver: the I2C device driver (also called client driver) is implemented on the device side in the I2C hardware system structure, and the device is generally hung on an I2C adapter controlled by a CPU and exchanges data with the CPU through the I2C adapter. The I2C device driver mainly contains data structures I2c _ driver and I2c _ client, and we need to implement member functions therein according to specific devices.

An i2c directory is located under the drivers directory in the Linux kernel source code, and the i2c directory contains the following files and folders: (1) i2c-core.c, which implements the functions of the I2C core and/proc/bus/I2 c interface; (2) i2c-dev.c, which realizes the function of the I2C adapter equipment file; (3) a busses folder; and (4) the algos folder.

Through abstraction of the I2C frame, the consumer can interact data with the slave devices only through a simple API without paying attention to technical details of the I2C bus. Normally, the consumer is the other driver (such as HDMI driver, touch screen driver, etc.) in kernel mode. At the same time, I2C frame also provides a similar interface to user space through a character device, through which user space programs can access the slave devices. Inside the I2C frame, there are four modules of I2C core, I2C busses, I2C algos and I2C muxes. The I2C core uses two submodules I2C adapter and I2C algorithm to abstract the function of an I2C controller, and uses I2C client and I2C driver to abstract the function of an I2C slave device (corresponding to the device and the device driver in the device model). In addition, based on the I2C protocol, the function of SMBus (System Management Bus) is realized by a SMBus module. I2C algos includes a plurality of general I2C algorithms, which means the generation method of I2C protocol package and further combine into a read/write (read/write) instruction of I2C, generally implemented by hardware, without paying special attention to the directory. The I2C muxes are used to implement the multiplexing function of the I2C bus.

In view of the above, an embodiment of the present invention provides a method for driving an AT24xx EEPROM, including the following steps:

instantiating I2C to drive a core structure I2c _ driver and registering the structure in an I2C core;

the method comprises the steps of realizing encapsulation of a local private structure body, calling a device enumeration function (probe function) defined in a core structure body to initialize and store the local private structure body so as to prepare related software and hardware resources; and

registering an operation function set facing an upper layer through the device enumeration function, and calling a read-write function through the operation function set facing the upper layer to perform read-write operation on an I2C interface of the AT24xx EEPROM.

In some embodiments, the methods of the invention further comprise: before instantiating the I2C driven core fabric, board level information of the AT24xx EEPROM is added to the board level file of the system.

The present invention does not depend on the hardware characteristics of the specific SoC and I2C controller, so in some embodiments, if an ARM platform is externally connected to an AT24xx EEPROM, only the corresponding I2c _ board _ info needs to be added to the board-level file, and the code is as follows:

Static sttruct i2c_board_info i2c_devs0[]__initdata＝{

{I2C_BOARD_INFO(“24c02”,0x57),},

}；

in the case of a device tree, simply add a node to the dts file:

in some embodiments, when the X86 platform is driven by the method of the present invention, only the corresponding board level information of AT24xx needs to be added to the DSDT, and the codes are as follows:

Scope(_SB.PCI0)

{

Device(I2C0)

{

Name(LINK,"\\_SB.PCI0.I2C0")

Method(_PSC,0,NotSerialized)//_PSC:Power State Current

{

Return(GETD(SB10))

}

Method(_PS0,0,NotSerialized)//_PS0:Power State 0

{

LPD0(SB10)

}

Method(_PS3,0,NotSerialized)//_PS3:Power State 3

{

LPD3(SB10)

}

in some embodiments, I2c _ driver corresponds to a set of driving methods, and its main member functions include probe (), remove (), suspend (), resume (), etc., and in addition, ID _ table in the form of struct I2c _ device _ ID is a matching manner specific to I2C devices, and stores therein ID tables of I2C devices supported by the driver, and we also implement them. The code to instantiate i2c _ driver is as follows:

static struct i2c_driver at24_driver＝{

.driver＝{

.name＝"at24",

.acpi_match_table＝ACPI_PTR(at24_acpi_ids),

.of_match_table＝of_match_ptr(at24_of_ids),

},

.probe＝at24_probe,

.remove＝at24_remove,

.id_table＝at24_ids,

}；

wherein, at24_ of _ ids is an array of _ device _ id type, which is a DTS matching mode supported by ARM platform, and contains the "compatible" of all devices supported by the driver, for matching EEPROM nodes defined in the device tree; at24_ ACPI _ ids is an array of ACPI _ device _ id types, and is an ACPI table matching mode supported by the X86 platform for matching device information in a DSDT file. Finally, calling an i2c _ driver registration function return i2c _ add _ driver (& at24_ driver) in the driven entry function at24_ init to complete the registration of i2c _ driver; the i2c _ driver offload function i2c _ del _ driver (& at24_ driver) is called in the exit function at24_ exit to complete the offload of i2c _ driver.

In some embodiments, the probe function is key to initializing the hardware, where the core code logic is as follows:

the AT24_ data structure is a local private structure of the AT24xx EEPROM, and includes i2c _ client, and exclusive locks, wait queues, and temporary buffer (buffer) software resources required in the hardware access process. The I2c _ client is an I2C device hardware abstraction provided by the I2C subsystem, and contains hardware-related resource information, the mutual exclusion lock is used for preventing a plurality of upper-layer applications from accessing the EEPROM hardware in a race mode, the waiting queue is used for optimizing the data transmission process, and the temporary buffer area is used for the turnover of local data. The probe () function is to fully prepare the relevant software and hardware resources around the at24_ data structure. The code logic firstly judges whether the matching mode of the platform equipment is the DTS of ARM or the ACPI of X86, if the matching mode is the DTS matching mode, the function of _ match _ device () is called to find the AT24xx specific model matched with the DTS from the array of ad24_ dt _ ids, and if the matching mode is the ACPI matching mode, the function of ACPI _ match _ device () is called to find the AT24xx specific model matched with the DSDT from the array of AT24_ ACPI _ ids; then, a series of initialization actions are carried out, after all at24_ data members are ready, an i2c _ set _ clientdata () function is called to store the initialized at24_ data into dev- > driver _ data of the i2c _ client; the register _ chrdev () function is used to register the upper level up set of operation functions at24cxx _ fops, defined as follows:

static struct file_operations at24cxx_fops＝{

.owner＝THIS_MODULE,

.read＝at24cxx_read,

.write＝at24cxx_write,

}；

when the upper application program needs to read and write the AT24xx EEPROM, the functions of AT24cxx _ read and AT24cxx _ write implemented in AT24cxx _ fops are called, so as to initiate actual access behaviors aiming AT the AT24xx EEPROM hardware; class _ create and device _ create are used to automatically create a device node, here dev/at24 cxx.

In some embodiments, I2C transfers (reads or writes) are in units of I2c msg, the data structure contains all information related to data transfer, wherein addr represents the address of I2C slave device; flags represent flag that data transmission can carry; the commonly used I2C _ M _ TEN represents the slave address supporting 10-bit, and I2C _ M _ RD represents that the transmission is a read operation; len denotes the length of data transmission in bits (byte).

In some embodiments, there are two types of interfaces associated with I2C data transfer: one type uses i2c client as parameter to perform simple data transceiving, including i2c _ master _ send and i2c _ master _ recv. The method can only send or receive a certain amount of data in a standard manner.

The other type takes i2c adapter and i2c msg as parameters, and can be used for more flexible read or write data, including i2c _ transfer. By using the method, struct i2c _ msg is used as a parameter, and a certain amount of data can be read at a time, or written, or read and written.

The read function interface realized by the driver is as follows:

among them, referring to Random Eead timing charts of at24c08 handbook, it is known that: s Addr Wr [ A ] Comm [ A ] S Addr Rd [ A ] [ Data ] NAP, here using I2c _ smbus _ read _ byte _ Data to read I2C Data.

The writing function is similar, and the data writing is carried out by calling i2c _ smbus _ write _ byte _ data, and the following steps are implemented:

in some embodiments, a driver implemented according to the method of the present invention may be tested with the following test code, with the following test cases:

void print_usage(char*file)

{

printf("％s r addr\n",file)；

printf("％s w addr val\n",file)；

}

int main(int argc,char**argv)

{

int fd；

unsigned char buf[2]；

if((argc！＝3)&&(argc！＝4))

{

print_usage(argv[0])；

return-1；

}

fd＝open("/dev/at24cxx",O_RDWR)；

if(fd<0)

{

printf("can't open/dev/at24cxx\n")；

return-1；

}

if(strcmp(argv[1],"r")＝＝0)

{

buf[0]＝strtoul(argv[2],NULL,0)；

read(fd,buf,1)；

printf("data:％c,％d,0x％2x\n",buf[0],buf[0],buf[0])；

}

else if(strcmp(argv[1],"w")＝＝0)

{

buf[0]＝strtoul(argv[2],NULL,0)；

buf[1]＝strtoul(argv[3],NULL,0)；

write(fd,buf,2)；

}

else

{

print_usage(argv[0])；

return-1；

}

return 0；

}

through testing, the I2C interface of the AT24C08EEPROM can be read and written normally through the driver.

Where technically feasible, the technical features listed above for the different embodiments may be combined with each other or changed, added, omitted, etc. to form further embodiments within the scope of the invention.

It can be seen from the foregoing embodiments that the AT24xx EEPROM driving method and apparatus provided in the embodiments of the present invention adapt to a full series of AT24xx chips in compliance with a design concept of separating a host driver and a peripheral driver, and support a multi-platform and multi-format device/driver matching manner, and both the ARM platform and the X86 platform are applicable, have better adaptability, simplify the implementation of device drivers, and provide maximum convenience for the maintenance and upgrade of drivers.

In view of the above objects, a second aspect of the embodiments of the present invention provides an embodiment of an AT24xxEEPROM driving apparatus.

The AT24xx EEPROM drive includes AT least one processor and memory storing a computer program operable on the processor, the processor executing the program to perform any of the methods described above.

Fig. 2 is a schematic diagram of a hardware structure of an embodiment of the AT24xx EEPROM driving apparatus according to the present invention.

Taking fig. 2 as an example, the apparatus includes a processor 201 and a memory 202, and may further include: an input device 203 and an output device 204.

The processor 201, the memory 202, the input device 203 and the output device 204 may be connected by a bus or other means, and fig. 2 illustrates the connection by a bus as an example.

The memory 202, which is a non-volatile computer-readable storage medium, may be used for storing non-volatile software programs, non-volatile computer-executable programs, and modules, such as program instructions/modules corresponding to the AT24xx EEPROM driving method in the embodiments of the present application. The processor 201 executes various functional applications of the server and data processing, i.e., the AT24xx EEPROM driving method of implementing the above-described method embodiments, by running non-volatile software programs, instructions, and modules stored in the memory 202.

The memory 202 may include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required for at least one function; the stored data area may store data created from use of the AT24xx EEPROM drive device, and the like. Further, the memory 202 may include high speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid state storage device. In some embodiments, memory 202 may optionally include memory located remotely from processor 201, which may be connected to local modules via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The input device 203 may receive input numeric or character information and generate key signal inputs related to user settings and function control of the AT24xxEEPROM drive device. The output device 204 may include a display device such as a display screen.

Program instructions/modules corresponding to the one or more AT24xx EEPROM drive methods are stored in the memory 202 and, when executed by the processor 201, perform the AT24xx EEPROM drive methods of any of the above-described method embodiments.

Any of the embodiments of the AT24xx EEPROM driver apparatus described above may be implemented to achieve the same or similar effects as any of the previously described method embodiments corresponding thereto.

Finally, it should be noted that, as will be understood by those skilled in the art, all or part of the processes in the methods of the above embodiments may be implemented by a computer program, which may be stored in a computer-readable storage medium, and when executed, may include the processes of the embodiments of the methods described above. The storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), a Random Access Memory (RAM), or the like.

In addition, the apparatuses, devices and the like disclosed in the embodiments of the present invention may be various electronic terminal devices, such as a mobile phone, a Personal Digital Assistant (PDA), a tablet computer (PAD), a smart television and the like, or may be a large terminal device, such as a server and the like, and therefore the scope of protection disclosed in the embodiments of the present invention should not be limited to a specific type of apparatus, device. The client disclosed in the embodiment of the present invention may be applied to any one of the above electronic terminal devices in the form of electronic hardware, computer software, or a combination of both.

Furthermore, the method disclosed according to an embodiment of the present invention may also be implemented as a computer program executed by a CPU, and the computer program may be stored in a computer-readable storage medium. The computer program, when executed by the CPU, performs the above-described functions defined in the method disclosed in the embodiments of the present invention.

Further, the above method steps and system elements may also be implemented using a controller and a computer readable storage medium for storing a computer program for causing the controller to implement the functions of the above steps or elements.

Further, it should be appreciated that the computer-readable storage media (e.g., memory) described herein can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory. By way of example, and not limitation, nonvolatile memory can include Read Only Memory (ROM), Programmable ROM (PROM), Electrically Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM), which can act as external cache memory. By way of example and not limitation, RAM is available in a variety of forms such as synchronous RAM (DRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The storage devices of the disclosed aspects are intended to comprise, without being limited to, these and other suitable types of memory.

Those of skill would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the disclosure herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as software or hardware depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the disclosed embodiments of the present invention.

The various illustrative logical blocks, modules, and circuits described in connection with the disclosure herein may be implemented or performed with the following components designed to perform the functions described herein: a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination of these components. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP, and/or any other such configuration.

The steps of a method or algorithm described in connection with the disclosure herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal.

In one or more exemplary designs, the functions may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a general-purpose or special-purpose computer, or a general-purpose or special-purpose processor. Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, Digital Subscriber Line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk and disc, as used herein, includes Compact Disc (CD), laser disc, optical disc, Digital Versatile Disc (DVD), floppy disk, blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

The foregoing is an exemplary embodiment of the present disclosure, but it should be noted that various changes and modifications could be made herein without departing from the scope of the present disclosure as defined by the appended claims. The functions, steps and/or actions of the method claims in accordance with the disclosed embodiments described herein need not be performed in any particular order. Furthermore, although elements of the disclosed embodiments of the invention may be described or claimed in the singular, the plural is contemplated unless limitation to the singular is explicitly stated.

It should be understood that, as used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly supports the exception. It should also be understood that "and/or" as used herein is meant to include any and all possible combinations of one or more of the associated listed items.

The numbers of the embodiments disclosed in the embodiments of the present invention are merely for description, and do not represent the merits of the embodiments.

It will be understood by those skilled in the art that all or part of the steps for implementing the above embodiments may be implemented by hardware, or may be implemented by a program instructing relevant hardware, where the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a magnetic disk, an optical disk, or the like.

The above-described embodiments are possible examples of implementations and are presented merely for a clear understanding of the principles of the invention. Those of ordinary skill in the art will understand that: the discussion of any embodiment above is meant to be exemplary only, and is not intended to intimate that the scope of the disclosure, including the claims, of embodiments of the invention is limited to these examples; within the idea of an embodiment of the invention, also technical features in the above embodiment or in different embodiments may be combined and there are many other variations of the different aspects of an embodiment of the invention as described above, which are not provided in detail for the sake of brevity. Therefore, any omissions, modifications, substitutions, improvements, and the like that may be made without departing from the spirit and principles of the embodiments of the present invention are intended to be included within the scope of the embodiments of the present invention.

Claims

1. An AT24xx EEPROM driving method, comprising the steps of:

instantiating an I2C driven core structure and registering the structure into an I2C core;

the encapsulation of a local private structure body is realized, and a device enumeration function defined in the core structure body is called to initialize and store the local private structure body so as to prepare relevant software and hardware resources; and

registering an operation function set facing an upper layer through the device enumeration function, calling a read-write function through the operation function set facing the upper layer to carry out read-write operation on an I2C interface of the AT24xx EEPROM,

wherein, the method further comprises: before the I2C driven core structure body is instantiated, board level information of the AT24xx EEPROM is added into a board level file of a system,

adding the board-level information of the AT24xx EEPROM in a board-level file of a system includes: in the case of an ARM platform supporting a device tree, adding board level information of the AT24xx EEPROM in a DTS file,

adding the board-level information of the AT24xx EEPROM in a board-level file of a system further includes: in the case of the X86 platform, adding the board level information of the AT24xx EEPROM in the DSDT,

the instantiating I2C drives the core fabric and registering the fabric into the I2C core includes: defining an array of the type of _ device _ id which represents a DTS matching mode supported by an ARM platform and an array of the type of ACPI _ device _ id which represents an ACPI matching mode supported by an X86 platform in the I2C driving core structure,

the implementing of the encapsulation of the local private structure, and calling the device enumeration function defined in the core structure to initialize and save the local private structure, so as to prepare the relevant software and hardware resources, includes: the device enumeration function firstly judges whether the matching mode of the platform device is the DTS of ARM or the ACPI of X86, and carries out a series of initialization actions based on the matching mode.

2. The method of claim 1, wherein instantiating I2C drives a core fabric and registering the fabric into an I2C core further comprises: calling the I2C driven core structure registration function in the driven entry function completes the registration of the I2C driven core structure.

3. The method of claim 1, wherein the local private structure comprises i2c _ client and mutex locks, wait queues, and temporary buffer software resources required in hardware access engineering.

4. The method of claim 3, wherein reading from and writing to the I2C interface of the AT24xx EEPROM is in units of I2c msg.

5. An AT24xx EEPROM drive, comprising:

at least one processor; and

a memory storing program code executable by the processor, the program code implementing the method of any one of claims 1-4 when executed by the processor.