PSoC™ Creator & Designer Forum Discussions

One of the more powerful aspects of PSoC 3 and PSoC 5 is the ability to use components that encapsulate both hardware and software functionality.  Cypress provides a large library of the most common components that you might need (I2C, UART, DAC), but there is no end to the possible components that PSoC 3 and PSoC 5 can support.  The Creator platform allows you to develop and use your own components using the same methodology as Cypress engineers.

There are 3 levels of components that a user might want to develop:

    
1. Schematic Component
    
2. Verilog Component
    
3. Datapath Component
   

Each level gets progressively more involved and more powerful.  A schematic based component provides a hierarchical schematic capability.  Here you can combine any of the components in the current library and also encapsulate the APIs that go with that combination.  With a Verilog based component you have the ability to pull in more complex unique digital content and take direct advantage of the PLDs built into PSoC 3 and 5.  The capability to do either Schematic or Verilog based components is in Creator today.  The third level, datapath based components, adds to a Verilog component the usage of the datapath resources in PSoC 3 and 5.  With datapaths you can create denser designs and more flexibily communicate between your hardware component and the CPU. 

In order to get you started on the right track, several training classes are developed that include:

    
• Video
    
• Slides
    
• Example Projects
   

They are all posted on the Cypress website under the Design Support tab, then Technical Training, then On-Demand Training, or you can skip directly there with the following links:

    
• PSoC Creator 110: Schematic Components 
    
• PSoC Creator 111: Component Parameters 
    
• PSoC Creator 112: Introduction to Component API Generation 
    
• PSoC Creator 113: PLD Based Verilog Components
   

This blog post tells you how to observe memory locations in the debugger watch window. This is useful if you want to group together and view separate memory locations that are linked by functionality such as DAC configuration, DAC routing and DAC trim.

To observe memory in the XDATA space, use the following in the watch window: 

*((char*)0x01yyy)

Where YYYY is a 2 byte address. This limits the addressable range for XDATA to 64KB. The char designator restricts it to a single byte, which for most debugging purposes is sufficient.

*Note: There are no spaces in the name.

Other observable memory locations:

The address spaces are limited based on address type through the watch window (Keil limit), and everything must be addressed via the 24 bit address.

XDATA: 0x01YYYY    64k limit

DATA:  0x0000YY    128 byte limit

CODE:  0xFFYYYY    64k limit

PDATA: 0xFE00YY    256 byte limit

Other types: Char is not the only allowable type. For larger values (16 and 32 bit) you can also use int and long:

*((int*)0x01YYYY)

*((long*)0x01YYYY)

Be aware though, Keil is a big endian compiler, so it will interpret memory differently than if you read it out of the memory window. For example:

In the memory map:

0x7000   0x7001   0x7002    0x7003

FE           00            00             1F

The result of the watch window:

Watch window expressions:

You can also create interesting expressions in the watch window:

In the memory map:
0x4690    0x4691
77        02

(int)(*((char*)0x014690)+(*((char*)0x014691)<<8))

This generates the following value -> 0x0277

   
For PSoC 5 (GCC), there are no memory restrictions for PSoC 5 so the entire register space can be accessed in the debugger.

The same techniques apply for PSoC 5 when setting up watch variables for memory locations, although the compiler is little endian oriented, so the int and long values will look different from PSoC 3 to PSoC 5 for the same value:

In the memory map:
0x7000    0x7001    0x7002     0x7003
FE        00        00         07

The result of the watch window:

 Quick Reference (PSoC 3):

XDATA: *((char*)0x01YYYY)

*Limited to 64 KB, no spaces in name

CODE: *((char*)0xFFYYYY)

*Limited to 64 KB, no spaces in name

DATA: *((char*)0x0000YY)

*Limited to 128 B, no spaces in name


Quick Reference (PSoC 5):

ALL MEMORY: *((char*)0xYYYYYYYY)


* no spaces in name

PSoC®3 and PSoC®5 devices feature a Direct Memory Access (DMA) engine, which can used for data transfer between on-chip elements without any CPU intervention. The DMA engine is part of a high performance bus known as the peripheral hub (PHUB). The PHUB is a programmable and configurable central bus backbone within PSoC3/PSoC5 devices that ties the various on-chip system elements together. It consists of multiple spokes; each spoke is connected to one or more peripheral blocks.

The DMA with the help of Transaction Descriptors (TD) can move data from a source to destination at very high speeds. The TDs can be chained together to perform complex data transfers. The following diagram illustrates a simple data transfer using DMA.

The key features of PSoC® 3 and PSoC® 5 DMA are:

    
• 24 DMA channels
    
• Each channel has one or more Transaction Descriptors (TDs) to configure channel behavior. Up to 128 total TDs can be defined
    
• TDs can be dynamically updated
    
• Eight levels of priority per channel
    
• Any digitally routable signal, the CPU, or another DMA channel, can trigger a transaction
    
• Each channel can generate up to two interrupts per transfer
    
• Transactions can be stalled or canceled
    
• Supports transaction size of infinite or 1 to 64k bytes
    
• TDs may be nested and/or chained for complex transactions
   

Please refer AN52705 - PSoC® 3 and PSoC 5 - Getting Started with DMA for information on different ways to configure the DMA channel and TD to perform data transfers. The application note also has example projects and a brief video.