Automatic application programming interface (API) generation for functional blocks

A method of generating an application programming interface (API) for an electronic circuit. A graphical user interface is displayed through which a user can initiate generation of the API. A component is selected from a plurality of components for placement in said electronic circuit. The component represents an implementable function in the electronic circuit. The component is configured using the graphical user interface. The data pertaining to the selected component and the configuration of the component is stored. The graphical user interface is utilized to access the stored data. The interface is initiated to invoke a processing of said data which causes a generation of the application programming interface. The application interface is for controlling the function of the component in said electronic circuit.

FIELD OF THE INVENTION

The present invention relates to providing APIs (application programming interfaces) for programmed electronic circuits. More specifically, the present invention provides a software application which automatically generates APIs relative to components in a programmed electronic device.

BACKGROUND OF THE INVENTION

A circuit designer determines the various functions that are necessary for proper operation of a programmable electronic device being created. Once the designer has determined the required functions, the functions are organized and placed in accordance with available resource constraints regarding the electronic device and the system into which the electronic device will be implemented.

A circuit designer further needs to determine the various interconnections between the functions and configure the input/output pins. Subsequently, the designer needs to configure the functions within the programmable electronic device. Conventionally performed manually, configuration includes placing the functions within the programmable electronic device, mapping the functions for connections, configuring multifunction input/output ports or pins which typically contain multiple registers that require programming. The programming of the registers configure the pin type and drive characteristics of the input/output pins.

Designers commonly use data sheets to describe the electronic circuit they designed and have configured. Subsequent to the configuration of the programmable electronic device, API's (application programming interfaces) are needed in order to interact with the electronic device to instruct the electronic device to perform its embedded functions. The programmer needs to know all of the registers and other technical information required to instruct the programmable electronic device to invoke the embedded functions, e.g., start timing, stop timing, etc. Manual programming is tedious and prone to programming errors and difficult to debug, the process of correcting errors within the programming.

Therefore, it would be advantageous to provide a method which provides an user friendly interface for circuit designing, configuration, and programming. It would be further advantageous to provide such a method that assists in the reduction of programming errors. It would be further advantageous to provide such a method which frees designers and programmers from remembering registers and other technical information, such as pin configurations, that invoke the embedded functions within a programmable electronic device.

SUMMARY OF THE INVENTION

Thus, the present invention provides a method which provides an user friendly interface for circuit designing, configuration, and programming. The present invention further provides such a method and which assists in the reduction of programming errors. The present invention further provides such a method which frees designers and programmers from remembering registers and other technical information, such as pin configurations, that invoke the embedded functions within a programmable electronic device.

Embodiments of the present invention provide a convenient user-friendly graphical user interface for designing, configuring, and programming electronic circuits and devices. Embodiments further provide for a method which provides a reduction in programming errors. Embodiments provide for such a method which does not require circuit designer to memorize registers and other technical information that invoke the embedded functions of programmable electronic circuits or devices.

A method to generate APIs (application programming interface) for an electronic circuit is described. In a method embodiment, a graphical user interface is displayed through which a user can initiate generation of the API. A component is selected from a plurality of components for placement in said electronic circuit. The component represents an implementable function in the electronic circuit. The component is configured using the graphical user interface. The data pertaining to the selected component and the configuration of the component is stored. The graphical user interface is utilized to access the stored data. The interface is initiated to invoke a processing of said data which causes a generation of the application programming interface. The application interface is for controlling the function of the component in said electronic circuit.

DETAILED DESCRIPTION

Notation and Nomenclature

It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussions, it is appreciated that throughout the present invention, discussions utilizing terms such as “storing” or “configuring” or “initiating” or “providing” or “selecting” or “generating” or “accessing” or “utilizing” or “invoking” or “setting” or “placing” or “displaying” or the like, refer to the action and processes of a computer system or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

The present invention is discussed primarily in the context of programming an electrical device, such as a microcontroller or an integrated circuit. However, it is appreciated that the present invention may be used to program other electronic devices that have the capability of being programmed. It is further appreciated that, in one embodiment, the programming of an electrical device is performed on a desktop or laptop computer system. It is also appreciated that the present invention can be used with other types of computer systems, e.g., mainframe computers, and portable computer devices, e.g., handheld computers (PDAs), that can provide programming of electronic devices.

It is further appreciated that the present invention is embodied in PSOC and/or PROGRAMMABLE SYSTEM ON A CHIP microcontrollers and in PSOC DESIGNER software, available from Cypress MicroSystems, Inc., of Bothell, Wash. It is also appreciated that PSOC DESIGNER software provides a graphical user interface to facilitate the programming of electronic devices, such as microcontrollers, integrated circuits, and the like, such as is described in co-pending U.S. patent application Ser. No. 09/989,570, filed on Nov. 19, 2001, entitled “METHOD FOR FACILITATING MICROCONTROLLER PROGRAMMING”, by Bartz, et al., and assigned to the assignee of the present invention and incorporated herein by reference.

Exemplary Computer System

With reference toFIG. 1, portions of the present invention are comprised of computer-readable and computer executable instructions which reside, for example, in computer-readable media of an electronic system such as a computer system.FIG. 1illustrates an exemplary computer system150upon which embodiments of the present invention may be practiced. It should be appreciated that computer system150ofFIG. 1is an exemplary representation of a number of different computer systems and electronic devices in which the present invention can operate, including but not limited to desktop computer systems and/or laptop computer systems.

Computer system150includes an address/data bus109for communicating information, a processor101coupled with bus109for processing information and instructions, a non-volatile memory (ROM—read only memory)102coupled with bus109for storing static information and instructions for processor101, and a volatile memory (RAM—random access memory)103coupled with bus109for storing information and instructions for the processor101. Computer system150also includes data storage device104such as a magnetic or optical disk and disk drive coupled with bus109for storing information and instructions. Data storage device104can include one or more removable magnetic or optical storage media, e.g., diskettes, tapes, SD (secure digital) cards, MMC (multi-media cards), which are computer readable memories. Memory units of computer system150include volatile memory103, non-volatile memory102, and data storage device104.

Electronic device150ofFIG. 1can further include an optional signal generating device108, e.g., a wired or wireless network interface card (NIC) coupled with bus109for interfacing with other computer systems and/or other electronic devices. Electronic device150can also include an optional alphanumeric input device106which includes alphanumeric and function keys coupled with bus109for communicating information and command selections to processor101. An optional display device105can be coupled with bus109for displaying information to a computer user. Display device105may be a liquid crystal display (LCD), a cathode ray tube (CRT), a flat panel display such as an FED (field emission display), an electronic paper display, or nearly any other display device suitable for creating and generating graphic images and alphanumeric characters recognizable to a user.

Electronic device150also includes an optional cursor control or directing device107coupled with bus109for communicating user input information and command selections to processor101. Cursor control device107allows the user to dynamically signal the two dimensional movement of a visible symbol (cursor) on a display screen of display device105. Many implementations of cursor control device107are known in the art, including but not limited to, a trackball, mouse, optical mouse, touch pad, touch screen, joystick, or special keys on alphanumeric input device106capable of signaling movement of a given direction or manner of displacement. Alternatively, it is appreciated that a cursor can be directed and/or activated via input from alphanumeric input device106using special keys and/or key sequence commands.

FIG. 2is a block diagram illustrating an exemplary client-server computer system network275, within which embodiments of the present invention may be practiced. Network275may be a communication network located within a firewall of an organization or corporation (an “Intranet”), or network275may represent a portion of the World Wide Web or Internet. Client (or user) computer systems290aand290band server computer system30are communicatively coupled via communication lines273aand273b; the mechanisms for communicatively coupling computer systems over the Internet or over Intranets are well-known in the art.

It is appreciated that in one embodiment, client computer systems290aand290band server computer30have an instancing of the device programming software disposed therein. It is appreciated that, in another embodiment of the present invention, the device programming software can be disposed in computer system290aand in the server computer30. Accordingly, if a company creates a new component/user module/device, or if an existing component/user module/device is modified by that particular company, the information regarding that specific component/user module/device can be made available to that company's clients for updating. In one embodiment, that updated information can be acquired by the client via the Internet. In one embodiment, the data can be configured to be readable by a handheld device, e.g., a PDA (personal digital assistant), such that a PDA can be used to acquire updated or new information, and then transferred to the computer system upon which the device programming software is disposed, e.g., computer system150ofFIG. 1. Once the new or updated information is acquired by the client, the information can be stored in a data storage device, data storage device104ofFIG. 1.

FIG. 3is a screen shot of a starting page300of the device programming software, in one embodiment of the present invention. Starting page300is displayed to a user when the device programming software is initiated. Within starting page300is start selection box301, which provides multiple selections from which a user may choose. In one embodiment, a user may start a new project by clicking on select button310, or alternatively, a user may open an existing project via the browse button311. Browse button311enables a user to retrieve a project that is stored within a memory unit, e.g., data storage device104ofFIG. 1. Subsequent to selection of the project to be opened, via browser button311, a user then selects a subsystem, e.g., function configuration subsystem312, source file editing subsystem313, or debugging subsystem314ofFIG. 3, for utilization in conjunction with the project with which a user is working. The subsystems within the device programming software are dedicated interfaces for providing specific programming functionality. In the instance within the device programming software, there are, in one embodiment, three such subsystems.

The first subsystem is a function configuration subsystem (e.g., the DEVICE EDITOR subsystem)500ofFIGS. 5,6A,6B, and7. The function configuration subsystem is utilized for selecting user modules, placing user modules, setting user parameters, selecting pin values, as described inFIG. 4, and for generating user project files, e.g., user project files408ofFIG. 4.

The second subsystem is a source file editing subsystem (e.g., the APPLICATION EDITOR subsystem)900ofFIG. 9. The source file editing subsystem is for programming the desired functionality into the device, subsequent to the completion of the configuration process. The source file editing subsystem is where source-code programming occurs. The source file editing subsystem source-code programming includes, but is not limited to, editing or modifying files, creating or adding files, removing or deleting files, compiling/assembling files, and building the project. Building the project links all of the programmed functionality of the source files, including device configuration, and loads it into a .rom file, which is the file that a user downloads for debugging and/or device programming.

The third subsystem is a debugging subsystem, e.g., DEBUGGER314ofFIG. 3. The debugging subsystem allows a user to test the project in a hardware environment while viewing and debugging device activity in a software environment.

Still referring toFIG. 3, it is appreciated that the resulting graphical user interface that is displayed to a user is dependent upon which of the subsystems has been selected by a user. In one embodiment,FIG. 5depicts the graphical user interface that is displayed to a user when the subsystem device editor312is selected. It is appreciated that alternative graphical user interfaces are generated which correspond to the subsystem selected by a user.

FIG. 4is a block diagram for describing an overview of the functionality of a function configuration subsystem (e.g., the DEVICE EDITOR subsystem)500ofFIG. 5, a subsystem of the device programming software (e.g., PSOC DESIGNER software), in one embodiment of the present invention. The function configuration subsystem500provides to a user the ability to configure a programmable electronic device, such as a microcontroller, with specific functions as determined by a user. Graphical user interface403, such as those depicted inFIGS. 5,6A,6B, and7, provides an information-rich environment to a user during the editing process. In one embodiment, function configuration subsystem500outputs a user project data file, e.g., user project data file404ofFIG. 4. In one embodiment, function configuration subsystem500outputs a set of user project files, e.g., user project files408. It is appreciated that user project data file404and user project files408can be built and debugged as an embedded application.

Still referring toFIG. 4, in one embodiment, steps to configure a programmable electronic device, e.g., a microcontroller, include creating a new project based upon a selected part. It is appreciated that the data for the selected part can, in one embodiment, be drawn from device data402. Subsequent to creating a new project, user modules are selected to be included in the project. It is appreciated that the data for the selected user modules can, in one embodiment, be drawn from user module data406. User modules can include, but are not limited to UARTs (universal asynchronous receiver transmitters), counters, amplifiers, timers, digital to analog converters, and analog to digital converters. The selected user modules are then placed on the part. The placement of each of the user modules on the part triggers a dynamic update of the user project data, e.g., user project data404. Parameters for each of the placed user modules are then set, which further triggers a dynamic update of user project data404. Pin values are then selected for connection to the appropriate user modules. Subsequent to pin value selection, the user project files, e.g., user project files408, are generated and the user project data, e.g., user project data404, is saved.

Still referring toFIG. 4, GUI403, through which a user observes and inputs their changes, e.g., user inputs405, is driven by device data402and user module data406, in one embodiment of the present invention. It is appreciated that user project data404contains sufficient information, such that, in one embodiment, when that information is combined with device data402and user module data406, user source files can be produced. In one embodiment, user source files can include, but are not limited to, initialization data and routines that realize the configuration when an embedded application is started. Also included in user source files are, in one embodiment, API functions that a user can utilize to control access the user modules. Further included in user source files is a boot file which contains an interrupt vector table. It is appreciated that the interrupt vector table is determined by the placement of the user modules.

It is noted that embodiment of the present invention are drawn to providing an automatic generation of the above mentioned application programming interfaces (APIs) for controlling the embedded functions within an electronic circuit or device, e.g., a programmable electronic device such as a microcontroller. In one embodiment, the generated API is predicated upon, but not limited to, the intended functionality of the electronic circuit or device being developed, the functions contained within the electronic device, the placement and configuration of the functions, the function connections with other functions and with the electronic device, and the resources of the electronic device and the resources of the system into which the electronic device is to be implemented.

FIG. 5depicts, in one embodiment, function configuration subsystem500, a graphical user interface that is generated in response to a user selecting the DEVICE EDITOR subsystem412of the device programming software (e.g., PSOC DESIGNER software), as described inFIG. 3. Within the displayed interface of function configuration subsystem500, there are several active windows. It is appreciated that the subsystems, as described inFIG. 3, comprise multiple active windows. It is further appreciated that each of the subsystems contain their own particular active windows. It is also appreciated that, in one embodiment, a subsystem may have various different active windows which are independently generated depending upon which task a user is performing or which view a user has chosen within the selected subsystem.

Still referring toFIG. 5, function configuration subsystem500is shown in a user module selection view, and to the left is user module window501, which displays, in this embodiment, the user modules or components which are available to be utilized in the current project. In one embodiment, user modules/components can include, but are not limited to, ADCs, DACs, timers, PWMs, and so on. It is through this view that the user modules/components for the current project are selected.

To the right of user module window501are user module information windows502aand502b. In this embodiment, user module information window502ashows a schematic diagram of a selected module, e.g., an ADCINC12_1, and user module information window502bshows the data of the selected module. In user module information window502b, shown is the specific technical information related to the selected user module/component. Additionally, as can be seen along the bottom of window502b, there are multiple select tabs which, when selected, generate data relative to that subject. For example, if a user selects “Specs” from the tabs, the device programming software will display data regarding the specifications of the selected module. It is appreciated that in the event any of the data related to the selected module, in this example, ADCINC12_1is changed, that updated information is displayed in user module information windows502aand502b, respectively.

Referring still toFIG. 5, to the right of window502aand above window502bis resource manager window503, in one embodiment. Resource manager window503displays the available resources, e.g., RAM, ROM, and digital blocks. Window503also displays the amount of those resources which are being used/consumed by the selected module. Above window502aand window503is user module selection window504. Window504displays those modules that are being utilized in the current project. Window504indicates seven user modules are being utilized in the current project. It is appreciated that a project can have a fewer number of modules or a greater number of modules. The number of modules is dependent upon the requirements of a particular project. It is further appreciated that as each module is selected, a graphic representing the selected module is dynamically placed in user module selection window504. It is appreciated that the data regarding the selected user modules/components is stored, e.g., in user module data406ofFIG. 4.

FIG. 6Ashows, in one embodiment, function configuration subsystem500in a module placement view. It is through this view that the selected user modules/components, as described inFIG. 5, are placed. In this embodiment, window501displays the global resources and user module resources relative to the placement of the selected modules for the current project. The global resources are hardware settings that determine the underlying operation of the part (for the entire application). Global resources can include parameters such as, CPU-Clock, which designates the processing speed of the current project. To the right of each of the global resources are corresponding values which can be adjusted in accordance with available values and requirements of the current project. Adjusting the values requires a simple click on the value to generate a list of available values for that particular resource.

In this embodiment, user module selection window504is analogous to window504ofFIG. 5, and is analogously disposed. Beneath window504, in this embodiment, is placer view window505. Placer view window505shows the placement of the modules within the current project.

Still referring toFIG. 6A, module ADCINC12_1, highlighted within window504and indicated by arrow544, is shown to be placed in blocks DBA00and DBA01, respectively, as indicated by the checkered pattern surrounding blocks DBA00and DBA01, and by arrow555. Additionally, the parameters for the selected user module/component, ADCINC12_1are shown in the bottom portion of window501. A displayed question mark indicates unconfigured parameters for that module/component. It is appreciated that for the blocks in placer view window505that have modules placed therein, each has the corresponding module identification, e.g., blocks DBA00and DBA01indicate that module ADCINC12_1is thusly placed.

FIG. 6B, analogous toFIG. 6A, shows the placement of module UART1, as indicated by the highlighting of UART1and arrow545, within user module selection window504. UART1is shown to be placed in blocks DCA06and DCA07, respectively, as indicated by the surrounding checkered pattern and by arrow556, as seen directly beneath window504, on the right side of window505. It is appreciated that as each module is selected and placed, its placement location is graphically shown to a user. It is further appreciated that if a module was to be placed in a different block, that would be dynamically reflected in the display. As described above, the blocks where UART1is placed, DCA06and DCA07show the module identification. It is appreciated that the data related to the placement of the selected user modules/components are stored, e.g., in user project data404ofFIG. 4.

FIG. 7shows function configuration subsystem500in a pin-out view, in one embodiment. It is through this view that the configuration of the pins, e.g., connections, pin types, and drive characteristics are determined. Active window501displays global resources and port and drive pin configurations for the corresponding pin numbers on an electronic circuit shown to the right of window501, in pin-out view window506. In this embodiment, the electronic circuit is shown to be two-sided and containing 48 pins. It is appreciated that the pin-out view is dependent upon the selected part. For example, if the selected part in the current project was a four-sided circuit with 44 pins, instead of the two-sided part with 48 pins, as shown, the pin-out view would generate a representation of that part that would show four sides with eleven pins on each side. In another example, if the selected part in the current project was a ball grid array, that, too, would be graphically represented in pin-out view window506.

Still referring toFIG. 7, each of the pins are configurable by, in one embodiment, selecting the appropriate pin in a pin-out view window, e.g., pin-out view window506. Configuring the pins can also be achieved by selecting the desired pin from the port and drive portion of window501. In either instance, when a pin is selected, a pop-up menu is generated that shows the options available for the selected pin. Additionally, once the options relative to the pin are chosen, the results are dynamically displayed in the port and drive configuration portion of window501and graphically represent in placer view505. Further, subsequent to the options chosen for the selected pin number, connection information is also dynamically displayed within placer view window505. It is appreciated that the data regarding pin placement, connection, and configuration is stored, e.g., in user project data404ofFIG. 4.

Subsequent to completing the selection, placing, and configuration of the user modules/components in the microcontroller, a user needs to generate the APIs (application programming interface) for controlling the user modules of the current project.FIG. 8is a screen shot depicting the ease with which a user can initiate the generation of the API.

FIG. 8shows function configuration subsystem500in pin-out view. To initiate the generation of API related to the current project, a user just clicks on generate application button810. Clicking generate application button810causes the device programming software to instruct the computer system upon which the device programming software is loaded, e.g., computer system150ofFIG. 1, to process the data that has been stored, e.g., device data402, user project data404, and user module data406. The device programming software incorporates the above described data and existing assembly-source and C compiler code (including the project library source, e.g., PSocConfig.asm in source tree window901inFIG. 9) and generates an API (application programming interface) shell, which in one embodiment can include an ISR (interrupt service routine) shell, and which is used by application programmers to cause the user module to do specific functions.

It is appreciated that generate button810does not have to be selected in a function configuration subsystem, e.g., DEVICE EDITOR subsystem500ofFIG. 8, to generate the APIs. It is known by the source file editing subsystem, e.g., source file editing subsystem900ofFIG. 9, that the most current/up-to-date APIs have not been generated, and source file editing subsystem900will, in one embodiment, initiate API generation when the project is built, e.g., selecting build button950ofFIG. 9.

The APIs are, in one embodiment, in the form of .asm (editable assembly language source file), .h (editable assembly language include/header file), and .inc (editable c-language include file) files. It is appreciated that these files are editable, such that a user can alter the contents. In one embodiment, these files can be used to perform common functions that are required to interact with the user module (e.g., how to start the timer, how to stop the timer, how to interact with the timer, etc.). Further, the generation processes receive setting information from a parameterization block are slightly altered thereby such that the proper settings are realized. These files provide the device-interface and interrupt-activity framework for source programming. The API and ISR files can be accessed in a source tree, e.g., source tree window901ofFIG. 9. In addition, the device programming software has further created a data sheet based upon the configurations from function configuration subsystem500ofFIGS. 5,6A,6B, and7.

By using the automatically generated APIs, a user need not be aware of all of the low level registers and other low level technical information required to instruct the user module to invoke its function. The user simply needs to interact with the APIs which are written in a higher level of abstraction.

It is appreciated that generate application button810inFIG. 8can be activated from within any of the three function configuration subsystem window views, e.g., the selection view as shown inFIG. 5, the placement view as shown inFIGS. 6A and 6B, and the pin-out view as shown inFIG. 7.

FIG. 9, shows, in one embodiment, a screen shot depicting activating source file editing subsystem900. To the left is source tree window901, a hierarchical display of the files generated by clicking on generate application button810. To the right is source-file editing window902, which displays those files in source tree window901for facilitating viewing and editing of the source files. Along the bottom of the source file editing subsystem interface is status window903, which displays error messages if there are code problems that occur when the files are compiled and built.

Still referring toFIG. 9, shown in source-file editing window902are assorted files, e.g., files904,905,906,907, and908that were generated when generate application button810was selected. The top most file within window903is a boot.asm file, e.g., boot.asm904, which is updated from its default name, boot.tpl. Each project receives it own particular boot.asm. When Boot.asm is updated, it reflects the current project configurations and which also includes a jump table for interrupt handlers.

Directly below boot.asm904is a main.asm, e.g., main.asm905. Main.asm is also present in each project, and resolves the external reference from the boot sequence. When initially created upon new project creation, the “_main” function contains a simple forever loop.

Beneath main.asm905are ADCINC12_1.inc906, Counter16_1.inc907, and Counter16_1.h908, respectively. Each was retrieved from source tree window901for viewing and editing. By retrieving a source file, it is convenient to edit the generated APIs for customization of the functions they perform, and how the function is performed. It is appreciated that the .asm, .h, and .inc files are named to reflect the user module/component for which they are associated.

It is appreciated that for a user to compile and build the source code, they need to simply click on build button950, also ofFIG. 9.

The operating platform upon which embodiments of the present invention may be practiced is, in one embodiment, a MICROSOFT WINDOWS operating platform commercially available from Microsoft Corporation of Redmond, Wash. However, it is appreciated that other operating platforms may be used to practice embodiments of the present invention.

FIG. 10is a flowchart1000of steps performed in accordance with one embodiment of the present invention for providing a generation of an application programming interface (API) generation for an electronic circuit. Flowchart1000includes processes of the present invention which, in one embodiment, are carried out by processors and electrical components under the control of computer readable and computer executable instructions. The computer readable and computer executable instructions reside, for example, in data storage features such as computer usable volatile memory103and/or computer usable non-volatile memory102ofFIG. 1. However, the computer readable and computer executable instructions may reside in any type of computer readable medium. Although specific steps are disclosed in flowchart800, such steps are exemplary. That is, the present invention is well suited to performing various other steps or variations of the steps recited inFIG. 10. Within the present embodiment, it should be appreciated that the steps of flowchart1000may be performed by software, by hardware or by any combination of software and hardware.

In step1002ofFIG. 10, a graphical user interface is displayed, such as function configuration subsystem500ofFIG. 5, through which a user can initiate the generation of the API (application programming interface), in one embodiment of the present invention.

In step1004ofFIG. 10, a component is, in one embodiment, selected from a number of available components, such as those graphically presented in user module window501ofFIG. 5. It is appreciated that the component represents an implementable function in said electronic circuit being designed.

In step1006ofFIG. 10, the selected component, fromFIG. 5, is configured, in one embodiment, by using the graphical user interface. The process of configuring the selected component/user module comprises placing the component within operation blocks of the electronic circuit being designed, as shown and described in placer view window505ofFIGS. 6A and 6B.

Configuring the component further comprises, in one embodiment, determining pin placement, pin types and drive characteristics, as shown in pin-view window506, user module window501, and placer view504ofFIG. 7.

In step1008ofFIG. 10, the data regarding the current project is seamlessly stored. In one embodiment, the data relating to the electronic device being designed is stored in device data402and user project data404ofFIG. 4. In one embodiment, the data relating to the selected component is stored in user module data406and user project data404ofFIG. 4. In one embodiment, the data relating to the configuration of the component is stored in user project data402ofFIG. 4.

In step1010ofFIG. 10, the interface is utilized to access the stored data. The interface accesses the data stored in device data402, user module data406, and user project data404.

In step1012ofFIG. 10, the interface is initiated to invoke a processing of the stored data which causes a generation of the application programming interface, as described inFIG. 8. The generated application programming interfaces, as shown inFIG. 9, are for controlling the function of the component in the electronic circuit.