CN117331616A - Complex driving method and system for block equipment - Google Patents
Complex driving method and system for block equipment Download PDFInfo
- Publication number
- CN117331616A CN117331616A CN202311243071.XA CN202311243071A CN117331616A CN 117331616 A CN117331616 A CN 117331616A CN 202311243071 A CN202311243071 A CN 202311243071A CN 117331616 A CN117331616 A CN 117331616A
- Authority
- CN
- China
- Prior art keywords
- block
- blkdev
- registry
- mapping table
- complex driving
- Prior art date
- Legal status (The legal status 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 status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 54
- 238000013507 mapping Methods 0.000 claims abstract description 31
- 230000006870 function Effects 0.000 claims description 15
- 238000004590 computer program Methods 0.000 claims description 5
- 238000012937 correction Methods 0.000 claims description 4
- 238000012795 verification Methods 0.000 claims description 2
- 238000013461 design Methods 0.000 abstract description 25
- 238000011161 development Methods 0.000 abstract description 8
- 230000009286 beneficial effect Effects 0.000 abstract description 7
- 230000007246 mechanism Effects 0.000 abstract description 6
- 238000004891 communication Methods 0.000 description 13
- 238000007726 management method Methods 0.000 description 7
- 238000010586 diagram Methods 0.000 description 6
- 238000005516 engineering process Methods 0.000 description 6
- 230000003993 interaction Effects 0.000 description 6
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 230000008569 process Effects 0.000 description 3
- 230000003068 static effect Effects 0.000 description 3
- 230000000694 effects Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 230000006399 behavior Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 239000000969 carrier Substances 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000003745 diagnosis Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000001737 promoting effect Effects 0.000 description 1
- 238000004064 recycling Methods 0.000 description 1
- 238000013468 resource allocation Methods 0.000 description 1
Classifications
-
- 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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/35—Creation or generation of source code model driven
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
The application provides a complex driving method and a complex driving system for block equipment, wherein the method comprises the following steps: the block device complex driving method comprises the following steps: constructing a device registry; constructing a device mapping table, wherein the device mapping table comprises a plurality of mapping table items BlkDevevMappingItems, and each BlkDevevMappingItem is responsible for associating a device name with an identifier; building block device examples, including BlkDev MappingItem and BlkDev Op construct pointers to the registry; build BlkDev Op associates one operation lookup table for each instance of a drive. The design and development work of the complex drive of the block device under Autosar is subjected to consistency constraint through mechanisms such as a design method, a programming framework and the like. The standardization of the complex driving programming model of the block type equipment is also beneficial to improving the quality of software and accelerating the positioning problem and solving the efficiency.
Description
Technical Field
One or more embodiments of the present disclosure relate to the field of automotive technologies, and in particular, to a complex driving method and driving system for a block device.
Background
Autosar (Automotive Open System Architecture), i.e. the open automotive system architecture, is currently one of the most widely used common standards in the automotive industry.
The method aims at defining a general specification or an implementation standard for different types of hardware, different automobile controller components and different software developers, so that a plurality of embedded systems with different functions, different chips and different hardware topologies can be efficiently designed, developed and tested according to a unified development paradigm.
However, in the official definition of Autosar, there is a part that is not constrained and defined in detail, i.e., a complex driving part.
Because of the default defined by the Autosar standard for this part, the implementation of the block device driver will also be different for different hardware platforms; furthermore, the block device driving implementation of different Autosar application fields can be different; the implementation of the same platform may vary from vendor to vendor.
From this point of view, the design cost, implementation cost, maintenance cost paid by the software engineer in maintaining the Autosar complex drive are increased.
Disclosure of Invention
In view of this, it is an object of one or more embodiments of the present disclosure to provide a complex driving method and driving system for a block device, so as to facilitate a user to apply an autopar platform.
In a first aspect, a block device complex driving method is provided, the method is based on an autopar platform, and the block device complex driving method includes:
constructing a device registry, and statically registering a list of drive types, wherein the list is named BlkDevRegItem, and each list at least comprises the following data members: class number, device name, device number, device entity;
constructing a device mapping table, wherein the device mapping table comprises a plurality of mapping table items BlkDevevMappingItems, and each BlkDevevMappingItem is responsible for associating a device name with an identifier for a client to use;
building block device examples, including BlkDev MappingItem and BlkDev Op construct pointers to the registry; wherein BlkDev MappingItem pointed to in the registry is used for information acquisition by BlkDev Op; the BlkDev Op structure body pointer is a function pointer which stores the specific implementation of opening, closing and reading operations;
BlkDev Op is constructed, associating an operation lookup table for each instance of the drive.
In the technical scheme, the complex driving design and development work of the block equipment under the Autosar is subjected to consistency constraint through mechanisms such as a design method, a programming framework and the like. Make up for the standardized constraints of the Autosar authorities on this part of the complex drive. The standardization of the complex driving programming model of the block type equipment is also beneficial to improving the quality of software and accelerating the positioning problem and solving the efficiency.
In a specific embodiment, each of the entries includes at least the following data members: class number, device name, device number, device entity, specifically comprising:
the said class number: the same equipment type uses the same equipment class number, uint32;
the device name: the name assigned to the device by the developer, char, must be globally unique;
the device number: the same class of devices does not allow the use of the same device number, uint32;
the device entity: one entity is equal to one instance, blkbev entity;
the method also comprises a last item and a next item, wherein the last item points to another BlkDevRegItem; while the next item points to another blkdievregitem.
In a specific embodiment, the device mapping table includes the following:
an identifier: globally unique, recyclable;
pointing to a certain entry BlkDevRegItem in the registry;
status: the state associated with the identifier is maintained.
In a specific embodiment, the blkbev op specifically comprises:
an operation of opening the device;
closing the operation of the drive;
a read operation;
a write operation;
IO control operations.
In a specific embodiment, the device map and the device registry are global data structures.
In a specific implementation manner, the device mapping table is used for searching the mapped parameters according to the request, and has functions of duplication checking, verification and error correction.
In a second aspect, there is provided a block device complex drive system, the system comprising:
the device registry is responsible for statically registering a table of drive types, and the table is named BlkDevRegItem, and each table at least comprises the following data members: class number, device name, device number, device entity;
the device mapping table comprises a plurality of mapping table items BlkDevevMappingItems, and each BlkDevevMappingItem is responsible for associating a device name with an identifier for use by a client;
a block device instance containing a BlkDevevMappingItem and BlkDevevOp structure pointer to the registry; wherein BlkDev MappingItem pointed to in the registry is used for information acquisition by BlkDev Op; the BlkDev Op structure body pointer is a function pointer which stores the specific implementation of opening, closing and reading operations;
BlkDev op associates one operation lookup table for each driven instance.
In the technical scheme, the complex driving design and development work of the block equipment under the Autosar is subjected to consistency constraint through mechanisms such as a design method, a programming framework and the like. Make up for the standardized constraints of the Autosar authorities on this part of the complex drive. The standardization of the complex driving programming model of the block type equipment is also beneficial to improving the quality of software and accelerating the positioning problem and solving the efficiency.
In a specific embodiment, the class number: the same equipment type uses the same equipment class number, uint32;
the device name: the name assigned to the device by the developer, char, must be globally unique;
the device number: the same class of devices does not allow the use of the same device number, uint32;
the device entity: one entity is equal to one instance, blkbev entity;
each table item further comprises a last item and a next item, wherein the last item points to another BlkDevRegItem; while the next item points to another blkdievregitem.
In a specific embodiment, the device mapping table includes the following:
an identifier: globally unique, recyclable;
pointing to a certain entry BlkDevRegItem in the registry;
status: the state associated with the identifier is maintained.
In a third aspect, there is provided an electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the block device complex driving method as claimed in any one of the preceding claims when executing the program.
In a fourth aspect, a non-transitory computer readable storage medium is provided, the non-transitory computer readable storage medium storing computer instructions for causing the computer to perform any of the block device complex driving methods described above.
In a fifth aspect, there is also provided a computer program product comprising instructions which, when run on a computer, cause the computer to perform the method of any one of the possible designs of the first aspect and the first aspect of the present application.
In addition, the technical effects of any of the possible design manners in the third aspect to the fifth aspect may be referred to as effects of different design manners in the method section, and are not described herein.
Drawings
For a clearer description of one or more embodiments of the present description or of the solutions of the prior art, the drawings that are necessary for the description of the embodiments or of the prior art will be briefly described, it being apparent that the drawings in the description below are only one or more embodiments of the present description, from which other drawings can be obtained, without inventive effort, for a person skilled in the art.
Fig. 1 is a block diagram of a complex driving system of a block device according to an embodiment of the present application;
fig. 2 is a schematic diagram of the complex driving system of the block device and other Autosar modules according to the embodiment of the present application;
FIG. 3 is a schematic diagram of information interaction of each part in a block device complex security driver tried to be provided in the application;
fig. 4 is a block diagram of an electronic device according to an embodiment of the present application.
Detailed Description
For the purposes of promoting an understanding of the principles and advantages of the disclosure, reference will now be made to the embodiments illustrated in the drawings and specific language will be used to describe the same.
It is noted that unless otherwise defined, technical or scientific terms used in one or more embodiments of the present disclosure should be taken in a general sense as understood by one of ordinary skill in the art to which the present disclosure pertains. The use of the terms "first," "second," and the like in one or more embodiments of the present description does not denote any order, quantity, or importance, but rather the terms "first," "second," and the like are used to distinguish one element from another. The word "comprising" or "comprises", and the like, means that elements or items preceding the word are included in the element or item listed after the word and equivalents thereof, but does not exclude other elements or items. The terms "connected" or "connected," and the like, are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. "upper", "lower", "left", "right", etc. are used merely to indicate relative positional relationships, which may also be changed when the absolute position of the object to be described is changed.
The technical carriers involved in payment in the embodiments of the present disclosure may include, for example, near field communication (Near Field Communication, NFC), WIFI, 3G/4G/5G, POS machine card swiping technology, two-dimensional code scanning technology, bar code scanning technology, bluetooth, infrared, short message (Short Message Service, SMS), multimedia message (Multimedia Message Service, MMS), and the like.
In order to facilitate understanding of the complex driving method of the block device provided by the embodiment of the application, an application scenario thereof is first described. The complex driving method of the block equipment is used for facilitating driving design of a user. In the architecture of Autosar, complex drivers are located between the controller hardware and the Autosar RTE layer (interface). Complex drives are an off-specification system component. Since in the abstract design of Autosar, it is not specified how the developer designs the complex driver of the block device, and how the application interacts with the complex driver of the block device, and how the complex driver of the block device is implemented internally. We claim this part as a non-standard module of Autosar, which needs to be designed and implemented by the specific user on his own according to the specific intention. The code of the Autosar standard module may be manually implemented or automatically generated, typically by purchasing commercial software development kits and commercial tools to obtain the system environment and development capabilities on a particular hardware platform. Such as Vector, ETAS, EB, parasoft from mainstream suppliers. However, in different mainstream Autosar products, there is no unified (even conceptual-level) definition and design paradigm for complex drives of block devices. As a developer of an Autosar application system, there is no unified framework for developing own block device drivers on different hardware platforms and different Autosar platforms. Therefore, the embodiment of the application provides a complex driving method of block equipment, which is used for facilitating the design of a user. For ease of understanding, the following detailed description is provided in connection with the accompanying drawings.
First, a block device is described, and from the perspective of the type of computer device, there is a device that may be referred to as a block device. The method is characterized by comprising the following steps: random reading, random erasing, power-down saving, controllable IO attribute, synchronous and asynchronous reading and writing, hard buffer area, bulk reading and writing and the like.
The embodiment of the invention provides a complex driving equipment model for computer block equipment, which describes a programming design method and a matched frame design for an Autosar platform. Meanwhile, the capability of an Autosar block device driver developer can be provided: the implementation method of the complex drive of all block devices is normalized by using the same design paradigm, programming paradigm and concept paradigm, so that the universality, portability and robustness of the device drive are improved on a certain level.
In the embodiment of the application, the design and development work of the complex drive of the block device under Autosar is subjected to consistency constraint through mechanisms such as a design method, a programming framework and the like. Make up for the standardized constraints of the Autosar authorities on this part of the complex drive. The standardization of the complex driving programming model of the block type equipment is also beneficial to improving the quality of software and accelerating the positioning problem and solving the efficiency.
In order to facilitate understanding of the method, first, a hardware structure corresponding to the block device complex driving method provided in the embodiment of the present application is described in detail.
Referring to fig. 1, fig. 1 shows a block device complex driving system provided in an embodiment of the present application. The overall frame structure of the system comprises: application, run time Env, BLK device complex drive architecture (block device complex drive framework), and control hardware. The number of applications may be three as shown in fig. 1, and are named as ApplicationA, applicationB and Application c for convenience of description. The above application is a client using a complex drive system of a block device. The multiple clients can share the same device driver, and the synchronization problem is solved by the writer of the driver in the operation function, which is not described in detail herein.
Run time Env abstracts the entire software system into a stack of application-callable interface behaviors, the specification of which conforms to the Autosar standard.
The same driving framework can have multiple driving types, such as SPI, keyboard, touch screen, GPU, etc. In addition, the same drive type can have multiple device instances, as on a chip, and multiple Flash hardware interfaces. Illustratively, BLK devices drive class A1-3, and BLK devices drive class B1-2. Of course, other types of driving may be used in addition to the examples described above, and are not illustrated here.
The complex driving framework of the block device can accept the request of the client and control the hardware through the device driving program, thereby indirectly achieving the purpose of controlling the hardware by the application program. In addition, if the device driver wants to complete a complete function, the device driver needs to achieve the purposes of synchronization, resource allocation, authority management, storage and the like through the use of other Autosar modules.
Referring to fig. 2, correspondence is shown when the block device complicates the relationship of the driving frame and other Autosar modules. Different classes can interact with other Autosar modules to realize interrupt management, diagnostic services, state management, encryption services, memory management, and the like. Exemplary, the BLK device drives the class a examples 1, 2, and 3, the BLK device drives the class B examples 1 and 2, and the BLK device drives the class C example 1 to implement interaction conditions such as interrupt management, diagnostic service, status management, encryption service, and memory management with other Autosar modules, as shown in fig. 2.
As can be seen from fig. 2, the block device complex driver framework responds to requests from all clients, managing all block device drivers down. The driver includes multiple classes (BLK device driver class a, BLK device driver class B, BLK device driver class C). Wherein each class may have single and multiple instances, such as instance 1, 2, 3 in BLK device drive class a, instance 1, 2 in BLK device drive class B, and instance 1 in BLK device drive class C. Furthermore, the implementation may be different for each instance in each category (depending on the device serial number), and the system level services that each instance relies on may be different (e.g., nvFlash and the interrupt number required by the touchpad are certainly different).
All system services are theoretically available to all drivers, but the driver itself is required to be responsible for solving all synchronization problems. In addition, all the block devices are complex driven examples, and the system service is used in the same way as the local service is used mutually. In particular implementations, the driver code runs in a task context, not in an OS context.
Referring also to fig. 3, fig. 3 shows the information interaction between parts in a drive model in a block device drive framework.
The driving model specifically comprises:
device registry (blkdievregtbl) which is responsible for static registration (temporarily excluding dynamic registration) a table of drive categories, named blkdievregitem, each containing the following data members: class number, device name, device number, device entity.
Specifically, the category No.: the same device type uses the same device class number, uint32. Device name: the name that the developer gives to the device, char, must be globally unique. Device number: the same class of devices does not allow the same device number to be used, uint32. The device entity: one entity is equal to one instance, blkbev entity. In addition, each table entry further includes a last entry and a next entry, wherein the last entry points to another BlkDevRegItem; while the next item points to another blkdievregitem. The two pointers of the previous item and the next item enable BlkDev regTbl to be provided with tables with linear, annular, balanced tree and other structures, and the speed of searching and inserting data can be improved according to specific performance requirements, and the patent is not limited specifically.
A device mapping table (blkdiev mappingtbl), the device mapping table containing a plurality of mapping table entries blkdiev mappingitems, each blkdiev mappingitem being responsible for associating a device name with an identifier for use by a client. And the equipment mapping table can search the mapped parameters according to the request and has the functions of duplication checking, checking and error correction.
BlkDevevMappingTbl has the following structure:
an identifier: globally unique, recoverable multiplexing.
Points to a certain entry BlkDevRegItem in the registry.
Status: maintaining the state associated with the identifier, such as open, closed, error, etc., facilitates recycling.
A block device instance (blkbev entity) containing a blkbev map ingitem and a blkbev op structure pointer to the registry; wherein BlkDev MappingItem pointed to in the registry is used for information acquisition by BlkDev Op; and the BlkDev Op structure body pointer is a function pointer which stores specific implementation of operations such as opening, closing, reading and writing.
BlkDev op: an operation lookup table is associated for each driven instance. The method specifically comprises the following operations:
an operation of opening the device;
closing the operation of the drive;
a read operation;
a write operation;
IO control operations.
When information interaction is specifically performed, the interaction mode is shown by an arrow in fig. 3. Wherein, the single-phase arrow is a unidirectional reference; and the double-headed arrow is a double-headed reference. While the right-hand funcxx is the operating function associated to the device.
In the above arrangement, the device registry (blkdiev regtbl) and the device mapping table (blkdiev mappingtbl) are global data structures. The whole system (or framework) is initially powered up with BlkDevevMappinTbl empty.
Reference may be made to the following steps in the specific operation:
1) Opening the device: when the client uses OpenBlkDev to open the device, returning a global unique identifier for an application program to use; in the process of opening the device, an entry is added to the Mapping table, necessary data is filled, and a reference count is added to the device registration BlkDevRegItem for synchronous operation.
2) Registration device: a device driver is registered using RegBlkDEV, the process assigns a class number, a device number, and initializes the corresponding BlkDEV Entity data.
3) And (3) association operation: the corresponding BlkDevOp and BlkDevEntity constructs were related using SetBlkDevOp.
4) Read operation: parameters such as identifier returned by the incoming openblkev, buffer, buffer size, etc. are used by readblkev.
5) Write operation: and using the parameters of WriteBlkDev, an incoming device identifier, data to be written, length to be written and the like.
6) Device control operation: using ctlblkbev, an incoming identifier, control type, control data length.
7) And (3) equipment diagnosis: using diagblkbev, incoming identifier, diagnostic service number, diagnostic code, buffer, length, etc.
As can be seen from the above description, the system provided in the embodiment of the present application performs consistency constraint on the design and development of complex drivers of block devices under Autosar through mechanisms such as a design method and a programming framework. Make up for the standardized constraints of the Autosar authorities on this part of the complex drive. The standardization of the complex driving programming model of the block type equipment is also beneficial to improving the quality of software and accelerating the positioning problem and solving the efficiency.
The embodiment of the application also provides a block device complex driving method based on the Autosar platform, and the block device complex driving system described above is specifically applied. The block device complex driving method comprises the following steps:
constructing a device registry, and statically registering a list of drive types, wherein the list is named BlkDevRegItem, and each list at least comprises the following data members: class number, device name, device number, device entity; wherein, the category number: the same equipment type uses the same equipment class number, uint32; device name: the name assigned to the device by the developer, char, must be globally unique; device number: the same class of devices does not allow the use of the same device number, uint32; the device entity: one entity is equal to one instance, blkbev entity; in addition, the data member further comprises a last item and a next item, wherein the last item points to another BlkDevRegItem; while the next item points to another blkdievregitem.
Constructing a device mapping table, wherein the device mapping table comprises a plurality of mapping table items BlkDevevMappingItems, and each BlkDevevMappingItem is responsible for associating a device name with an identifier for a client to use; wherein, the device mapping table contains the following contents: an identifier: globally unique, recyclable; pointing to a certain entry BlkDevRegItem in the registry; status: the state associated with the identifier is maintained. The device mapping table is used for searching the mapped parameters according to the request, and has the functions of duplication checking, checking and error correction.
Building block device examples, including BlkDev MappingItem and BlkDev Op construct pointers to the registry; wherein BlkDev MappingItem pointed to in the registry is used for information acquisition by BlkDev Op; and the BlkDev Op structure body pointer is a function pointer which stores the specific implementation of the read-write operation of opening and closing.
BlkDev Op is constructed, associating an operation lookup table for each instance of the drive. Specifically, blkbev op specifically includes: an operation of opening the device; closing the operation of the drive; a read operation; a write operation; IO control operations.
Reference is made in particular to the detailed description of figures 1 to 3 above.
In the technical scheme, the complex driving design and development work of the block equipment under the Autosar is subjected to consistency constraint through mechanisms such as a design method, a programming framework and the like. Make up for the standardized constraints of the Autosar authorities on this part of the complex drive. The standardization of the complex driving programming model of the block type equipment is also beneficial to improving the quality of software and accelerating the positioning problem and solving the efficiency.
The embodiment of the application also provides electronic equipment, which comprises a memory, a processor and a computer program stored on the memory and capable of running on the processor, and is characterized in that the processor executes the program to realize the complex driving method of the block equipment.
The embodiment of the application also provides a non-transitory computer readable storage medium, wherein the non-transitory computer readable storage medium stores computer instructions, and the computer instructions are used for enabling a computer to execute the complex driving method of any piece of equipment.
Embodiments of the present application also provide a computer program product comprising instructions which, when run on a computer, cause the computer to perform the method of any one of the possible designs described above.
It should be noted that the methods of one or more embodiments of the present description may be performed by a single device, such as a computer or server. The method of the embodiment can also be applied to a distributed scene, and is completed by mutually matching a plurality of devices. In the case of such a distributed scenario, one of the devices may perform only one or more steps of the methods of one or more embodiments of the present description, the devices interacting with each other to accomplish the methods.
The foregoing describes specific embodiments of the present disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.
For convenience of description, the above devices are described as being functionally divided into various modules, respectively. Of course, the functions of each module may be implemented in one or more pieces of software and/or hardware when implementing one or more embodiments of the present description.
The device of the foregoing embodiment is configured to implement the corresponding method in the foregoing embodiment, and has the beneficial effects of the corresponding method embodiment, which is not described herein.
Fig. 4 shows a more specific hardware architecture of an electronic device according to this embodiment, where the device may include: a processor 1010, a memory 1020, an input/output interface 1030, a communication interface 1040, and a bus 1050. Wherein processor 1010, memory 1020, input/output interface 1030, and communication interface 1040 implement communication connections therebetween within the device via a bus 1050.
The processor 1010 may be implemented by a general-purpose CPU (Central Processing Unit ), microprocessor, application specific integrated circuit (Application Specific Integrated Circuit, ASIC), or one or more integrated circuits, etc. for executing relevant programs to implement the technical solutions provided in the embodiments of the present disclosure.
The Memory 1020 may be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory ), static storage device, dynamic storage device, or the like. Memory 1020 may store an operating system and other application programs, and when the embodiments of the present disclosure are implemented in software or firmware, the associated program code is stored in memory 1020 and executed by processor 1010.
The input/output interface 1030 is used to connect with an input/output module for inputting and outputting information. The input/output module may be configured as a component in a device (not shown) or may be external to the device to provide corresponding functionality. Wherein the input devices may include a keyboard, mouse, touch screen, microphone, various types of sensors, etc., and the output devices may include a display, speaker, vibrator, indicator lights, etc.
Communication interface 1040 is used to connect communication modules (not shown) to enable communication interactions of the present device with other devices. The communication module may implement communication through a wired manner (such as USB, network cable, etc.), or may implement communication through a wireless manner (such as mobile network, WIFI, bluetooth, etc.).
Bus 1050 includes a path for transferring information between components of the device (e.g., processor 1010, memory 1020, input/output interface 1030, and communication interface 1040).
It should be noted that although the above-described device only shows processor 1010, memory 1020, input/output interface 1030, communication interface 1040, and bus 1050, in an implementation, the device may include other components necessary to achieve proper operation. Furthermore, it will be understood by those skilled in the art that the above-described apparatus may include only the components necessary to implement the embodiments of the present description, and not all the components shown in the drawings.
The computer readable media of the present embodiments, including both permanent and non-permanent, removable and non-removable media, may be used to implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device.
Those of ordinary skill in the art will appreciate that: the discussion of any of the embodiments above is merely exemplary and is not intended to suggest that the scope of the disclosure, including the claims, is limited to these examples; combinations of features of the above embodiments or in different embodiments are also possible within the spirit of the present disclosure, steps may be implemented in any order, and there are many other variations of the different aspects of one or more embodiments described above which are not provided in detail for the sake of brevity.
Additionally, well-known power/ground connections to Integrated Circuit (IC) chips and other components may or may not be shown within the provided figures, in order to simplify the illustration and discussion, and so as not to obscure one or more embodiments of the present description. Furthermore, the apparatus may be shown in block diagram form in order to avoid obscuring the one or more embodiments of the present description, and also in view of the fact that specifics with respect to implementation of such block diagram apparatus are highly dependent upon the platform within which the one or more embodiments of the present description are to be implemented (i.e., such specifics should be well within purview of one skilled in the art). Where specific details (e.g., circuits) are set forth in order to describe example embodiments of the disclosure, it should be apparent to one skilled in the art that one or more embodiments of the disclosure can be practiced without, or with variation of, these specific details. Accordingly, the description is to be regarded as illustrative in nature and not as restrictive.
While the present disclosure has been described in conjunction with specific embodiments thereof, many alternatives, modifications, and variations of those embodiments will be apparent to those skilled in the art in light of the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may use the embodiments discussed.
The present disclosure is intended to embrace all such alternatives, modifications and variances which fall within the broad scope of the appended claims. Any omissions, modifications, equivalents, improvements, and the like, which are within the spirit and principles of the one or more embodiments of the disclosure, are therefore intended to be included within the scope of the disclosure.
Claims (10)
1. The complex driving method of the block equipment is based on an Autosar platform and is characterized by comprising the following steps of:
constructing a device registry, and statically registering a list of drive types, wherein the list is named BlkDevRegItem, and each list at least comprises the following data members: class number, device name, device number, device entity;
constructing a device mapping table, wherein the device mapping table comprises a plurality of mapping table items BlkDevevMappingItems, and each BlkDevevMappingItem is responsible for associating a device name with an identifier for a client to use;
building block device examples, including BlkDev MappingItem and BlkDev Op construct pointers to the registry; wherein BlkDev MappingItem pointed to in the registry is used for information acquisition by BlkDev Op; the BlkDev Op structure body pointer is a function pointer which stores the specific implementation of opening, closing and reading operations;
BlkDev Op is constructed, associating an operation lookup table for each instance of the drive.
2. The block device complex driving method according to claim 1, wherein each table entry comprises at least the following data members: class number, device name, device number, device entity, specifically comprising:
the said class number: the same equipment type uses the same equipment class number, uint32;
the device name: the name assigned to the device by the developer, char, must be globally unique;
the device number: the same class of devices does not allow the use of the same device number, uint32;
the device entity: one entity is equal to one instance, blkbev entity;
the method also comprises a last item and a next item, wherein the last item points to another BlkDevRegItem; while the next item points to another blkdievregitem.
3. The block device complex driving method according to claim 2, wherein the device mapping table contains the following:
an identifier: globally unique, recyclable;
pointing to a certain entry BlkDevRegItem in the registry;
status: the state associated with the identifier is maintained.
4. A block apparatus complex driving method according to claim 3, wherein said blkbev op specifically comprises:
an operation of opening the device;
closing the operation of the drive;
a read operation;
a write operation;
IO control operations.
5. The block device complex driving method of claim 4, wherein the device mapping table and the device registry are global data structures.
6. The block device complex driving method according to any one of claims 1 to 5, wherein the device mapping table is used for searching the mapped parameters according to the request, and has functions of duplication checking, verification and error correction.
7. A block device complex drive system, comprising:
the device registry is responsible for statically registering a table of drive types, and the table is named BlkDevRegItem, and each table at least comprises the following data members: class number, device name, device number, device entity;
the device mapping table comprises a plurality of mapping table items BlkDevevMappingItems, and each BlkDevevMappingItem is responsible for associating a device name with an identifier for use by a client;
a block device instance containing a BlkDevevMappingItem and BlkDevevOp structure pointer to the registry; wherein BlkDev MappingItem pointed to in the registry is used for information acquisition by BlkDev Op; the BlkDev Op structure body pointer is a function pointer which stores the specific implementation of opening, closing and reading operations;
BlkDev op associates one operation lookup table for each driven instance.
8. The block device complex driving system according to claim 7, wherein,
the said class number: the same equipment type uses the same equipment class number, uint32;
the device name: the name assigned to the device by the developer, char, must be globally unique;
the device number: the same class of devices does not allow the use of the same device number, uint32;
the device entity: one entity is equal to one instance, blkbev entity;
each table item further comprises a last item and a next item, wherein the last item points to another BlkDevRegItem; while the next item points to another blkdievregitem.
9. The block device complex driving system of claim 8, wherein the device mapping table comprises the following:
an identifier: globally unique, recyclable;
pointing to a certain entry BlkDevRegItem in the registry;
status: the state associated with the identifier is maintained.
10. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the block device complex driving method of any one of claims 1 to 6 when the program is executed by the processor.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311243071.XA CN117331616A (en) | 2023-09-25 | 2023-09-25 | Complex driving method and system for block equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311243071.XA CN117331616A (en) | 2023-09-25 | 2023-09-25 | Complex driving method and system for block equipment |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117331616A true CN117331616A (en) | 2024-01-02 |
Family
ID=89294466
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311243071.XA Pending CN117331616A (en) | 2023-09-25 | 2023-09-25 | Complex driving method and system for block equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117331616A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114625358A (en) * | 2022-03-16 | 2022-06-14 | 中国第一汽车股份有限公司 | A universal character device driving system and method |
-
2023
- 2023-09-25 CN CN202311243071.XA patent/CN117331616A/en active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114625358A (en) * | 2022-03-16 | 2022-06-14 | 中国第一汽车股份有限公司 | A universal character device driving system and method |
| CN114625358B (en) * | 2022-03-16 | 2025-06-03 | 中国第一汽车股份有限公司 | A universal character device driving system and method |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11861375B2 (en) | Configuration for application using microservices | |
| US9934005B2 (en) | Dynamically building locale objects or subsections of locale objects based on historical data | |
| TWI577539B (en) | Computer implementation method for runtime system, computer readable storage memory and system | |
| CN108108239A (en) | Method and device for providing service function and computer readable storage medium | |
| US9003363B2 (en) | Device flags | |
| US10187479B2 (en) | Cloud-scale heterogeneous datacenter management infrastructure | |
| US9292270B2 (en) | Supporting dynamic behavior in statically compiled programs | |
| EP4144573A1 (en) | Systems and methods for accessing charging capabilities of electric vehicle charging stations | |
| US20150121055A1 (en) | Flexible bootstrap code architecture | |
| EP4155935A1 (en) | Cloud migration for legacy on-premises process code | |
| CN117331616A (en) | Complex driving method and system for block equipment | |
| US9836282B2 (en) | Separation of concerns between information technology services models | |
| CN102591710A (en) | Sharing object representations | |
| US9141353B2 (en) | Dynamically building locale objects at run-time | |
| CN110837446A (en) | Equipment management method and device applied to embedded system, medium and embedded equipment | |
| Yang et al. | Professional Microsoft Smartphone Programming | |
| CN104142817A (en) | Method and device for measuring resource usage of users in Java applications | |
| EP4191492A1 (en) | Transaction engine | |
| CN114625358B (en) | A universal character device driving system and method | |
| CN113035336A (en) | Social security docking method, device and system for hospital information system and electronic equipment | |
| CN114860436B (en) | A memory crash prevention method and device based on Linux environment | |
| CN112527249A (en) | Window processing method and device, electronic equipment and storage medium | |
| US9792093B2 (en) | Dynamically building subsections of locale objects at run-time | |
| CN117391670A (en) | Charged detection method and device based on digital test |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |