Method for parameterizing a user module

[0001] The present invention generally relates to software applications. Specifically, the present invention relates to an application used for designing a microcontroller.

[0002] Microcontrollers function to replace mechanical and electromechanical components in a variety of applications and devices. Since they were first introduced approximately 30 years ago, microcontrollers have evolved to the point where they can be used for increasingly complex applications. Some microcontrollers in use today are also programmable, expanding the number of applications in which they can be used.

[0003] However, even though there are a large number of different types of microcontrollers available on the market with a seemingly wide range of applicability, it is still often difficult for a designer to find a microcontroller that is particularly suited for a particular application. Unique aspects of the intended application may make it difficult to find an optimum microcontroller, perhaps necessitating a compromise between the convenience of using an existing microcontroller design and less than optimum performance.

[0004] In those cases in which a suitable microcontroller is found, subsequent changes to the application and new requirements placed on the application will likely affect the choice of microcontroller. The designer thus again faces the challenge of finding a suitable microcontroller for the intended application.

[0005] Currently, design tools are available for designing, configuring and programming microcontrollers or other programmable electronic devices for providing a desirable microcontroller. Conventional design tools often provide for including a number of selectable microprocessor peripherals in the programmable device. In order to design the peripheral component to provide optimal performance, parameters of the peripheral component are adjusted accordingly. The conventional tools typically require a user to open up a separate application for determining the optimized parameters of selected peripherals. Typically, the separate application must be accessed through the operating system of the computer system, and cannot be accessed directly from the microcontroller design tool.

[0006] Upon completion of parameterizing a user module, the parameterized data is entered into the microcontroller design tool. Currently, the parameterized data must be entered into the microcontroller design tool manually. Unfortunately, many peripherals have complex design techniques, and there are a large number of parameters that must be set. Each parameter may be several digits in length, and may comprise a decimal point and/or may be positive or negative in value. Entering the parameters into the design tool can be very time-consuming, cumbersome and error prone. For example, if a decimal is misplaced, or a value is placed in the wrong parameter field, the peripheral component may not function properly. Since many programmable microcontrollers comprise a number of complex peripheral components, the functionality of the microcontroller may be compromised due to transcription errors.

[0007] Accordingly, a need exists for a method or system for linking an external design tool to a microcontroller design application for helping a user parameterize a user module for a programmable electronic device. A need also exists for a method or system that satisfies the above need and that provides for accessing the external design tool directly from the microcontroller design application. A need also exists for a method or system that satisfies the above needs and provides for loading parameter values from the external design tool directly into the microcontroller design application.

[0008] Embodiments of the present invention provide a method for parameterizing a user module. A first design application corresponding to a parameter of a user module is accessed, wherein the user module is a pre-configured electronic design to be implemented on a microcontroller. In one embodiment the first design application is an external design application for assisting in deriving parameterized data. In one embodiment, the first design application is accessed in response to selecting the parameter within a graphical interface of the second design application. The parameter is adjusted within the first design application to derive parameterized data.

[0009] In response to a command, the parameterized data is automatically loaded into a second design application. In one embodiment, the parameterized data is loaded into a parameter field of a graphical interface of the second design application. In one embodiment the second design application is a microcontroller design application for programming a microcontroller. In one embodiment, the command is closing the first design application. In another embodiment, the command is accessing a transfer control of a graphical interface of the first design application.

[0010] Embodiments of the present invention provide a graphical user interface comprising a first display region and a second display region. The first display region displays a first design application corresponding to a parameter of a user module, wherein a user module is a pre-configured electronic design to be implemented on a microcontroller. The first design application is for adjusting the parameter to derive parameterized data. In one embodiment, the first design application is an external design application for assisting in deriving the parameterized data. In one embodiment, the first design application is accessible in response to selecting the parameter within the second display region.

[0011] The second display region displays a second design application configured to receive the parameterized data in response to a command of the first design application, wherein the parameterized data is loaded into a parameter field of the second display region, wherein the parameter field corresponds to the parameter. In one embodiment, the second design application is a microcontroller design application for programming a microcontroller. In one embodiment, the command is closing the first design application. In another embodiment, the command is accessing a transfer control of a graphical interface of the first design application.

[0022] Reference will now be made in detail to the various embodiments of the invention, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with the various embodiments, it will be understood that they are not intended to limit the invention to these embodiments. On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the invention as defined by the appended claims. Furthermore, in the following detailed description of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be obvious to one of ordinary skill in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the present invention.

[0023] Some portions of the detailed descriptions that follow are presented in terms of procedures, logic blocks, processing, and other symbolic representations of operations on data bits within a computer memory. These descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. In the present application, a procedure, logic block, process, or the like, is conceived to be a self-consistent sequence of steps or instructions leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, although not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated in a computer system. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as transactions, bits, values, elements, symbols, characters, fragments, pixels, or the like.

[0024] 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 “accessing,” “adjusting,” “loading,” “programming,” “assisting,” “closing,” “selecting,” “deriving” or the like, refer to actions and processes (e.g., processes 300 and 800 of FIGS. 3 and 8, respectively) of a computer system or similar electronic computing device. The computer system or similar electronic computing device manipulates and transforms data represented as physical (electronic) quantities within the computer system memories, registers or other such information storage, transmission or display devices. The present invention is well suited to use with other computer systems.

[0025] Refer now to FIG. 1, which illustrates an exemplary computer system 190 upon which embodiments of the present invention may be practiced. In general, computer system 190 comprises bus 100 for communicating information, processor 101 coupled with bus 100 for processing information and instructions, random access (volatile) memory (RAM) 102 coupled with bus 100 for storing information and instructions for processor 101, read-only (non-volatile) memory (ROM) 103 coupled with bus 100 for storing static information and instructions for processor 101, data storage device 104 such as a magnetic or optical disk and disk drive coupled with bus 100 for storing information and instructions, an optional user output device such as display device 105 coupled to bus 100 for displaying information to the computer user, an optional user input device such as alphanumeric input device 106 including alphanumeric and function keys coupled to bus 100 for communicating information and command selections to processor 101, and an optional user input device such as cursor control device 107 coupled to bus 100 for communicating user input information and command selections to processor 101. Furthermore, an optional input/output (I/O) device 108 is used to couple computer system 190 onto, for example, a network.

[0026] Display device 105 utilized with computer system 190 may be a liquid crystal device, cathode ray tube, or other display device suitable for creating graphic images and alphanumeric characters recognizable to the user. Cursor control device 107 allows the computer user to dynamically signal the two-dimensional movement of a visible symbol (e.g., a pointer) on a display screen of display device 105. Many implementations of the cursor control device are known in the art including a trackball, mouse, joystick or special keys on alphanumeric input device 106 capable of signaling movement of a given direction or manner of displacement. It is to be appreciated that the cursor control 107 also may be directed and/or activated via input from the keyboard using special keys and key sequence commands. Alternatively, the cursor may be directed and/or activated via input from a number of specially adapted cursor directing devices.

[0027] Microcontroller suppliers (e.g., commercially available from Cypress MicroSystems in Bothell, Wash.) offer standard parts that combine a microprocessor with several user-configurable “building blocks.” These building blocks may be assembled, configured and programmed to form many standard microprocessor peripherals, as well as to form unique peripherals as may be required by a specific application. Thus, a user can tailor a microcontroller to meet his or her specific requirements, in less time and at less cost than through other means. A microcontroller assembled from these building blocks is referred to herein as a programmable system on a chip (PSoC).

[0028] The present invention is described in the context of a software tool, portions of which are comprised of computer-readable and computer-executable instructions which reside, for example, in computer-usable media of a computer system such as that exemplified by FIG. 1. The present invention is primarily described as being used with a tool for designing configuring, programming, compiling, building (assembling), emulating, and debugging an embedded microcontroller, in particular a class of microcontrollers that provide analog and/or digital subsystems comprising many dynamically configurable blocks. An example of this class is referred to herein as a programmable system on a chip (PSoC). Additional information regarding PSoCs is provided in the co-pending, commonly-owned U.S. patent application Ser. No. 10/033,027, filed Oct. 22, 2001, by W. Snyder, and entitled “Microcontroller Programmable System on a Chip,” hereby incorporated by reference.

[0029] FIG. 2A is a block diagram of an integrated circuit (or microcontroller) 210 that exemplifies a microcontroller which uses the PSoC architecture. In the illustrated embodiment, integrated circuit 210 includes a system bus 211, and coupled to bus 211 are synchronous random access memory (SRAM) 212 for storing volatile or temporary data during firmware execution, central processing unit (CPU) 214 for processing information and instructions, flash read-only memory (ROM) 216 for holding instructions (e.g., firmware), input/output (I/O) pins 218 providing an interface with external devices and the like, and system on a chip (SoC) blocks 225. The SoC blocks 225 include analog blocks and digital blocks, which are further described below (see FIG. 2B).

[0030] Referring to FIG. 2B, an embodiment of SoC block 225 is depicted in greater detail. In this embodiment, SoC block 225 includes an analog functional block 230, a digital functional block 240, and a programmable interconnect 250. Analog block 220 includes, in the present embodiment, a matrix of interconnected analog blocks A1 through AN. The number N may be any number of analog blocks. Likewise, digital block 240 includes, in the present embodiment, a matrix of interconnected digital blocks D1 through DM. The number M may be any number of digital blocks. The analog blocks A1 through AN and the digital blocks D1 through DM are fundamental building blocks that may be combined in different ways to accomplish different functions. Importantly, different combinations of blocks, producing different functions, may exist at different times within the same system. For example, a set of blocks configured to perform the function of analog-to-digital conversion may sample a signal. After processing that signal in the digital domain, those same blocks (perhaps in conjunction with a few others) may be recombined in a different configuration to perform the function of digital-to-analog conversion to produce an output signal.

[0031] Continuing with reference to FIG. 2B, the internal matrices of analog blocks 230 and digital blocks 240 may be constituted, in one embodiment, by a routing matrix described further in the patent application referenced above. Analog blocks 230 and digital blocks 240 are electrically and/or communicatively coupled to programmable interconnect 250, in the present embodiment, by intra-block routing 235. Each individual functional unit, e.g., analog blocks A1 through AN and digital blocks D1 through DM, may communicate and interact with each and/or any other functional unit. Which functional unit communicates with which other functional unit is programmable, in the present embodiment, via the configurability of the programmable interconnect 250. The programmable interconnect 250 is connected via an internal input/output (I/O) bus 236 to pin-by-pin configurable I/O transceivers (pins) 218 (FIG. 2A), which effect communicative coupling between integrated circuit 210 (FIG. 2A) and external modalities. The total pin count of pin-by-pin configurable I/O pins 218 may vary from one application to another, depending on the system device under consideration.

[0032] With reference next to FIG. 3, process 300 illustrates exemplary steps used by a microcontroller design tool in accordance with one embodiment of the present invention. The purpose of process 300 is to configure, program, compile, build, emulate and debug a customized microcontroller (a “target device”) based on the integrated circuit 210 and SoC blocks 225 of FIGS. 2A and 2B.

[0033] In one embodiment, process 300 of FIG. 3 is carried out by a processor 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 memory 102, computer-usable non-volatile memory 103, and/or data storage device 104 of FIG. 1. The computer-readable and computer-executable instructions are used to control or operate in conjunction with, for example, central processing unit 101 of FIG. 1.

[0034] Although specific steps are disclosed in process 300 of FIG. 3, such steps are exemplary. That is, the present invention is well suited to use with various other steps or variations of the steps recited in process 300. Additionally, for purposes of clarity and brevity, the following discussion and examples specifically deal with a microcontroller design tool. The present invention, however, is not limited solely to use with a microcontroller design tool. Instead, the present invention is well suited to use with other types of computer-aided hardware and software design systems in which it is necessary to accomplish a multitude of tasks as part of an overall process.

[0035] In step 310, applicable “user modules” are selected. A user module, as used herein, is a preconfigured function that may be based on more than one SoC blocks. A user module, once placed and programmed, will work as a peripheral on the target device. At any time in process 300, user modules may be added to or removed from the target device.

[0036] The selected user modules can then “placed” or “mapped” onto the SoC blocks 225 of FIG. 2B. Once a user module is placed, its parameters can be viewed and modified as needed. Global parameters used by all of the user modules (for example, CPU clock speed) can also be set.

[0037] Continuing with step 310 of FIG. 3, interconnections between the selected user modules can be specified, either as each user module is placed or afterwards. The pin-out for each PSoC block can be specified, making a connection between the software configuration and the hardware of the target device.

[0038] In step 320, application files can be generated. When application files are generated, existing assembly-source and C compiler code are updated for all device configurations, and application program interfaces (APIs) and interrupt service routines (ISRs) are generated.

[0039] In step 330, the functionality can be programmed into the target device. Source code files can be edited, added or removed.

[0040] In step 340, the assembler process can be executed. The assembler operates on an assembly-language source to produce executable code. This code is compiled and built into an executable file that can be downloaded into an emulator, where the functionality of the target device can be emulated and debugged.

[0041] In step 350, the target device can be “built.” Building the target device links all the programmed functionalities of the source files (including device configuration), which are downloaded to a file for debugging.

[0042] In step 360, the target device can be emulated using an in-circuit emulator for debugging. The emulator allows the target device to be tested in a hardware environment while device activity is viewed and debugged in a software environment.

[0043] FIG. 4 is an exemplary graphical user interface (GUI) 400 as displayed on a computer display comprising a display region 405 in accordance with one embodiment of the present invention. In one embodiment, GUI 400 is displayed on display device 105 of computer system 190 (FIG. 1). It is appreciated that GUI 400 is exemplary only, and that they may include different numbers and shapes of elements and windows other than those that are illustrated.

[0044] In one embodiment, display region 405 is for displaying a design application. In one embodiment, the design application is a microcontroller design application for programming a microcontroller. Display region 405 comprises selected user modules 415, and user module parameters 420. In one embodiment, first display region 405 also comprises menu bar 410 for performing operations within the design application, global resources information 430 for setting parameters for all user modules and user module placement 435 for placing a user module onto the SoC blocks (e.g., SoC blocks 225 of FIG. 2B).

[0045] Selected user modules 415 comprises at least one user module 425. It should be appreciated that selected user modules 415 may comprise any number of user modules (e.g., user modules 425a-n), and is not limited by the present embodiment. In response to a user module being selected, for example user module 425a, parameters corresponding to user module 425a are rendered in user module parameters 420.

[0046] In one embodiment, user module 425a is selected by a user using well-known GUI techniques. That is, for example, a user can position a cursor over an element and “click” a cursor control element (e.g., a mouse) to select an element. In one embodiment, highlighting or changing the color of the user module indicates a selected user module. In another embodiment, a selected user module is by bolding or otherwise altering the text within the user module. In general, a selected user module is rendered in a way that allows the user to readily determine which user module has been selected.

[0047] User module parameters 420 comprises at least one parameter for a selected user module. User module parameters are used to define the operating characteristics of a user module. A parameter has a corresponding field for inputting a value for the parameter. It should be appreciated that user module parameters 420 may comprise any number of parameters and corresponding fields (e.g., parameters 1-n and fields 1-n), and are not limited to the present embodiment. The number of parameters and corresponding fields within user module parameters 420 is dependent on the parameters defined within a selected user module.

[0048] A parameter value for a parameter is input into the corresponding field. In one embodiment, an external design application is used for assisting in deriving the parameterized data for a parameter. In one embodiment, a parameter is selected by a user using well-known GUI techniques, as described above. In response to the parameter being selected, an external design application is opened in a different display region for assisting in deriving parameterized data.

[0049] FIG. 5 is an exemplary graphical user interface 500 as displayed on a computer display comprising a first display region 505 and a second display region 405 in accordance with one embodiment of the present invention. In one embodiment, GUI 500 is displayed on display device 105 of computer system 190 (FIG. 1). It is appreciated that GUI 400 is exemplary only, and that they may include different numbers and shapes of elements and windows other than those that are illustrated.

[0050] In one embodiment, display region 505 is for displaying a design application. In one embodiment, the design application is an external design application for assisting in deriving parameterized data 515. It should be appreciated that the design application may be any computer application used for calculating data. In one embodiment, the design application is a spreadsheet application. In one embodiment, display region 505 comprises menu bar 510 for performing operations within the design application and transfer control 520 for loading parameterized data 515 into a microcontroller design application.

[0051] The parameter is adjusted within the external design application, resulting in parameterized data 515. In response to a command, parameterized data 515 is automatically load into a microcontroller design application (e.g., the design application of second display region 405). In one embodiment, the command is closing the external design application. For example, upon exiting the external design application, parameterized data 515 is automatically loaded into the microcontroller design application. In another embodiment, the command is accessing transfer control 520. For example, upon accessing transfer control 520, parameterized data 515 is automatically loaded into the microcontroller design application. It should be appreciated that transfer control 520 can be accessed by a user using well-known GUI techniques.

[0052] In one embodiment, parameterized data 515 is loaded into a parameter field corresponding to the selected parameter within the microcontroller design application. For example, parameter 1 of user module parameters 420 of FIG. 4 is selected. An external design application (e.g., the design application of first display region 505 of FIG. 5) is accessed for assisting in deriving parameterized data 515 of FIG. 5. Upon determining parameterized data 515, a command is issued (e.g., closing the external design application or accessing transfer control 520 of FIG. 5). In response to the command, parameterized data 515 is automatically loaded into field 1 of user module parameters 420 of FIG. 4.

[0053] FIG. 6 is an exemplary screen shot of GUI 600 comprising microcontroller design application 605 in accordance with one embodiment of the present invention. GUI 600 comprises selected user modules 610, and user module parameters 620. In response to selecting a user module (e.g., user module 615) of the selected user modules 610, parameters for the selected user module are presented in user module parameters 620. User module parameters 620 comprises a plurality of parameters, including parameter 625 and corresponding field 630. In response to selecting parameter 625, an external design application is accessed.

[0054] FIG. 7 is an exemplary screen shot of GUI 700 comprising microcontroller design application 605 and external design application 705 in accordance with one embodiment of the present invention. In the present embodiment, external design application 705 is a spreadsheet application. It should be appreciated that external design application 705 can be any application used for calculating data, and is not intended to be limited to the present embodiment. Using external design application 705, parameterized data 710 is calculated. In response to a command (e.g., exiting external design application 705), parameterized data 710 is automatically loaded into microcontroller design application 605. In one embodiment, where external design application 705 was accessed in response to the selection of parameter 625 of FIG. 6, parameterized data 710 is automatically loaded into field 630 of microcontroller design application 605.

[0055] FIG. 8 is a flowchart illustrating steps in a process 800 for parameterizing a user module in accordance with one embodiment of the present invention. In one embodiment, process 800 is carried out by processors and electrical components under the control of computer readable and computer executable instructions. Although specific steps are disclosed in process 800, such steps are exemplary. That is, the embodiments of the present invention are well suited to performing various other steps or variations of the steps recited in FIG. 8.

[0056] At step 810 of process 800, a first design application corresponding to a parameter of a user module is accessed in response to a selection, wherein a user module is a pre-configured electronic design to be implemented on a microcontroller. In one embodiment, the first design application is an external design application for assisting in deriving parameterized data. In one embodiment, the first design application is accessed in response to selecting the parameter within a graphical interface of a second design application. In one embodiment, the second design application is a microcontroller design application for programming a microcontroller.

[0057] At step 820, the parameter is adjusted within the first design application to derive parameterized data. In one embodiment, the first design application is an external design application for assisting in deriving parameterized data. It should be appreciated that the design application may be any computer application used for calculating data. In one embodiment, the design application is a spreadsheet application.

[0058] At step 830, the parameterized data automatically loading said into a second design application in response to a command. In one embodiment, the second design application is a microcontroller design application for programming a microcontroller. In one embodiment, the command is closing the first design application. In another embodiment, the command is accessing a transfer control of a graphical interface of the first design application. In one embodiment, the parameterized data is loaded into a parameter field of a graphical interface of the second design application.

[0059] The preferred embodiment of the present invention, a method for parameterizing a user module, is thus described. While the present invention has been described in particular embodiments, it should be appreciated that the present invention should not be construed as limited by such embodiments, but rather construed according to the below claims.