Circuit Cellar - Digital Library

To help get a feel for the capabilities of CY8C2xxx devices, you need to take a look at the design tools available for the CY8C2xxx family of PSoC microcontrollers. The PSoC Designer is a PC-based integrated development environment (IDE) configured to take you from project design through application development including device configuration, compiling, assembling, debugging, and device programming. All of this is handled in three steps. Here’s a look at each.

Things start off at a gentle pace with the creation of a project. First, you’re asked for a project name and directory. Then, you must make a selection from the parts catalog of the device that you will use for your project. At this point, you must also indicate whether you will be designing the code in C (available for less than $150) or assembly. The choice of which language to use will determine how the main application code will be generated as you add modules.

Next, you get into the nitty-gritty. On the Config pull-down menu, you’ll see the three parts of the device editor. As you can see in Photo 1, the left-hand frame of the selection screen has a list of module types. A click on any of these will display all of the pre-configured modules available using the digital or analog PSoC blocks.

Photos 1 and 2 display various amplifiers. I clicked on the instrumentation amplifier (INSAMP), as you can see in the top frame of Photo 1. The middle frame shows a block diagram of the module chosen and the amount of resources used both by this module and in the total design thus far. The lower frame displays a data sheet of the module. The datasheet also shows the code, which will be added to your project when and if the module is added to the project.

(Click here to enlarge)

Photo 1—In the selection screen of the device editor, you get to choose preconfigured module types. Each preconfigured module comes complete with its own datasheet.

You can choose all of the modules for your project before proceeding or go through the placement of each as they are chosen. Photo 2 shows the INSAMP being placed after choosing the placement screen of the device editor. The hatched area in the large frame highlights the blocks into which the module can be placed.

(Click here to enlarge)

Photo 2—Placement of a selected module is the next task. The design editor shows legal placement locations.

Alternate placements are cycled through using the Next Allowed Placement command. Remember to pay attention to the possible interconnection because they differ depending on the placement of the module. After you’ve chosen the position of the module, stick the module down using the Place command.

You will see the global resources in the upper left frame. These can be set from the drop-down menu that appears when the entry at the right of the resource is clicked on. For instance, the 24V1 and 24V2 can be set to values that will be needed by various modules you select (i.e., data rate generator). The configurable parameters of the chosen module are listed in the user module parameter frame. The parameters can be set the same way as the global resources or by clicking on the appropriate module labels in the large placement frame. You will notice that some of the module parameters include the I/O interconnections.

Now, it’s time to configure the I/O pins. Choosing Pinout from the Config drop-down menu will display a screen similar to Photo 3. Even though you’ve previously configured modules with specific I/O pins, you must again configure the interconnection at the I/O pins. Note that both ends of all user connections must be handled separately. Configuring the I/O pins can be done either on the pinout diagram in the center frame or in the pin list in the lower left frame.

(Click here to enlarge)

Photo 3—The device editor’s final step is the physical connection of I/O signals to the pins of the device.

One of the modules I placed in this project was a low-pass filter (LPF). Now, design of a switched capacitor filter is not something you can whip off in an afternoon. There are endless decisions to make, such as filter type, clock frequency, capacitor values, and so on. Cypress included filter spreadsheets for LPF and BPF, which simplify the design of a filter and spit out appropriate values to transfer to the configuration parameters.

Finally, the PSoC designer can take your configured design and generate application files for each of the modules you chose. This takes place when you enter the Generate Application command. But be aware that like most Windows applications, PSoC designer commands can be initiated in a number of ways—shortcut keys, drop-down menu, or icon on a tool bar.

Let’s go on to the third step in the PSoC design process and look at the files created by the generator. At this point, you’ve indicated which PSoC microcontroller you wish to use as well as what modules are necessary to make up your design. You have interconnected the modules and the I/O pins of the device. The Generate Application command has created a number of files based on your previous selections. Photo 4 shows a list of the source, library source, and library header files my project generated.

(Click here to enlarge)

Photo 4—Here’s a list of the files created by the Generate Application command for this project.

There are two files, boot.asm and main.asm, in the source folder. The former contains the interrupt table (filled with jumps to the interrupt routines needed by your module selections), sleep timer interrupt service routine supported through interrupt 15, initialization of the oscillator register, C support code if needed, and a jump to the main.asm file. This boot.asm file is regenerated from a template file anytime a Generate Application command is executed to assure it reflects any changes to modules. main.asm, on the other hand, contains nothing at this time. This is where your actual application code will go when you get around to writing it. I’ll come back to this later on.

Every module placed in your project will produce a module source code file and, if necessary, a module interrupt source code file in the library source folder. The module source code file contains the routines to initialize, enable, disable, and otherwise make use of the module. The module interrupt source code file contains the interrupt service routine necessary for that module, which requires interrupt action.

In support of the source code files, the library header folder contains include files for each module placed in your project and header files used exclusively for C. The include file holds register declarations for use with the code of the associated module.

If you were to look into the boot.asm file, you would see an LCALL to an external routine, known as LoadConfigInit. This routine is in one of the remaining files in the library source folder, PSoCConfig.asm. The PSoCConfig.asm library folder uses the PSoCCConfigTBL.asm file to configure the PSoC modules based on their configuration for your particular project.

The final two files in the library header folder are ftb_test_one_ GlobalParams.inc and m8c.inc (except the ftb_test_oneAPI.h file that’s used exclusively with C). As the name implies, the ftp_test_one_ GlobalParams.inc file holds those global parameters set while you configure the device. The m8c.inc file contains all of the specific CY8C2xxx family system declarations and a set of predefined macros.

That’s a whole lot of code and we haven’t even written a byte of application yet. Essentially, all of the necessary code to use the placed modules is now ready for use. All you need to do to make use of the modules is place the appropriate calls to initialize the modules and use their functions in your application. Use the main.asm file for this. Because I configured the global and module parameters in the previous step, the boot.asm file automatically initializes those registers and the only task I have to do is initialize the modules. Now that I’ve covered the groundwork, it’s time to move onto the application.

PREVIOUS • NEXT