PSoC Processors and Infineon

I like PSoC processors, and I cannot lie. They were extremely innovative and the development tools are like nothing else in the industry. In specific, these are "system on a chip" chips that actually live up to their name: they have a CPU (either an 8051 variant or some flavour of ARM processor... the PSoC 4200 that I have been using often has a 48MHz ARM Cortex-M0+ CPU), a fairly complete set of often-used peripherals (e.g. Serial Communications Blocks that can be a UART, I2C, SPI, etc.), but then they have programmable and reconfigurable digital and analog circuitry! On the analog side, it comes with things like op-amps, comparators, multiple-input scanning ADCs, and DACs (some specialized current mode ones for use with capacitive touch sensing, another specialty of the PSoC processors), and the PSoC 1 had support for switched capacitor technologies (used for signal filters, etc.). But it was routable on the chip and could be connected to almost any pin (there were "associated" pins that used less resources, but it wasn't cast in stone that they had to be used)! For the digital side of things, they created something called Universal Digital Blocks (UDBs). I'm not going to lie... UDBs are hard to use and it takes a lot of work to wrap your brain around them... but, once (if?) you figure out how to use them... wow! Like seriously wow, these things are game changing! Where in most designs I would need to add all sorts of circuitry to a board to customize it to the application I want to use it for, with UDBs I could implement most smallish designs right on the PSoC chip itself without having to use any other chips on the printed circuit board to support the application. I can't emphasize too hard how spectacular this capability is. Without going into detail (I could go on and on, but won't), the UDBs each contain two PLDs (12C4 with 8 product terms (PTs)), a swiss army knife control and status block (so many different functions), all the digital and clock and reset programmable routing needed, and an 8-bit "datapath processor" (DP) that can be chained to adjacent DPs to form larger data-word processors (e.g. 32-bit). The microcode of the DP processor is normally controlled by the PLD logic... you can literally build your own custom processor out of programmable logic on the PSoC itself from UDBs. The DP contains an ALU, a register set, input and output FIFOs (to communicate with the CPU and optional DMA on some chips), and an 8 instruction microcode set (surprisingly powerful). UDBs can also be used to build things like " I2C, UART, SPI, SDI12 , OneWire, (Capture) Timer block, CAN, Manchester decoder, Quadrature decoder, Counter block, SmartIO, LFSR / CRC functionality, ShiftReg glitch filtering, State Machine functionality, and random number generation". Powerful, but hard to work with because of their configurability and layer upon layer of functionality. The PSoC chips contain zero to dozens of these UDBs, and the 4200 that I've gravitated to has 4.

Cypress, who made the PSoC family, was bought by Infineon, and I don't know what I'm seeing yet. Even before then, Cypress seemed to be moving away from the "system on chip" concept, that made them stand out in the crowded and competitive microcontroller field, towards more ultra high volume applications with hardcoded functionality on their processors rather than the configurable logic and analog capabilities that made PSoC different. In one of the forums, someone [Rolf_Nooteboom] said (before the Infineon buyout) "I am still worried Cypress is phasing out UDBs and that would be worst thing what could happen to PSoC imho (it would then be like any other microcontroller and lose a lot of the functionality for why one would choose PSoC over an other MCU)", to which someone [Len_CONSULTRON] answered "According to a Field rep for Cypress I spoke to, this appears to be the direction. It is my understanding that the reasoning behind this direction is that few designers using their product make use of all the UDB and routable analog features". By the very nature of having a reconfigurable digital and analog feature set, the functionality built onto the chip will always be a superset of what is used in any particular application (although I've come close to using every part of a PSoC in one application). This "wastage" means we're paying for circuitry on the chip that is not used. The cost/benefit equation is such that the hope is that extra cost is more than offset by speeding development (saving money on R&D directly, but also by getting to market faster which can easily be a 50% increase in profits) and reducing parts count on the printed circuit board (fewer components means less costly boards and lower board R&D costs, higher reliability, and lower inventory/stock requirements which can also be huge [especially in times of supply chain disruptions like we're seeing now]). This value proposition doesn't break down until very high volumes are achieved with product sales (like hundreds of thousands to millions of units of one design). The margins get slimmer for chip manufacturers as volumes increase, but so does the challenge of having to manage a complex product portfolio where a few models get chosen for a few high volume products and the rest end up in medium to low volume applications. Here we see another sickness caused by the MBA/CEO class: they're lazy and stupid and are obsessed with specific metrics that translate into short term success (where they fill their pockets) but not into long term company stability (if the horses they were betting on fail, there's nothing to fall back on... saw it at Nortel before it went bust... it's the same sort of people every time: they ditch the product lines growing at 5% a year in favour of the latest bubble growing at 100% per year, and when the bubble collapses, so does the whole company... but I digress).

Anyway, there are two reasons why I'm making this post. The first is that I'm working on a design that has ended up needing quite a bit of UDB functionality, and the second is that I commented on the above forum discussion with the following, which I wanted to preserve for myself (in case Infineon nukes the community forums or specific threads... although they do seem to be enhancing them rather than shutting them down, although there was a definite period of chaos that was quite concerning).

UDBs and analog routing are the reason why I've stuck with PSoC even though it's a more expensive chip in some cases: the per-unit cost is made up for by the integration, ease of use, and flexibility it offers me as a designer (not to mention the uniqueness of PSoC Creator!). The patents look like they're in place (depending on which one) for the next decade or so. If Infineon/Cypress does phase out UDBs, I hope someone licenses those patents to use them in their own chips (or that they sell at least some of the "before PSoC 6" families to another company). If not, in 2032 (presuming they're not abandoned earlier), someone could integrate them, or an upgraded version of them (I can think of some changes that would be great), into RISC-V based chips perhaps or as dedicated "configurable/programmable datapath" chips (in either case, the clock rates could probably be jacked up significantly).

The two main relevant patents I could find are:

Universal digital block with integrated arithmetic logic unit

Universal digital block interconnection and channel routing

I'd love to have the money to make an offer to buy the PSoC line (or at least some sub-technologies like the UDB), but I live from paycheque to paycheque (and not always reliably) like many people. So file the thought under "if wishes were fishes".

Anyway, more of a "note to self" than anything.

On an unrelated note, I managed to finish "Season 1" of "The Passionate Friar on YouTube" (Episode 26). It ends with a bang and not a whimper (intensity 11 out of 10), and I am doing some "housekeeping" before starting on "Season 2" (hopefully some time in the next 8 weeks).

Watch on YouTube

PWM Audio from Flash with PSoC 4

Copying another post I made on the Cypress/Infineon user forum here so I have it myself.

I have written an article on my blog on the process I followed to get an audio clip into a PSoC 4200 MCU (I used the CY8CKIT-049-42xx PSoC 4 Prototyping Kit), and play it back using a TCPWM component. I start with a 44.1kHz 16-bit PCM stereo audio recording (CD quality), and go step-by-step on how to process the audio, reduce the dynamic range (bits per sample) and the sampling rate to reduce the number of bits needed for the clip, how to program the samples into flash so they're accessible to an interrupt handler, and how to use a PWM technique to generate the analog output of the audio. I provide instructions on what is needed with respect to filtering and amplification, but don't go into detail (that's for another post another time probably). I did use the two on-chip op-amps with a few resistors and capacitors to implement a 4th order Chebychev filter and then used an off-the-shelf audio amplifier to drive a speaker. Other than PSoC Creator, all of the software I used is open source or are simple little C programs I wrote myself (and provide instructions on how to duplicate). Spoiler alert: I got about 1.4 seconds of 11-bit 11.025kHz linear PCM audio into the chip (which takes about two thirds of the flash memory). If that's not enough, there are some serial (SPI) flash memories that can hold about 9 minutes at that rate/sample depth (<$4 in qty. 1). I implemented this on a PSoC 4200, but the technique is quite general (and can be used with MCUs that have proper DACs as well).

Here's the link: Stuffing an audio file into a tiny processor chip

In response, someone [odissey1] asked me if I could post the project code, so...

Project file or it never happened, eh? Fair enough. Please find attached.

1kHz_PWM_Audio_Demo_v1.0 project file is here!

The archive contains a project targeted at the CY8CKIT-049-42xx PSoC 4200 prototyping kit (including it's use of the bootloader component); but the schematic, TCPWM configuration, and source code should be easily adaptable to any PSoC target with a TCPWM component (the C code is mostly generic with a few PSoC specific commands to set things up). The CY8CKIT-049-42xx bootloader files are there too so it should compile right out of the .zip file without reconfiguration if you have one lying around. I have also included a simple audio data file ("sine_1kHz.dat") that has a 1kHz sine wave sampled in it that the code just repeats over and over again (and outputs on P3.0 for this project).

Here's a bad photo taken with my terrible phone using a sad oscilloscope of the PWM data output on a pin (you can see the density of the PWM signal changing).



Here's another bad photo taken with my terrible phone using a sad oscilloscope of the output from the not so great filter circuit using the PSoC 4200's on-chip op-amps. Note that there is a fair amount of distortion in the sine wave... the filter really isn't that good, but it's still good enough for what I needed it for. Also note that the 'scope is set to 2V/div and 0.5ms/div, and that the ground potential is the graticule below the waveform, so you can see that the centre of the sine wave (the common mode voltage) is indeed at about 1/2 of the supply voltage of the PSoC 4200 (5V... powered off the USB interface of the CY8CKIT-049-42xx). The filter could be made much better if the digital PWM signal were run through a divider first and if I were a little more careful with the component selection (but the lack of a SPICE model for the on-chip op-amps makes doing a great job a little harder).



Hopefully this proves useful.

As an aside, this project file is intended for use with the PSoC_Creator Integrated Development Environment. As a write this, it is available for free download (it was always free) at: https://www.infineon.com/cms/en/design-support/tools/sdk/psoc-software/psoc-creator/

They then asked (reasonably enough), "Do you have any idea why the sine output looks asymmetric? Is this the effect of the Chebyshev filter or intended PCM signal?"

And my answer:

There are a bunch of reasons why the "sine" is not so sinusoidal, where to start? The filter components I used were built on a little breadboard PCB plugged onto connectors I put on the CY8CKIT-049-42xx and the circuit has no particularly effective ground, so there are all kinds of basic signal integrity problems. The sine wave only has 14 samples (that I kind of randomly chose... the samples are not symmetric and the knee might simply be from looping), so it's going to be pretty choppy no matter what (it would be that way even with a proper DAC), but the problem is compounded by using a PWM and asking a sub-optimal filter circuit to do a lot of heavy lifting in filtering out that digital signal. The filter circuit itself doesn't have the exact component values I wanted because I didn't have those values on hand, so it's approximate in its performance that way too. If I wasn't swinging nearly 5V peak-to-peak I think that would help a lot as well. The op-amps on the PSoC 4200 kind of suck in terms of their performance, and using a filter built with good quality external components would give a much better result (my early attempts were nightmarish, so the distortion here is actually a huge step forward from where I started). Lastly, the lack of a SPICE model for the on-chip op-amps meant that I couldn't really tune the filter circuit nicely to the op-amp performance and just kind of did things empiirically. I know I could do better even using the on-chip op-amps, but that's a project for another day. Ultimately, I was completely successful in what I was trying to do, which was to only use a CY8CKIT-049-42xx that I had (with a few external passive components) to drive an amplifier and little speaker with a short audio clip. In the context that I was using it, and with the audio clip I had, the sound coming out was entirely acceptable (even with whatever distortion it would have).

After looking at the code for the project I provided they said, "The code is certainly not trivial. My guess that most of the complexity comes from extracting the 11-bit audio from the 8-bit storage array. Is there any audio software capable of such packing or you had to post-process PCM data?"

So...

I just used open source software to get the data into a format where I could pack the 11-bit samples with my own code (into 8-bit bytes). As I wrote in my "article", I did it in two stages: the first little program took it from 16-bit signed PCM (in a RAW file format, that had already had its dynamic range squashed to 11-bits) and wrote it out to disk as a 11-bit samples packed together as a data stream (written out 8-bits at a time to disk), then another little program to convert the byte-stream into comma-separated ASCII for loading into the C compiler uint8_t array when it compiled.

I didn't post the code for the audio conversion at the time, but here it is in all its (lack of) glory for posterity. Very simple code, but tricky to get right.

First, compile "encode_raw.c" and "enc2dat.c" (filenames are links to C code files).

Follow the instructions in the article I wrote to get a RAW audio file (the instructions are relatively clear in my opinion). Then run the encode_raw program:

encode_raw filename.raw

This will generate a binary file filename.enc that contains the packed 11-bit PCM audio data. The run the enc2dat program:

enc2dat filename.enc

This will generate a text file filename.dat that contains the data for including in the final project code like so:

const uint8_t audio_data [] = {
#include filename.dat" // Put comma separated values audio samples file here
};

This initializes the uint8_t array with the audio data that the program's code will need to pull out as an 11-bit PCM stream (from the array of 8-bit values). I thought this was a fairly clever way of doing it as it allowed this arbitrary audio data to be programmed into Flash along with the program code. If more data space was needed (the chip I was using only had 32K of Flash for programs and data), then an externally connected Flash chip could be used.

And for anyone who scrolled by, here's a non-technobabble gift. Show 25 from Season 1... Note: this episode is Not Safe For Work (NSFW) and full of various naughty bits (every 25th show will be a collection of the naughtier songs and videos I have run across so they're all in one place and are easier to avoid and/or focus on).

Watch on YouTube