Skip navigation
Home > All Places > PSoC 6 MCU Community > Blog > 2017 > April
2017

Hello!

 

Thought I've give an introduction to PSoC 6's Digital to Analog Converter.

As a key component of the programmable analog system the PSoC 6 includes a 12-bit Continuous Time Digital to Analog Converter (CTDAC) providing a precision voltage output. The CTDAC can be used in applications that require voltage references, bias, or waveform output. When optionally coupled with the CTBm block the CTDAC provides even greater flexibility. Some of the key features are:

  • Up to 500 kHz output settling and update rate that can be synchronized with a hardware trigger
  • Output voltage data may be provided by firmware or DMA with either immediate update or buffered synchronization. DMA based data provides an efficient method to generate arbitrary waveforms.
  • CTDAC output remains active in Deep Sleep power mode allowing external circuitry to remain biased or internal comparators to retain reference thresholds.
  • Output voltage is relative to the configured CTDAC reference voltage. Reference voltage sources include VDDA, internal chip references, or external references routed to a pin.
  • CTBm OpAmps may optionally be used to buffer the CTDAC output to drive low impedance external loads or to buffer a high impedance external reference voltage.

 

Feel free to leave comments and ask questions, we appreciate the feedback!

Hi everyone!

 

Thought I'd introduce PSoC 6's Direct Memory Access (DMA) feature. The PSoC 6 device has two DMA hardware blocks and each DMA block has to 16 DMA channels. Each DMA channel can be configured to transfer data from memory to memory, peripheral to memory, memory to peripheral or peripheral to peripheral, with no CPU involvement.

 

Each DMA channel’s transfer is configured by a DMA descriptor. The DMA channel only holds a pointer to the descriptor structure in memory (RAM or Flash). Thus the number of descriptors you can associated with a channel, is limited by the SRAM/FLASH memory available to hold them.

 

The DMA descriptor has a next descriptor field that lets the user chain descriptors. Thus each channel could associate with a descriptor in memory but that descriptor could be the first one in a chain of many descriptors which are also in memory. This is will let the user set up a series of distinct and dissimilar transfer operations.

 

Each descriptor is built to be configured to work in any of these modes

  • A single data transfer from a source address to a destination address.
  • 1D transfer: A loop of data transfers from source address to destination addresses. You can optionally have the source or the destination or both addresses incrementing with each transfer. The increment value itself can also be configured.
  • 2 D transfer: A nested loop of data transfers. Here the descriptor can be set up to do a loop of 1D transfer.

The input triggers are independently configured to trigger single data transfers or entire 1D loop transfer or an entire 2D loop transfer.

 

There is a very elaborate trigger routing matrix present in the PSoC 6 that allows for the different peripherals in the PSoC 6 device to generate trigger signal for the DMA channels. In addition the DMA channels themselves have trigger outputs that can be used to trigger other DMA channels.

 

Feel free to leave comments or ask questions!

JimT_21

IDEs for PSoC 6 Development

Posted by JimT_21 Apr 18, 2017

Here’s the good news. You can use just about any IDE to create firmware for PSoC 6 devices. How easy or hard it will be may vary, but the choice is yours. Read Software Development Models for PSoC 6 to learn more. I discuss PSoC Creator relative to PSoC 6 and the Peripheral Driver Library (PDL) in that article. The PDL is designed to be used with any IDE.

 

Let me group third-party IDEs into two categories: those that are “supported” and those that aren’t. You can use any IDE effectively, even "unsupported" IDEs.

 

Supported IDEs

The list of supported IDEs is subject to change, but as I write this the plans include:

  • IAR Embedded Workbench
  • Keil µVision
  • Atollic TrueStudio
  • iSystem WinIDEA
  • Command-line tools (make file)

 

For a supported IDE, you get some extra goodies to make life easier. These include

  • A template project for each core
  • Project build settings set for the particular device
  • IDE-specific files like startup code, linker files, or a flash loader
  • A defined export/import process for generated files

 

The export/import process varies significantly per IDE, so once you get the PSoC 6 platform you’ll want to read the PSoC Creator help files on how to import the code. You are not required to use the export/import process, you can always just add files from the Generated_Sources folder to your IDE’s project file. And that takes us to the "other" IDEs.

 

Other IDEs

So what if your preferred IDE isn’t on the “supported” list? Well, there is no formal export/import process. You manually add the PSoC Creator generated files to your IDE's project. You don’t have a template project, so you have to set up your own project completely. But it's your IDE, and you're familiar with what options are required and how to set them. You may need to develop some IDE-specific code, like a linker command file. However, you can examine those provided with the PDL to see how it’s done.

 

In all cases, whether it is a “supported” IDE or not, you can use PSoC Creator generated code if you want, or develop entirely without PSoC Creator. PSoC 6 Components and PDL Drivers talks a little bit about the trade-offs. I am personally very much a believer in code generation tools. Your mileage may vary.

 

IDEs are highly variable. Some have compilers that do a better job optimizing code. Some support dual-core debugging, and some do not. It’s quite likely that you have your favorite. I learned long ago to not argue over matters of taste or preference, like which IDE is best. I have a suspicion that in my near future I'll be writing some formal detailed collateral on how to use PSoC Creator generated code in your IDE for PSoC 6 development.I'd like to hear from you on whether you think that's a worthwhile bit of information.

 

What really matters is: can you choose the IDE you want? The answer to that is simple. Yes.

Hello!

 

Thought I'd introduce the Serial Communication Blocks (SCBs) in the PSoC 6 architecture. Our first PSoC 6 lineup, the PSoC 63 Connectivity lineup has nine SCBs. Each SCB can be configured for either I2C, SPI, or UART. The mode of operation of the SCB can be changed during run time. The PSoC 6 SCBs have two 128 byte deep FIFOs, one for transmit and one for receive. These FIFOs can be written/read by both the CPU and DMA. One of the SCBs out of the nine in PSoC 6 is designed to wake the device up from deep-sleep modes of operation, this SCB is called the deep-sleep SCB. This wakeup can occur on I2C address match, or SPI slave select assertion.

 

Feel free to leave comments or ask questions, we appreciate the feedback!

Hi everyone!

 

Thought I'd give an update on the PSoC 6 Inter-Processor Communication (IPC) feature for the dual-core ARM Cortex architecture.

The PSoC 6 is a multi-core architecture with two processors CM0+ and CM4 on the same die, with all the memory and peripherals available for use by both the cores. This adds a lot of value to the user who wants to set up a system where the processing load is shared by the two cores. To make such a design possible the two cores must communicate with each other. There are different ways that can happen.

 

At the instruction-set level, you can use the send event instruction (SEV). This generates an interrupt event for each core in a multi-core system. Using the SEV gives you one channel of communication with another core, through the event signal. This means all communication would need to be through this one event. You need to set up a higher layer of code to deal with data transfer and multiplexing of different events.

 

PSoC 6 hardware implements a more capable solution. In addition to the SEV instruction, PSoC 6 has 16 hardware Inter-Processor Communication (IPC) channels. Each channel can be configured to be an exclusive communication medium between the two cores. Each IPC channel implements a hardware semaphore or mutex. You can use this to ensure exclusive access to shared resources. Each channel also has an associated 32-bit shared data register. You can use the register to pass a 32-bit value, or use it for a pointer to any data of arbitrary complexity.

 

In addition to the 16 IPC channels, PSoC 6 also provides 16 IPC interrupts. Each IPC interrupt can be used as event triggers from one core to another. This mechanism can be used in conjunction with an IPC channel to set up a messaging scheme with a notification event and acknowledgement.

 

The Peripheral Drive Library (PDL) implements an API to give you high-level access to the IPC hardware. The PDL implements a semaphore system which can be used to ensure exclusive access to shared resources or single bit flag communication between the two cores. The PDL uses a single IPC channel, but gives you the ability to set up an arbitrary number of semaphores on that channel (limited by available SRAM).

 

In addition, the PDL also provides communication pipe implementations for messaging between cores. Each processor has at least one “end point” structure. Messages are transferred between endpoints. The end point (among other things) has an array of “clients”. Each client has a client ID (the index into the client array and an associated callback function. ”. The messages sent to a specific endpoint can be addressed to a specific client at the end point. Thus each client can be handled differently when a message is sent to it. 

 

Feel free to leave comments and questions, we appreciate the feedback!

MichiyukiY_91

PSoC 6 Flash

Posted by MichiyukiY_91 Apr 11, 2017

Hello,

 

Thought I'd give an introduction on the flash in the PSoC 6 architecture.

Our first PSoC 6 device has up to 1MB of flash. A flash controller does 128-bit wide flash reads, to reduce power. PSoC 6 flash has read-while-write (RWW) capability, which allows updating the flash while executing from it. This is useful for applications that update flash, such as bootloaders and data loggers. The CPUs in PSoC 6 each have an 8KB 4-way set-associative flash cache. This reduces the number of flash accesses for CPU instructions, which in turn increases CPU execution speed and reduces power. The CPU subsystem architecture incorporates multiple bus masters – the two CPU cores as well as two DMA controllers and a cryptography block (Crypto). Generally, all memory and peripherals are shared by all of the bus masters. Shared resources are accessed through standard ARM multi-layer bus arbitration. Exclusive accesses are supported by an inter-processor communication (IPC) block, which implements hardware semaphores and mutual exclusion (mutexes).

 

Feel free to leave comments and questions, we appreciate the feedback!

In this article I want to go a bit deeper into the difference between using a PSoC Creator component, and using the PDL directly. I talked about development models for PSoC 6 here. (You can find out what the PDL is here; and how it is designed, here.)

 

Most PSoC 6 peripherals have a corresponding PSoC Creator Component. You drag the Component into your design and configure it inside PSoC Creator. Based on your design and configuration, PSoC Creator generates the code required to configure the peripheral. It generates an API for that specific component. All of this is unchanged for PSoC 6 and the PDL.

PDL Component.png

Here's what's new. The PSoC 6 Component is built on top of the PDL.

 

In the past, the Component API was the only option. For PSoC 6, the Component API uses the PDL. PDL 3.0 is a separate entity. That means you have a choice. You can use the Component API, or you can use the PDL API directly. The PDL is designed to work with, or without, PSoC Creator.

 

Here’s an example. Your PSoC Creator design might include a PWM component, which you could name “MyPWM.” You would at some point write code modify the compare value in the PWM to change the duty cycle. Here’s the Component API code that sets the compare value for that Component.

APIDiff.png

 

Notice that the generated Component API calls the PDL API. Let’s start with the PDL API call. This function has three parameters. The first is the base hardware address for the peripheral. (Read PDL 3.0 - Designed for Flexibility to learn about base hardware addresses.) Because the PWM actually has multiple counters, you also specify which counter to use. And of course there is the actual compare value.

 

By contrast, the Component API call has only one simple parameter: the value. That’s because PSoC Creator “knows” which base hardware address to use, and which counter, based on the system design and pin assignments you set up in the tool.

 

These two APIs, Component and PDL, are fully compatible. You can mix and match as you see fit. The Component API is often simpler, but adds a level of indirection (a function call to make a function call). In many cases the overhead is trivial or non-existent, and might even be optimized away. In other cases it might be more significant.

 

The table summarizes some of the key differences.

KeyDiffs.png

 

There is absolutely no requirement to use PSoC Creator. If you do not use PSoC Creator, then you make PDL API function calls directly, providing all parameters. You get the Component API whenever you use PSoC Creator to generate code. You can use it even if you import the code into your preferred IDE.

 

One neat thing about the Component API in the generated code is that it is often just a wrapper on top of the PDL API. Even if you don’t want to use PSoC Creator as a production tool, you can use it as a learning tool. You will be able to explore the generated code to see how it makes PDL function calls, and learn how to use the PDL effectively.

MichiyukiY_91

PSoC 6 SAR ADC

Posted by MichiyukiY_91 Apr 10, 2017

Hello,

 

Thought I'd give an introduction for the ADC available on the PSoC 6 architecture. The ADC is a Successive Approximation (SAR) type with 12 bits of resolution. It is an updated and improved version of the SAR ADC found on PSoC 4 devices. The key features are:

  • Up to 1 million samples per second at a fixed 12 bits of resolution
  • The programmable analog features of PSoC 6 allow almost every pin to be used as an ADC input. The GPIO pin analog signals can be routed to the ADC through the AMUX busses under software control.
  • A built in 8 channel hardware sequencer can also automatically scan each channel and stores the results for later CPU processing. An upper and lower limit is also able to be compared with each scan and generate an interrupt if an out of range condition is detected.
  • Sequencer channels also support hardware averaging and accumulation of up to 256 samples for lower noise or higher resolution and the resulting 16-bit results.
  • Sequencer allows a software controlled 9th channel to be injected between scans for less frequent measurements. The 9th channel can connect to almost any pin through the AMUX busses. 
  • The ADC provides dedicated connections to the integrated CTBm OpAmps and DAC allowing advanced analog signal effects to be generated and scanned.
  • Supports single ended and differential conversions. The 8 channel sequencer supports up to 4 differential signals.
  • Analog reference is selectable to Vdd, Vdd/2, 1.024V, or an external reference provided to a GPIO pin.
  • Able to read the on chip temperature sensor and supply voltages to allow temperature and voltage based adjustments.
  • Supports one shot or continuous hardware scan triggering and a variety of conversion complete signals that can be used with interrupts, DMA, or custom logic.
  • The ADC control signals and data can be routed to the programmable digital logic (UDBs) to create custom scan functionality, and unique automatic processing of conversion data in hardware.

 

Feel free to leave comments or questions, we appreciate the feedback!